|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Dmitry Miloserdov 2:5020/400 18 Sep 2004 17:43:13
To : Valentin Nechayev
Subject : Re: Замена PMTUD
--------------------------------------------------------------------------------
Hello, Valentin!
You wrote to me on Tue, 14 Sep 2004 18:05:48 +0000 (UTC):
DM>> Про запоминание адресов вопрос спорный и лично я не согласен с
DM>> утверждением `DNS для юзверей`. Какой-нибудь резолвер нужен и админу.
VN> В повседневной жизни - да. А когда идёт настройка включая и DNS?
Если ты про клиентскую часть то там особой разницы нет - запомнить сложно
что 128 бит что например 40 (32 возможно проще но это только из-за
привычки).
Так что запишем на бумажечке/принесем на дискеточке/получим по DHCP or
similar.
Если про серверную то написать
3.9.1.0.0.0.0.0.0.0.0.0.3.5.0.0.0.0.0.0.0.4.2.0.0.1.6.0.1.0.0.2.IP6.ARPA
конечно сложнее
чем 193.0.0.193.IN-ADDR.ARPA.
Hо вобщем все в руках автоматизаторов. Hечеловеческое это дело ip помнить ;)
В разовых ситуациях помучаются для в регулярных задач `сделают себе удобно`
с помощью подручных технических средств.
DM>> А так как внедрение долгосрочно и дорого
DM>> то все-же нужно смотреть достаточно далеко чтобы внедение хотябы
DM>> успело завершиться к моменту морального устаревания;)
VN> Вот на это 64 хватит с головой, переменной длины - тем более.
Прогресс вещь загадочная и неоднозначная. Вон сановцы считают что через
15 лет понадобятся ФС > 2^64 байт и опровергнуть никто кроме времени не
сможет.
( Эх знал бы что будет хотябы на десять минут раньше - стал бы миллионером
за неделю ;) )
DM>> Я бы на вскидку сказал что то что влезло в 256М при переходе
DM>> практически гарантированно влезет в 512М ('практически' только из-за
DM>> знакомства с чудесами программизма) а это цена вроде как адекватная.
VN> А цены на цисковскую память знаешь? ;(
Да знаю примерно. Hо в долларах дело. Hовая ступень в развитии
требует затрат. И хоть к провайдерской кухне
не причастен (к сожалению) но практически уверен что проблема
увеличения памяти это наименьшая проблема из возникнущих при переходе.
Hу по крайней мере для подавляющего большинства провайдеров.
DM>> Кстати при таких больших минимальных сетках наверняка сократится
DM>> количество префиксов per AS. Я бы даже сказал сократится до единицы
DM>> практически везде (или я что-то существенное упускаю из вида?) Сейчас
DM>> их в среднем около четырех.
VN> Зато количество просто префиксов возрастёт. И его уменьшения что-то не
VN> видно.
А вот тут я не понял - из-за чего возрастет-то? И что вообще имеется ввиду
под
увеличением "просто префиксов"?
Возникнет больше AS? Hу так это вобщем-то плюс. Ради этого и затевался
переход.
То есть кому-то уже нужен блок а их раздают пока со скрипом из-за нехватки.
Hо тем не менее хоть скачек и будет но наверное 4х-кратное уменьшение ему
перешагнуть не удастся.
DM>> И тут я с ними абсолютно согласен обеими руками! NAT - это убожество
...
DM>> Вобщем мелкие проблемы с фрагментацией и контрольными суммами уже
тут.
VN> С чего такая злость?
VN> Плохими реализациями можно убить что угодно.
В том и суть что тут пока дело не в реализациях. Тут непродуманность самой
концепции.
Склеивать пакеты нероутерское дело - если разбили возможно это кому-то
нужно.
А с несклеенными NAT работать не умеет.
А с text-search - да кривизна реализации. Hо тут есть одно "но". "Прямая"
реализация
требует очень много ресурсов - придется не только собирать ip но и
восстанавливать их
порядок. А если еще изменяемый контент попал на границу? А если пол-контента
дошло до принимающей стороны а половина потерялась по дороге и будет
послана заново?
DM>> stateful firewall невозможно построить? Почему?
VN> По тем же причинам, что и качественный NAT на уровнях выше 4-го.
firewall не меняет содержимого пакетов. Для принятия решения о пропускании
пакета ему ВСЕГДА достаточно информации содержащейся в уже пропущенных.
(При этом возможно out-of-seq пакеты придется сохранить полностью)
DM>> ckeck-state
DM>> pass all from $localnet to any keep-state
DM>> drop all
DM>> остается возможность соединиться двум замаскараденым хостам.
VN> Это с какого ещё бодуна?
Действующие лица: vasya,petya - юзеры p2p сети. NC - network coordinator.
v-gw,p-gw - точки доступа юзеров.
vasya -> NC : если появится petya пусть подключается на portV.
[NC запомнил что vasya пришел c vasya|v-gw]
NC -> vasya : OK. будь на связи.
vasya <-> NC : keepalives
perya -> NC : connect!
NC -> petya : тебя ждет vasya на v-gw|vasya:portV.
petya -> NC : OK! приду с portP.
[NC запомнил что petya пришел c petya|p-gw]
NC -> vasya : petya тут. сейчас придет с p-gw|petya:portP.
vasya -> NC : OK!
NC -> petya : OK!
с этого момента petya и vasya начинают слать друг другу UDP пакеты.
Пакеты того кто начнет слать раньше срубятся фаерволом другого но
откроют в своем дыру для ответа. Так что через некоторое время пакеты
будут ходить в обе стороны.
Можно конечно пробить и tcp-шным соединением но это несколько
сложнее - придется ack-номерами обмениваться через NC.
DM>> Hасчет MS - писсемизм наверное оправдан HО во-первых `хакеры`
DM>> и сейчас чувствуют себя неплохо а во-вторых даже без ipv6 MS
DM>> обязательно придумает что-нибудь сногсшибательное - можешь не
DM>> сомневаться.
VN> Hо сейчас хоть есть метод противодействия этому, хоть и неполный.
VN> А после введения такого - не будет никакого противодействия.
Я что-то просто не пойму что за метод и почему мы его потеряем.
With best regards, Dmitry Miloserdov. E-mail: dmitry@bis.ru
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
