UPDATE(2007-09-15): лучше начинать смотреть с
выборки в моём журнале,
там на сейчас значительно новее данные, и вообще жизнь.
Некоторая сумма моих возражений против IPv6. Письмо в ньюсгруппу.
Date: Fri, 10 Sep 2004 08:28:42 +0300
From: Valentin Nechayev
Subject: Re: Замена PMTUD
Message-ID: <20040910052842.GB96232@quarta.carrier.kiev.ua>
X-Comment-To: Dmitry Miloserdov
Newsgroups: fido7.ru.unix.bsd
>>> Dmitry Miloserdov wrote:
VN>>>> Ты не понимаешь политику партии.
VN>>>> Hа нас надвигается полным ходом IPv6, чтоб он сдох.
SO>>> А что, никто еще всю критику в одном месте не собрал и бучу не
SO>>> поднимал?
VN>> Ты предполагаешь возможность остановить этот паровоз?
DM> Что-то мне подсказывает что мнение у тебя по поводу ipv6 уже сложилось ;)
DM> А можешь поделится с общественностью основными _на_твой_взгляд_
DM> упущениями в новом стандарте. Что стало хуже по сравнению с 4 и что
DM> должно было стать лучше но не стало.
Что стало хуже: начнём с размерностей. Адрес 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 бит только потому, что кому-то
влом послать лишний DHCP-запрос...
С другой стороны, на уровне глобальной маршрутизации предлагают иметь
возможность роутинга как по /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 беспрепятственно растущий и дружеский (никаких хакеров).
"Хочу в СССР..." ([Вовочка из анекдота])
DM> И еще - что наводит на мысль что паровоз уже рядом? кричат-то уже лет 5-6
DM> вроде.
Наводит то, что "dig @ns.ripe.net чего-то" перестал работать,
если в ядре нет IPv6.
Ceterum censeo IPv6 esse delendam.
-netch-
(C) 2007 Valentin Nechayev. All rights reserved.
Разрешается полное или частичное копирование, цитирование.
При полном или частичном копировании ссылка на оригинал
обязательна.