[GTER] anúncio mínimo de prefixo ipv6 BGP.

[Antonio M. Moreiras]

Em 12/06/2018 21:50, Roosvelt David escreveu:
> o ASN ISP recebe um /32 de IPv6 delegado pelo RIR, assim como um /22 de IPv4.
>
> o ASN não ISP("usuário final") recebe um /24 de IPv4 e um /48 de IPv6 do RIR.

Pela política atual um ASN ISP pode receber um /24 IPv4, um /22 não é
mais o mínimo (atualmente é o máximo).

> seguindo a “herança”(notem as aspas) do IPv4 onde se fragmentava o prefixo maior (/19, /20, /21…) em diversos /24 que são os prefixos minimamente aceitados pelos UPSTREAMs para fechar uma sessão BGP. (embora ultimamente ande aparecendo uns /25 perdidos por ai…) ou os /24 mais específicos pra forçar o tráfego a vir por Transito A, B, n…
>
> pressupõe-se desta forma que no IPv6, sendo o /48 o menor prefixo aceito para fechar uma sessão BGP, eu teria de quebrar meu /32 em 65536 prefixos /48 para anunciar de forma “mais específica” para os meus trânsitos.
>
> Porém isso fica um tanto óbvio que tratam-se de protocolos distintos, e aplicar a mesma métrica culminaria com uma dispendiosa configuração e manipulação desses prefixos.
>
> Portanto a “herança” do IPv4 de anunciar os prefixos mais específicos com o mínimo aceitável do /24, no IPv6 o uso do /48 como anúncio extremamente específico acaba-se sendo aplicada somente em casos extremamente necessários. ou se houver downstreams ASN que só possua o /48.
>
> portanto a minha dúvida é se existe alguma BCOP ou RFC que recomende a fragmentação do /32 de IPv6 para ser anunciado nos meus Upstreams. se fragmento em /36, /40 ou /44, ou outro tamanho que seria uma métrica recomendável de fragmentação dos prefixos para anúncios.

Quebrar o bloco IPv4 em vários /24 e anunciá-los individualmente
certamente NÃO É uma boa prática.

Tanto para IPv4 como para IPv6 o ideal sempre é anunciar o bloco da
forma mais agregada que for possível. No caso do IPv6, se você tem um
/32, anuncia o /32.

Se for necessário desagregar, por razões de engenharia de tráfego, o
ideal é fazer com que isso não passe dos seus upstreams. Ou seja, os
blocos desagregados devem, se possível, ser anunciados com a community
de 'no-export', sendo que eles têm seu efeito e morrem nos seus
upstreams, não poluindo a tabela de rotas dos demais. Se isso não for o
suficiente para obter o efeito desejado, que se anuncie sem o
'no-export', mas sempre com a menor desagregação possível. Por exemplo,
se dividir o /32 em dois /33 para ajudar a balancear o tráfego de
entrada por dois upstreams já é o suficiente, não há razão alguma para
dividir em vários /36, ou /40, ou /44.

As limitações em /48 IPv6 ou /24 IPv4 se pararmos pra pensar, são meio
burras. O que se quer realmente é que haja a menor quantidade de
prefixos possíveis anunciados, o tamanho deles não importa realmente.
Mas a limitação funciona em certo grau, porque pelo menos o cara que
está quebrando seu bloco em quinhentos /24 sem necessidade real, vai ter
um limite imposto e não vai poder fazer pior que isso. O lado ruim
dessas limitações é que tem gente por aí com /24 IPv4 e com /48 IPv6 que
fica sem uma ferramenta importante de engenharia de tráfego na mão...

Com o IPv6, em particular, é possível e recomendável fazer um bom
planejamento da rede, com a distribuição adequada dos usuários no bloco
(ou do bloco para os usuários, se preferirem), de forma a favorecer a
organização, futuras expansões, e sem dúvida a agregação no roteamento.
A necessidade de dividir a rede em meio milhão de /48s pra engenharia de
tráfego ser efetiva só vai existir se os usuários forem agrupados sem
qualquer planejamento num canto qualquer do seu bloco IPv6.

Engenharia de tráfego no BGP e planejamento da rede estão intimamente
ligados. Resumidamente, o que apresentamos no curso BCOP do
Ceptro/NIC.br sobre esse assunto está neste vídeo:
https://youtu.be/h74MVDgfYV8

Moreiras.