Вкратце объясню, что это такое. IPv6 в течении ближайших нескольких лет придёт на смену IPv4, который сейчас используется повсеместно. Придёт на смену из-за того, что IPv4-адреса закончились. Будут использоваться адреса вида не 192.168.0.1, а 77:0:0:0:0:ff:53:0f, что позволит в будущем дать отдельный «белый» IP всем кофеваркам на земле.

Мы уже можем получить себе «белый» IPv6, и заиметь полный доступ к своему к компьютеру с любого места, где есть IPv6. На IPv6 можно настроить доступ к своему серверу.

Настроим же! Это просто!
Абсолютно бесплатные IPv6-адреса с доменом четвёртого уровня раздаёт туннельный брокер gogo6, через которого мы и будем получать наш туннель.
Но до этого давайте прогуляемся на http://ipv6.google.com и http://test-ipv6.com — вдруг у вас уже есть IPv6?

Гугл не открывается, а «стабильность и готовность IPv6 соединения» на втором сайте- 0/10?
Да, ваш провайдер всё ещё не поддерживает IPv6. В России такое- у 99% абонентов.

Если поддержки IPv6 таки нет- пора его настроить. Получать статический IP мы будем у gogo6- ибо там это делается максимально просто.
1. Сначала регистрируемся тут:
http://www.gogo6.com/profile/gogoCLIENT

2. Переходим по ссылке, что пришла нам на e-mail, заполняем поля. Можете попереводить, а можете просто заполнить «по образцу».

3. Если ссылка на закачку не открылась, переходим по ссылке выше ещё раз, и качем gogoCLIENT Windows Installer своей битности.

4. Теперь- переходим по адресу http://www.gogo6.com/freenet6/account , и выбираем сервер, что нам удобнее. Вбиваем адрес нашего будущего сервера, своё мыло, и пароль.

5. Устанавливаем скачанный ранее клиент.

6. Меняем в клиенте сервер на authenticated.freenet6.net, и вбиваем свой логин/пароль, полученные на шаге 4. Жмакаем apply, connect.

7. Всё! Мы получили статический IPv6-адрес, и домен вида user.broker.freenet6.net!
Ваш IP, и полученный компьютером домен можно посмотреть на вкладке «status».
Перейдите на http://test-ipv6.com . 10/10? Всё отлично!
Теперь вы можете организовать доступ к компьютеру как угодно, и поднять на нём что угодно. Начиная от простого minecraft-сервера для друзей, заканчивая связью компьютера с веб-сайтом. Единственное, что нужно- на компьютере, что подключается к вам, должна быть поддержка IPv6.

Внимание! При подключении по IP, а не по домену, во всех приложениях придётся писать IP не классически, как с IPv4- «127.

Включаем IPv6-доступ без статического адреса.
Как же настроить IPv6 без получения статического адреса, например, на другом компьютере, что нужно подключить к вашему? Очень просто! На понадобится либо uTorrent, либо тот же gogo6 client.
Для начала сходите на http://ipv6.google.com — если тот открывается- настраивать ничего не надо, у вас есть IPv6 от провайдера.

Включаем ipv6 через uTorrent, и Teredo.
1. Качаем uTorrent.
2. Идём в меню «Настройки»->»Настройки программы».
3. Идём в «общие», и нажимаем «Установить IPv6/Teredo».

4. Перезагружаемся, заходим на ipv6.google.com
5. Заработало? Ура, мы часть нового интернета!

Включаем IPv6 через gogonet.
1. Качаем клиент gogonet: http://server.lionovsky.ru/distrib/gogonet.zip .
2. В архиве 2 версии: 32, и 64-бит. Устаналиваем нужное. При возникновении запроса по поводу недподписанного драйвера- соглашаемся.
3. Кликаем next->next, и так далее.
4. После перезагрузки идём в «пуск»-«все программы»-«gogo6»-«gogoClient»-«gogoCLIENT Utility»
5. Проверяем, так ли стоят настройки (по умолчанию- всегда так):

6. Нажимаем кнопку Connect, если она не нажата. Готово- мы в IPv6!
Внимание: в Windows 8 иснсталлер запускать в режиме совместимости с Windows 7!

А ещё- вот вам заметка о преимуществах IPv6.
1. Торренты качаются, и раздаются значительно лучше. Подключив IPv6 вы сможете раздать намного больше контента, что положительно скажется на рейтинге. Вы сможете намного быстрее забрать файлы у сидеров, блокированных NAT.

3. Facebook и vkontakte так же не будут требовать слишком частых подтверждений номера мобильного, так как ваш IPv6-адрес уникален, и с него не поспамит сосед.
4. Провайдеры задирают цены на «белые» IP. В Ленинградской области, например, цена подскочила в 2 раза из-за дефецита адресного IPv4-пространства. Не стоит поддерживать эту тенденцию, и кормить монопилистов- включите IPv6, и забейте на них.
5. IPv6 безопаснее своего предшественника, на котором держится сейчас весь интернет. Новые встроенные алгоритмы шифрования, трудность сканирования адресного пространства на уязвимости. Подсетей же в сотни тысяч раз больше, и 99,9% сейчас- пустые.

Источник:
http://lionovsky.ru/text_nastraivaem_ipv6. html

В представлении IPv6 у нас есть три метода адресации:

Одноадресный адрес: Одноадресный адрес идентифицирует один сетевой интерфейс. Пакет, отправленный на одноадресный адрес, доставляется на интерфейс, идентифицированный этим адресом.
Многоадресный адрес: Многоадресный адрес используется несколькими хостами, называемыми группой, получает адрес назначения многоадресной рассылки.Эти хосты не обязательно должны быть географически вместе. Если на этот многоадресный адрес будет отправлен какой-либо пакет, он будет распределен по всем интерфейсам, соответствующим этому многоадресному адресу.
Anycast Address: Anycast Address назначается группе интерфейсов. Любой пакет, отправленный на произвольный адрес, будет доставлен только на один интерфейс-член (в большинстве случаев возможно ближайший хост).

