Tue, Feb 08, 2011 at 23:24:28, gul wrote about "Re: [uanog] Изя всё.":
Ты представляешь в обозримом будущем v6-only ресурс? Которому настолько начхать на v4-пользователей, что он не озаботился покупкой себе v4-адреса? VN>> Ну вообще-то такие уже существуют. Ссылки не приведу, но есть. Есть VN>> и такие, которые дают сильно облегчённый доступ через v6 и обычный VN>> через v4. VN>> Разумеется, это не гугл и не новостной сайт. У гугла вообще нет v6 адреса. Интересно, это принципиальная позиция или просто торможение. А облегчённый доступ - ну понятно, биллинг-то на v6 не работает. :)
Про гугл тут уже ответили, а при чём тут биллинг - я не понял.
Я не говорю, что расширение можно сделать вообще незаметно для всех, чтобы появились новые адреса, а пользователи со старым софтом и железом стали с ними работать, ничего у себя не меняя. Такое, конечно, невозможно.
Но когда я апдейчу у себя операционку, меня не особенно заботит возможная бинарная несовместимость - пересоберу, не проблема.
Угу. И данные, записанные в старой версии, тебе не нужны. ;)
И если мне скажут, что с 2013 года появятся новые адреса, которые будут поддерживаться только в FreeBSD 10, RedHat 16, Windows9 и JunOs 11 - для меня это вообще проблемой не будет. Я в любом случае не собирался приходить в 2013 год с имеющимся у меня сейчас Леопардом. Пользователи давно не удивляются, когда им говорят "этот сайт работает только с IE версии не ниже 7", и с пониманием относятся к необходимости апдейтов.
У меня обратное впечатление. "Необходимость апдейтов" принимают только некоторые, уже опытные, и только если их чем-то соблазнили. Большинство или просто апдейтят не замечая (как рекомендуется в настройке Windows), или стоят на своём до последнего.
Я не вижу в этом ни одной серьёзной проблемы, VN>> Ты скажи, как именно ты собрался это реализовывать, и должны ли VN>> текущие реализации знать, что это уже не обычный IPv4 на 32 бита или VN>> нет, и как именно. Причём на всех уровнях. Например, как ты VN>> представляешь себе вместить 48 или 64 бита в struct sockaddr_in? Если кто-то работает с sockaddr_in по явным смещениям и ориентируется на его фиксированный размер вместо использования sizeof(sockaddr_in), тому придётся внести некоторые изменения в код. Примерно как тем, кто ориентировался на фиксированный тип time_t или int или long или size_t или off_t или прочих типов. Или на восьмибитность символа.
Увы, там несовместимостей значительно больше. Взять хотя бы возможность хранить v4-адрес одним long'ом, которая достаточно часто используется. Причём, будь это unsigned long, проблем было бы даже меньше, но оно таки у очень многих uint32_t. А если менять код - то уже нет фатальной разницы, на что именно менять. Но это ты пошёл в сторону вопроса о коде. Я же больше имел в виду проблемы собственно совместимости уже написанного. До определённой степени она есть - за счёт IPv4-mapped адресов. В принципе тебе ничто не мешает связаться с ::ffff:10.0.3.4 на ::ffff:192.168.1.5 так, чтобы соединение реально случилось по v4 (не помню, насколько стеки поддерживают автоматизацию этого действия, но даже сделать простой враппер с аллокацией v4 сокета вместо v6 будет тривиально). Насколько я вижу, всякие редхатофедоры это давно сделали: tcp 0 0 ::ffff:YY.193.194.194:80 ::ffff:XX.133.134.30:53671 TIME_WAIT - (чуть замаскировал первые октеты) Я не знаю, почему netstat в Fedora показывает часть соединений на один и тот же 80-й порт в чистом v4 синтаксисе, а часть - в v4-mapped v6, но такие строчки там есть и показывают, что соединение было принято объединённым v6/v4 сокетом.
Ничего - с utf-8 как-то смирились, так что смириться с изменением структуры sockaddr_in или in_addr тоже можно. По крайней мере, эти изменения существенно меньше, чем переписывание кода на IPv6 с совсем другими структурами и другим API.
Ну "смирились" про utf-8 - это жестокое преувеличение. Стало одним из возможных вариантов, более того, основным для большинства установок - это да, современный линукс на восьмибитке уже трудно себе представить. (Я вот никак не решусь на своей фряхе перейти на utf-8, хотя на сейчас всех препятствий осталось - перевести несколько файлов.) Но вначале переход был мучительным. Помнишь grep на RedHat 8.0, который в случае включения utf-8 локали начинал даже ascii текст разбирать в ~1000 раз медленнее? Потом это, конечно, залечили. Но опять-таки изменение структуры - это изменение на уровне программиста, то есть его хоть ясно, как решать. Есть более сложные и путаные вопросы, и в основном они в районе проблем межсетевого взаимодействия.
а при этом большинство проблем, которые возникают с IPv6, не возникли бы. VN>> Слабо верится. Любое расширение - это несовместимость. VN>> IPv6 имеет одну принципиально важную основу: оно исходит из подхода VN>> "помирать, так с музыкой" - простите, "если ломать, то так, чтобы VN>> хватило надолго и всерьёз и не надо было ломать в ближайшие 10 лет". Я считаю, что IPv6 имеет противоположную основу. Оно не ломает IPv4. А ломать придётся.
Ну формат заголовка пакета ведь уже сломали? Я что-то плохо верю в возможность автоматической конверсии заголовка даже в случае v4-mapped адресов на v6 части пути. Flow label потеряется. Часть v6 заголовков не может быть адекватно конвертирована в v4. И такого много. Значит, на этапе установления связи уже надо однозначно знать, каким вариантом будем связываться. На сейчас, если стек видит v4-mapped адрес, он таки переключается на v4, по крайней мере в Linux. На моём десктопе (OpenSuSE 11.3): === #!/usr/bin/env python import socket s = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM, socket.IPPROTO_UDP) s.bind(('::', 4444)) s.sendto('Hello v6 world\n', ('::ffff:192.168.1.104', 4444)) === Смотрим в tcpdump: 07:02:49.374514 IP 192.168.1.106.4444 > 192.168.1.104.4444: UDP, length 15 0x0000: 4500 002b 0000 4000 4011 a69f c0a8 016a E..+..@.@......j 0x0010: c0a8 0168 115c 115c 0017 a86e 4865 6c6c ...h.\.\...nHell 0x0020: 6f20 7636 2077 6f72 6c64 0a o.v6.world. По-твоему, этого недостаточно для совместимости? (Попробовал повторить на FreeBSD - отказалось на моменте конверсии getaddrinfo() текстового представления v6. Пока не знаю, это шутки питона или libc.) VN>> А что ты предложишь?
64-битных адресов хватит навсегда.
С этим я в принципе согласен, но при одном принципиальном условии:
если отказаться от новомодных тенденций в автоконфигурации. На
сейчас в v6, например, взаимодействие в пределах одного сетевого
сегмента настраивается автоматически (я даже не уверен, можно ли тут
сказать "настраивается") и работает гарантированно устойчиво (без
конфликтов и с фиксированными адресами) независимо от момента
настройки. Для v4 ты что сделаешь аналогом? Даже 169.254/16 это
"подарок" Microsoft, а не органическое свойство протокола, и требует
соответствующей поддержки в управлении сетевым стеком. И
фиксированных адресов там нет, чуть включились в ином порядке в
следующий раз - сели на другие адреса. Обычно они берутся просто
случайным образом. Я бы, конечно, перерабатывал MAC и делал
фиксированную последовательность для пробы, но сложилось уже иначе.
И если ты думаешь, что для 64 бит можно это повторить, выделив
старшие 16 бит фиксированно (или чуть меньше, чтобы разные локальные
сети делать), а младшие 48 брать из MAC'а, то я тебе вынужден буду
возразить, что не MAC единым живо человечество. Вот, например, у
Infiniband аналог MAC карточки (зовётся GUID) занимает уже 8 байт,
а L2 адрес там 20 байт (старшие 4 по местной политике виртуализации
сетевых интерфейсов, а 16 методом, идентичным формированию v6
link-local):
# ip link show ib0
6: ib0:
Но эти адреса должны включать в себя IPv4 как подмножество. Тогда действительно будет возможен переход со старого на новое. 64-битный адрес - это u_int64_t, одно слово на 64-битных архитектурах, один регистр. 128-битный IPv6 - это массив, с которым обращаться гораздо сложнее. Разница существенная.
На сейчас это уже малосущественная разница. Ты можешь держать адрес и как 128-битное целое, а если тебе этого не позволяет напрямую язык (многие позволяют) - делаешь адекватную библиотеку. На C++ создание типа данных [u]int128_t на основании имеющихся целых - задача для школьника. На C чуть сложнее (будет путаное API), но не сложнее, чем работать со всякими div_t или sockaddr_in. Ты наверняка читал мои наезды на IPv6. Заметь, я там ни слова не говорил про сложность хранения/передачи/etc. адресов - потому что jIMHO её нет. Проблема в первую очередь в работе человека с этими адресами. Никакой DNS не поможет нокеру, если сеть в дауне, резолвинг сломан, а надо по traceroute определить, через кого пошёл поток. И вообще админам всех типов работа резко усложняется - помнить кучу страшных цифр. И ещё в моих наездах претензией (второй основной) было то, что ради перехода на v6 не подогнали апдейт остальной сетевой организации. Начиная с самой структуры адреса (вообще ведь никто толком не думал, правильно ли это объединять идентификацию и раутинговые указания в одну сущность). Далее, - номер порта 16 бит - для бытового потребителя много, но для серьёзной системы - крайне мало. - TCP sequence numbers в 32 бита - сейчас просто несекьюрно, для современного мира надо 64 или 128 (вот тут уже можно не экономить) - формат DNS вообще надо переписать с нуля - проблемы MTU не решили, только усугубили. единственное что может чем-то помочь - требование минимума в 1280 байт (если кто не помнит, для v4 минимум - 68 (прописью: шестьдесят восемь байт)) всё это можно было решить за прошедшие 17 лет не раз, но никто не чешется, pardon my french. С этой точки зрения, до последних лет IPv6 - просто отвлекалово от реальных проблем.
Зачем нужен этот массив (и маршрутизация по flow label) - непонятно. Насколько с ним тяжело работать на больших скоростях - понятно.
В случае магистрального ISP типа твоей работы достаточно маршрутизации до /32, что принципиально не меняется по сравнению с v4 (всё равно смотрели полные 4 байта). Политика IANA+RIRs для v6 - выдавать только целые блоки /32 на AS - помогает оптимизировать основной случай (а не бардак всех размеров, как v4) вплоть до аппаратной поддержки. (И даже обсуждаемые /48 на PI это всего лишь ещё один фиксированный размер, а не шатание всех уровней от /26 до /19.) В более мелкие размеры и тем более на flow labels надо смотреть уже на уровне внутри ISP к своим клиентам, где скорости на порядки ниже, а техника разнообразнее. А там даже простой IDS сожрёт значительно больше ресурсов, чем маршрутизация по flow label. Так что не всё так грустно, как ты описываешь.
В первую очередь, не нужно было бы делать отдельную сетку, с отдельными BGP и таблицами роутинга, VN>> Не отдельными? А какая цена замены 32->64? Не более, чем, например, замена классического форвардинга на cef. И даже менее - там алгоритм другой, а тут просто изменяется кол-во битовых разрядов.
Так оно и при текущем v6 такое же, потому что младшие 64 начинают работать только в пределах последнего сегмента. Только твои 64 имеют неопределённую структуру, а в v6 она чётко определена для >99% практически значимых случаев (32 на AS, 16 на клиента, 16 на сеть клиента, 64 внутри той сети).
А так, как оно сделано в IPv6 - проблемы будут ещё и через 10, и через 20 лет, потому что не видно механизма, каким образом IPv4 может куда-то деться. IPv6 не заменит IPv4, равно как метро не заменит автомобили. VN>> См. IPv4-compatible и IPv4-mapped адреса. IPv4 включается в IPv6 как VN>> частный случай. IPv4 мапится в IPv6, но тоже не совсем без проблем. Например, если у меня только v6 и собственный dns, а у гугля только v4, то при обращении к гуглю я получу "host not found" - чтобы этого не было, я должен использовать специальный dns 6to4-гейта. А этот гейт мне ещё нужно где-то найти. Если я пользователь - понятно, спрашивать провайдера, а если я сам ISP, имеющий только v6-адреса, что делать?
DNS тут почти ни при чём. Давай не будем сейчас вспоминать конкретную битность, названия протоколов и т.д., просто назовём - формат A (более узкий) и формат B (более широкий). Если у клиента адрес типа B, то сервер с типом только A не сможет с ним работать без дополнительного шлюза (фактически NAT). Если у сервера адрес типа B, проблема та же. Кроме того, ты вспоминаешь DNS - опять-таки, это метод узнать адрес, и если клиент не может понимать адреса типа B, ему без разницы, есть ли к нему шлюз. Из этого следует, что на переходный период нужно делать, чтобы и у клиентов и у серверов было оба варианта адреса, ну и, само собой, их поддержка. По твоему конкретному примеру. Во-первых, не host not found, а no data (а если мы говорим про DNS, будет не NXDOMAIN, а положительный ответ, но с нулевым answer count). Во-вторых... да, если провайдер - сам организуй этот гейт:) но дело в нём, а не в DNS, который будет уже вспомогательным средством. И на переходный период таки не надо делать v6 only, надо давать всегда два адреса.
Да и возможность такого гейтования никак не отвечает на вопрос, кто, когда и зачем может у себя отключить имеющуюся поддержку IPv4.
А это будет постепенным процессом. Сначала начнут раздавать v6 адреса по желанию. Потом начнутся v6-only ресурсы. Так что плющить и метелить будет долго, но очень медленно и постепенно...
И даже смешнее. Если всё-таки IPv6 начнёт вытеснять IPv4, то IPv4-адреса начнут освобождаться, дефицит исчезнет, а без дефицита IPv4 вновь получит преимущества перед IPv6. Классическая система лисы и зайцы, находящаяся в динамическом равновесии. Лисы никогда не смогут съесть всех зайцев.
А вот против этого уже сыграет привычка. Если все сидят на v6, то v4 уже не будет удобным. Это надо подымать вторую систему адресации... а зачем? VN>> Но протокол всё равно надо менять, ты в рамках того VN>> же не сможешь включить более 32 бит не меняя формат пакета.
Разумеется, для 64-битных адресов заголовок пакета должен быть другим. Но это не мешает обратной совместимости.
Увы, мешает. Если бы он изначально расширялся, было бы проще. (Так сделано в стеке ISO, причём достаточно дешёвыми методами.) -netch-