[Dyr]

Juniper, суки, нихера не готов к IPv6 туннелированию как минимум на MX-серии. Ни BGP толком не завёлся (точнее, завёлся, только next-hop со стороны клиента стал ::ipv4-адрес_роутера, который, естественно, недоступен), ни GRE и IPIP-тоннели. Поддержки SIT, 6rd, 6to4, Teredo нету, ***, до сих пор.

[Сильвер]

добрый.

Может быть не внимательно перечитал ветку, но вроде не было:

как с биллингом кто воюет при выделении клиенту только V6, у нас проблема в нормальном сборе V9 netflow выскочила:

flowd кушает проц по черному ( ранее flow-tools пользовали) и куда более придирчив к загрузке машины и дисковой системы, а данные для обработки сливать надо:(

ng_netgraph сегодня научился делать экспорт в NetFlow v9.

 

[Tosha]

ng_netgraph сегодня научился делать экспорт в NetFlow v9.

У них проблема, как я понял, не в генерации NetFlow v9 а в том, чтобы нормально принять данные в этом формате для целей биллинга...

[Сильвер]

У них проблема, как я понял, не в генерации NetFlow v9 а в том, чтобы нормально принять данные в этом формате для целей биллинга...

Я про

flowd кушает проц по черному ( ранее flow-tools пользовали) и куда более придирчив к загрузке машины и дисковой системы, а данные для обработки сливать надо:(

ng_netgraph в этом плане экономнее.

[Dyr]

Сегодня из Juniper (индонезийского отделения. хехе) пришёл ответ по IPv6:

Hi Dennis,

- IP6 tunneling using IP6 over ipv4 tunnelling has been supported in JUNOS since version 7.X.

on M series or MX series Tunnel service need to be enabled.

on M series it requires MS-PIC module, on MX-series it can use the embedded tunnel services on DPC or MPC module.

to enable embedded tunnel services on DPC or MPC, you can refer to this document :

http://www.juniper.net/techpubs/software/j...aces-on-mx.html

 

- 6rd tunnelling on JUNOS on MX will be supported by 1H2011, or junos version 11.3 or 11.4. currently this feature is still beta on 11.1/11.2

- DS-Lite tunneling has been supported on JUNOS on MX since 10.2, and tunnel service must also be enabled.

 

for your second question, if the customer is connected to network using both IPv4 and IPv6, in this dual stack, he still can access IPv4 network, but if the customer is connected to the network using only IPv6, if they want access IPv4 network, NAT64 need to be configured somewhere on the network, and it can be done at the MX240 (which is the border router). This is the scenario where the subscriber will not get any ipv4 address from the provider.

to enable NAT64 on MX240, it requires MS-DPC module, because the translation process is done at the MS-DPC module.

NAT64 has been supported on JUNOS since 10.3, DNS64 (the NAT ALG for translating DNS from 6-to-4) is supported from 10.4.

 

or we can also use v4 over v6 tunnelling to allow IPv4 traffic from home user which is connected to service provider network using IPv6. in this case the tunnel will be between user's PC and the MX (The border router), there will be no IPv4 on the access network. This is the scenario where subscriber is connected to the service provider using v6 but the service provider allow IPv4 over tunnel.

the tunnelling mechanism can be ip over ip tunneling or can be DS-lite, which both are supported on MX240.

[anad]

ng_netgraph сегодня научился делать экспорт в NetFlow v9.

У них проблема, как я понял, не в генерации NetFlow v9 а в том, чтобы нормально принять данные в этом формате для целей биллинга...

угу именно с тем чтобы принять нормально(: Генерация - только к CISCO

крайне вероятно что много разного софта называется flowd, но имеется в виду этот "flowd is a small, fast and secure NetFlow™ collector"

nfdump пробую

 

[alks]

интерестно - а с какой маской теперь выдавать адреса клиентам если к примеру в Ipv4 мелкому юрику даем сетку /30

и вообще по какому принципу теперь нарезать на подсети?

[Dyr]

RFC рекомендует минимум /64 для клиентов, а лучше, мол, и /56 для юриков.

И забудьте об экономии адресов - для блоков IPv6 /32 даже 56ых блоков более 16 миллиардов.

Изменено 3 марта, 2011 пользователем Dyr

[Сильвер]

ng_netgraph сегодня научился делать экспорт в NetFlow v9.

У них проблема, как я понял, не в генерации NetFlow v9 а в том, чтобы нормально принять данные в этом формате для целей биллинга...

угу именно с тем чтобы принять нормально(: Генерация - только к CISCO

крайне вероятно что много разного софта называется flowd, но имеется в виду этот "flowd is a small, fast and secure NetFlow™ collector"

nfdump пробую

Был невнимателен, подумал о генерации flow.

[alks]

RFC рекомендует минимум /64 для клиентов, а лучше, мол, и /56 для юриков.

И забудьте об экономии адресов - для блоков IPv6 /32 даже 56ых блоков более 16 миллиардов.

 

учитывая что райп сейчас по дефолту выдает блоки ipv6 /32 то /64 это получается 4000 подсети

не маловато будет? или я чего то недопонимаю...

[Dyr]

 

Я немного ошибся, /56 в /32 "всего лишь" 16 миллионов :)

Изменено 3 марта, 2011 пользователем Dyr

[anad]

интерестно - а с какой маской теперь выдавать адреса клиентам если к примеру в Ipv4 мелкому юрику даем сетку /30

и вообще по какому принципу теперь нарезать на подсети?

богатые вы(:

давно уже выдаем по /32 на клиента.

про блоки IPv6 - судя по скорости выдачи адресов RIPE просто не читает заявки :) ( /64 - куда столько), да и про 16 миллиардов - китайцы не спят.

Изменено 3 марта, 2011 пользователем anad

[alks]

IPv6 Relative Network Sizes

 

/128 1 IPv6 address A network interface

/64 1 IPv6 subnet 18,446,744,073,709,551,616 IPv6 addresses

/56 256 LAN segments Popular prefix size for one subscriber site

/48 65,536 LAN segments Popular prefix size for one subscriber site

/32 65,536 /48 subscriber sites Minimum IPv6 allocation

/24 16,777,216 subscriber sites 256 times larger than the minimum IPv6 allocation

 

***ться можно - что там рекомендует к выдаче RFC - /64? т.е. 18... я хз как это по русски произнести такое кол-во адресов :))

товарищи поделитесь собственными соображениями на этот счет

 

[rm_]

alks

соображения очень простые: stateless autoconfiguration (route advertisements) работает исключительно при /64 на физическую среду.

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

Отсюда рекомендация /56 на конечного юзера. Ибо давать "две, четыре, шесть штук" /64 по логике менее удобно.

https://datatracker.ietf.org/doc/draft-ietf...?include_text=1

Отказываться от stateless autoconfig - значит получать на порядок больший головняк с настройкой (DHCPv6, который ещё и не во всех осях присутствует) и на порядок меньший plug-and-play. А главное, нету большого резона это делать, имеющему /32 провайдеру адресов хватит примерно на 16 миллионов клиентов с /56 - но ещё задолго до достижения этого кол-ва на практике, ему легко дадут ещё одну /32, а то и несколько.

Изменено 3 марта, 2011 пользователем rm_

[Dyr]

+1 к мнению rm_.

Самое тяжёлое в IPv6 поначалу, это привыкнуть к с виду безумнейшему разбазариванию адресов. ;)

