Доброго времени суток. Есть маршрутизатор cisco 2921, IOS c2900-universalk9_npe-mz.SPA.152-4.M3.bin и cisco 3945, IOS c3900-universalk9-mz.SPA.151-4.M3.bin.Почему-то они ничего не знают про ipv6 nat
#ipv6 ?
access-list Configure access lists
cef Cisco Express Forwarding for IPv6
cga Configure IPv6 certified generated address
dhcp Configure IPv6 DHCP
flowset Set flow label random for originated packets
general-prefix Configure a general IPv6 prefix
hop-limit Configure hop count limit
host Configure static hostnames
icmp Configure ICMP parameters
local Specify local options
mfib Multicast Forwarding
mld Global mld commands
mobile Mobile IPv6
multicast Configure multicast related commands
multicast-routing Enable IPv6 multicast
nd Configure IPv6 ND
neighbor Neighbor
ospf OSPF
pim Configure Protocol Independent Multicast
port-map Port to application mapping (PAM) configuration commands
prefix-list Build a prefix list
radius RADIUS configuration commands
route Configure static routes
router Enable an IPV6 routing process
source-route Process packets with source routing header options
spd Selective Packet Discard (SPD)
tacacs TACACS configuration commands
traffic Configure traffic parameters
unicast-routing Enable unicast routingЧто за ерунда?
>[оверквотинг удален]
> source routing header options
> spd
> Selective Packet Discard (SPD)
> tacacs
> TACACS configuration commands
> traffic
> Configure traffic parameters
> unicast-routing Enable unicast routing
>
Разобрался, зачем-то они засунул nat-pt в security/
>[оверквотинг удален]
>> spd
>> Selective Packet Discard (SPD)
>> tacacs
>> TACACS configuration commands
>> traffic
>> Configure traffic parameters
>> unicast-routing Enable unicast routing
>>
>> Что за ерунда?
> Разобрался, зачем-то они засунул nat-pt в security/Наверное потому что самому IPv6 NAT не нужен, его для этого и изобрели.
>[оверквотинг удален]
>>> tacacs
>>> TACACS configuration commands
>>> traffic
>>> Configure traffic parameters
>>> unicast-routing Enable unicast routing
>>>
>>> Что за ерунда?
>> Разобрался, зачем-то они засунул nat-pt в security/
> Наверное потому что самому IPv6 NAT не нужен, его для этого и
> изобрели.Ок, а клиенту отдавать сети /64? Не жирно ли будет? Так, пул /48 исчерпается, а использовано будет %5 адресов.
>[оверквотинг удален]
>>>> traffic
>>>> Configure traffic parameters
>>>> unicast-routing Enable unicast routing
>>>>
>>>> Что за ерунда?
>>> Разобрался, зачем-то они засунул nat-pt в security/
>> Наверное потому что самому IPv6 NAT не нужен, его для этого и
>> изобрели.
> Ок, а клиенту отдавать сети /64? Не жирно ли будет? Так, пул
> /48 исчерпается, а использовано будет %5 адресов.Клиенту отдавать можно и меньше чем /64
>[оверквотинг удален]
>>>> traffic
>>>> Configure traffic parameters
>>>> unicast-routing Enable unicast routing
>>>>
>>>> Что за ерунда?
>>> Разобрался, зачем-то они засунул nat-pt в security/
>> Наверное потому что самому IPv6 NAT не нужен, его для этого и
>> изобрели.
> Ок, а клиенту отдавать сети /64? Не жирно ли будет? Так, пул
> /48 исчерпается, а использовано будет %5 адресов.Вообще-то RFC напрямую настаивает на отдаче как минимум /64 клиенту, рекомендуя отдавать /56 если клиент не частник. Отдавая меньший блок, вы ломаете вообще все.
Пул /48 вам расширят по первому требованию, RIR раздают блоки с возможностью их расширения без сегментации.
Методики распределения аресов IPv4 не нужно применять к IPv6 напрямую.
>[оверквотинг удален]
>>> Наверное потому что самому IPv6 NAT не нужен, его для этого и
>>> изобрели.
>> Ок, а клиенту отдавать сети /64? Не жирно ли будет? Так, пул
>> /48 исчерпается, а использовано будет %5 адресов.
> Вообще-то RFC напрямую настаивает на отдаче как минимум /64 клиенту, рекомендуя отдавать
> /56 если клиент не частник. Отдавая меньший блок, вы ломаете вообще
> все.
> Пул /48 вам расширят по первому требованию, RIR раздают блоки с возможностью
> их расширения без сегментации.
> Методики распределения аресов IPv4 не нужно применять к IPv6 напрямую.Можно ссылку? На сколько я понял, они проверяют заполненность пула. К тому же, такое распределение не рационально...
>[оверквотинг удален]
>>> Ок, а клиенту отдавать сети /64? Не жирно ли будет? Так, пул
>>> /48 исчерпается, а использовано будет %5 адресов.
>> Вообще-то RFC напрямую настаивает на отдаче как минимум /64 клиенту, рекомендуя отдавать
>> /56 если клиент не частник. Отдавая меньший блок, вы ломаете вообще
>> все.
>> Пул /48 вам расширят по первому требованию, RIR раздают блоки с возможностью
>> их расширения без сегментации.
>> Методики распределения аресов IPv4 не нужно применять к IPv6 напрямую.
> Можно ссылку? На сколько я понял, они проверяют заполненность пула. К тому
> же, такое распределение не рационально...http://www.ripe.net/ripe/docs/ripe-552
http://tools.ietf.org/html/rfc6177Сейчас LIRу, чтобы дать блок адресов от /48 до /64 клиенту, даже не надо никаких запросов никуда делать. Тупо в базе RIR регистрируешь как ASSIGNED и все.
Клиенту нужно дать столько /64, сколько у него будет сегментов с IPv6. C вменяемым запасом под расширение. Проще, для документирования, на 4х-битной границе, чтобы префиксы удобнее писать.
Использование вашего пула проверять будут не по реально работающим адресам, а по регистрациям в БД.
Оператору дается минимум /32 и без подтверждения необходимости расширяется до /29.Зачем осложнять себе и клиенту жизнь всякими трансляциями - для меня лично загадка.
> http://www.ripe.net/ripe/docs/ripe-552обновлено
> Ок, а клиенту отдавать сети /64? Не жирно ли будет? Так, пул
> /48 исчерпается, а использовано будет %5 адресов.Уточнение, клиент-то Point-to-Point один писюк, или за линком еще сегменты локалки есть?
>> Ок, а клиенту отдавать сети /64? Не жирно ли будет? Так, пул
>> /48 исчерпается, а использовано будет %5 адресов.
> Уточнение, клиент-то Point-to-Point один писюк, или за линком еще сегменты локалки есть?Какая разница, один или много: rfc требует /64 сеть. И вообще, сегодня 1, завтра десяток.
Не нарушайте связность в ipv6 без веских причин, это плохо для всех: для оператора, которому нужно не просто рутить, а еще и транслировать адреса (соответственно - оборудование); для абонента, у которого приложения, спроектированные под end-to-end связность опять будут вынуждены работать через промежуточные сервера и STUN-костыли.
> Не нарушайте связность в ipv6 без веских причин, это плохо для всех:Это не я пытаюсь что-то нарушить. Это раз.
Для point-to-point линков, например между роутерами, можно вполне себе использовать все что угодно, от /64 до /127 и это ничего не нарушит, более того, из соображений безопасности (переполнение таблицы соседей) некоторые предлагают использовать /127, см. http://tools.ietf.org/html/rfc6164
а другие, для удобства документирования /112
это два.
Для PPPoE пула, на сам линк тоже достаточно одной /64 на весь виртуальный интерфейс.
> Так, пул /48 исчерпаетсяСтранно, провайдерам и LIR дают минимум /32. Мне перезванивали из RIPE и спрашивали почему так _мало_ запросил, когда я заявку на /32 подал.
А /32, замечу, это как весь существующий интернет IPv4 вместе взятый, с приватными сетями и мультикаст диапазонами, причем по /64 каждому.
1. по /64 исчерпать? даже /48 очень не быстро
2. /64 выдается для autoconfig'урации. Если у Вас клиенты будут прописывать руками ipv6-адреса, то без разницы какого размера сеть будет выдаваться.
Если провайдер выдаёт одну подсетку /64 на pppoe интерфейс, можно ли адреса этой подсети раздать и на локальную сеть?
> Если провайдер выдаёт одну подсетку /64 на pppoe интерфейс, можно ли адреса
> этой подсети раздать и на локальную сеть?С чего решил, что /64 выдан на тебя одного? Я подозреваю что это общий сегмент на все PPP сеансы.
Для выдачи префикса ЗА PPP соединение есть специальный механизм: DHCPv6 Prefix-delegation
Смотри в сети документ TR-187.
> С чего решил, что /64 выдан на тебя одного? Я подозреваю что
> это общий сегмент на все PPP сеансы.Не подумал об этом.
> Для выдачи префикса ЗА PPP соединение есть специальный механизм: DHCPv6 Prefix-delegation
Ростелеком не осилил.
>> С чего решил, что /64 выдан на тебя одного? Я подозреваю что
>> это общий сегмент на все PPP сеансы.
> Не подумал об этом.
>> Для выдачи префикса ЗА PPP соединение есть специальный механизм: DHCPv6 Prefix-delegation
> Ростелеком не осилил.Буквально сегодня свой PI блок IPv6 анонсировали через Ростелеком. Вся процедура от заявки до первого пинга заняла месяца три :)
Правда чуства праздника нет :) Скорость работы пока не ахти - мало межсетевых линков.
>>> С чего решил, что /64 выдан на тебя одного? Я подозреваю что
>>> это общий сегмент на все PPP сеансы.
>> Не подумал об этом.
>>> Для выдачи префикса ЗА PPP соединение есть специальный механизм: DHCPv6 Prefix-delegation
>> Ростелеком не осилил.
> Буквально сегодня свой PI блок IPv6 анонсировали через Ростелеком. Вся процедура от
> заявки до первого пинга заняла месяца три :)
> Правда чуства праздника нет :) Скорость работы пока не ахти - мало
> межсетевых линков.Уже как год владеем блоком pi ipv6, трафик минимален. Думаю если всякие колхоз-телекомы попинать, то быстрее разойдется.
>[оверквотинг удален]
>>>> это общий сегмент на все PPP сеансы.
>>> Не подумал об этом.
>>>> Для выдачи префикса ЗА PPP соединение есть специальный механизм: DHCPv6 Prefix-delegation
>>> Ростелеком не осилил.
>> Буквально сегодня свой PI блок IPv6 анонсировали через Ростелеком. Вся процедура от
>> заявки до первого пинга заняла месяца три :)
>> Правда чуства праздника нет :) Скорость работы пока не ахти - мало
>> межсетевых линков.
> Уже как год владеем блоком pi ipv6, трафик минимален. Думаю если всякие
> колхоз-телекомы попинать, то быстрее разойдется.Колхоз-телеком может пинать только колхоз-клиент который несет деньги. Из этого же следует просто ответ на вопрос почему у колхоз телекомов нет ipv6. Колхоз клиену он не нужен.