IPv6: различия между «маршрутизируемым префиксом» и «префиксом ссылки»?

Каковы точные различия между «префиксом маршрутизации» и «префиксом ссылки» для IPv6?
Как эти различия в Wireshark-Trace? (если вы наблюдаете Хост с назначенным «маршрутизируемым префиксом» или Хост с назначенным «префиксом связи»).
Как эти различия в протоколе обнаружения соседей? (с точки зрения другого / внешнего хоста) Работают
ли они вместе , эти два типа префиксов?

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

Пример иерархии

Интернет-провайдеру был присвоен префикс от RIR (Региональный Интернет-реестр), который в этом примере, как мы предположим, будет 2001:db8::/32. Этот префикс отличается от тех, которые передаются клиентам, в том смысле, что интернет-провайдер должен будет объявить его через BGP другим интернет-провайдерам, с которыми он работает.

Интернет-провайдер теперь собирается назначать префиксы клиенту. Сначала они назначаются 2001:db8:0:1::/64каналу, соединяющему маршрутизатор ISP и маршрутизатор CPE (оборудование абонентской базы). Это префикс ссылки, потому что он назначен ссылке. Как общая рекомендация, все префиксы ссылок в IPv6 должны быть /64.

Маршрутизатор ISP отправит объявления маршрутизатора с объявлением этого префикса, а CPE будет использовать SLAAC для создания адреса для внешнего интерфейса, указывающего на маршрутизатор ISP внутри /64. Давайте предположим, что внешний интерфейс получил IP-адрес 2001:db8:0:1:42:ff:fe00:42/64(в этой нотации /64указано, чтобы напомнить нам, какова длина префикса ссылки, но я мог бы также не указывать его).

Этот префикс связи достаточен для связи маршрутизатора CPE с остальным миром, но он не помогает маршрутизатору CPE поддерживать клиентов в локальной сети, подключенных к его внутреннему интерфейсу. Маршрутизатор CPE нуждается в префиксе для локальной сети, которая маршрутизируется через этот маршрутизатор CPE, поэтому он называется маршрутизируемым префиксом .

Маршрутизируемый префикс может быть настроен статически или через DHCPv6. Точные подробности того, как маршрутизатор CPE согласовывает длину префикса с сервером DHCPv6, предоставленным поставщиком услуг Интернета, выходят за рамки этого ответа. Поиск делегирования префиксов может рассказать вам больше об этом. Давайте предположим, что маршрутизируемый префикс заканчивается 2001:db8:1::/48. На маршрутизаторе ISP будет создана запись в таблице маршрутизации, указывающая, что 2001:db8:1::/48необходимо маршрутизировать через шлюз 2001:db8:0:1:42:ff:fe00:42. Эта запись в таблице маршрутизации является определяющей функцией маршрутизируемого префикса.

Маршрутизатор CPE может иметь несколько внутренних локальных сетей, из которых /48он может выделять /64префикс канала для каждой внутренней локальной сети. Если мы предположим, что одна из локальных сетей была назначена в 2001:db8:1:1::/64качестве префикса канала, то узел этой линии может получить адрес 2001:db8:1:1::42:ff:fe00:43через SLAAC. Этот узел может быть беспроводным маршрутизатором, которому требуется префикс для его беспроводного интерфейса. CPE может назначить 2001:db8:1:100::/60маршрутизированный префикс для беспроводного маршрутизатора, а беспроводной маршрутизатор может назначить 2001:db8:1:100::/64префикс канала для беспроводного интерфейса.

Теперь в такой настройке мы имеем иерархию префиксов. Следующее все вложено друг в друга:

• 2001:db8::/32 BGP объявил префикс
• 2001:db8:1::/48 маршрутизируемый префикс
• 2001:db8:1:100::/60 маршрутизируемый префикс
• 2001:db8:1:100::/64 префикс ссылки

Как на самом деле обрабатываются пакеты

Когда маршрутизатор ISP получает пакет, для 2001:db8:0:1::/64которого есть префикс канала, он выполняет обнаружение соседей, чтобы найти MAC-адрес хоста в /64.

Таким образом, маршрутизатору ISP потребуется отдельная запись кэша соседей для каждого IP-адреса в префиксе канала.

Когда маршрутизатор ISP получает пакет, для 2001:db8:1::/48которого является маршрутизируемый префикс, он выполняет обнаружение соседей, чтобы найти MAC-адрес шлюза 2001:db8:0:1:42:ff:fe00:42.

Таким образом, маршрутизатору ISP требуется только одна запись кэша соседа для шлюза, чтобы маршрутизировать пакеты на любой IP-адрес в маршрутизируемом префиксе. Это свойство имеет решающее значение для масштабируемости Интернета.

