През юли работната група IETF (Internet Engineering Task Force) се опита да измисли начин настоящиятинтернет протокол IPv4 да говори с бъдещия IPv6. Ако това стане възможно, то тогава няма да се налага всички IP адреси да бъдат обновени наведнъж.
С цел процесът да напредне преди следващата среща на IETF през ноември в Минеаполис, миналата седмица се състоя двудневна такава в Монреал, съобщи arstechnica.com. Основният проблем, с който се сблъсква IETF, въпреки че двата протокола са от едно семейство, е съществената разлика между тях – IPv4 използва 32-битови адреси, докато IPv6 използва 128-битови. Как тогава да се накара система, състояща се само от IPv4 адреси, да комуникира със система от IPv6 адреси?
Най-простият начин е чрез превод на съобщенията. Още преди години IETF стандартизира технология за това, която носи името SIIT (Stateless IP and ICMP Translation). Но тук се появява и един голям проблем – преводът се извършва едно към едно. В бъдеще обаче няма да има достатъчно IPv4 адреси, за да се дава собствен адрес на всяка система (затова именно се нуждаем от IPv6).
Ето защо, в посоката IPv6-to-IPv4 се налага множество системи да споделят един единствен IPv4 адрес. Това се постига сравнително лесно – използва се SIIT, а след това обикновен IPv4 NAT.
Спецификацията NAT-PT (Network Address Translation-Protocol Translation) използва тази техника заедно със система, която пресреща DNS заявки и генерира отговори с фалшиви IPv6 адреси с 32 бита за IPv4 дестинацията, закодирани в основните 32 бита на IPv6 адреса. Пакетите, изпращани към тези адреси, се насочват към транслатор, който след това използва SIIT и NAT, за да създаде IPv4 пакет, който се изпраща към първоначалната IPv4 дестинация. Връщащите се пакети се превеждат в противоположната посока.
Хубавото на системата NAT-PT е, че може просто да се сложи една кутия между IPv4 и IPv6 частите на дадена мрежа и всичко ще работи – или почти всичко. Протоколите, като FTP, VoIP или пиър-ту-пиър приложенията обаче ще се объркат, тъй като когато една IPv6 система каже на един IPv4 сървър или на един пиър своя IPv6 адрес, то сървърът или пиърът няма да разберат и/или няма да могат да използват IPv6 адреса. Поради това, IETF разкритикува остро DNS, като след това обяви, че NAT-PT няма вече да се препоръчва за масова употреба.
Сред по-добрите алтернативи на системата се нареждат NAT64, NAT6 и SNAP-PT, като всички те запълват в различни степени недостатъците на NAT-PT. И тъй като SIIT и NAT-PT са били определени в началото на десетилетието, IETF е хвърлила много труд по NAT, уточнявайки най-добрите практики за NAT устройства, както и начини за опериране на пиър-ту-пиър приложения чрез тях, използвайки техники с имена като ICE, STUN и TURN.
Повечето от тях могат да бъдат използвани за мрежи IPv6-to-IPv4 и за IPv6 пиър-ту-пиър приложения. Така изглежда, че някаква част от основния проблем в комуникацията между двата вида адреси може да се реши.
Съществува обаче и въпросът за възможността IPv4 клиенти да комуникират с IPv6 сървъри. Макар че преводът може да стане по почти същия начин, то тук се появява много сериозен проблем – не е възможно IPv6 дестинацията да се закодира в основните 128 бита на един 32-битов IPv4 адрес в един фалшив DNS отговор. Това породи и значителна дискусия в Монреал дали е нужно да се разреши проблемът в посоката на комуникация IPv4 клиент към IPv6 сървър така, както специалистите се опитват да го разрешат в обратната посока.
В Интернет има много сървъри само за IPv4, а освен това досега всеки, който използва IPv6, прави своя сървър достъпен и за IPv4. Но големите потребители, като например американските военни, казват, че за в бъдеще те ще имат нужда от разрешаване на проблема IPv4 клиент-към-IPv6 сървър, което и приключва дискусиите по въпроса.
Единственият въпрос, който остава, е дали да се създаде интегрирано решение и в двете посоки, или първо да се намери такова в посоката IPv6-to-IPv4, колкото се може по-бързо, а след това да се отдели повече време за обратната посока на комуникация.