IPv6 теория и практика: введение в IPv6

[DoMoVoY]

Региональные регистраторы давно уже дают /32 сеть по умолчанию или больше адресов, если сможешь обосновать зачем. /48 более актуально для PI сетей.

[amarao]

LIR'ы получают /32, на тренинге говорили, что надо стремиться к одному размеру выделяемого клиентам сегмента. Рекомендовано (примерно): /56 на заявку, если есть необходимость в нескольких сетях клиента — /48, если есть более-менее адекватное обоснование — до /32 на клиента (в этом случае LIR'у выдают ещё одну /32).

LIR, который выдаёт клиентам /64, будет побит камнями, потому что если в BGP будут анонсить квинтиллионы /64, то компания «сисько системсь» озолотится, барыжа маршрутизаторы с терабайтами памяти под full view.

Таким образом становится понятно, почему сисько рекомендует LIR'ам выдавать побольше /64 и поменьше агрегированных сетей.

[bebebe]

Вы так говорите (про анонсы /64 в BGP), как, например, сейчас провайдеры якобы вываливают в full view каждый ipv4 /32, который они выдают каждому домашнему роутеру на PPPoE. Ну такого же нет. Зачем вы вводите людей в заблуждение?

[amarao]

Статью поправили. В оригинале было так, что лиры должны клиентам 64 выдавать.

[rootman]

Подпрваил только опечатку "… а провайдер добавляет от себя ещё 16 бит и получает 65536 сетей с префиксом...", было "… получает 216 сетей..." и то что помечено как UPD.

[bebebe]

Ну если у вас есть какой-то пиринг с админом-идиотом на той стороне — то вас жаль.

[PTPtupit]

/32 иногда анонсят аплинкам, которые умеют blackhole community :)

[DoMoVoY]

/64 — это минимальный рекомендуемый префикс в основном для механизмов stateless настройки ipv6-адресов. Также начиная от такой длины префикса аппаратные роутеры/коммутаторы оптимально используют TCAM память.

Нынешняя выдача операторам /32 аналогична выдаче /24 ipv4 (если учитывать размер кусочка от всего пирога адресного пространства ipv6 и ipv4), но /32 ipv6 оператор может использовать на более чем 100000 абонентов (в ipv4 на то потребовалось бы префикса /15).

[PTPtupit]

«Также начиная от такой длины префикса аппаратные роутеры/коммутаторы оптимально используют TCAM память.»
Вы не могли бы пояснить почему?

[DoMoVoY]

потому что для префикса /64 достаточно хранить саму сеть, т.е. 64бита и длину префикса, то в случае /65-/128 нужно хранить префикс большей длины, а учитывая, что самые распространенные архитектуры 32бит или 64бит, то получаем увеличение необходимой памяти в 1,5-2 раза или невозможность коммутации по таким префиксам аппаратно и обработка происходит на CPU.

[rootman]

Вполне разумно звучит.

[Ovsiannikov]

rfc3177
основная идея в том, что такая схема очень удобна, т.е.
провайдеру удобно выделять всем абонентам префиксы одинаковой длины, удобно выдать настройки один раз и не менять.
удобно когда все блоки одинакового размера, у всех провайдеров, а 2^64 — достаточно всем, даже очень крупным предприятиям, с кучей филиалов.
/48 на провайдера, потому что 48+(8+8)=64 и т.п.
ещё придумывают разные экспериментальные протоколы, для которых важно предположение, что первые 64 бита — сеть, а следующие 64 — хост.

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

[rootman]

Тут надо смотреть не слева направо а справа налево. Фишка /64 в том, чтобы все (!) клиентские сети были одного размера. То есть, даже если мы поместим в одну ethernet сеть все возможные мак-адреса, то получим только 48 бит занятых в хостовой части. А что касается заканчивающихся адресов — просто посчитайте. Оставшиеся 64 бита — это очень много. Опять же, тут уже писали, что выдаётся сейчас только диапазон начинающийся на двойку, на сколько я помню. Соответственно, если он закончится быстрее планируемого, то дальше можно будет попробовать поменять схему. Впрочем, вряд ли изменения коснутся хостовой части адреса, уж больно много всего завязано сейчас на эти /64 Скорее пересмотрят использование адресов в маленьких сетях точка-точка, или не будут выдавать провайдерам по /32

[MrSelfDestruct]

Раньше и ipv4 тоже довольно-таки щедро раздавался. Не так, как ipv6, но всё равно щедро.

[mafet]

Кажется у меня появился шанс понять ipv6, спасибо за статью!

[rootman]

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

[bebebe]

Автор, объясните, чем мне помогут ::ffff:xxxx:xxxx-адреса. Вы уверяете, что

Эти адреса используются для устройств, не поддерживающих IPv6

Вот у меня есть железка X, умеющая только ipv4. Что дальше?

[rootman]

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

[bebebe]

В смысле? Вы уверяете это в статье. Я спрашиваю, что и как конкретно.
Теперь вы отказываетесь от своих слов.

Простите, но ваша статья ужасно сырая и в голове каша.

[TrueBers]

Mapped-адреса используются, прежде всего, в dual-stack. Когда создаётся один сокет IPv6 на оба протокола ( IPv4 и IPv6 ), и везде используется IPv6 адреса. Т. е. если через этот сокет пришли данные через IPv4, адрес будет показан всё равно в виде вышеописанного IPv6 mapped-адреса. На канальном уровне разницы не будет вообще. Там будет старый добрый IPv4, разница только в в унификации отображения для пользователя.

[rootman]

Спасибо — этого мне очень не хватало.

[agmt]

