Re: IPv6

От Valentin Nechayev (2:5020/400) к Ivan Shmakov

From: Valentin Nechayev <netch@segfault.kiev.ua>

>>> Ivan Shmakov wrote:

 IS>> А вот смотреть на клиентов, имеющих 24/7 1 TB Torrent-сервер в сети

 IS>> провайдера, которым, спасибо NAT, приходится пользоваться услугами

 IS>> чего-нибудь вроде narod.ru -- весьма грустно.

 VN>> Значит, провайдер жлобский.  Он тебе и на v6 отдаст один адрес

 VN>> вместо сети, и будешь лапу сосать.  А ещё и NAT подымет.

IS> 	Если они попытаются экономить на том, на чем сэкономить едва ли

IS> 	возможно в принципе, то это будет уже не <<жлобство>>.

IS> 	К слову, провайдер не так уж плох.  Во-первых, их появление, на

IS> 	мой взгляд, стимулировало ощутимое снижение цен на

IS> 	<<широкополосный доступ>> в городе.  (В региональном филиале

IS> 	Сибирьтелекома, похоже, осознали, что и с ними могут

IS> 	конкурировать.)

Если серые адреса были временным решением - понятно, такое бывает. Hо

если через год он не начнёт давать нормальные адреса - это уже

жлобство.

IS> 	BTW, я не уверен, что каждому клиенту нужно выделять именно

IS> 	сеть.  Ясно, однако, что едва ли есть причины ограничивать

IS> 	клиента одним адресом.  С точки зрения реализации -- можно

IS> 	применять NDP proxy на маршрутизаторе.

К сожалению, в IPv6 длина префикса более 64 на бродкастовых

интерфейсах (Ethernet, etc.) невозможна, большинство стеков сойдут с

ума. Поэтому меньший блок чем /64 не выдадут. Больший - могут.

 IS>> Да, считать нагрузку, создаваемую на сеть провайдера данными

 IS>> клиента, станет, пожалуй, несколько сложнее -- тут привязкой

 IS>> сетевого адреса к порту <<умного>> коммутатора не обойтись.  Hо

 IS>> такие подсчеты -- уже не столь критичны для flat rate.

 VN>> Привязку сделают по первым /64, не проблема.

IS> 	Это, пожалуй, наиболее простое решение.

IS> 	Есть подозрение, что IPsec, IKEv2, защищенный DNS, и наличие у

IS> 	каждого клиента по закрытому ключу и сертификату на каждый

IS> 	используемый адрес позволило бы получить полностью защищенную

IS> 	сеть, при желании -- в т. ч. и между клиентами.

IS> 	Впрочем, я не уверен, что у <<компетентных органов>> не

IS> 	возникнет каких-либо вопросов в отношении такой схемы.

Ещё и IPSec сюда примешивать и вообще любую шифрацию - по-моему,

перебор. Вообще тут самый безопасный вид сети - кабельный (DOCSIS).

Если сделать Ethernet-свичи с эмуляцией этого подхода (у VLAN есть

одна вершина и всё, исходящее не из неё, в неё наливается) - это решит

большинство типичных проблем домосеток.

 VN>> Для зверей типа нашей "Воли" /48 нереально, а вот /60 - вполне.

 IS>> Или 16 по /64.  ... И почему бы не позволить клиенту иметь в сети 1

 IS>> .. 1000 адресов в таком случае?  Особенно при назначении их DHCP

 IS>> (похоже, еще один способ идентифицировать клиента?) или через RA?

 VN>> Это куда?

IS> 	Что именно?

Для начала, что такое RA в данном случае?

 IS>> В случае острой необходимости пропустить некий протокол между двумя

 IS>> IP-адресами через firewall, можно закрыть глаза на безопасность и

 IS>> сделать (src, dst, proto) -> allow.  При использовании NAT -- все,

 IS>> приехали.

 VN>> Это слишком грубое решение.  Разрешить, например, весь TCP означает

 VN>> фактически открыть таз миру.

IS> 	Проблема в том, что если firewall не умеет некоторый протокол,

IS> 	его можно разрешить для данной пары адресов на firewall, после

IS> 	чего управлять доступом настраивая firewall на той конкретной

IS> 	системе, где оный протокол требуется.

Идея понятна, но реализация такого фактически означает снова иметь

полный файрволл на клиентской машине. Hа которой он ой не всегда может

быть настроен правильно и тем более не всегда так настраивается.

Я этот вариант поэтому не учитываю - не следует перекладывать на

посторонних.

--netch--

--- ifmail v.2.15dev5.4

 * Origin: Dark side of coredump (2:5020/400)

Ответы на это письмо:

From: Username
Заголовок следующего сообщения в треде может быть длинным и его придется перенести на новую строку

From: Username
Или коротким