On Tue, Feb 08, 2011 at 11:24:28PM +0200, Pavel Gulchouck wrote:
On Tue, Feb 08, 2011 at 10:00:14PM +0200, Valentin Nechayev writes: VN> Tue, Feb 08, 2011 at 16:29:41, gul wrote about "Re: [uanog] Изя всё.":
Ты представляешь в обозримом будущем v6-only ресурс? Которому настолько начхать на v4-пользователей, что он не озаботился покупкой себе v4-адреса?
VN> Ну вообще-то такие уже существуют. Ссылки не приведу, но есть. Есть VN> и такие, которые дают сильно облегчённый доступ через v6 и обычный VN> через v4. VN> Разумеется, это не гугл и не новостной сайт.
У гугла вообще нет v6 адреса. Интересно, это принципиальная позиция или просто торможение.
Сознательная позиция. Пока явно не попросишь для своих резолверов открыть v6 и не пообещаешь что: - понимаешь все риски - будешь помогать дигностировать проблемы доступности v6 - для массового клиента не доедет AAAA
А облегчённый доступ - ну понятно, биллинг-то на v6 не работает. :)
А провайдер для доступа к такому ресурсу делает у себя нат для пользователей, не поддерживающих ipv6? Не верится.
VN> Пользователям, не поддерживающим v6, невозможно даже адресовать VN> такой ресурс, поэтому такие варианты не рассматриваем.
http://tools.ietf.org/html/draft-liu-behave-nat46-02 Всё очень грустно, да.
Не все так грустно. Просто надо теребить своих вендеров и самим думать и готовиться.
На мой взгляд, правильнее было бы расширить адресное пространство, сохраняя обратную совместимость (я об этом уже писал у себя в блоге),
VN> И как именно ты предлагаешь это сделать?
Детально я это не продумывал (потому что пока не верю в возможность реализации), но концептуально описал в соседнем письме.
А если подумать? Основное ограничение второго пути - нет поддержки в сети доступа.
как asn16 расширили до asn32, или как time_t может быть 64-битным без всяких потрясений.
VN> Плохие примеры. Для ASN32 расширение потребовало переделки софта VN> всех участников, которые хотели полноценно видеть эти номера; а VN> остальные получали какие-то огрызки, которые примерно соответствуют VN> тому, как получилось с v4/v6. Расширение time_t до 64 бит сломало VN> совместимость всех бинарных форматов, которые сохраняли время, и VN> потребовало переходников с конвертерами. Ты не видишь его проблем VN> только потому, что на самом деле мы этого переполнения не достигли.
Я не говорю, что расширение можно сделать вообще незаметно для всех, чтобы появились новые адреса, а пользователи со старым софтом и железом стали с ними работать, ничего у себя не меняя. Такое, конечно, невозможно.
Но когда я апдейчу у себя операционку, меня не особенно заботит возможная бинарная несовместимость - пересоберу, не проблема. И если мне скажут, что с 2013 года появятся новые адреса, которые будут поддерживаться только в FreeBSD 10, RedHat 16, Windows9 и JunOs 11 - для меня это вообще проблемой не будет. Я в любом случае не собирался приходить в 2013 год с имеющимся у меня сейчас Леопардом.
Операционка не проблема. Проблема в ASIC'е первого line-rate порта по дороге. На его разработку и выпуск потрачены годы и миллионы. Как его поменять быстро и бесплатно, не поделишься идеями?
Пользователи давно не удивляются, когда им говорят "этот сайт работает только с IE версии не ниже 7", и с пониманием относятся к необходимости апдейтов.
Я не вижу в этом ни одной серьёзной проблемы,
VN> Ты скажи, как именно ты собрался это реализовывать, и должны ли VN> текущие реализации знать, что это уже не обычный IPv4 на 32 бита или VN> нет, и как именно. Причём на всех уровнях. Например, как ты VN> представляешь себе вместить 48 или 64 бита в struct sockaddr_in?
Если кто-то работает с sockaddr_in по явным смещениям и ориентируется на его фиксированный размер вместо использования sizeof(sockaddr_in), тому придётся внести некоторые изменения в код. Примерно как тем, кто ориентировался на фиксированный тип time_t или int или long или size_t или off_t или прочих типов. Или на восьмибитность символа. Ничего - с utf-8 как-то смирились, так что смириться с изменением структуры sockaddr_in или in_addr тоже можно. По крайней мере, эти изменения существенно меньше, чем переписывание кода на IPv6 с совсем другими структурами и другим API.
а при этом большинство проблем, которые возникают с IPv6, не возникли бы.
VN> Слабо верится. Любое расширение - это несовместимость. VN> IPv6 имеет одну принципиально важную основу: оно исходит из подхода VN> "помирать, так с музыкой" - простите, "если ломать, то так, чтобы VN> хватило надолго и всерьёз и не надо было ломать в ближайшие 10 лет".
Я считаю, что IPv6 имеет противоположную основу. Оно не ломает IPv4. А ломать придётся.
VN> А что ты предложишь?
64-битных адресов хватит навсегда.
640K хватит для любой из ОС (c).
Но эти адреса должны включать в себя IPv4 как подмножество. Тогда действительно будет возможен переход со старого на новое. 64-битный адрес - это u_int64_t, одно слово на 64-битных архитектурах, один регистр. 128-битный IPv6 - это массив, с которым обращаться гораздо сложнее. Разница существенная. Зачем нужен этот массив (и маршрутизация по flow label) - непонятно. Насколько с ним тяжело работать на больших скоростях - понятно.
Размер flow-label согласуется с размером 2^10? А два раза по 2^10? Сделают еще одно MPLS-based прилоежение, если кому-то действительно будет нужна flow-label коммутация. И на этом вопрос закроется.
В первую очередь, не нужно было бы делать отдельную сетку, с отдельными BGP и таблицами роутинга,
VN> Не отдельными? А какая цена замены 32->64?
Не более, чем, например, замена классического форвардинга на cef. И даже менее - там алгоритм другой, а тут просто изменяется кол-во битовых разрядов. Даже админ может не знать, пока специально не посмотрит, 32-битная или 64-битная таблица роутинга у его роутера, точно так же, как он может не знать, поддерживает ли его роутер asn32.
с двумя разными адресами у пользователей и у сайтов, получать отдельные блоки адресов, практически полностью переписывать работу с сокетами в софте... И тогда через 2-5 лет (при поддержке вендоров) действительно мог бы состояться плавный переход на IPng, а на старые IPv4-адреса обращали бы внимания не больше, чем сейчас на шестизначные номера icq.
А так, как оно сделано в 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-адреса, что делать?
Да и возможность такого гейтования никак не отвечает на вопрос, кто, когда и зачем может у себя отключить имеющуюся поддержку IPv4.
Verizon для voice-only сервисов. Такой ответ подойдет?
И даже смешнее. Если всё-таки IPv6 начнёт вытеснять IPv4, то IPv4-адреса начнут освобождаться, дефицит исчезнет, а без дефицита IPv4 вновь получит преимущества перед IPv6. Классическая система лисы и зайцы, находящаяся в динамическом равновесии. Лисы никогда не смогут съесть всех зайцев.
VN> Но протокол всё равно надо менять, ты в рамках того VN> же не сможешь включить более 32 бит не меняя формат пакета.
Разумеется, для 64-битных адресов заголовок пакета должен быть другим. Но это не мешает обратной совместимости.
И еще один новый Netflow? И новый cef? ;-) -- ZA-RIPE||ZA1-UANIC