IPv6 для провайдеров

Вы находитесь здесь: version6.ru » IPv6 для провайдеров
Эта страница — только для чтения. Вы можете посмотреть исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
====== IPv6 для провайдеров ======
//Впервые опубликовано 2012-01-19//

===== Где взять? =====
==== Ваш магистрал ====
У большинства магистральных операторов IPv6 уже имеется, даже если он пока и не предлагается клиентам как коммерческая услуга. Если вы решили заняться внедрением IPv6, первым делом свяжитесь с вашим магистралом и спросите его о сроках начала предоставления IPv6. Весьма вероятно, что данный процесс на их стороне тормозится существующим мнением об отсутствии спроса на данную услугу -- которое будет частично опровергнуто вашим звонком. 

Неполный список магистралов, про которых известно, что они уже начали выдачу IPv6-транзита своим клиентам:
  * Комстар-Директ (AS8359)
  * Мегафон (AS31133)
  * Orange Business (AS2854)
  * ReTN (AS9002)
  * Ростелеком (AS12389)
  * RTcomm (AS8342)
  * РТцентр (AS39293)
  * СтартТелеком (AS8744)
  * ТТК (AS20485)

==== Другой магистрал ====
  * Известный многим [[http://tunnelbroker.net/|туннельный брокер Hurricane Electric]] помимо ориентированных на конечного пользователя туннелей предлагает также бесплатный IPv6-транзит для операторов посредством организации BGP-пиринга через IPv6-туннель.
  * [[http://streamv6.net/|Комстар-Директ]] предлагает услугу транзита IPv6 с подключением к сети через туннель поверх IPv4.

==== 6to4.ru ====
В рамках проекта [[http://6to4.ru/|6to4.ru]] создаётся виртуальная точка обмена траффиком на базе 6to4-адресов и динамического туннелирования IPv6 поверх IPv4. Основной акцент здесь делается не на раздачу одним оператором full-view всем остальным, а на равноправный пиринг участников.

===== Как раздать? =====
Наиболее распространённой является двухступенчатая схема:
  * получение домашним роутером клиента одного IPv6-адреса на WAN-интерфейсе (например через SLAAC в случае IPoE, или IPv6CP в случае PPPoE/PPTP/L2TP);
  * получение этим роутером посредством DHCPv6-PD подсети для нарезки её на более мелкие /64 и дальнейшей их раздачи через свои LAN и WiFi-интерфейсы.

В случае, если в качестве терминирующего подключение устройства выступает обычный компьютер без настроенной маршрутизации, процесс может ограничиться первым пунктом.

===== Сколько раздавать? =====
В ранних RFC и рекомендациях RIR'ов звучала цифра /48 на каждого конечного пользователя. Позже от этого решено было отказаться, и в [[http://www.rfc-editor.org/rfc/rfc6177.txt|обновлённом RFC]] говорится о необходимости "простого получения более чем одной /64". 

Почему одной /64 -- недостаточно? Дело в том, что SLAAC требует для работы по /64 на одну физическую сеть, и нельзя предполагать, что такая сеть у конечного пользователя всегда только одна. Простейший пример -- у пользователя может возникнуть необходимость иметь в квартире:
  * проводную Ethernet-сеть;
  * WiFi для собственных устройств (в целях безопасности - не бриджем с Ethernet);
  * WiFi для гостевых устройств, с доступом из неё только в Интернет.

Поэтому разумным значением на сегодня выглядит выдача подсетей по /56, при желании же сэкономить, можно подумать о /60.

  * [[http://www.rfc-editor.org/rfc/rfc6177.txt|Рекомендации по размеру подсети для конечных пользователей]]
  * [[http://www.bircd.org/annoyances/prefix64/|beware's annoyances - /64 prefix]]

===== Можно ли убрать IPv4? =====
В условиях недостатка IPv4-адресов, возникает вопрос, можно ли часть абонентов "пересадить" на IPv6, а v4-адреса им не давать. К сожалению на настоящий момент в качестве коммерческой услуги IPv6-only доступ нежизнеспособен. Причина проста: хотя и существует технология NAT из IPv6 в IPv4, называемая [[nat64|NAT64]], при её использовании у абонентов не будут работать не поддерживающие IPv6 приложения, а также протоколы, внедряющие на application-level буквальные IPv4-адреса. Среди таковых -- FTP, P2P, VoIP и практически все онлайновые игры.
  * [[http://tools.ietf.org/html/rfc6586|IPv6-only Experience]]
  * https://tools.ietf.org/html/draft-hazeyama-widecamp-ipv6-only-experience-00

Поэтому рабочим вариантом на обозримое будущее видится совмещение выдачи "серого" IPv4-адреса, и одновременно с ним -- реального диапазона IPv6-адресов. IPv6 в данной ситуации поможет значительно разгрузить IPv4 NAT, "оттянув" с него заметную часть трафика (это как минимум весь YouTube и значительная часть торрентов), а также снизить для абонента критичность наличия реального IPv4 (т.к. к примеру при необходимости настроить подключение из интернета к домашнему компьютеру по RDP или VPN, это можно будет сделать по его IPv6-адресу).

===== Где обсудить? =====
Дискуссии о внедрении IPv6 с точки зрения оператора связи периодически ведутся [[http://forum.nag.ru/forum/index.php?showforum=1|на форуме nag.ru]], а также [[/irc|в IRC-каналах об IPv6]].

===== Полезные ссылки =====
  * [[http://www.ciscoexpo.ru/expo2011/downloads/materials/sp/D3_IPv6_anidlis.pdf|Внедрение IPv6 в сетях широкополосного доступа]] (PDF)
  * [[http://is.park.ru/doc.jsp?listno=2167541&listpg=3&listcd=9&listmd=22&listfile=pub&urn=34849235|Вопросы внедрения IPv6 в сетях широкополосного доступа]]
for-isp.1346907930.txt.gz · Последние изменения: 2012-09-06 05:05 UTC От rm
	Новости
	Сообщество
	Twitter
	IRC
Views

Навигация

Personal Tools

Поиск

Инструменты

Ссылки
