Re: [uanog] Белые IP Freenet/O3

On Sat, Jan 31, 2015 at 11:37:08PM +0200, Anton Turygin writes:

Какие предложения? Как это можно было сделать "обратно совместимым"?

Чтобы полностью ответить на этот вопрос, нужно потратить много времени и оформить ответ в виде RFC. :) В общих чертах. Совместимость на уровне софта - это 64-битный struct in_addr, для которого существующие IPv4 являются младшими четырмя байтами. Всякие inet_addr(), inet_ntoa() и подобные считают текстовой записью адреса октеты через точку, начиная с первого ненулевого. Сокращённые записи вроде 127.1 или 192.168/16 для IPv4 можно оставить в виде исключения, но можно и считать их устаревшими, в пользу полных 127.0.0.1 и 192.168.0.0/48, а для "длинных" адресов сокращённую форму запретить сразу, иначе возникнет неоднозначность (1.2.3.4/32 - это подразумевается 1.2.3.4/64 или 1.2.3.4.0.0.0.0/32?). Впрочем, можно и изменить синтаксис, сделав для длинных IP запись октетов через какой-нибудь другой разделитель, чтобы смысл prefixlen был понятен однозначно. Для "длинный" prefixlen писать не через '/', а через что-то другое. Совместимость на уровне линка (eth, ppp) - при negotiation заявляется (или не заявляется) очередной capability, и если он поддерживается с обеих сторон, линк поднимается на 64-битных IP, если хотя бы одна сторона этого не заявляет - поднимается на обычном IPv4. Если у пакета src и dst являются 4-байтными, он отправляется как обычный IPv4, если хотя бы один из адресов большой - отправляется в новом формате. Протоколы маршрутизации - то же самое, дополнительный capability. Таблицу маршрутизации можно держать одну, но у некоторых роутов будет признак: поддерживаются только старые IP. Такие маршруты будут игнорироваться при принятии решения о маршрутизации пакетов с длинными src ip. В таком случае провайдеры будут заинтересованы в апдейте IOS/JunOs/XOS/... до поддерживающих 64-битные IP по нескольким причинам: во-первых, для возможности применять эти IP в собственной инфраструктуре, во-вторых, для возможности в перспективе давать эти IP пользователям и прочим ресурсам, в-третьих, для транзита через себя трафика с расширенными IP (это ж прибыль), в-четвёртых, для предоставления доступа к чужим пользователям и ресурсам с длинными IP. С точки зрения пользователя - со временем некоторые сайты будут доступны только свежей версией операционки. К этому все относятся нормально - некоторые ресурсы и сейчас не открываются старыми версиями браузеров, и пользователи с пониманием относятся к необходимости апдейтов. Конечно, много чего надо бы проработать (формат заголовка, модификацию TCP, расширение DNS, всякие netflow и т.д.), но принципиальных проблем я не вижу. И реализация всяко проще, чем IPv6. И вот в таком варианте новые IP-адреса действительно могут со временем поглотить старые, т.е. решить проблему дефицита IP-адресов, не создавая новых сущностей.

Кстати, в реалиях адресации сети "обратной совместимости" мало. Нужна полная.

Полная необязательна. Да и недостижима. Маршруты от/к ресурсам, живущим на новых адресах, будут естественным образом обходить операторов, эти адреса не поддерживающих. Обратная совместимость явно лучше полного отсутствия совместимости, которое мы имеем с IPv6.

2015-01-31 14:52 GMT+02:00 Pavel Gulchouck :

...

On Wed, Jan 28, 2015 at 11:04:49PM +0100, Andrei Kozlov writes:

...

Думаю, не все так безоблачно, с модификацией заголовка, как кажется на первый взгляд. Неиспользуемые широкой общественностью биты могут быть задействованы в экпериментальных и прочьих проприетарных целях. Для таких случаев, решение подлатать на время v4 - кошмар.

На мой взгляд, v6 - рациональное решение, даже с некоторой изящной эволюционной составляющей. В основе 2 очень важные вещи:

- учтены недостатки v4 и проявленя забота о соседях по OSI; - обширные возможности по безболезненному переходу на новый протокол.

Бизнес-кейс для перехода, по большому счету, отсутствует (пока), что в существенной степении тормозит процесс. Но это не является недостатком протокола, imho.

IPv6 - epic fail, который затормозит развитие цивилизации. :)

- Нет обратной совместимости на уровне API и приложений; для поддержки IPv6 софт нужно не просто перекомпилировать (как, например, для 64-битного time_t или off_t), а существенно переписывать; - нет обратной совместимости на уровне протоколов маршрутизации; для роутинга IPv6 нужно поднимать отдельные BGP-сессии, строить отдельный OSPF и т.д., а не просто проапдейтить прошивку, как для поддержки AS32; - адреса занимают больше одного регистра современного процессора, поэтому с ними нужно обращаться как с массивами, а не как с int, что получается заметно менее удобно и эффективно, хотя 64-битных адресов было бы с головой достаточно - это примерно количество песчинок во всех пустынях Земли; это не в два раза больше, чем 32-битных, а в четыре миллиарда раз больше; - нет ни одного сколь-нибудь серьёзного изменения/улучшения, которое оправдывало бы отказ от обратной совместимости.

Отсутствие обратной совместимости приводит к тому, что IPv6 не заменяет собой IPv4, а строится рядом с ним, параллельно и независимо. А значит, IPv6 не решает проблему дефицита IPv4-адресов - IPv4 будут необходимы сетевым ресурсам, пока будут оставаться IPv4-пользователи, т.е. всегда. А если IPv6 не решает глобальную проблему дефицита IPv4-адресов, но создаёт много проблем, зачем он вообще нужен?

...

2015-01-28 11:58 GMT+01:00 Andrii Stesin :

...

а всего-то надо было инвентаризовать де-факто неиспользуемые байты в заголовке IPv4 и парочку из них использовать чтобы добавить перед имеющимися четырьмя одля адресации, еще на 100 лет бы хватило...

-- Паша.