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: 2005-04-07 08:54 pm (UTC)Re: Perlman
Date: 2005-04-07 10:47 pm (UTC)Во-первых, такие адреса вообще не нужно конфигурировать. Хостам и внутренним раутерам в сети нужно знать единственный элемент информации - префикс. Сравни это с IP, где хост должен знать как минимум свой адрес, маску, и адрес исходящего раутера. DHCP решает проблему конфигурации хостов, но DHCP надо конфигурировать на сервере.
Во-вторых, такие адреса позволяют строить очень большие сети, в которых хосты могут свободно физически мигрировать без изменения level-3 адреса. Например, я взял свой ноутбук, отключил от провода, включил wireless и пошел продолжать работать на свежий воздух. Адрес IPv4 у меня при этом обычно меняется, потому что он слишком сильно привязан к физической топологии сети.
Дома посмотрю книжку - может, еще чего вспомню.
А вообще эта дама очень умная. Она сейчас в IETF в новом проекте участвует - rbridge. Можешь взглянуть.
Re: Perlman
Date: 2005-04-08 05:38 am (UTC)Ага, а адрес шлюза оно святым духом вычислит.
> DHCP решает проблему конфигурации хостов, но DHCP надо конфигурировать на сервере.
В простейшем случае той конфигурации ноль целых хрен десятых - вписать на какие интерфейсы какие адреса даём.
И заметь, в отличие от варианта "знаем префикс" - всё делается автоматически, клиенту не надо вводить строчку безумных знаков.
(Понятно, что там есть ещё и audodiscovery, но я работаю в пределах твоих аргументов)
> Во-вторых, такие адреса позволяют строить очень большие сети, в которых хосты могут свободно физически мигрировать без изменения level-3 адреса. Например, я взял свой ноутбук, отключил от провода, включил wireless и пошел продолжать работать на свежий воздух. Адрес IPv4 у меня при этом обычно меняется, потому что он слишком сильно привязан к физической топологии сети.
Раутинг в IPv4 и IPv6 одинаков. Что в одном что в другом случае должна быть одна L3 сеть. Если же имелся в виду так называемый mobile address, то это не более чем идентификатор, того же примерно типа что и mac-адрес, а фактический раутинговый адрес будет совсем другой.
> А вообще эта дама очень умная. Она сейчас в IETF в новом проекте участвует - rbridge. Можешь взглянуть.
Посмотрю, но по приведённым пока аргументам кажется, что тут случилась победа ума над разумом и здравым смыслом.
no subject
Date: 2005-04-08 07:51 pm (UTC)> Ага, а адрес шлюза оно святым духом вычислит.
Зачем святым духом. Первый пакет, уходящий наружу, посылаешь бродкастом, на что шлюз отвечает чем-то типа ICMP redirect. В дальнейшем эта информация кешируется.
>> DHCP решает проблему конфигурации хостов, но DHCP надо конфигурировать на сервере.
> В простейшем случае той конфигурации ноль целых хрен десятых - вписать на какие интерфейсы какие адреса даём. И заметь, в отличие от варианта "знаем префикс" - всё делается автоматически, клиенту не надо вводить строчку безумных знаков. (Понятно, что там есть ещё и audodiscovery, но я работаю в пределах твоих аргументов)
Ты не понял. Клиенту вообще ничего не надо вводить. Администратору для настройки внутренней сети надо ввести один элемент - префикс - в одном месте - главном шлюзе. Все остальное делается автоматически. Свитчи узнают префикс друг от друга. Хосты узнают префикс от ближайшего раутера.
Еще раз - все эти проблемы в IP уже решены. Например, для домашней сетки, где люди просто не умеют ничего настраивать, достаточно иметь NAT + DHCP + разумные настройки по умолчанию. Но я говорю о том, что в IPX эти проблемы просто никогда не возникали, соответственно, и решать их не приходилось.
> Раутинг в IPv4 и IPv6 одинаков. Что в одном что в другом случае должна быть одна L3 сеть.
Размер сети ограничен количеством доступных адресов, которых в IPv4 просто мало. Поэтому с целью эффективно использовать имеющееся пространство адресов ставят раутеры и разбивают сетку на подсетки. Переходя между ними, хост вынужден менять адрес. А когда у тебя в каждой сетке есть гарантированно ~2^47 уникальных адресов - такой проблемы не возникает. И раутеры, кстати, не нужны.
Снова таки - в IPv4 есть решение, NAT + приватные адреса типа 10/8. А в IPX и IPv6 нет проблемы.
no subject
Date: 2005-04-08 09:46 pm (UTC)Что положительного-то? Мы теряем независимость L3 адреса от L2 адреса, взамен приобретая только геморрой с размерностью. Хорошо разве что для настроек типа "воткнул и завелось"... но они и на IPv4 работали без проблем.
Код-то уже написан, тем более он совершенно крошечный...
>> Ага, а адрес шлюза оно святым духом вычислит.
> Зачем святым духом. Первый пакет, уходящий наружу, посылаешь бродкастом, на что шлюз отвечает чем-то типа ICMP redirect. В дальнейшем эта информация кешируется.
И опять замена одного шила на другое мыло.
> Ты не понял. Клиенту вообще ничего не надо вводить. Администратору для настройки внутренней сети надо ввести один элемент - префикс - в одном месте - главном шлюзе. Все остальное делается автоматически. Свитчи узнают префикс друг от друга. Хосты узнают префикс от ближайшего раутера.
> Еще раз - все эти проблемы в IP уже решены. Например, для домашней сетки, где люди просто не умеют ничего настраивать, достаточно иметь NAT + DHCP + разумные настройки по умолчанию. Но я говорю о том, что в IPX эти проблемы просто никогда не возникали, соответственно, и решать их не приходилось.
Так в том и дело! Проблемы решены, технология надёжна и отделяет мухи от котлет - L2 от L3. И тут приходит самозваный лесник, разгоняет всех нахер и говорит - ваше решение неправильно, сейчас мы всё переделываем - и переделывает смешивая два совершенно разных уровня и вводя новое решение для давно решённых проблем. Какой в этом смысл? Просто переделать захотелось?
>> Раутинг в IPv4 и IPv6 одинаков. Что в одном что в другом случае должна быть одна L3 сеть.
> Размер сети ограничен количеством доступных адресов, которых в IPv4 просто мало. Поэтому с целью эффективно использовать имеющееся пространство адресов ставят раутеры и разбивают сетку на подсетки. Переходя между ними, хост вынужден менять адрес. А когда у тебя в каждой сетке есть гарантированно ~2^47 уникальных адресов - такой проблемы не возникает. И раутеры, кстати, не нужны.
Угумс, broadcast segment на десятки тысяч хостов? Да чтоб меня покрасили такое использовать, там же из-за бродкастов трафика видать не будет.
И что значит "с целью эффективно использовать имеющееся пространство адресов ставят раутеры и разбивают сетку на подсетки"? Тут нет логической связи, для предельно эффективного использования, наоборот, ничего разбивать не надо - граничные адреса теряться не будут. Разбиение на подсети делается не для "эффективного использования пространства адресов", а для избавления от необходимости бриджинга далёких сетей, для защиты подсетей друг от друга и так далее. И общее пространство этому только мешает.
> Снова таки - в IPv4 есть решение, NAT + приватные адреса типа 10/8. А в IPX и IPv6 нет проблемы.
NAT решает совсем другую задачу - изоляцию внутренних сетей от внешнего мира. Задача экономии адресов тут побочная даже сейчас, когда адреса якобы "кончаются" (на самом деле распределено только 1/4 всего пространства A+B+C, это при том, что не подключён только ленивый или совсем нищий).
В IPX нету проблемы в чём - не надо раутеров? Он просто не раутится (потуги в виде "номера сети" не считаем, они толком за пределами NetWare не реализовались). Зато отсутствие механизма трансляции адресов между L2 и L3 и целостного адреса приводит к тому, что или требуется свой слой костылей и подпорок (см. NCP), или сидим в одном broadcast segment и не высовываемся. То есть проблема значительно острее чем в IPv4. У IPv6 - если мы пользуемся логическим адресом - работает тот же ARP, но в профиль. Если физическим - теряем независимость адресов и как следствие возможности HSRP/etc., и даже просто возможность сменить железо хоста без длительного пинания всех кэшей.
no subject
Date: 2005-04-08 10:26 pm (UTC)no subject
Date: 2005-04-08 10:30 pm (UTC)no subject
Date: 2005-04-08 11:21 pm (UTC)>> /ARP не нужен/
>
> Что положительного-то? [...] Код-то уже написан, тем более он совершенно крошечный...
На писютере - крошечный. А на каком-нибудь 8-битном тостере с IP
интерфейсом - очень даже не крошечный. Там может физически не
быть места в памяти для таблицы ARP.
Кстати говоря. Я тебе объясняю, каковы преимущества при включении L2
адреса в L3 адрес. А ты мне можешь объяснить, чем противоположная
ситуация может быть выгодна? Только не надо говорить про "замену железа
хоста". Я вот недавно перелез на новую машину - уже с месяц не могу
обновить файл лицензии на Tornado 2 development environment, который
привязан к MAC.
> Так в том и дело! Проблемы решены, технология надёжна и отделяет мухи
> от котлет - L2 от L3. И тут приходит самозваный лесник, разгоняет всех нахер и говорит - ваше решение неправильно, сейчас мы всё переделываем [...]
Я тебе не про лесника рассказываю. И IPv6 я не защищаю. Я тебе
пересказываю часть содержания книги Ради Перлман. Основной тезис этой
части таков: давайте посмотрим на разные протоколы в области
маршрутизации пакетов (level 2 и level 3). Интересные и правильные идеи
из некоторых протоколов (например, IPX или CLNP), к сожалению, были не
поняты, проигнорированы или неправильно заимствованы другими протоколами
(например, IP). И наоборот. Кстати говоря, она довольно критически
относится к IPv6, не сильно отделяя его от IPv4.
> Угумс, broadcast segment на десятки тысяч хостов? Да чтоб меня покрасили такое использовать, там же из-за бродкастов трафика видать
> не будет
[...]
> Разбиение на подсети делается не для "эффективного использования
> пространства адресов", а для избавления от необходимости бриджинга
> далёких сетей, для защиты подсетей друг от друга и так далее.
Бродкасты можно фильтровать. Защиту можно сделать на бриджах. И так далее. А что плохого в бриджинге далеких сетей?
>> /Снова таки - в IPv4 есть решение, NAT + приватные адреса типа
>> 10/8. А в IPX и IPv6 нет проблемы./
>
> NAT решает совсем другую задачу - изоляцию внутренних сетей от внешнего мира.
Правильно. Поэтому ты не можешь использовать приватные адреса, если ты хочешь оставаться подключенным к интернету, но у тебя нет NAT.
> Задача экономии адресов тут побочная даже сейчас, когда адреса якобы "кончаются" (на самом деле распределено только 1/4
> всего пространства A+B+C, это при том, что не подключён только ленивый или совсем нищий).
Ась? Я домашний юзер, хочу подключить дома пять компьютеров, принтер и 8-битный тостер с веб-интерфейсом. А мой IP провайдер требует с меня $10/месяц за каждый новый адрес. Ты мне объясни, почему это так, если адреса только "якобы" кончаются. Так вот, не буду я ему платить, я поставлю раутер с NAT и приватными адресами внутри. А если бы это был CLNP провайдер, я уверен, он бы мне без напряга и за бесплатно выделил целую сетку для всех моих устройств.
> В IPX нету проблемы в чём - не надо раутеров? Он просто не раутится (потуги в виде "номера сети" не считаем, они толком за пределами NetWare не реализовались).
IPX умер именно потому, что за пределами NetWare с ним никто толком не работал. А номер сети, если его сделать иерархическим и может быть чуток расширить - самое оно.
> Зато отсутствие механизма трансляции адресов между L2 и L3 и целостного адреса приводит к тому, что или требуется свой слой костылей и подпорок (см. NCP),
При чем тут NCP? NCP - это вообще L4.
> У IPv6 - если мы пользуемся логическим адресом - работает тот же ARP, но в профиль. Если физическим - теряем независимость адресов и как следствие возможности HSRP/etc.,
При чем тут HSRP? Читаем сискину документацию:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/cs009.htm
"HSRP is compatible with Novell's Internetwork Packet Exchange (IPX)"
"HSRP allows two or more HSRP-configured routers to use the MAC address and IP network address of a virtual router"
То есть, MAC клонируется на несколько раутеров. И все это работает с IPX и IPv6 и работало бы с CLNP, если бы хоть кто-то его использовал.
> и даже просто возможность сменить железо хоста без длительного пинания всех кэшей.
Какое железо? Сетевой адаптер? Сделай хосту host id и используй его в качестве MAC.
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)
no subject
Date: 2005-04-09 08:22 am (UTC)> Правильно. Поэтому ты не можешь использовать приватные адреса, если ты хочешь оставаться подключенным к интернету, но у тебя нет NAT.
Трюизм, однако.;)) Как он влияет на остальное рассуждение? NAT будет использоваться и с IPv6, потому что маскировка внутренней структуры, даже таких факторов, как размер внутренней сети, адреса активных хостов в ней, количество активных хостов и корреляция источников запросов - является полезной информацией для intruder'а и потому должна минимально показываться.
А кто не хочет NAT - ему и сейчас никто не мешает.
> Ась? Я домашний юзер, хочу подключить дома пять компьютеров, принтер и 8-битный тостер с веб-интерфейсом. А мой IP провайдер требует с меня $10/месяц за каждый новый адрес. Ты мне объясни, почему это так, если адреса только "якобы" кончаются.
Потому что провайдер - козёл. И потому что он хочет чтобы юзер был глупый, с виндой и смотрел раз в день одну страничку, радовался скорости и создавал ничтожный суммарный трафик. А тут приходишь ты, один вид которого раздражает (ибо пришёл) с запросом, который вызывает головную боль и мысли о том, что ты скоро захочешь reverse DNS, CIR в полосе трафика и SLA по надёжности работы.
А если ты придёшь к нам;)) - тебе адреса выдадим просто под грамотно написанную заявку. Это при том, что у нас плотно забитые /19 + /18, а у твоего DSL провайдера наверно десяток /15. И реверс у нас делается за пару часов по простому письму.
> Так вот, не буду я ему платить, я поставлю раутер с NAT и приватными адресами внутри. А если бы это был CLNP провайдер, я уверен, он бы мне без напряга и за бесплатно выделил целую сетку для всех моих устройств.
Ни CLNP ни IPv6 просто так тебе такого не дадут. Если провайдер будет жлобиться - он и на IPv6 даст тебе одиночный адрес и ты будешь на нём тосковать с NAT'ом внутри. И адрес будет привязан к маку, так что после смены железа ты будешь ещё месяц кидаться в него бумажками с просьбой сменить адрес, ждать часами на телефоне его техподдержки с индусскими девочками, потом плюнешь на него, сделаешь `ifconfig xl0 hwaddr 0.1.2.3.4.5' и будешь надеяться что не попадёшь под статью договора про фальсификацию IP-адреса.
Дело не в адресах, дело в жлобах.
> IPX умер именно потому, что за пределами NetWare с ним никто толком не работал. А номер сети, если его сделать иерархическим и может быть чуток расширить - самое оно.
С IPX не работали "толком" потому, что он никому такой не нужен и потому что в IP проблемы построения глобальной сети решаются с пол-пинка без расширения, которое ещё и будет реализовано пятью ведущими вендорами несовместимо друг с другом.
>> Зато отсутствие механизма трансляции адресов между L2 и L3 и целостного адреса приводит к тому, что или требуется свой слой костылей и подпорок (см. NCP),
> При чем тут NCP? NCP - это вообще L4.
При том, что в NetWare задачи взаимодействия хостов решается NCP и средствами поверх него, где и отрабатываются lookup'ы и в ответ сообщаются адреса, номера сокетов и прочие адресные координаты. А IPX остаётся голым транспортом.
>> и даже просто возможность сменить железо хоста без длительного пинания всех кэшей.
> Какое железо? Сетевой адаптер? Сделай хосту host id и используй его в качестве MAC.
О! Вот и пришли снова к тому, что физический адрес побоку, а вместо этого вводим логический и работаем через него. А теперь объясни, почему этот адрес мы должны выставлять на L2, когда по логике он должен быть уже на L3? ;))
Я этого не говорил
Date: 2005-04-12 03:43 pm (UTC)Нет, просто книжка очень неплохо написана.
Короче, я, что называется, "слил" :) Я тебе обсуждаемую книжку мылом послал, почитай, если захочется.
Re: Я этого не говорил
Date: 2005-04-26 07:10 am (UTC)И она агитирует что CLNP был бы лучше. А у него длина адреса переменная. А по приведённым ссылкам - народ согласен был на любое решение лишь бы длина адреса была постоянной. Это ж-ж-ж-ж неспроста.
-netch-, проливающий слёзы по горькой судьбе IPX с четырьмя разными инкапсуляциями
Переменная длина/иерархический адрес
Date: 2010-01-17 01:20 pm (UTC)Вот представим себе ситуацию, есть магистральный провайдер, LIR, владеет большим блоком, скажем, /17. У него ряд клиентов, из них хотя бы один, ну так /23, имеет канал к другому провайдеру. Дык вот наш магистрал может, по идее, анонсировать весь /17 агрегированным. Но. Если вдруг линк до того клиента, который еще канал имеет, рвется - из мира тот должен сохранять доступ. И магистралу теперь разбивать свой /17 на кучу мелких? Это, в случае аварии, дополнительно усилит нагрузку на сеть. Если же ту /23 анонсировать всегда, это +1 запись в таблицу всем роутерам Интернета.
Эта ситуация - просто переложенный на BGP пример. Теперь вопрос, спасла ли бы иерархическая адресация от того, что каждый такой мелкий префикс надо анонсировать отдельно всему Интернету? То есть в глобальном плане, размер full view у всех. И как в случае иерархической адресации решается проблема "от родителя к потомку линк порвался, теперь всему миру надо слать не родителю, а на резервный канал потомка" ?
no subject
Date: 2009-02-09 12:07 pm (UTC)> с виндой и смотрел раз в день одну страничку, радовался скорости и
> создавал ничтожный суммарный трафик. А тут приходишь ты, один вид которого
> раздражает (ибо пришёл) с запросом, который вызывает головную боль и мысли
> о том, что ты скоро захочешь reverse DNS, CIR в полосе трафика и SLA по
> надёжности работы.
Ух какие разумные слова... Но спустя три года, некоторые домовые провайдеры Питера настолько оборзели, что позволяют юзать только 25 tcp портов в инет, причём независимо от того покупаешь ли ты внешний айпишник или нет... А ведь при плотном использованиии того же торрента, эти 25 портов, ака соединений заканчиваются моментально...
no subject
Date: 2006-10-23 08:39 pm (UTC)А как Вы расценивате прогнозы об исчерпании IPv4 к 2008-20012 гг. (http://en.wikipedia.org/wiki/IPv4#Exhaustion_date) ?
no subject
Date: 2008-10-11 10:24 pm (UTC)no subject
Date: 2008-10-12 09:11 am (UTC)no subject
Date: 2009-02-09 12:13 pm (UTC)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, только из-под полы.