IPv6: почему бы не использовать / 126 на каналах P2P для IPv6?

В IPv4 мы используем / 30 для сохранения адресов. Так почему некоторые люди рекомендуют использовать / 64 на P2P-ссылках вместо / 126? Я использую / 64 в обычных подсетях, но не использую / 64, когда в P2P-ссылках будет когда-либо использоваться только два адреса, огромная трата адресов?

Многие из нас используют / 126 в ссылках PTP. Мне лично нравится иметь возможность идентифицировать что-то как PTP-соединение сетевой инфраструктуры, основываясь только на первых 64 битах адреса, поэтому я оставляю за собой / 64 для получения / 126 из. У разных людей разные мнения о том, что важно, так что ... пожимай плечами

Кстати (# 1), поскольку IPv6 не имеет понятия широковещательного адреса или сетевого адреса в IP-сети, вы можете использовать / 127 вместо / 126. Имейте в виду, что хотя сетевые маски / 127 являются вполне допустимыми, некоторые механизмы поставщиков (ошибочно) не допустили их, считая сетевые маски / 127 «недействительными», что означает, что вы можете столкнуться с проблемами поддержки некоторых поставщиков, если решите попробовать их использовать. Вот почему я использую / 126.

Между прочим (# 2), если ваши ссылки действительно определены как ссылки PTP, вы должны иметь возможность использовать любые IP-адреса, при этом они вообще не должны находиться в общей IP-сети.

Ответ состоит из двух частей.

Во-первых, чтобы ответить на ваш вопрос напрямую: официальная рекомендация по этой теме изменилась. В прошлом RFC 3627 назывался «Использование длины префикса / 127 между маршрутизаторами, считающимися вредными». Однако текущая рекомендация отличается, однако: RFC 6164 рекомендует использовать / 127 (а не / 126!) В двухточечных каналах. В обоих RFC изложены причины соответствующих рекомендаций.

Вторая часть ответа заключается в том, что , как правило, вне связи точка-точка, IPv6 будет порывать с любым префиксом длиннее / 64. На самом деле это не сам IPv6, а многие используемые им протоколы, такие как SLAAC, обнаружение соседей и т. Д. Поскольку двухточечная связь не предусматривает какой-либо формы обнаружения, такое рассмотрение не имеет значения, и / 127 буду работать.

Потому что IPv6 всегда рекомендует использовать / 64 для всех ссылок.

Для второй части вопроса, это пустая трата времени?

A / 64 имеет 18,446,744,073,709,551,615 или 18 квинтиллионных адресов.

Большинство подсетей IPv4 имеют менее 255 хостов. Предположим, что у вас есть сеть с 255 хостами, и им дан префикс / 64. Это означает, что 255 хостам назначен адрес v6, а 18,446,744,073,709,551,360 адресов не используются. Это более 99,99%. Чтобы быть более точным, это шестнадцать девяток или, по сути, 100% «отходов».

Даже если у вас есть подсеть с 1 000 000 хостов, это 18,446,744,073,708,551,616 потерянных адресов, или все еще более 99,99%. Только тринадцать девяток на этот раз, но все равно эффективно на 100% «отходы».

Таким образом, разница в процентах между использованием миллиона адресов или двух адресов в одной ссылке незначительна.

И чтобы вы могли видеть, как выглядят эти цифры.

* Two hosts is 99.9999999999999999891579782751449556599254719913005828857422% unused.
* 255 hosts is 99.9999999999999986176422300809818466404976788908243179321289% unused.
* 1M  hosts is 99.99999999999457898913757247782996273599565029144287109375% unused.
* 4B  hosts is 99.999999976716935634613037109375% unused.

Даже весь Интернет IPv4, размещенный на одной ссылке / 64, фактически оставит 100% адресов неиспользованными. Когда вы смотрите на числа, подобные этому, использовать что-либо кроме / 64 в ссылке просто глупо.

Поэтому, как провайдер, я хотел добавить комментарий к этому. В частности, мы используем как GUA, так и ULA (уникальные локальные адреса) для нашей внутренней маршрутизации. Это означает, что у нас есть блок (/ 48) из пула GUA / 32, но мы фильтруем по краям, превращая их в ULA. Большая / 32 GUA все еще рекламируется, но / 48 ULA отфильтровывается по нашим краям. Мы используем этот ULA для большей части наших внутренних потребностей адресации (в зависимости от AS), а также для PtP-ссылок.

Все наши PtP-ссылки представляют собой полный блок / 64, однако они специально настроены как / 127 на маршрутизаторах. Это было сделано специально для борьбы с пинг-понгом, когда это возможно в пространстве IPv4 и IPv6. Вы редко видите это в пространстве IPv4, потому что мы все используем / 30s для PtP-ссылок там. Однако в пространстве IPv6 использование / 64 создает возможность для этих типов атак (см. Https://tools.ietf.org/html/rfc6164#section-5.1 ).

Как упоминалось ранее, выделение / 64 для этих ссылок кажется пустой тратой, но, как только вы потратите много времени на составление плана адресов IPv6 (хорошее чтение - https://www.amazon.com/IPv6-Address-Planning- Designing-Future-ebook-dp-B00PCZMAOW / dp / B00PCZMAOW ) вы видите, что НАМНОГО проще никогда не углубляться в рамки / 64 в ваших планах.

Также, как упоминалось ранее, поскольку мы говорим только о PtP-ссылках, / 127 не страдает ни от каких обычных проблем, выходящих за пределы / 64. Почему мы не используем ненумерованные адреса для PtP-ссылок? В основном для отладки, отслеживания, мониторинга и т. Д.

--- Я забыл упомянуть (после перечитывания некоторых комментариев выше ...) Если вы используете / 126 в качестве вашей PtP-ссылки, вы все еще страдаете от той же проблемы с пинг-понгом, что и / 64. Почему? Поскольку биты 00 и 11 в ваших / 126 являются действительными адресами IPv6 (тогда как в IPv4 это не так, они служат другой цели). Таким образом, хотя / 32 (два бита из / 32) работает для IPv4, / 127 (1 бит из / 128) - это то, что вам нужно для IPv6.