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
no subject
Date: 2005-04-09 08:21 am (UTC)А зачем ты её пересказываешь? Мало ли разной мути пишут;)) Если пересказываешь - значит, видишь какие-то осмысленные для себя аргументы. Вот я их и обсуждаю.
А что она при таких взглядах критически относится к IPv6 - я не удивляюсь, в контексте всего треда.
>> Что положительного-то? [...] Код-то уже написан, тем более он совершенно крошечный...
> На писютере - крошечный. А на каком-нибудь 8-битном тостере с IP интерфейсом - очень даже не крошечный. Там может физически не быть места в памяти для таблицы ARP.
Ну, во-первых, 8-битных уже точно не будет - небольшой 32-битный со всем на борту ты получишь за пару баксов. Во-вторых - таблица всё равно нужна, потому что Ethernet никто не отменял и MAC-адрес получателя ты даже в IPv6 не проигнорируешь, и наличие MAC-адреса в младшей части IPv6-адреса никто не гарантирует.
А раз так - то неоправданное разбухание адреса и съест память, которая нужна на совсем другое.
> Кстати говоря. Я тебе объясняю, каковы преимущества при включении L2 адреса в L3 адрес. А ты мне можешь объяснить, чем противоположная ситуация может быть выгодна? Только не надо говорить про "замену железа хоста". Я вот недавно перелез на новую машину - уже с месяц не могу обновить файл лицензии на Tornado 2 development environment, который привязан к MAC.
Понимаешь ли...
во-первых, если бы сделали использование MAC последовательно - включение бы L2 адреса в L3 имело смысл. Но этого не делают - и потому, что никто не гарантирует Ethernet подложку (P2P интерфейсы на каждом углу), и потому что независимые от железа адреса нужны для мировых сервисов, для которых нет дела что у тебя MAC меняется. Послушай dk@ сколько времени занимает переписка о замене NS для TLD, за это время железо успевает умереть от старости;))
Во-вторых... Tornado 2... ну ламеры они и бюрократы, наверно. А что это показывает? В моём окружении так ситуаций быть не может в принципе - ну не используем мы такие идиотские схемы защиты от пиратства.
Да, я всем обсуждением доказываю: независимость L3 адреса от L2 адреса - очень хорошая идея, потому что только такая независимость даёт возможность иметь глобально уникальные, максимально независимые от локальных проблем, длительно неизменные адреса. А это то, что необходимо для функционирования именно Internet, а не локальной сети, в которой можно волевым решением всё перестроить за несколько минут и успокоиться. Да, при этом простота локальной настройки приносится в жертву (хотя заметную только под микроскопом!) простоте глобальной настройки и поддержки. Ну так мы ж и говорим про Internet, а не про локалку. В локалке IP вообще не нужен - SMB покрывает все необходимые применения;)
>> Разбиение на подсети делается не для "эффективного использования пространства адресов", а для избавления от необходимости бриджинга далёких сетей, для защиты подсетей друг от друга и так далее.
> Бродкасты можно фильтровать. Защиту можно сделать на бриджах. И так далее. А что плохого в бриджинге далеких сетей?
Бриджинг далёких сетей плох тем, что они скорее всего не под общей администрацией. А остальные описанные меры - построение сети через %опу (другого термина здесь не могу найти;)) Сеть на Ethernet с фильтрацией бродкастов, но хождением уникастов, будет нарушать базовые принципы построения и тем самым вызывать массовые грабли всех видов.
(to be continued)