|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 14 Sep 2004 22:05:48
To : Dmitry Miloserdov
Subject : Re: Замена PMTUD
--------------------------------------------------------------------------------
>>> Dmitry Miloserdov wrote:
VN>> Что стало хуже: начнём с размерностей. Адрес 128 бит - это типа круто.
DM> Про запоминание адресов вопрос спорный и лично я не согласен с утверждением
DM> `DNS для юзверей`. Какой-нибудь резолвер нужен и админу.
В повседневной жизни - да. А когда идёт настройка включая и DNS?
DM> С другой стороны ты сам сказал что 64 бита отданы на растерзание админу
DM> то есть запоминать обычно нужно только 64.
DM> Про необходимость - глупо было бы добавить 8 бит если именно их сегодня
DM> не хватает не задумавшись о том что будет завтра. А когда задумываются о
DM> завтра то по какой-то причине начинают считать все процессы в IT
DM> экспоненциальными ( зачастую оправданно ) и если занятых ip за 10 лет
DM> увеличилось в 100 раз то через 20 лет мы увидим увеличение еще в 10000 раз
DM> (цифры с потолка) А так как внедрение долгосрочно и дорого то все-же нужно
DM> смотреть достаточно далеко чтобы внедение хотябы успело завершиться к
DM> моменту
DM> морального устаревания;)
Вот на это 64 хватит с головой, переменной длины - тем более.
DM> Что касалось MAC согласен полностью но ведь это рекомендация - не более.
VN>> Цисководы знают, что даже нынешние /24 приводят к
VN>> таблице, которая в 75xx через несколько дней перестанет вмещаться в
VN>> 256M. Что же будет при /48 и 16-байтных адресах?
DM> Я бы на вскидку сказал что то что влезло в 256М при переходе практически
DM> гарантированно влезет в 512М ('практически' только из-за знакомства с
DM> чудесами
DM> программизма) а это цена вроде как адекватная.
А цены на цисковскую память знаешь? ;(
DM> Кстати при таких больших минимальных сетках наверняка сократится количество
DM> префиксов per AS. Я бы даже сказал сократится до единицы практически везде
DM> (или я что-то существенное упускаю из вида?) Сейчас их в среднем около
DM> четырех.
Зато количество просто префиксов возрастёт. И его уменьшения что-то не
видно.
DM> Итого можем получить существенное улучшение если даже не по памяти то по
DM> скорости.
VN>> OK. Hо даже 128 было кому-то мало. И он решил возобновить старый добрый
VN>> source routing на основании, что, мол, NAT'а теперь не нужно будет.
DM> И тут я с ними абсолютно согласен обеими руками! NAT - это убожество
DM> в таком виде в котором оно есть сейчас. Когда оно жило на 3ем уровне
DM> оно было вполне разумно хотя и практически бесполезно. Когда к нему
DM> добавили букву `P` и приплели элементы 4того - это было оправдано но
DM> уже как-то не до конца продумано - стандарта-то нет. Вобщем мелкие
DM> проблемы с фрагментацией и контрольными суммами уже тут.
С чего такая злость?
Плохими реализациями можно убить что угодно.
DM> Hо мысль пошла дальше и NAT залезло в application но естественно
DM> не разбором всех предыдущих уровней а все так-же full-text-search с 3его.
Это уже кривизна реализации.
Заметь, что я не апологизирую NAT.
DM> stateful firewall невозможно построить? Почему?
По тем же причинам, что и качественный NAT на уровнях выше 4-го.
DM> Все протоколы которые жили под натом совершенно замечательно
DM> впишуться и в firewall. Hо при этом маршрутизатор не будет МЕHЯТЬ
DM> ничего выше своего уровня. И это большой плюс даже если остальная
DM> логика не изменится.
DM> Есть и другой большой плюс. Даже при firewall типа
DM> ckeck-state
DM> pass all from $localnet to any keep-state
DM> drop all
DM> остается возможность соединиться двум замаскараденым хостам.
Это с какого ещё бодуна?
DM> p2p должны пренепременно возрадоваться.
DM> Hасчет MS - писсемизм наверное оправдан HО во-первых `хакеры`
DM> и сейчас чувствуют себя неплохо а во-вторых даже без ipv6 MS обязательно
DM> придумает что-нибудь сногсшибательное - можешь не сомневаться.
Hо сейчас хоть есть метод противодействия этому, хоть и неполный.
А после введения такого - не будет никакого противодействия.
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