По сути, чтобы можно было писать сервера, не задумываясь о IPv4: создаёшь сокет «socket(AF_INET6, SOCK_STREAM, 0)» и если через setsockopt не поставить IPV6_V6ONLY, то библиотека сама будет преобразовывать отправку на IPv6 адрес ::ffff:xxxx:xxxx в отправку на IPv4 xx.xx.xx.xx (и в обратную сторону при приёме, естественно, т.е. будут прослушиваться оба порта IPv6:yyyy и IPv4:yyyy).

[Alexeyslav]

Это вообще дырка для совместимости с IPv4 сетью, чтобы вообще была теоретическая возможность из IPv6 сети без проблем взаимодействовать с IPv4 сетью через аппаратные шлюзы. Потом когда нибудь это всё уйдет в историю, а пятно останется.

[TrueBers]

Вы о каких шлюзах? Mapped-адреса на канальном и сетевом уровне ничем не отличаются от нативного IPv4. Они используются только чтобы представить для пользователя v4 адрес в формате v6. Железо не знает таких адресов, вы, вероятно, путаете с NAT64.

[Alexeyslav]

Я имею в виду переходник из IPv6 сети в IPv4 для устройств которые вообще не в курсе что есть в мире IPv6 но вынужденные по каким-то причинам работать в IPv6 сетях. Наверно это и есть NAT64. В любом случае для избежания конфликтов должен быть зарезервирован диапазон адресов.

[SFx]

когда есть только железка IPv4 — это все не имеет смысла.
но когда есть железка с IPv6, и с нее надо достучаться до железки с поддержкой только IPv4

вот так можно сделать ping 192.168.10.1 через IPv6

C:\>ping ::ffff:c0a8:0a01

Обмен пакетами с 192.168.10.1 по с 32 байтами данных:
Ответ от 192.168.10.1: число байт=32 время=1мс TTL=64
Ответ от 192.168.10.1: число байт=32 время=5мс TTL=64
Ответ от 192.168.10.1: число байт=32 время=2мс TTL=64
Ответ от 192.168.10.1: число байт=32 время=2мс TTL=64

Статистика Ping для 192.168.10.1:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 1мсек, Максимальное = 5 мсек, Среднее = 2 мсек

В данном случае пингуется шлюз-роутер, у которого нет IPv6 (и никогда не будет :( )

[TrueBers]

Да, но при этом используется на обоих узлах чистый IPv4. Тут не используется IPv6 как протокол! Используется только визуальный формат в виде IPv6, дальше по стеку идёт чистейший IPv4, который вообще не знает о v6, т. к. получает уже преобразованный чистый 32-битный IPv4.
Достучаться с IPv6-only железки до IPv4-only железки через такой адрес невозможно!

[SFx]

что в этой статье и указано.

[naszar]

А можете рассказать про IPv6 и IPSec? Как-то уже спрашивал дали только ссылку, из которой следует что поддерживается это только в Linux. Но насколько? Уже можно пользоваться, или шифрование еще в стадии разработки? Просто когда говорят про IPv6, говорят что у него есть шифрование и это круто. Хочется подробностей.

[Karroplan]

а почему нет ни слова про anycast? они хоть и не выделаются в отдельный префикс, на как один из типов адресов достойны упоминания…

[rootman]

Про anycast будет пара слов в следующей статье, но глобально я в нём не очень ориентируюсь. Если у вас есть хорошие материалы — было бы интересно почитать

[SFx]

Согласно, RFC4291, у нас, выходит, только одни Loopback адрес ::1?
Получается нет больше 127.0.0.1 — 127.255.255.255 такого диапазона loopback'ов (если конечно не использовать Mapped-адреса: ::ffff:7f00:2)?

[rootman]

Тут как раз ничего странного, меня наоборот всегда интересовало, зачем в IPv4 стооолько адресов для лупбэков. Я как-то не чувствую что лупбэков мало. ;-)

[foxmuldercp]

127.0.1.1, 127.1.1.1 это кроме «каноничного» 127..0.1 оторые я встречал в реальных конфигах.
Ну с цисками там понятно, в маршрутизации эти лупбек адреса достаточно активно использовались, насколько помню курс и лабы по icnd v2, а в нормальных ОС я честно даже и не знаю, зачем такое делать…

[SFx]

Это нужно для локально межпроцесового взаимодействия.
например можно два сервера поднять по разным 127.x.x.x и на одном порту.

[qw1]

Проверил, и действительно: если делать сокету bind к адресу 127.0.0.2, то коннект на адрес 127.0.0.1 не проходит, а на адрес 127.0.0.2 — проходит.

[qw1]

Не раскрыта тема v6-адресов с точками от ipv4.
Например, 2002:d941:d96c:8000:0:5efe:10.0.5.37
Судя по количеству недостающих хекстетов, последние 32 бита записаны в стандарте ipv4
В каких случаях применяется такая запись?

[TrueBers]

В случаях, когда префикс embedded-адреса равен всему остальному, не считая собственного самого IPv4 адреса, т. е. 128 — 32 = 96 битам.
Но это не обязательно, можно писать и хекстетами.
Просто по умолчанию принято, если префикс embedded-адреса равен /96, то последние 2 хекстета можно записать октетами через точку для наглядности.

[maks00x]

Очень интересно, как работает IPv6 с клиентами, которые сидят за маршрутизаторами с NAT, у которых есть только IPv4. В смысле, роутер клиента запрашивает по DHCP инфу, ему выдают "твой IP 2001:0DB8::ffff:172.16.0.2 (до клиента доходит только 172.16.0.2), шлюз: 2001:0DB8::ffff:172.16.0.1, маска 24", и тогда на нашем маршрутизаторе происходит аналог NAT, который превращает 2001:0DB8::ffff:172.16.0.1 в 2001:0DB8::1, например?