Примечание. Широковещательная передача не определена в IPv6.

Типы IPv6-адресов:
У нас 128 битов в IPv6-адресах, но, посмотрев на первые несколько битов, мы можем определить, какой это тип адреса.

Примечание: В IPv6 все нули и единицы могут быть назначены любому хосту, нет никаких ограничений, таких как IPv4. 5) используются только 4 идентификатора реестра.

Идентификатор поставщика: В зависимости от количества поставщиков услуг, работающих в регионе, определенные биты будут выделены в поле идентификатора поставщика. Это поле не нужно фиксировать. Допустим, если идентификатор провайдера = 10 бит, тогда идентификатор подписчика будет 56-10 = 46 бит.
Идентификатор подписчика: После того, как идентификатор провайдера зафиксирован, оставшаяся часть может использоваться интернет-провайдером как обычный IP-адрес.
Внутренний абонент: Эта часть может быть изменена в соответствии с потребностями организации, использующей услугу.

Одноадресный адрес на основе географии:

Префикс глобальной маршрутизации: Префикс глобальной маршрутизации содержит все сведения о широте и долготе. На данный момент он не используется. В географии одноадресная маршрутизация адресов будет основана на местоположении.
Идентификатор интерфейса: В IPv6 вместо идентификатора хоста мы используем термин идентификатор интерфейса.

Некоторые специальные адреса:
Не указано —

Loopback —

Совместимость с IPv4 —

Сопоставленный IPv4 —

Локальные одноадресные адреса:
Существует два типа локальных одноадресных адресов: Локальная ссылка и Локальная связь .

Локальный адрес ссылки:

Локальный адрес ссылки используется для адресации по одной ссылке. Его также можно использовать для связи с узлами по тому же каналу. Локальный адрес ссылки всегда начинается с 1111111010 (т.е. FE80). Маршрутизатор не будет пересылать пакеты с локальным адресом Link.

Местный адрес объекта:

Локальные адреса сайта эквивалентны частному IP-адресу в IPv4. Скорее всего, зарезервировано некоторое адресное пространство, которое можно маршрутизировать только внутри организации.Первые 10 битов установлены на 1111111011, поэтому локальные адреса сайта всегда начинаются с FEC0. Следующие 32 бита — это идентификатор подсети, который можно использовать для создания подсети в организации. Адрес узла используется для однозначной идентификации ссылки; поэтому здесь мы используем 48-битный MAC-адрес.

Артикул:

Эта статья предоставлена ​​ Abhishek Agrawal .Пожалуйста, напишите комментарии, если вы обнаружите что-то неправильное, или вы хотите поделиться дополнительной информацией по теме, обсужденной выше.

Вниманию читателя! Не прекращайте учиться сейчас. Получите все важные концепции теории CS для собеседований SDE с помощью курса CS Theory Course по приемлемой для студентов цене и станьте готовым к работе в отрасли.

7.3.2.9/8.3.2.8 Packet Tracer — Устранение неполадок в инструкциях по адресации IPv4 и IPv6, ответы

Packet Tracer — Устранение неполадок при адресации IPv4 и IPv6

Таблица адресации

Цели

, часть 1. Устранение неполадок, первая проблема

, часть 2: устранение второй проблемы

, часть 3. Устранение неполадок, третья проблема

Сценарий

Вы — сетевой специалист, работающий в компании, решившей перейти с IPv4 на IPv6.Тем временем они должны поддерживать оба протокола (двойной стек). Трое сотрудников позвонили в службу поддержки с проблемами и получили ограниченную помощь. Служба поддержки передала этот вопрос вам, специалисту по поддержке уровня 2. Ваша задача — определить источник проблем и внедрить соответствующие решения.

, часть 1. Устранение неполадок, первая проблема

Клиент, использующий PC1 , жалуется, что не может получить доступ к веб-странице dualstackserver. pka .

Шаг 1. Проверьте подробный билет службы поддержки.

Служба поддержки получила от клиента по телефону следующую информацию. Убедитесь, что это правильно.

Шаг 2. Рассмотрите возможные причины сбоя.

а. Обратите внимание на проведенные тесты. Если возможно, обсудите возможные сценарии, которые могут создать такую ​​ситуацию, с другими сетевыми техниками (одноклассниками).

г. Выполните больше тестов, если это поможет визуализировать проблему. Доступен режим моделирования.

Шаг 3: Предложите решение проблемы.

Составьте список вещей, которые можно изменить для решения этой проблемы. Начните с решения, которое, скорее всего, сработает.

Шаг 4: Реализуйте план.

Попробуйте наиболее подходящее решение из списка. Если это уже было сделано, переходите к следующему решению.

Шаг 5. Убедитесь, что решение устранило проблему.

а. Повторите тесты из тикета службы поддержки. Решило ли это проблему?

г. Если проблема все еще существует, отмените изменение, если вы не уверены, что оно правильное, и вернитесь к шагу 4.

Шаг 6: Задокументируйте решение.

Запишите решение проблемы. Если вы когда-нибудь снова столкнетесь с той же проблемой, ваши записи будут очень ценными.
Неверный DNS-адрес IPv4 ПК1.

Решение

, часть 2. Устранение второй проблемы

Клиент, использующий PC2 , жалуется, что не может получить доступ к файлам на DualStackServer.pk a в 2001: DB8: CAFE: 1 :: 10.

Шаг 1. Проверьте подробный билет службы поддержки.

Служба поддержки получила от клиента по телефону следующую информацию. Убедитесь, что это правильно.

Шаг 2: Выполните шаги 2–5 части 1 для решения этой проблемы.

Шаг 3: Задокументируйте решение.

Запишите решение проблемы. Если вы когда-нибудь снова столкнетесь с той же проблемой, ваши записи будут очень ценными.

DualStackServer.pka неверный адрес шлюза IPv6

Решение:

Часть 3. Устранение неполадок третьей проблемы

Клиент, использующий PC1 , жалуется, что не может связаться с PC2 .

