IPv6 considered harmful?
Apr. 7th, 2005 10:44 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
netchПочти самый полный вариант моих наездов на IPv6, некоторые результаты обсуждения в ru.unix.bsd и дополнительные материалы.
RFD.
Наезды:
=== cut <20040910052842.GB96232@quarta.carrier.kiev.ua> ===
Что стало хуже: начнём с размерностей. Адрес 128 бит - это типа круто.
Но у него по сравнению с 32-битовым адресом есть огромная проблема: он
непригоден к запоминанию. Кажется пустяком, но совсем не пустяк. Память
человека работает группами по 6-8 простых объектов (я пользуюсь ламерскими
формулировками, но должно быть понятно, о чём речь). IPv4 адрес как в
десятичной, так и в шестнадцатиричной нотации помещается в неё, IPv6 - нет.
Ладно бы он был 64 бита, но 128 - 32 отдельных hex цифры - приведёт к тому,
что сисадминам потребуется совершенно отдельный skill - счётчика-в-уме
(того что запоминает любые числа с первого раза). А такие счётчики редко
бывают нормальными людьми, чаще это страдальцы на голову.
Аргумент, что есть DNS, и что не дело человека помнить адреса - не годится:
DNS - для юзеров. А админы в первую очередь имеют дело именно с адресами.
Но, может быть, 128 бит - объективная необходимость? А фиг.
Сейчас и 64 бита не нужно. Как используются эти 128? Сразу 64 почти теряются -
при рекомендованной схеме раздачи на каждую организацию даётся своя /48
или /64, а далее цифры используются произвольно. Вы видели организацию
хотя бы на 2^32 хостов? Как же используются эти биты? Предлагается использовать
назначение согласно MAC-адресу интерфейса:( Это диверсия в квадрате.
MAC-адрес уникален, но он не предназначается для адресации в IP: суть IP
в том, что есть незавивисимость от сущностей нижних уровней, включая адреса
канального уровня. Ну и - MAC-адрес для целей адресования внутри организации,
_слишком_ уникален. В результате - теряем 48 бит только потому, что кому-то
влом послать лишний ARP-запрос...
С другой стороны, на уровне глобальной маршрутизации предлагают иметь
возможность роутинга как по /24 (рекомендация на ISP) так и по /48
(на клиента). Цисководы знают, что даже нынешние /24 приводят к таблице,
которая в 75xx через несколько дней перестанет вмещаться в 256M.
Что же будет при /48 и 16-байтных адресах? Может, не с той стороны менять
начали?
OK. Но даже 128 было кому-то мало. И он решил возобновить старый добрый
source routing на основании, что, мол, NAT'а теперь не нужно будет.
Адрес может быть на самом деле цепочкой адресов, каждый на те же 128 бит,
технически всё продумано и работает. А административно? Представим себе
толпу виндов за шлюзом, каждая ходит куда-то на веб, участвует в конференциях
и так далее. Строить stateful firewall принципиально невозможно - протоколы
разные, слишком сложные, если бы были только исходящие соединения - всё было
бы ok, но они в результате бегают в обе стороны. SOCKS или SIP proxy были
бы тут самым уместным. Что же получится? С выходом какого-нибудь MS .COM
Server 2006 хакерам настанет полная лафа. Во-первых, посредством source routing
всякий немного образованный будет пользоваться интернетом за счёт соседа
(а по умолчанию наверняка такое будет разрешено, и потребуется явно настраивать
запрет). Во-вторых, все внутренние адреса будет светиться наружу, и
порносайты будут продавать хакерам полные адреса клиентов (включая внутреннюю
часть), а хакеры будут на них вытворять что хотят. Представляете себе
нынешний мир с ~10 миллионами заражённых виндов на DSL'ях, но распространённый
на все корпоративные сети, где админ оказался недостаточно образован,
чтобы не верить очередной агитке мирового производителя десктопного софта?
Фрагментацию на раутерах убрали совсем. Может, раутерам и легче, но клиентам
станет тяжелее. Туннели плодятся как тараканы, MTU заранее неизвестно,
алгоритм PMTUD остался той же гнилой подпоркой (даже не костылём), что была
впервые изобретена когда ещё TCP толком не было. В IPv4 есть методы забить
на MTU - например, sysctl net.inet.tcp.path_mtu_discovery=0 и исходящее
с данного хоста начинает проходить всегда;)) С IPv6 так не получится.
В драфтах валяется рекомендация сделать наконец нормальную реализацию,
с возможностью собрать все MTU по дороге, с детально прописанной процедурой
восстановления MTU после перехода на постоянный канал и так далее,
но это в драфтах, а IPv6 RFC ссылается на всё ту же затёртую от времени
недореализацию.
TCP и UDP остались с 16 битами портов и 32 битами sequence numbers - мало.
Первое ещё остро не встало (года через 3 можно будет ожидать эффекты),
второе - уже приводит к успешным атакам. Вот на sequence numbers точно надо
было выделять 128 бит, а не на адреса.
В общем, единственное положительное (и то не 100%) - контрольная сумма
заголовка перестала содержать TTL (он же hop count), раутерам чуть легче.
Всё остальное - расчёт на совершенно другой Internet, чем нынешний -
Internet беспрепятственно растущий и дружеский (никаких хакеров).
"Хочу в СССР..." ([Вовочка из анекдота])
=== end cut ===
Вначале я ещё хотел там отругаться на неизменение TCP - нынешний стандарт мало что местами просто неверен (см. сравнение RFC 791 и RFC 1122 про смысл urgent pointer и его отработку разными ОС, или ru.unix.prog с проблемами некорректного согласования понятия urgent data с понятием OOB), но к тому же там точно надо расширить поля: как минимум 64 бита на sequence numbers и 32 на порт (возможно, порт сделать вообще двумерным... но я не представляю себе пока какую из реализаций выбрать). Но это тема отдельного рассмотрения.
Возражал в основном Dmitry Miloserdov, цитаты:
==={{{
VN> OK. Но даже 128 было кому-то мало. И он решил возобновить старый добрый
VN> source routing на основании, что, мол, NAT'а теперь не нужно будет.
И тут я с ними абсолютно согласен обеими руками! NAT - это убожество
в таком виде в котором оно есть сейчас. Когда оно жило на 3ем уровне
оно было вполне разумно хотя и практически бесполезно. Когда к нему
добавили букву `P` и приплели элементы 4того - это было оправдано но
уже как-то не до конца продумано - стандарта-то нет. Вобщем мелкие
проблемы с фрагментацией и контрольными суммами уже тут.
Но мысль пошла дальше и NAT залезло в application но естественно
не разбором всех предыдущих уровней а все так-же full-text-search с 3его.
stateful firewall невозможно построить? Почему?
Все протоколы которые жили под натом совершенно замечательно
впишуться и в firewall. Но при этом маршрутизатор не будет МЕНЯТЬ
ничего выше своего уровня. И это большой плюс даже если остальная
логика не изменится.
Есть и другой большой плюс. Даже при firewall типа
ckeck-state
pass all from $localnet to any keep-state
drop all
остается возможность соединиться двум замаскараденым хостам.
p2p должны пренепременно возрадоваться.
Насчет MS - писсемизм наверное оправдан НО во-первых `хакеры`
и сейчас чувствуют себя неплохо а во-вторых даже без ipv6 MS обязательно
придумает что-нибудь сногсшибательное - можешь не сомневаться.
===}}}
Про 128 бит. В 1994-м (год окончательного принятия 128 бит) шли шатания в предложениях; было одновременно 64 и 128, причём 128 вначале состояли из двух разных уникальных адресов (!) - 64 на глобально уникальный и 64 на локально уникальный. Окончательным аргументом в пользу 128 стало письмо:
==={{{ <9407072035.aa15952@sundance.itd.nrl.navy.mil>
Yes, you said the magic words, "FIXED LENGTH." I have espoused the virtues
of fixed length addresses before. My biggest beef with variable length
addresses is the issue of maintaining additional state or taking additional
time to parse an address whose length I don't know at the start.
[...]
> 8 byte fixed length address.
I have no problem with this, but this alienates many people. Also, there
seems to be a trend toward low percentage of allocated address space used.
(I offer NRL itself as an example, though not the worst, of such waste.)
If we could pull it off with 8 bytes, I'd be all behind it.
> 16 byte fixed length address.
This eliminates much alienation. Furthermore, wasted address space is not
a significant problem here.
[...]
My position can be best summarized as:
The SMALLEST possible fixed-length address. And that length
better have a good justification for why it cannot be smaller.
===}}}
(Письмо это можно найти в http://ftp.sayclub.com/pub/ietf/concluded-wg-ietf-mail-archive/sipp/1994-07)
Видимо, это было последней каплей - безо всякого обсуждения данного письма все резко переключились на единственный вариант драфта - со 128-битными адресами.
Свалка ссылок от поиска по архивам:
==={{{
http://www.ipv6.org/mailing-lists.html
текущие списки
http://playground.sun.com/pub/ipng/html/instructions.html
ipng Сана - подписка
ftp://playground.sun.com/pub/ipng/ipng-mail-archive/
архив ipng начиная с 08.1994
http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/IPng/1994-09/0000.html
кажется, этот же список с другой кочки зрения; это письмо от 1994-08-03
В 1994 IPv6 родился из SIPP (Simple Internet Protocol Plus)
http://www.ietf.cnri.reston.va.us/proceedings/94mar/charters/sipp-charter.html
SIPP жил 03.94 - 08.94
"PIP supported variable length addressing in 16-bit units, separation
of addresses from identifiers, support for provider selection, mobility,
and efficient forwarding." В общем, выглядел нормально, в отличие от.
http://ftp.sayclub.com/pub/ietf/concluded-wg-ietf-mail-archive/sipp/
Собственно архив sipp.
1994-07: размерность и формат адресов ещё не устоялись
1994-07: <9407072035.aa15952@sundance.itd.nrl.navy.mil>: хорошее обсуждение
<94Jul18.012106pdt.12171@skylark.parc.xerox.com> объявление драфта sipp
с 16-байтными адресами
Ключевое слово - SIPP-16 (против SIPP-8)
===}}}
Собственно что меня больше всего удивляет - за 10 лет бурного развития и особенно за последние 5 лет, когда стало ясно, что продолжение лавинообразного экстенсивного развития Internet приведёт только к тому, что мы утонем в волнах спама и хакерских атак - никто даже не пытался проанализировать основы и пересмотреть их не в пользу безграничного расширения...
Или пытался? Мне гугл ничего в пользу таких попыток не сказал.
UPD[07.08.2007]: ещё дискуссии:
http://www.linux.org.ru/view-message.jsp?msgid=2069015&page=1
http://www.rsdn.ru/Forum/message/2598417.flat.aspx
http://dbg.livejournal.com/54908.html
RFD.
Наезды:
=== cut <20040910052842.GB96232@quarta.carrier.kiev.ua> ===
Что стало хуже: начнём с размерностей. Адрес 128 бит - это типа круто.
Но у него по сравнению с 32-битовым адресом есть огромная проблема: он
непригоден к запоминанию. Кажется пустяком, но совсем не пустяк. Память
человека работает группами по 6-8 простых объектов (я пользуюсь ламерскими
формулировками, но должно быть понятно, о чём речь). IPv4 адрес как в
десятичной, так и в шестнадцатиричной нотации помещается в неё, IPv6 - нет.
Ладно бы он был 64 бита, но 128 - 32 отдельных hex цифры - приведёт к тому,
что сисадминам потребуется совершенно отдельный skill - счётчика-в-уме
(того что запоминает любые числа с первого раза). А такие счётчики редко
бывают нормальными людьми, чаще это страдальцы на голову.
Аргумент, что есть DNS, и что не дело человека помнить адреса - не годится:
DNS - для юзеров. А админы в первую очередь имеют дело именно с адресами.
Но, может быть, 128 бит - объективная необходимость? А фиг.
Сейчас и 64 бита не нужно. Как используются эти 128? Сразу 64 почти теряются -
при рекомендованной схеме раздачи на каждую организацию даётся своя /48
или /64, а далее цифры используются произвольно. Вы видели организацию
хотя бы на 2^32 хостов? Как же используются эти биты? Предлагается использовать
назначение согласно MAC-адресу интерфейса:( Это диверсия в квадрате.
MAC-адрес уникален, но он не предназначается для адресации в IP: суть IP
в том, что есть незавивисимость от сущностей нижних уровней, включая адреса
канального уровня. Ну и - MAC-адрес для целей адресования внутри организации,
_слишком_ уникален. В результате - теряем 48 бит только потому, что кому-то
влом послать лишний ARP-запрос...
С другой стороны, на уровне глобальной маршрутизации предлагают иметь
возможность роутинга как по /24 (рекомендация на ISP) так и по /48
(на клиента). Цисководы знают, что даже нынешние /24 приводят к таблице,
которая в 75xx через несколько дней перестанет вмещаться в 256M.
Что же будет при /48 и 16-байтных адресах? Может, не с той стороны менять
начали?
OK. Но даже 128 было кому-то мало. И он решил возобновить старый добрый
source routing на основании, что, мол, NAT'а теперь не нужно будет.
Адрес может быть на самом деле цепочкой адресов, каждый на те же 128 бит,
технически всё продумано и работает. А административно? Представим себе
толпу виндов за шлюзом, каждая ходит куда-то на веб, участвует в конференциях
и так далее. Строить stateful firewall принципиально невозможно - протоколы
разные, слишком сложные, если бы были только исходящие соединения - всё было
бы ok, но они в результате бегают в обе стороны. SOCKS или SIP proxy были
бы тут самым уместным. Что же получится? С выходом какого-нибудь MS .COM
Server 2006 хакерам настанет полная лафа. Во-первых, посредством source routing
всякий немного образованный будет пользоваться интернетом за счёт соседа
(а по умолчанию наверняка такое будет разрешено, и потребуется явно настраивать
запрет). Во-вторых, все внутренние адреса будет светиться наружу, и
порносайты будут продавать хакерам полные адреса клиентов (включая внутреннюю
часть), а хакеры будут на них вытворять что хотят. Представляете себе
нынешний мир с ~10 миллионами заражённых виндов на DSL'ях, но распространённый
на все корпоративные сети, где админ оказался недостаточно образован,
чтобы не верить очередной агитке мирового производителя десктопного софта?
Фрагментацию на раутерах убрали совсем. Может, раутерам и легче, но клиентам
станет тяжелее. Туннели плодятся как тараканы, MTU заранее неизвестно,
алгоритм PMTUD остался той же гнилой подпоркой (даже не костылём), что была
впервые изобретена когда ещё TCP толком не было. В IPv4 есть методы забить
на MTU - например, sysctl net.inet.tcp.path_mtu_discovery=0 и исходящее
с данного хоста начинает проходить всегда;)) С IPv6 так не получится.
В драфтах валяется рекомендация сделать наконец нормальную реализацию,
с возможностью собрать все MTU по дороге, с детально прописанной процедурой
восстановления MTU после перехода на постоянный канал и так далее,
но это в драфтах, а IPv6 RFC ссылается на всё ту же затёртую от времени
недореализацию.
TCP и UDP остались с 16 битами портов и 32 битами sequence numbers - мало.
Первое ещё остро не встало (года через 3 можно будет ожидать эффекты),
второе - уже приводит к успешным атакам. Вот на sequence numbers точно надо
было выделять 128 бит, а не на адреса.
В общем, единственное положительное (и то не 100%) - контрольная сумма
заголовка перестала содержать TTL (он же hop count), раутерам чуть легче.
Всё остальное - расчёт на совершенно другой Internet, чем нынешний -
Internet беспрепятственно растущий и дружеский (никаких хакеров).
"Хочу в СССР..." ([Вовочка из анекдота])
=== end cut ===
Вначале я ещё хотел там отругаться на неизменение TCP - нынешний стандарт мало что местами просто неверен (см. сравнение RFC 791 и RFC 1122 про смысл urgent pointer и его отработку разными ОС, или ru.unix.prog с проблемами некорректного согласования понятия urgent data с понятием OOB), но к тому же там точно надо расширить поля: как минимум 64 бита на sequence numbers и 32 на порт (возможно, порт сделать вообще двумерным... но я не представляю себе пока какую из реализаций выбрать). Но это тема отдельного рассмотрения.
Возражал в основном Dmitry Miloserdov, цитаты:
==={{{
VN> OK. Но даже 128 было кому-то мало. И он решил возобновить старый добрый
VN> source routing на основании, что, мол, NAT'а теперь не нужно будет.
И тут я с ними абсолютно согласен обеими руками! NAT - это убожество
в таком виде в котором оно есть сейчас. Когда оно жило на 3ем уровне
оно было вполне разумно хотя и практически бесполезно. Когда к нему
добавили букву `P` и приплели элементы 4того - это было оправдано но
уже как-то не до конца продумано - стандарта-то нет. Вобщем мелкие
проблемы с фрагментацией и контрольными суммами уже тут.
Но мысль пошла дальше и NAT залезло в application но естественно
не разбором всех предыдущих уровней а все так-же full-text-search с 3его.
stateful firewall невозможно построить? Почему?
Все протоколы которые жили под натом совершенно замечательно
впишуться и в firewall. Но при этом маршрутизатор не будет МЕНЯТЬ
ничего выше своего уровня. И это большой плюс даже если остальная
логика не изменится.
Есть и другой большой плюс. Даже при firewall типа
ckeck-state
pass all from $localnet to any keep-state
drop all
остается возможность соединиться двум замаскараденым хостам.
p2p должны пренепременно возрадоваться.
Насчет MS - писсемизм наверное оправдан НО во-первых `хакеры`
и сейчас чувствуют себя неплохо а во-вторых даже без ipv6 MS обязательно
придумает что-нибудь сногсшибательное - можешь не сомневаться.
===}}}
Про 128 бит. В 1994-м (год окончательного принятия 128 бит) шли шатания в предложениях; было одновременно 64 и 128, причём 128 вначале состояли из двух разных уникальных адресов (!) - 64 на глобально уникальный и 64 на локально уникальный. Окончательным аргументом в пользу 128 стало письмо:
==={{{ <9407072035.aa15952@sundance.itd.nrl.navy.mil>
Yes, you said the magic words, "FIXED LENGTH." I have espoused the virtues
of fixed length addresses before. My biggest beef with variable length
addresses is the issue of maintaining additional state or taking additional
time to parse an address whose length I don't know at the start.
[...]
> 8 byte fixed length address.
I have no problem with this, but this alienates many people. Also, there
seems to be a trend toward low percentage of allocated address space used.
(I offer NRL itself as an example, though not the worst, of such waste.)
If we could pull it off with 8 bytes, I'd be all behind it.
> 16 byte fixed length address.
This eliminates much alienation. Furthermore, wasted address space is not
a significant problem here.
[...]
My position can be best summarized as:
The SMALLEST possible fixed-length address. And that length
better have a good justification for why it cannot be smaller.
===}}}
(Письмо это можно найти в http://ftp.sayclub.com/pub/ietf/concluded-wg-ietf-mail-archive/sipp/1994-07)
Видимо, это было последней каплей - безо всякого обсуждения данного письма все резко переключились на единственный вариант драфта - со 128-битными адресами.
Свалка ссылок от поиска по архивам:
==={{{
http://www.ipv6.org/mailing-lists.html
текущие списки
http://playground.sun.com/pub/ipng/html/instructions.html
ipng Сана - подписка
ftp://playground.sun.com/pub/ipng/ipng-mail-archive/
архив ipng начиная с 08.1994
http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/IPng/1994-09/0000.html
кажется, этот же список с другой кочки зрения; это письмо от 1994-08-03
В 1994 IPv6 родился из SIPP (Simple Internet Protocol Plus)
http://www.ietf.cnri.reston.va.us/proceedings/94mar/charters/sipp-charter.html
SIPP жил 03.94 - 08.94
"PIP supported variable length addressing in 16-bit units, separation
of addresses from identifiers, support for provider selection, mobility,
and efficient forwarding." В общем, выглядел нормально, в отличие от.
http://ftp.sayclub.com/pub/ietf/concluded-wg-ietf-mail-archive/sipp/
Собственно архив sipp.
1994-07: размерность и формат адресов ещё не устоялись
1994-07: <9407072035.aa15952@sundance.itd.nrl.navy.mil>: хорошее обсуждение
<94Jul18.012106pdt.12171@skylark.parc.xerox.com> объявление драфта sipp
с 16-байтными адресами
Ключевое слово - SIPP-16 (против SIPP-8)
===}}}
Собственно что меня больше всего удивляет - за 10 лет бурного развития и особенно за последние 5 лет, когда стало ясно, что продолжение лавинообразного экстенсивного развития Internet приведёт только к тому, что мы утонем в волнах спама и хакерских атак - никто даже не пытался проанализировать основы и пересмотреть их не в пользу безграничного расширения...
Или пытался? Мне гугл ничего в пользу таких попыток не сказал.
UPD[07.08.2007]: ещё дискуссии:
http://www.linux.org.ru/view-message.jsp?msgid=2069015&page=1
http://www.rsdn.ru/Forum/message/2598417.flat.aspx
http://dbg.livejournal.com/54908.html
Re: Perlman
Date: 2010-10-04 02:49 pm (UTC)hm... u menja vychesljaet. ipv6 rabotaet bez vsjakih DHCP serverov, s obychnym radvd.
Adres shljuza ne mozhe tpredti s paketov kotorye prefix dajut?
Re: Perlman
Date: 2010-10-04 02:59 pm (UTC)Router solicitation, наверно. Это такой себе аналог DHCP, только из-под полы.