Обойти отсутствие маршрутизируемого префикса

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

• Обычно маршрутизируемые префиксы должны быть короче /64, но демон, отвечающий на запросы обнаружения соседей, может создать только «маршрутизированный» префикс, который длиннее, чем /64.
• Это немного увеличивает задержку из-за дополнительного обхода каждый раз, когда IP-адрес отсутствует в соседнем кэше на маршрутизаторе ISP.
• Это увеличивает нагрузку на маршрутизатор ISP из-за необходимости гораздо более частого обнаружения соседей. Вполне вероятно, что маршрутизатор ISP может пересылать пакеты к уже известному префиксу назначения исключительно аппаратно, но обнаружение соседей будет сделано программно.
• Это увеличивает потребление памяти на маршрутизаторе ISP. Если интернет-провайдер назначает маршрутизируемый префикс каждому клиенту, он может легко получить только одну запись в соседнем кэше для каждого клиента. Но с демоном соседнего респондента это может превратиться в тысячи записей на клиента.

Затраты на обработку на маршрутизаторе ISP могут быть существенной проблемой. Некоторые маршрутизаторы были настолько плохо при обработке потока пакетов , требующих обнаружение соседей , что он превратился в реальные атаки DoS, а также с помощью более длинных ссылок префиксов (в /120- 127диапазоне) была использовано в качестве временного решения для таких атак DoS.

Даже если маршрутизатор не уязвим для атаки DoS, память, необходимая для записей соседнего кэша при использовании описанного выше обходного пути, намного дороже для интернет-провайдера, чем IP-адреса для маршрутизируемого префикса, поэтому нет особых причин для интернет-провайдера отказаться от выдачи маршрутизированного префикса.

Особые случаи вокруг двухточечных ссылок

В двухточечных каналах (таких как туннели 6in4 и каналы PPP) нет необходимости в обнаружении соседей. Существует только одно направление для отправки пакета по такой ссылке, и перед отправкой пакета не нужно искать аппаратный адрес.

Это означает, что издержки обнаружения соседей не являются проблемой для такой ссылки. Таким образом, использование одного конца двухточечной связи с использованием большого количества адресов не является проблемой, если конечные точки имеют некоторое соглашение о том, кто использует какие адреса. Отсутствие обнаружения соседей означает, что также не обнаруживается повторяющийся адрес, поэтому, если обе конечные точки попытаются использовать один и тот же адрес, он не будет работать должным образом (если только вы не ожидаете, что он будет действовать как произвольный адрес).

Есть одно предостережение, о котором нужно помнить в отношении ссылок «точка-точка». Каждая конечная точка будет предполагать, что все адреса в ссылке, которой она не назначена, назначены другому концу. Это означает, что неиспользуемые адреса в соединении точка-точка склонны инициировать цикл маршрутизации. Такого цикла маршрутизации (и нескольких других случаев циклов маршрутизации) можно избежать, если конечная точка никогда не отправит пакет обратно обратно на узел, от которого он был получен. Таким образом, пакет, полученный от двухточечной линии связи, не должен отправляться обратно по одной и той же двухточечной линии связи, пока одна конечная точка получает это право, цикл маршрутизации прерывается. В качестве побочного узла в Ethernet допустимо принимать пакет и пересылать его обратно по тому же каналу, но рекомендуется избегать этого, если он будет перенаправлен обратно на тот же MAC-адрес, с которого он был получен.

Поскольку большинство адресов в двухточечной ссылке просто перенаправляются на другой конец ссылки без необходимости обнаружения соседей, это выглядит очень похоже на маршрутизируемый префикс. Например, если интернет-провайдер назначил 2001: db8: 42 :: / 64 для двухточечной связи с конечными точками, которым назначены адреса 2001: db8: 42 :: 1 и 2001: db8: 42 :: 2, то пакеты будут отправлены на большинство адресов. в 2001: db8: 42 :: / 64 будет перенаправлен от интернет-провайдера клиенту точно так же, как если бы это был маршрутизированный префикс, использующий 2001: db8: 42 :: 2 в качестве шлюза.

Это означает, что определенный взлом возможен. На CPE можно фактически настроить 2001: db8: 42 :: / 64 в качестве префикса канала в локальной сети. Чтобы CPE узнал, на какой из двух ссылок определенное место назначения включено, фактическую конфигурацию двухточечной связи к провайдеру необходимо изменить на 2001: db8: 42 :: / 126. Все это будет работать с одним незначительным исключением: хосты в локальной сети не могут обмениваться данными с четырьмя IP-адресами в 2001 году: db8: 42 :: / 126. Поскольку им, вероятно, в любом случае не нужно было общаться с ними, это не является серьезной проблемой. Однако не рекомендуется использовать этот хак, правильная конфигурация - получить маршрутизированный префикс от провайдера.