Шаг 1. Проверьте подробный билет службы поддержки.

Служба поддержки получила от пользователя по телефону следующую информацию. Убедитесь, что это правильно.

Шаг 2: Выполните шаги 2–5 из Часть 1 для решения этой проблемы.

Шаг 3: Задокументируйте решение.

Запишите решение проблемы. Если вы когда-нибудь снова столкнетесь с той же проблемой, ваши записи будут очень ценными.

Неверный адрес шлюза IPv4 ПК2

Решение:

Загрузите файл Pka и файл PDF ниже:

[Шкафчик] Шкафчик [id = 8545] не существует или шкафчики по умолчанию были удалены.

RFC 4798 — Подключение островов IPv6 через IPv4 MPLS с использованием граничных маршрутизаторов поставщика IPv6 (6PE)

Сетевая рабочая группа J.Де Клерк
Запрос комментариев: 4798 Alcatel-Lucent
Категория: Стандарты Track D. Ooms
                                                              OneSparrow
                                                              С. Прево
                                                                      BT
                                                          Ф. Ле Фошер
                                                                   Cisco
                                                           Февраль 2007 г.


             Подключение островов IPv6 через IPv4 MPLS с использованием
                    Граничные маршрутизаторы провайдера IPv6 (6PE)

Статус этой памятки

   Этот документ определяет протокол отслеживания стандартов Интернета для
   Интернет-сообщество и просит обсуждения и предложения по
   улучшения.Пожалуйста, обратитесь к текущему выпуску "Интернет
   Официальные стандарты протокола »(STD 1) для состояния стандартизации
   и статус этого протокола.  Распространение памятки не ограничено.

Уведомление об авторских правах

   Авторское право (C) IETF Trust (2007 г.).

Аннотация

   В этом документе объясняется, как соединить острова IPv6 через
   Облако IPv4 с поддержкой многопротокольной коммутации по меткам (MPLS). Этот
   подход основан на использовании пограничных маршрутизаторов IPv6 Provider Edge (6PE), которые являются двойными.
   Стек для подключения к островам IPv6 и к ядру MPLS, которое
   требуется только для работы IPv4 MPLS.Маршрутизаторы 6PE обмениваются IPv6
   информация о доступности прозрачно по ядру с помощью
   Многопротокольный протокол пограничного шлюза (MP-BGP) через IPv4. В процессе
   поэтому поле BGP Next Hop используется для передачи IPv4-адреса
   6PE, чтобы динамически устанавливаемая метка MPLS с сигналом IPv4
   Коммутируемые пути (LSP) могут использоваться без явного туннеля
   конфигурация.












Де Клерк и др. Standards Track [Страница 1] 

RFC 4798 6PE февраль 2007 г. 


Содержание

   1.Введение ................................................. ... 2
      1.1. Требования Язык ...................................... 4
   2. Обзор протокола .............................................. .4
   3. Транспортировка через LSP с сигнализацией IPv4 и привязку меток IPv6 ........ 5
   4. Пересечение нескольких автономных систем IPv4 ....................... 7
   5. Соображения безопасности ........................................ 10
   6. Благодарности ...............................................10
   7. Ссылки ............................................... ...... 11
      7.1. Нормативные ссылки ...................................... 11
      7.2. Информационные ссылки .................................... 11

1. Введение

   Существует несколько подходов к обеспечению подключения IPv6 через
   Базовая сеть MPLS [RFC4029], включая (i) требование, чтобы MPLS
   сети поддерживают настройку IPv6-сигнальных маршрутов с коммутацией меток (LSP)
   и установить соединение IPv6 с помощью этих LSP, (ii) использовать
   настроенное туннелирование через LSP с сигнализацией IPv4 или (iii) использовать IPv6
   Подход Provider Edge (6PE), определенный в этом документе. Подход 6PE требуется как альтернатива использованию стандартных
   туннели. Он обеспечивает решение для среды MPLS, в которой все
   туннели устанавливаются динамически, обращаясь к средам
   где усилия по настройке и поддержке явно настроены
   туннели не принимаются.

   Этот документ определяет операции подхода 6PE для
   соединение островов IPv6 через облако IPv4 MPLS. В
   подход требует, чтобы граничные маршрутизаторы, подключенные к островам IPv6, были
   Маршрутизаторы с двойным стеком, поддерживающие протокол BGP [RFC4760], а
   базовые маршрутизаторы необходимы только для работы IPv4 MPLS.Подход использует
   MP-BGP через IPv4 полагается на идентификацию маршрутизаторов 6PE с помощью
   свой IPv4-адрес и использует LSP MPLS с сигнализацией IPv4, которые не
   требуется явная конфигурация туннеля.

   В этом документе используется терминология [RFC2460] и [RFC4364]
   используется.

   В этом документе «остров IPv6» - это сеть, использующая собственный IPv6 как
   согласно [RFC2460].  Типичным примером острова IPv6 может быть
   сайт клиента IPv6, подключенный через маршрутизатор IPv6 Customer Edge (CE)
   к одному (или нескольким) пограничным маршрутизаторам Dual Stack Provider Edge Сервиса
   Провайдер.Эти граничные маршрутизаторы провайдера IPv6 (6PE) подключены к
   Базовая сеть IPv4 MPLS.





Де Клерк и др. Standards Track [Страница 2] 