[st_re]

Уу лет через 15 начнется работа над новым протоколом, в связи с тем что все блоки пораздавали.... но занято будет 0.0(0)1% адресов

[evd]

Уу лет через 15 начнется работа над новым протоколом, в связи с тем что все блоки пораздавали.... но занято будет 0.0(0)1% адресов

st_re, в IPv6 запас такой, что к этому ещё надо привыкнуть. IPv6-блоков размером /32, как нетрудно догадаться, можно раздать по одному на каждый существующий IPv4-адрес (забыв для простоты про private, multicast и прочие bogons). Сам блок /32 можно ровно столько же раз побить на "кусочки" по /64. Попробуйте набрать клиентскую базу в 4 миллиарда персон, чтобы раздать им свой единственный /32, одаривая каждого адресным пространством 2**64 :)

 

[m0xf]

Уу лет через 15 начнется работа над новым протоколом, в связи с тем что все блоки пораздавали.... но занято будет 0.0(0)1% адресов

IPv6-блоков размером /32, как нетрудно догадаться, можно раздать по одному на каждый существующий IPv4-адрес (забыв для простоты про private, multicast и прочие bogons).

3 бита съедает префикс адреса, поэтому остаётся примерно 500 тыс. блоков /32. Но в любом случае это много.

[rm_]

3 бита съедает префикс адреса

Чего бы это он съедает? То, что пока решили вопользоваться для аллокаций только одним из префиксов (2000::/3), никак не препятствует использованию в будущем и других свободных.

[evd]

3 бита съедает префикс адреса

