On Wed, Feb 09, 2011 at 07:59:09AM +0200, Valentin Nechayev writes: VN> Tue, Feb 08, 2011 at 23:24:28, gul wrote about "Re: [uanog] Изя всё.": [...]
Но эти адреса должны включать в себя IPv4 как подмножество. Тогда действительно будет возможен переход со старого на новое. 64-битный адрес - это u_int64_t, одно слово на 64-битных архитектурах, один регистр. 128-битный IPv6 - это массив, с которым обращаться гораздо сложнее. Разница существенная.
VN> На сейчас это уже малосущественная разница. Ты можешь держать адрес VN> и как 128-битное целое, а если тебе этого не позволяет напрямую язык VN> (многие позволяют) - делаешь адекватную библиотеку. На C++ создание VN> типа данных [u]int128_t на основании имеющихся целых - задача для VN> школьника. На C чуть сложнее (будет путаное API), но не сложнее, чем VN> работать со всякими div_t или sockaddr_in. Тут я имел ввиду более не код, а выполнение. Делать производительные роутеры 64-битными - это нормально. А 128-битными (чтобы IP-адрес был одним словом и помещался в один регистр) - уже черезчур. А значит, роутерам (как PC, так и железным) придётся работать с IPv6-адресами как с массивом, это дольше. Программистам в любом случае правильнее работать с struct in_addr, а как оно там внутри устроено (как длинное целое или как массив), ему не должно быть интересно. VN> Ты наверняка читал мои наезды на IPv6. Заметь, я там ни слова не VN> говорил про сложность хранения/передачи/etc. адресов - потому что VN> jIMHO её нет. Проблема в первую очередь в работе человека с этими VN> адресами. Никакой DNS не поможет нокеру, если сеть в дауне, VN> резолвинг сломан, а надо по traceroute определить, через кого пошёл VN> поток. И вообще админам всех типов работа резко усложняется - VN> помнить кучу страшных цифр. Там, кстати, есть ещё одни грабли, на которые мы уже наступили: неоднозначность записи IPv6-адреса. Это как возможность сокращать нули в виде "::" в произвольном месте, так и возможность записать адрес в верхнем или в нижнем регистре. В результате - текстовое сравнение адреса не работает. А это всякие grep, "| match", "| include"... В конфиге адрес прописан одним способом, в выводе bgp-sum он показывается иначе, скрипт не срабатывает (не видит соответствия). В ipv4 такое если есть, то в пренебрежимо малом масштабе (типа "ping 127.1"). VN> И ещё в моих наездах претензией (второй основной) было то, что ради VN> перехода на v6 не подогнали апдейт остальной сетевой организации. Совершенно согласен. Если уж делать новую версию с нуля, надо было много чего поправить - ведь есть что. А вместо этого сделали что-то странное (обязательный ipsec, flow labels, размер пакетов до 4G - кому всё это надо?). VN> Начиная с самой структуры адреса (вообще ведь никто толком не думал, VN> правильно ли это объединять идентификацию и раутинговые указания в VN> одну сущность). Тут не понял. Вроде ж, разные сущности, и соответствие между одним и другим задаёт таблица роутинга. Хотя, прописывать в адресе явно номер AS, которой он принадлежит, и тогда в таблице роутинга хранить не префиксы, а только автономки - это было бы прикольно. :) Фактически, оно примерно так в IPv6 и получается: старшие 32 бита адреса однозначно ставятся в соответствие номеру AS, блока /32 для автономки должно хватить, и fullview не растёт (в смысле, растёт лишь с кол-вом автономных систем). С 64-битными адресами можно было бы делать то же самое. А за дробление анонсов от одной AS и одного блока - канделябром. :) [...]
Да и возможность такого гейтования никак не отвечает на вопрос, кто, когда и зачем может у себя отключить имеющуюся поддержку IPv4.
VN> А это будет постепенным процессом. Сначала начнут раздавать v6 VN> адреса по желанию. Потом начнутся v6-only ресурсы. Так что плющить и VN> метелить будет долго, но очень медленно и постепенно... Не понимаю, откуда могут появиться v6-only ресурсы, пока есть хотя бы 10% v4-only пользователей. Ресурс ведь не захочет их лишаться. А пока все ресурсы будут обладать v4-адресами, будет оставаться много v4-only пользователей, ведь им нет смысла заводить v6-адрес. -- Паша.