RFC 4798 6PE февраль 2007 г.


            + -------- +
            | сайт A CE --- + + ----------------- +
            + -------- + | | | + -------- +
                         6PE- + IPv4 MPLS core + -6PE - CE сайт C |
            + -------- + | | | + -------- +
            | сайт B CE --- + + ----------------- +
            + -------- +

             Острова IPv6 Облако IPv4 Остров IPv6
            <-------------> <---------------------> <----------- --->

                                  Рисунок 1

   Метод соединения, описанный в этом документе, обычно
   применяется к интернет-провайдеру (ISP), имеющему IPv4 MPLS
   сеть, знакомая с BGP (возможно, уже предлагающая
   BGP / MPLS VPN), который хочет предложить услуги IPv6 некоторым
   своих клиентов. Однако интернет-провайдер может (пока) не захотеть обновлять
   ядро сети на IPv6, а также использовать только туннелирование IPv6-over-IPv4. С участием
   описанный здесь подход 6PE, провайдеру нужно только обновить
   некоторые маршрутизаторы Provider Edge (PE) для работы с двойным стеком, чтобы они
   ведут себя как маршрутизаторы 6PE (и отражатели маршрутов, если они используются для
   обмен доступностью IPv6 между маршрутизаторами 6PE) при выходе из
   Нетронутые основные маршрутизаторы IPv4 MPLS. Эти маршрутизаторы 6PE обеспечивают
   подключение к островам IPv6.Они также могут предоставлять другие услуги
   одновременно (подключение IPv4, услуги IPv4 L3VPN, L2VPN
   услуги и др.). Также при подходе 6PE туннели не должны быть
   явно настроен, и не нужно вставлять заголовки IPv4 в
   перед пакетами IPv6 между клиентом и поставщиком.

   Интернет-провайдер обеспечивает подключение IPv6 к своим одноранговым узлам и восходящим потокам, используя
   означает, что выходит за рамки этого документа, и его маршрутизаторы 6PE
   повторно объявите его через ядро ​​IPv4 MPLS с помощью MP-BGP. Интерфейс между граничным маршрутизатором острова IPv6 (Клиент
   Edge (CE) маршрутизатор) и маршрутизатор 6PE - это собственный интерфейс IPv6, который
   может быть физическим или логическим. Протокол маршрутизации (IGP или EGP) может работать
   между маршрутизатором CE и маршрутизатором 6PE для распределения IPv6
   информация о доступности. В качестве альтернативы статические маршруты и / или
   маршрут по умолчанию может использоваться на маршрутизаторе 6PE и маршрутизаторе CE для
   контроль достижимости. Остров IPv6 может подключаться к провайдеру
   сеть через более чем один интерфейс.Подход 6PE, описанный в этом документе, может быть использован для клиентов.
   у которых уже есть служба IPv4 от поставщика сети и
   дополнительно требуется услуга IPv6, а также для клиентов, которые
   требуется только подключение по IPv6.




Де Клерк и др. Стандарты Track [Страница 3] 

RFC 4798 6PE февраль 2007 г.


   Сценарий также описан в [RFC4029].

   Обратите внимание, что подход 6PE, указанный в этом документе, обеспечивает глобальные
   Доступность IPv6. Поддержка IPv6 VPN не входит в объем
   этот документ и рассматривается в [RFC4659].

   Развертывание подхода 6PE в существующем облаке IPv4 MPLS делает
   не требует внедрения новых механизмов в ядро ​​(кроме
   потенциально те, которые описаны в конце раздела 3 для работы с
   динамическое обнаружение MTU). Конфигурация и работа 6PE
   подход имеет много общего с конфигурацией и
   операции службы IPv4 VPN ([RFC4364]) или службы IPv6 VPN
   ([RFC4659]) через ядро ​​IPv4 MPLS, потому что все они используют MP-BGP для
   распространять информацию о доступности не-IPv4 для транспорта по
   Ядро IPv4 MPLS.Однако конфигурация и работа 6PE
   подход несколько проще, так как он не задействует все VPN
   такие концепции, как таблицы виртуальной маршрутизации и пересылки (VRF).

1.1. Требования Язык

   Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «НЕ ДОЛЖНЫ»,
   «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом
   документ следует интерпретировать, как описано в RFC 2119 [RFC2119]. 

2. Обзор протокола

   Каждый сайт IPv6 подключен как минимум к одному маршрутизатору Provider Edge, который
   находится на границе облака IPv4 MPLS.Мы называем такой
   маршрутизатор маршрутизатор 6PE. Маршрутизатор 6PE ДОЛЖЕН иметь двойной стек IPv4 и
   IPv6. Маршрутизатор 6PE ДОЛЖЕН быть настроен как минимум с одним IPv4.
   адрес на стороне IPv4 и хотя бы один адрес IPv6 на стороне IPv6
   боковая сторона. Настроенный адрес IPv4 должен быть маршрутизируемым в IPv4.
   облако, и должна быть метка, привязанная через метку IPv4
   протокол распространения на этот маршрут IPv4.

   В результате каждый рассматриваемый маршрутизатор 6PE знает, какой MPLS
   метка для отправки пакетов на любой другой маршрутизатор 6PE.Обратите внимание, что
   Сеть MPLS, предлагающая услуги BGP / MPLS IP VPN, уже выполняет эти
   требования.

   В облаке IPv4 не нужно вводить дополнительные маршруты.

   Мы называем маршрутизатор 6PE, получающий пакеты IPv6 от сайта IPv6,
   входящий маршрутизатор 6PE (относительно этих пакетов IPv6).  Мы называем 6PE
   маршрутизатор, пересылающий пакеты IPv6 на сайт IPv6, выходящий маршрутизатор 6PE
   (относительно этих пакетов IPv6).





Де Клерк и др. Стандарты Track [Страница 4] 

