Комментарии 42
Региональные регистраторы давно уже дают /32 сеть по умолчанию или больше адресов, если сможешь обосновать зачем. /48 более актуально для PI сетей.
LIR'ы получают /32, на тренинге говорили, что надо стремиться к одному размеру выделяемого клиентам сегмента. Рекомендовано (примерно): /56 на заявку, если есть необходимость в нескольких сетях клиента — /48, если есть более-менее адекватное обоснование — до /32 на клиента (в этом случае LIR'у выдают ещё одну /32).
LIR, который выдаёт клиентам /64, будет побит камнями, потому что если в BGP будут анонсить квинтиллионы /64, то компания «сисько системсь» озолотится, барыжа маршрутизаторы с терабайтами памяти под full view.
Таким образом становится понятно, почему сисько рекомендует LIR'ам выдавать побольше /64 и поменьше агрегированных сетей.
LIR, который выдаёт клиентам /64, будет побит камнями, потому что если в BGP будут анонсить квинтиллионы /64, то компания «сисько системсь» озолотится, барыжа маршрутизаторы с терабайтами памяти под full view.
Таким образом становится понятно, почему сисько рекомендует LIR'ам выдавать побольше /64 и поменьше агрегированных сетей.
Вы так говорите (про анонсы /64 в BGP), как, например, сейчас провайдеры якобы вываливают в full view каждый ipv4 /32, который они выдают каждому домашнему роутеру на PPPoE. Ну такого же нет. Зачем вы вводите людей в заблуждение?
/64 — это минимальный рекомендуемый префикс в основном для механизмов stateless настройки ipv6-адресов. Также начиная от такой длины префикса аппаратные роутеры/коммутаторы оптимально используют TCAM память.
Нынешняя выдача операторам /32 аналогична выдаче /24 ipv4 (если учитывать размер кусочка от всего пирога адресного пространства ipv6 и ipv4), но /32 ipv6 оператор может использовать на более чем 100000 абонентов (в ipv4 на то потребовалось бы префикса /15).
Нынешняя выдача операторам /32 аналогична выдаче /24 ipv4 (если учитывать размер кусочка от всего пирога адресного пространства ipv6 и ipv4), но /32 ipv6 оператор может использовать на более чем 100000 абонентов (в ipv4 на то потребовалось бы префикса /15).
«Также начиная от такой длины префикса аппаратные роутеры/коммутаторы оптимально используют TCAM память.»
Вы не могли бы пояснить почему?
Вы не могли бы пояснить почему?
потому что для префикса /64 достаточно хранить саму сеть, т.е. 64бита и длину префикса, то в случае /65-/128 нужно хранить префикс большей длины, а учитывая, что самые распространенные архитектуры 32бит или 64бит, то получаем увеличение необходимой памяти в 1,5-2 раза или невозможность коммутации по таким префиксам аппаратно и обработка происходит на CPU.
rfc3177
основная идея в том, что такая схема очень удобна, т.е.
провайдеру удобно выделять всем абонентам префиксы одинаковой длины, удобно выдать настройки один раз и не менять.
удобно когда все блоки одинакового размера, у всех провайдеров, а 2^64 — достаточно всем, даже очень крупным предприятиям, с кучей филиалов.
/48 на провайдера, потому что 48+(8+8)=64 и т.п.
ещё придумывают разные экспериментальные протоколы, для которых важно предположение, что первые 64 бита — сеть, а следующие 64 — хост.
ну и последнее, сейчас выдаётся только часть адресного пространства, и если текущая схема каким-либо образом себя дискридитирует, то её можно будет поменять.
основная идея в том, что такая схема очень удобна, т.е.
провайдеру удобно выделять всем абонентам префиксы одинаковой длины, удобно выдать настройки один раз и не менять.
удобно когда все блоки одинакового размера, у всех провайдеров, а 2^64 — достаточно всем, даже очень крупным предприятиям, с кучей филиалов.
/48 на провайдера, потому что 48+(8+8)=64 и т.п.
ещё придумывают разные экспериментальные протоколы, для которых важно предположение, что первые 64 бита — сеть, а следующие 64 — хост.
ну и последнее, сейчас выдаётся только часть адресного пространства, и если текущая схема каким-либо образом себя дискридитирует, то её можно будет поменять.
Тут надо смотреть не слева направо а справа налево. Фишка /64 в том, чтобы все (!) клиентские сети были одного размера. То есть, даже если мы поместим в одну ethernet сеть все возможные мак-адреса, то получим только 48 бит занятых в хостовой части. А что касается заканчивающихся адресов — просто посчитайте. Оставшиеся 64 бита — это очень много. Опять же, тут уже писали, что выдаётся сейчас только диапазон начинающийся на двойку, на сколько я помню. Соответственно, если он закончится быстрее планируемого, то дальше можно будет попробовать поменять схему. Впрочем, вряд ли изменения коснутся хостовой части адреса, уж больно много всего завязано сейчас на эти /64 Скорее пересмотрят использование адресов в маленьких сетях точка-точка, или не будут выдавать провайдерам по /32
Раньше и ipv4 тоже довольно-таки щедро раздавался. Не так, как ipv6, но всё равно щедро.
Кажется у меня появился шанс понять ipv6, спасибо за статью!
Автор, объясните, чем мне помогут ::ffff:xxxx:xxxx-адреса. Вы уверяете, что
Вот у меня есть железка X, умеющая только ipv4. Что дальше?
Эти адреса используются для устройств, не поддерживающих IPv6
Вот у меня есть железка X, умеющая только ipv4. Что дальше?
На сколько я понимаю, оно не должно и не будет работать. Это просто формальный способ отображения одного множества на другое, чтобы всё было разложено по полочкам в IPv6
Mapped-адреса используются, прежде всего, в dual-stack. Когда создаётся один сокет IPv6 на оба протокола ( IPv4 и IPv6 ), и везде используется IPv6 адреса. Т. е. если через этот сокет пришли данные через IPv4, адрес будет показан всё равно в виде вышеописанного IPv6 mapped-адреса. На канальном уровне разницы не будет вообще. Там будет старый добрый IPv4, разница только в в унификации отображения для пользователя.
Спасибо — этого мне очень не хватало.
По сути, чтобы можно было писать сервера, не задумываясь о IPv4: создаёшь сокет «socket(AF_INET6, SOCK_STREAM, 0)» и если через setsockopt не поставить IPV6_V6ONLY, то библиотека сама будет преобразовывать отправку на IPv6 адрес ::ffff:xxxx:xxxx в отправку на IPv4 xx.xx.xx.xx (и в обратную сторону при приёме, естественно, т.е. будут прослушиваться оба порта IPv6:yyyy и IPv4:yyyy).
Это вообще дырка для совместимости с IPv4 сетью, чтобы вообще была теоретическая возможность из IPv6 сети без проблем взаимодействовать с IPv4 сетью через аппаратные шлюзы. Потом когда нибудь это всё уйдет в историю, а пятно останется.
когда есть только железка IPv4 — это все не имеет смысла.
но когда есть железка с IPv6, и с нее надо достучаться до железки с поддержкой только IPv4
но когда есть железка с IPv6, и с нее надо достучаться до железки с поддержкой только IPv4
вот так можно сделать ping 192.168.10.1 через IPv6
В данном случае пингуется шлюз-роутер, у которого нет 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 (и никогда не будет :( )
Да, но при этом используется на обоих узлах чистый IPv4. Тут не используется IPv6 как протокол! Используется только визуальный формат в виде IPv6, дальше по стеку идёт чистейший IPv4, который вообще не знает о v6, т. к. получает уже преобразованный чистый 32-битный IPv4.
Достучаться с IPv6-only железки до IPv4-only железки через такой адрес невозможно!
Достучаться с IPv6-only железки до IPv4-only железки через такой адрес невозможно!
А можете рассказать про IPv6 и IPSec? Как-то уже спрашивал дали только ссылку, из которой следует что поддерживается это только в Linux. Но насколько? Уже можно пользоваться, или шифрование еще в стадии разработки? Просто когда говорят про IPv6, говорят что у него есть шифрование и это круто. Хочется подробностей.
а почему нет ни слова про anycast? они хоть и не выделаются в отдельный префикс, на как один из типов адресов достойны упоминания…
Согласно, RFC4291, у нас, выходит, только одни Loopback адрес
Получается нет больше 127.0.0.1 — 127.255.255.255 такого диапазона loopback'ов (если конечно не использовать Mapped-адреса:
::1? Получается нет больше 127.0.0.1 — 127.255.255.255 такого диапазона loopback'ов (если конечно не использовать Mapped-адреса:
::ffff:7f00:2)? Тут как раз ничего странного, меня наоборот всегда интересовало, зачем в IPv4 стооолько адресов для лупбэков. Я как-то не чувствую что лупбэков мало. ;-)
127.0.1.1, 127.1.1.1 это кроме «каноничного» 127..0.1 оторые я встречал в реальных конфигах.
Ну с цисками там понятно, в маршрутизации эти лупбек адреса достаточно активно использовались, насколько помню курс и лабы по icnd v2, а в нормальных ОС я честно даже и не знаю, зачем такое делать…
Ну с цисками там понятно, в маршрутизации эти лупбек адреса достаточно активно использовались, насколько помню курс и лабы по icnd v2, а в нормальных ОС я честно даже и не знаю, зачем такое делать…
Это нужно для локально межпроцесового взаимодействия.
например можно два сервера поднять по разным 127.x.x.x и на одном порту.
например можно два сервера поднять по разным 127.x.x.x и на одном порту.
Не раскрыта тема v6-адресов с точками от ipv4.
Например,
Судя по количеству недостающих хекстетов, последние 32 бита записаны в стандарте ipv4
В каких случаях применяется такая запись?
Например,
2002:d941:d96c:8000:0:5efe:10.0.5.37Судя по количеству недостающих хекстетов, последние 32 бита записаны в стандарте ipv4
В каких случаях применяется такая запись?
В случаях, когда префикс embedded-адреса равен всему остальному, не считая собственного самого IPv4 адреса, т. е. 128 — 32 = 96 битам.
Но это не обязательно, можно писать и хекстетами.
Просто по умолчанию принято, если префикс embedded-адреса равен /96, то последние 2 хекстета можно записать октетами через точку для наглядности.
Но это не обязательно, можно писать и хекстетами.
Просто по умолчанию принято, если префикс embedded-адреса равен /96, то последние 2 хекстета можно записать октетами через точку для наглядности.
Очень интересно, как работает 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, например?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
IPv6 теория и практика: введение в IPv6