Чего бы это он съедает? То, что пока решили вопользоваться для аллокаций только одним из префиксов (2000::/3), никак не препятствует использованию в будущем и других свободных.

А кроме того, 2**(32-3) ~= 500 миллионов, а не тысяч :)

Изменено 3 марта, 2011 пользователем evd

[st_re]

evd, я математику в школе учил, спасибо. Некто Билл уже как то упоминал, что 640к это бесконечно много для любой задачи. потом его поделия не влезали в 640мег.... такими темпами скоро уже и 640 гиг будет нормально, 10и лет не пройдет.

2000/3 разбазарят лет за 5-10. не больше. и дай бог, чтобы потом рост замедлился, а не ускорился. (да, про то, что там можно будет поменять дефолт и на клиента выдавать не /64 а, скажем /96 я слышал.... Вы застали переход от классовой к бесклассовой системе, когда выдача сети типа 192.168.0.0/25 была невозможна, ибо не жреть ее часть оборудования... и прочая хрень вида rip1 ?) я более чем уверен, что в 99% случаев /64 будет нахардкожено в софте намертво.

 

А кроме того, 2**(32-3) ~= 500 миллионов, а не тысяч :)

уу, и в рипе арины и прочие выдается оно по одной.. потом будет куча дыр, ы выдать нечего.

 

Возможно я пессимист... но кто то в проектировании явно оптимист ;)

[Max P]

так всё таки, на чем остановиться для дуал-стека? городить тередо и прочие тунели чего то не очень хочется, на юзера значит всё таки /56 лучше отдать? или пофигу и дать всем /64 нехай там сами у себя разбираются?

[AlexUkr]

Надо изначально ориентироваться на выдачу каждому домашнему абоненту /56 подсети, как того советует RFC. Крупным юрлицам - /48. Пожадничать сегодня и начинать раздавать /64 будет ошибкой, потому что через N лет пойдёт мода на какую нибудь технологию, разделяющую домашнюю сеть на подсети (потому что стандарты IPv6 сами подталкивают к этому, да и мали ли чего ещё напридумывают в будущем), и перенумеровывать сетку будет та ещё головная боль. Причин не давать каждому по /56 просто не существует.

[evd]

st_re, IPv6 разрабатывали люди, хорошо знакомые с высказываниями некоего бизнесмена про 640k ;)

 

Аналогию с классами/CIDR IPv4 и с rip1 не догнал, sorry. Так же, как и утверждение про хардверный /64. Чего там вендоры наворотят, особенно на первых этапах, можно только гадать. Только какое это отношение имеет к размерам адресного пространства IPv6?

[st_re]

st_re, IPv6 разрабатывали люди, хорошо знакомые с высказываниями некоего бизнесмена про 640k ;)

ну тогда я спокоен. ;)

 

Аналогию с классами/CIDR IPv4 и с rip1 не догнал, sorry. Так же, как и утверждение про хардверный /64. Чего там вендоры наворотят, особенно на первых этапах, можно только гадать. Только какое это отношение имеет к размерам адресного пространства IPv6?

Екскурс в историю, скорее всего всем известный. Когда деревья были большими и в4 только родился, было принято что есть классы A B C D E (ну почти как права ;) и класс определял что 10.1.1.1 это хост 1.1.1 в сети 10.0.0.0. потом решили что 2^(8*3) больно дохера и придумали подсети.. но т.к. адрес сети, к примеру 10.0.0.0/8 и подсети 10.0.0.0/9 совпадает, и кому то показалось, что этот адрес зачем то нужен, то такую подсеть повелели не разрешать. по той же причине под нож пошла 10.128.0.0/9 ибо там бродкаст не ясно чей... А потом, прошло много лет, и некто придумал classless и повелел юзать любые маски при любых сетях... но только вот добрые вендоры и софтописатели уже успели наплодить кучу софта/железа которые тупо проверяли класс и не ели крайние подсети. и это аукалось еще лет 10 время от времени. ну а рип1 был весьма популярен, но, сорри, маску не передавал, и внедрение cidr поверх rip1 было более чем.... увлекательным делом.

 

Если сейчас велят, что автонастройка работает при 64 и короче бит сети, то будет куча софта, где это вшито намертво... и оно там останется даже если кто то следующий решит, что кощерно абоненту с 2 ноутбуками и 3 телевизорами выдавать что-то помельче, чем сеть на 18446744073709551616 адресов. Этого куча клиентского оборудования тупо не оценит и не будет автонастраиваться при, скажем, /96.