RFC 4798 6PE февраль 2007 г.


   Происходит соединение островов IPv6 через облако IPv4 MPLS
   через следующие шаги:

   1.Обмен информацией о доступности IPv6 между маршрутизаторами 6PE с MP-
      BGP [RFC2545]:

      Маршрутизаторы 6PE ДОЛЖНЫ обмениваться префиксами IPv6 через MP-BGP.
      сеансы согласно [RFC2545], работающие по IPv4. Адрес MP-BGP
      Используемый идентификатор семейства (AFI) ДОЛЖЕН быть IPv6 (значение 2). При этом
      маршрутизаторы 6PE передают свой IPv4-адрес как BGP Next Hop для
      объявленные префиксы IPv6. IPv4-адрес выходящего 6PE
      маршрутизатор ДОЛЖЕН быть закодирован как IPv4-сопоставленный адрес IPv6 в BGP.
      Поле следующего прыжка.Эта кодировка соответствует определению
      отображаемого IPv4-адреса IPv6 в [RFC4291] как "тип адреса
      используется для представления адресов узлов IPv4 как адресов IPv6 ". 
      Кроме того, 6PE ДОЛЖЕН привязать метку к префиксу IPv6 в соответствии с
      [RFC3107]. Используемый идентификатор семейства адресов подпоследовательности (SAFI)
      в MP-BGP ДОЛЖЕН быть SAFI «метка» (значение 4), как определено в
      [RFC3107]. Обоснование этого и политики присвоения меток
      обсуждается в разделе 3.

   2.Транспортировать пакеты IPv6 от входящего маршрутизатора 6PE к выходному
      Маршрутизатор 6PE через LSP с сигнализацией IPv4:

      Входящий маршрутизатор 6PE ДОЛЖЕН пересылать данные IPv6 через IPv4-
      сигнализировал LSP к выходному маршрутизатору 6PE, идентифицированному IPv4
      адрес, объявленный в IPv4-сопоставленном IPv6-адресе BGP Next
      Перейдите к соответствующему префиксу IPv6.

   В соответствии со спецификацией BGP [RFC4271] маршрутизаторы PE образуют
   полная пиринговая сетка, если не используются Отражатели маршрута.

3. Транспортировка через LSP с сигнализацией IPv4 и привязку меток IPv6.

   В этом подходе IPv4-сопоставленные адреса IPv6 позволяют маршрутизатору 6PE
   который должен переслать пакет IPv6 для автоматического определения
   LSP с сигнализацией IPv4 для использования в конкретном месте назначения IPv6 путем поиска
   в информации о маршрутизации MP-BGP. LSP с сигнализацией IPv4 могут быть установлены с использованием любых существующих
   метод установки метки [RFC3031] (LDP, RSVP-TE и т. д.).

   Для обеспечения взаимодействия между системами, реализующими 6PE
   подход, описанный в этом документе, все такие системы ДОЛЖНЫ поддерживать
   туннелирование с использованием сигнальных IPv4 LSP MPLS, установленных LDP [RFC3036].

   При туннелировании пакетов IPv6 через магистраль IPv4 MPLS, а не
   последовательно добавить заголовок IPv4 и затем выполнить наложение метки



Де Клерк и др.Standards Track [Страница 5] 

RFC 4798 6PE февраль 2007 г.


   на основе заголовка IPv4 входящий маршрутизатор 6PE ДОЛЖЕН напрямую
   выполнить наложение метки заголовка IPv6 без добавления каких-либо
   Заголовок IPv4. Наложенная (внешняя) метка ДОЛЖНА соответствовать IPv4-
   сигнализирует LSP, начинающийся на входящем маршрутизаторе 6PE и заканчивающийся на
   выходной маршрутизатор 6PE.

   Хотя этот подход теоретически может работать в некоторых ситуациях
   использование одного уровня этикеток дает значительные преимущества в
   используя второй уровень меток, которые привязаны к префиксам IPv6 через
   Рекламные объявления MP-BGP в соответствии с [RFC3107]. Например, использование метки второго уровня позволяет Penultimate Hop
   Popping (PHP) на маршрутизаторе с коммутацией меток IPv4 (LSR) в восходящем направлении от
   выходящий маршрутизатор 6PE без каких-либо возможностей / обновлений IPv6 на
   предпоследний роутер; это потому, что он все еще передает пакеты MPLS
   даже после PHP (вместо того, чтобы передавать пакеты IPv6 и
   инкапсулируйте их соответствующим образом).

   Кроме того, существующий LSP с сигнализацией IPv4, который использует "IPv4 Explicit NULL
   метка "на последнем переходе (например, потому что этот LSP уже
   используется для передачи трафика IPv4 с помощью туннелирования Pipe Diff-Serv Tunneling
   Модель, как определено в [RFC3270]) не может использоваться для передачи IPv6 с
   одиночная метка, так как "Явная метка NULL IPv4" не может использоваться для
   переносить собственный трафик IPv6 (см. [RFC3032]), в то время как его можно использовать для
   переносят помеченный трафик IPv6 (см. [RFC4182]).Вот почему вторая метка ДОЛЖНА использоваться с подходом 6PE. 

   Метка, привязанная MP-BGP к префиксу IPv6, указывает на исходящий
   6PE Router, что пакет является пакетом IPv6. Этот лейбл рекламировал
   выходным маршрутизатором 6PE с MP-BGP МОЖЕТ быть произвольным значением метки,
   который определяет контекст маршрутизации IPv6 или исходящий интерфейс для
   отправить пакет или МОЖЕТ быть явной нулевой меткой IPv6. An
   Маршрутизатор ingress 6PE ДОЛЖЕН быть в состоянии принять любую такую ​​объявленную метку.

   [RFC2460] требует, чтобы каждая ссылка в Интернете IPv6 имела MTU.
   1280 октетов или больше.Следовательно, на ссылках MPLS, которые используются для
   транспорт IPv6 в соответствии с подходом 6PE, который не поддерживает
   фрагментация и повторная сборка для конкретных каналов, MTU должен быть
   настроен как минимум на 1280 октетов плюс служебные данные инкапсуляции.

   Некоторые хосты IPv6 могут отправлять пакеты, размер которых превышает MTU.
   доступны в ядре IPv4 MPLS и полагаются на обнаружение MTU пути для
   узнайте об этих ссылках.  Чтобы упростить операции обнаружения MTU, один
   вариант для сетевого администратора, чтобы спроектировать MTU на
   интерфейсы входа 6PE, обращенные к ядру, согласуются с ядром
   MTU.ICMP-сообщения "Packet Too Big" могут быть отправлены обратно
   входящий 6PE без соответствующих пакетов, когда-либо поступающих в MPLS



Де Клерк и др. Стандарты Track [Страница 6] 