Еще один способ сохранить адреса - выделить глобальные адреса только для маршрутизируемого префикса и использовать адреса RFC 4193 для связи точка-точка. Это, однако, глупый взлом, поскольку он все еще имеет некоторые недостатки для решения несуществующей проблемы.

Также возможно вообще не назначать никакого префикса для связи точка-точка. Пока у каждой конечной точки есть другой интерфейс, на котором у нее есть глобальный адрес, они могут использовать адрес, назначенный другому интерфейсу, при обмене данными по каналу точка-точка. Я не знаю каких-либо недостатков этого подхода, поэтому, если вы обнаружите, что этот подход для связи «точка-точка» упрощает конфигурацию вашей сети, не стесняйтесь использовать его, но не используйте его в качестве меры для сохранения адресов.

Варианты использования для маршрутизируемого префикса

• Иерархическая маршрутизация, как в моем первом примере, предназначена для маршрутизируемых префиксов.
• VPN / туннели добавляют еще один уровень в иерархию маршрутизаторов, нуждающихся в префиксах. Хотя они являются виртуальными, а не реальными аппаратными средствами, они не отличаются в плане адресации и нуждаются в маршрутизируемом префиксе, как физическая ссылка.
• Назначение множества адресов хосту . Существуют варианты использования для назначения большого количества адресов одному хосту. Для нескольких адресов они могут быть просто назначены и обработаны с обнаружением соседей для каждого и столько же записей кэша, сколько существует адресов. Но если нужны тысячи адресов, лучше использовать маршрутизируемый префикс.

Более подробный пример последнего пункта - это рекурсоры DNS. Поскольку я не вижу, чтобы DNSSEC набирал обороты, пока мы не закончили борьбу с IPv4, необходимы другие меры против отравления DNS. Усилия были направлены на то, чтобы получить как можно больше энтропии в запросах. Идентификатор и номер порта могут содержать не более 32 бит энтропии, еще несколько бит могут быть сохранены в запросе, если прописные и строчные буквы смешиваются в имени домена, которое должно быть разрешено. Таким образом, вы редко получите более 48 бит. Назначение полного значения /64для рекурсора DNS позволило бы увеличить энтропию на 64 бита за один раз, что больше, чем все остальные усилия вместе взятые.

Префикс связи используется между вашим маршрутизатором и вашим провайдером.

Направленный префикс используется внутри вашей сети.

Если вы получите маршрутизируемый префикс / 64 от вашего интернет-провайдера, то вы просто попросите маршрутизатор объявить этот префикс в вашей локальной сети. Если вы получили префикс меньше / 64 (возможно, / 48?), Вам следует подумать о том, как логически подсетить этот префикс для использования всеми вашими маршрутизаторами в вашей организации.

В Wireshark, в зависимости от того, где вы перехватываете пакеты, вы можете видеть только используемый маршрутизируемый префикс (если вы перехватываете в локальной сети), или вы можете видеть оба используемых префикса (если вы перехватываете в глобальной сети).

Что касается протокола обнаружения соседей, он также зависит от ссылки. На линии связи между провайдером и вашим маршрутизатором NDP используется для определения MAC-адреса интерфейса WAN вашего маршрутизатора и MAC-адреса вышестоящего маршрутизатора вашего провайдера. На вашем интерфейсе локальной сети NDP используется для обнаружения MAC-адреса хостов в вашем сегменте локальной сети.

Надеюсь это поможет.

Префикс - это маршрутизируемый префикс, если пакеты с этим префиксом должны проходить через маршрутизатор, чтобы достичь места назначения. Префикс - это префикс канала, если он находится в сегменте, к которому подключен интерфейс локальной сети.

Поскольку пакет путешествует по Интернету, целевой / 64, на который он нацелен, будет маршрутизированным префиксом, пока вы не достигнете последнего прыжка. Тогда это будет префикс ссылки.

Маршрутизируемые префиксы обычно агрегируются. Многие / 64 могут быть объединены в один более короткий префикс, чтобы уменьшить размер таблиц маршрутизации. На границе между интернет-провайдерами обычно устанавливается максимальная длина префикса / 48.

Если префикс имеет значение от / 0 до / 63, вы обычно можете предположить, что это префикс с маршрутизацией. Если префикс / 64, вам нужно больше информации, чтобы узнать, является ли он префиксом с маршрутизацией или ссылкой.