RFC 4798 6PE февраль 2007 г.


   ядро. В противном случае маршрутизаторы в сети IPv4 MPLS имеют возможность
   генерировать ICMP-сообщение "Packet Too Big", используя такие механизмы, как
   описано в Разделе 2.3.2, «Туннелирование частных адресов через
   Public Backbone »[RFC3032].Обратите внимание, что в приведенном выше случае основной маршрутизатор с исходящим
   ссылка с MTU меньше 1280 получить инкапсулированный IPv6
   пакет больше, чем 1280, то механизмы [RFC3032] могут привести
   в сообщении "Packet Too Big" не доходит до отправителя. Это
   потому что, согласно [RFC4443], основной маршрутизатор будет создавать ICMP
   Сообщение "Packet Too Big" заполнено вызывающим пакетом размером до 1280
   байтов, а при пересылке в нисходящем направлении к выходному PE согласно
   [RFC3032], MTU исходящего канала приведет к тому, что пакет будет
   упал. Это может вызвать серьезные проблемы в работе; то
   отправитель пакетов заметит, что его данные не получают
   через, не зная, почему и куда их выбрасывают. Этот
   проблема может возникнуть только в том случае, если приведенная выше рекомендация (для настройки MTU
   на каналах MPLS не менее 1280 октетов плюс накладные расходы инкапсуляции)
   не соблюдается (возможно, из-за неправильной конфигурации).

4. Пересечение нескольких автономных систем IPv4

   В этом разделе обсуждается случай, когда подключены два острова IPv6.
   в разные автономные системы (АС).Как в случае с операциями магистрали с несколькими AS для IPv4 VPN
   описанный в разделе 10 [RFC4364], можно выделить три основных подхода:
   отличился:

   а. eBGP перераспределение маршрутов IPv6 от AS к соседней AS

      Этот подход эквивалентен обмену маршрутами IPv6 на
      процедура (a), описанная в разделе 10 [RFC4364] для
      обмен маршрутами VPN-IPv4.

      В этом подходе маршрутизаторы 6PE используют IBGP (согласно [RFC2545]
      и [RFC3107] и как описано в этом документе для одиночной AS
      ситуации) для перераспределения помеченных маршрутов IPv6 либо
      Пограничный маршрутизатор автономной системы (ASBR), маршрутизатор 6PE, или к маршруту
      отражатель, клиентом которого является маршрутизатор ASBR 6PE. ASBR тогда
      использует eBGP для перераспределения (немаркированных) маршрутов IPv6 в ASBR
      в другой AS, которая, в свою очередь, распределяет их по маршрутизаторам 6PE
      в этой AS, как описано ранее в этой спецификации, или, возможно,
      другому ASBR, который, в свою очередь, распространяет их и т. д.







Де Клерк и др. Стандарты Track [Страница 7] 

RFC 4798 6PE февраль 2007 г.


      Может быть одно или несколько соединений ASBR через любую
      две AS.IPv6 необходимо активировать на каналах между ASBR и
      каждый маршрутизатор ASBR 6PE имеет как минимум один IPv6-адрес на
      интерфейс к этой ссылке.

      LSP между AS не используются. Фактически есть отдельная сетка
      LSP через маршрутизаторы 6PE в каждой AS.

      При таком подходе ASBR, обменивающийся маршрутами IPv6, может передавать
      IPv6 или IPv4. Обмен маршрутами IPv6 ДОЛЖЕН осуществляться как
      согласно [RFC2545].

      Обратите внимание, что одноранговая ASBR в соседней AS, к которой подключен IPv6
      маршруты были распределены с помощью eBGP, должны, в свою очередь, перераспределять
      эти маршруты к 6PE в своей AS с использованием IBGP и кодирования собственного
      IPv4-адрес в качестве IPv4-сопоставленного IPv6 BGP Next Hop. б. eBGP перераспределение маркированных маршрутов IPv6 от AS к соседним
      В ВИДЕ

      Этот подход эквивалентен обмену маршрутами IPv6 на
      процедура (b), описанная в разделе 10 [RFC4364] для
      обмен маршрутами VPN-IPv4.

      В этом подходе маршрутизаторы 6PE используют IBGP (как описано ранее.
      в этом документе для ситуации с одной AS) для распространения
      маркированные маршруты IPv6 либо к пограничному маршрутизатору автономной системы
      (ASBR) 6PE маршрутизатор, или к отражателю маршрута, у которого ASBR 6PE
      роутер - это клиент.Затем ASBR использует eBGP для перераспределения
      помеченные маршруты IPv6 к ASBR в другой AS, которая, в свою очередь,
      распределяет их на маршрутизаторы 6PE в этой AS, как описано
      ранее в этой спецификации или, возможно, в другой ASBR, который
      в свою очередь распространяет их и т. д.

      Может быть одно или несколько соединений ASBR через любую
      две AS. IPv6 может или не может быть активирован на меж-ASBR
      ссылки. 

      Этот подход требует наличия путей с переключением меток.
      установлены через AS.Отсюда соответствующие соображения
      описанная для процедуры (b) в разделе 10 [RFC4364] применяется
      в равной степени подходит этот подход для IPv6.

      При таком подходе ASBR, обменивающийся маршрутами IPv6, может передавать
      IPv4 или IPv6 (в этом случае, очевидно, необходимо активировать IPv6
      по ссылке между ASBR). При пиринге через IPv6 обмен
      маркированные маршруты IPv6 ДОЛЖНЫ выполняться в соответствии с [RFC2545] и
      [RFC3107]. При пиринге через IPv4 обмен помеченными IPv6



Де Клерк и др.Стандарты Track [Страница 8] 

RFC 4798 6PE февраль 2007 г.


      маршруты ДОЛЖНЫ выполняться в соответствии с [RFC2545] и [RFC3107] с
      кодирование IPv4-адреса ASBR как IPv4-сопоставленного IPv6
      адрес в поле BGP Next Hop.

   c. Многоступенчатое перераспределение eBGP помеченных маршрутов IPv6 между
      исходная и конечная AS, с перераспределением eBGP помеченных
      IPv4 направляет из AS в соседнюю AS. Этот подход эквивалентен обмену маршрутами IPv6 на
      процедура (c), описанная в разделе 10 [RFC4364] для обмена
      Маршруты VPN-IPv4.

      При таком подходе маршруты IPv6 не поддерживаются и не
      распространяются маршрутизаторами ASBR. Маршрутизаторы ASBR не должны быть
      двойной стек, но могут быть маршрутизаторы только для IPv4 / MPLS. ASBR должен
      поддерживать маркированные маршруты IPv4 / 32 к маршрутизаторам 6PE в своей AS.
      Он использует eBGP для распространения этих маршрутов на другие AS.ASBR в
      любые транзитные AS также должны будут использовать eBGP для передачи
      помеченные маршруты IPv4 / 32. Это приводит к созданию IPv4
      Путь с коммутацией меток от входящего маршрутизатора 6PE к выходному 6PE
      роутер. Теперь маршрутизаторы 6PE в разных AS могут устанавливать многопоточность.
      eBGP соединяются друг с другом через IPv4 и могут обмениваться помеченными
      Маршруты IPv6 (с IPv4-сопоставленным IPv6 BGP Next Hop) по этим
      соединения. 

      IPv6 не нужно активировать на каналах между ASBR.Соображения, описанные для процедуры (c) в Разделе 10
      [RFC4364] в отношении возможного использования многоузлового eBGP.
      соединения через рефлекторы маршрутов в разных АС, а также
      в отношении использования третьей метки в случае, если IPv4 / 32
      маршруты для маршрутизаторов PE НЕ сообщаются маршрутизаторам P,
      в равной степени применимы к этому подходу для IPv6.

      Этот подход требует наличия путей с коммутацией меток IPv4.
      устанавливается через AS, ведущие от входящего пакета 6PE
      маршрутизатор к его выходному маршрутизатору 6PE.Отсюда соображения
      описана для процедуры (c) в разделе 10 [RFC4364], с
      в отношении LSP, охватывающих несколько AS, в равной степени применяются
      подход для IPv6.

      Также обратите внимание, что обмен маршрутами IPv6 может начаться только после
      BGP создал соединение IPv4 между AS.








Де Клерк и др. Стандарты Track [Страница 9] 

RFC 4798 6PE февраль 2007 г. 


5. Соображения безопасности

   Расширения, определенные в этом документе, позволяют распространять протокол BGP.
   информация о доступности маршрутов IPv6 через ядро ​​MPLS IPv4
   сеть.Таким образом, не возникает никаких новых проблем безопасности, кроме тех
   которые уже существуют в BGP-4 и используют MP-BGP для IPv6.

   Функции безопасности BGP и соответствующая политика безопасности
   определенные в домене ISP.

   Для распределения маршрутов IPv6 между AS в соответствии со случаем (а) из
   В разделе 4 этого документа никаких новых вопросов безопасности не возникает, кроме
   те, которые уже существуют при использовании eBGP для IPv6 [RFC2545].

   Для распределения маршрутов IPv6 между AS в соответствии со случаем (b)
   и (c) Раздела 4 настоящего документа, процедуры требуют, чтобы
   через границы AS должны быть установлены пути с коммутацией меток.Следовательно, между и
   среди множества АС вдоль пути. Необходимо соблюдать осторожность, чтобы избежать
   "подделка ярлыков".  С этой целью ASBR 6PE ДОЛЖЕН принимать только маркированные
   пакетов от его партнера ASBR 6PE, если самая верхняя метка является меткой, которая
   он явно сообщил этому партнеру ASBR 6PE.

   Обратите внимание, что для распределения маршрутов IPv6 между AS, согласно
   случай (c) Раздела 4 настоящего документа, подделка этикеток может быть более серьезной.
   трудно предотвратить.Действительно, метка MPLS, распространяемая с
   Маршруты IPv6 через multi-hop eBGP отправляются напрямую от выходного 6PE.
   для ввода 6PE в другую AS (или через отражатели маршрута). Этот
   метка прозрачно рекламируется через границы AS. когда
   исходящий 6PE, отправивший помеченные маршруты IPv6, получает данные
   пакет, у которого есть эта конкретная метка поверх своего стека, он не может
   иметь возможность проверить, была ли метка помещена в стек
   вход 6PE, которому это разрешено.Таким образом, одна AS может быть
   уязвим для подделки меток в другой AS. Та же проблема
   в равной степени относится к варианту (c) раздела 10 [RFC4364].  Просто
   как и в случае с [RFC4364], обращаясь к этой конкретной безопасности
   вопрос требует дальнейшего изучения.

6. Благодарности

   Мы хотим поблагодарить Жерара Гасто и Эрика Леви-Абеньоли, которые
   способствовал этому документу. Мы также хотим поблагодарить Три Т. Нгуен,
   кто инициировал этот документ, но, к сожалению, тоже много скончался
   скоро.Мы также благодарим Пекку Саволу за его ценные комментарии и
   предложения.






Де Клерк и др. Стандарты Track [Страница 10] 

RFC 4798 6PE февраль 2007 г.


7. Ссылки

7.1. Нормативные ссылки

   [RFC2119] Брэднер, С. "Ключевые слова для использования в RFC для обозначения
              Уровни требований », BCP 14, RFC 2119, март 1997 г.

   [RFC2460] Диринг, С. и Р. Хинден, «Интернет-протокол, версия 6
              (IPv6) Specification », RFC 2460, декабрь 1998 г.[RFC2545] Маркес, П. и Ф. Дюпон, "Использование мультипротокола BGP-4
              Расширения для междоменной маршрутизации IPv6 », RFC 2545, март
              1999 г.

   [RFC3032] Розен, Э., Таппан, Д., Федорков, Г., Рехтер, Ю.,
              Фариначчи, Д., Ли, Т., и А. Конта, "Стек этикеток MPLS
              Кодирование », RFC 3032, январь 2001 г.

   [RFC3036] Андерссон, Л., Дулан, П., Фельдман, Н., Фредетт, А., и
              Б. Томас, "Спецификация LDP", RFC 3036, январь 2001 г.

   [RFC3107] Рехтер Ю.и Э. Розен, "Информация о маркировке в
              BGP-4 ", RFC 3107, май 2001 г.

   [RFC4291] Хинден, Р. и С. Диринг, "Адресация IP версии 6
              Архитектура », RFC 4291, февраль 2006 г.

   [RFC4760] Бейтс, Т., Чандра, Р., Кац, Д., и Ю. Рехтер,
              «Многопротокольные расширения для BGP-4», RFC 4760, январь
              2007 г.

7.2. Информативные ссылки

   [RFC3031] Розен, Э., Вишванатан, А., и Р. Каллон, "Многопротокольная
              Архитектура коммутации меток », RFC 3031, январь 2001 г.[RFC3270] Ле Фошер, Ф., Ву, Л., Дэви, Б., Давари, С., Ваананен,
              П., Кришнан, Р., Шеваль, П. и Дж. Хейнанен, "Мульти-
              Переключение меток протокола (MPLS) Поддержка дифференцированного
              Услуги », RFC 3270, май 2002 г.

   [RFC4029] Линд, М., Ксинант, В., Парк, С., Бодо, А., и П.
              Савола, "Сценарии и анализ внедрения IPv6 в
              ISP Networks », RFC 4029, март 2005 г.

   [RFC4182] Розен, Э., «Снятие ограничения на использование MPLS.
              Explicit NULL », RFC 4182, сентябрь 2005 г.Де Клерк и др. Стандарты Track [Страница 11] 

RFC 4798 6PE февраль 2007 г.


   [RFC4271] Рехтер, Й., Ли, Т., и С. Харес, "Пограничный шлюз
              Протокол 4 (BGP-4) », RFC 4271, январь 2006 г.

   [RFC4364] Розен, Э. и Я. Рехтер, "Виртуальный частный IP-адрес BGP / MPLS
              Сети (VPN) », RFC 4364, февраль 2006 г.

   [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
              Протокол сообщений (ICMPv6) для Интернет-протокола
              Версия 6 (IPv6) Specification », RFC 4443, март 2006 г.[RFC4659] Де Клерк, Дж., Оомс, Д., Каруги, М., и Ф. Ле Фошер,
              "Расширение BGP-MPLS IP Virtual Private Network (VPN) для
              IPv6 VPN ", RFC 4659, сентябрь 2006 г.






































Де Клерк и др. Стандарты Track [Страница 12] 

RFC 4798 6PE февраль 2007 г.


Адреса авторов

   Джереми де Клерк
   Alcatel-Lucent
   Copernicuslaan 50
   Антверпен 2018
   Бельгия

   Электронная почта: Джереми[email protected]


   Дирк Оомс
   OneSparrow
   Belegstraat 13
   Антверпен 2018
   Бельгия

   Электронная почта: [email protected]


   Стюарт Прево
   BT
   Комната 136 Polaris House, Adastral Park, Martlesham Heath
   Ипсвич Суффолк IP5 3RE
   Англия
   Электронная почта: [email protected]


   Франсуа Ле Фошер
   Cisco
   Domaine Green Side, Авеню де Руманиль, 400
   Биот, София Антиполис 06410
   Франция

   Электронная почта: [email protected]
















Де Клерк и др. Стандарты Track [Страница 13] 

RFC 4798 6PE февраль 2007 г.


Полное заявление об авторских правах

   Авторское право (C) IETF Trust (2007 г.).На этот документ распространяются права, лицензии и ограничения.
   содержится в BCP 78, и, за исключением случаев, изложенных в нем, авторы
   сохраняют все свои права.

   Этот документ и содержащаяся в нем информация размещены на
   Принцип «КАК ЕСТЬ» и ПОСТАВЩИК, ОРГАНИЗАЦИЯ, ПРЕДСТАВЛЯЕМЫЕ ОН / ОНА
   ИЛИ СПОНСИРУЕТСЯ (ЕСЛИ ЕСТЬ) ИНТЕРНЕТ-ОБЩЕСТВОМ, IETF TRUST И
   ИНТЕРНЕТ-ИНЖИНИРИНГ TASK FORCE ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНОЙ
   ИЛИ ПОДРАЗУМЕВАЕМЫЕ, ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯ НИКАКИХ ГАРАНТИЙ НА ИСПОЛЬЗОВАНИЕ
   ПРИВЕДЕННАЯ ИНФОРМАЦИЯ НЕ НАРУШАЕТ НИКАКИХ ПРАВ ИЛИ ПОДРАЗУМЕВАЕМЫХ
   ГАРАНТИИ КОММЕРЧЕСКОЙ ЦЕННОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ.Интеллектуальная собственность

   IETF не занимает никакой позиции относительно действительности или объема любых
   Права интеллектуальной собственности или другие права, которые могут быть заявлены
   относятся к реализации или использованию технологии, описанной в
   этот документ или степень, в которой любая лицензия на такие права
   может быть, а может и нет; и не означает, что
   предпринял какие-либо независимые усилия для выявления таких прав. Информация
   о процедурах в отношении прав в документах RFC может быть
   найдено в BCP 78 и BCP 79.Копии разглашения прав интеллектуальной собственности в секретариат IETF и
   гарантии предоставления лицензий или результат
   попытка получить генеральную лицензию или разрешение на использование
   такие права собственности разработчиками или пользователями этого
   спецификацию можно получить из он-лайн репозитория IETF IPR по адресу
   http://www.ietf.org/ipr.

   IETF приглашает любую заинтересованную сторону довести до ее сведения любые
   авторские права, патенты или заявки на патенты или другие проприетарные
   права, которые могут распространяться на технологии, которые могут потребоваться для реализации
   этот стандарт.Пожалуйста, направьте информацию в IETF по адресу
   [email protected].

Подтверждение

   Финансирование функции редактора RFC в настоящее время обеспечивается
   Интернет-общество.







Де Клерк и др. Стандарты Track [стр. 14]