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

Roosvelt David roosveltdavid at hotmail.com
Tue Jun 12 21:50:49 -03 2018


Já assisti essa palestra do Balbinot, que é excelente, e todos que estão adotando o IPv6 em larga escala em seus ISPs tem Obrigação de assistir. quem ainda insiste em delegar prefixos menores que /56 ou o /64 pra assinantes só vai ter dor de cabeça.

——

PORÉM,  minha referência não é referente ao usuário final “Assinante varejo/corp do ISP” e sim ao usuário final “ASN" com recursos próprios de numeração. conforme definido no item 3.2  desta página. https://registro.br/tecnologia/provedor-acesso.html?secao=numeracao

me referi aos Usuários finais ASN, ou seja ASNs que não são considerados ISPs. pois estes recebem a delegação dos RIRs de um prefixo /24 de IPv4 e /48 de IPv6 próprios.

Ou seja, uma empresa com ASN próprio que não possui seus prefixos atrelados a operadora A ou B. e pode mandar a Operadora de Transito ir pastar quando bem entender sem perder os prefixos.

acho que essa referência a ASNs não ISP como "usuários finais" causa uma certa confusão. rs

menciono eles,  pois eles definem uma métrica mínima de tamanho de prefixos aceitáveis pelos trânsitos para fechar uma sessão BGP.

Estou detalhando melhor pois recebi várias msg no pv com a interpretação equivocada de “Usuários finais”  chovendo no molhado com a delegação para assinantes. que não é o foco da minha dúvida.

———

a minha dúvida É DO OUTRO LADO DA REDE, na Borda. conversando com as Operadoras de transito no BGP.

o cenário é o seguinte:

tenho meu ASN e meus upstreams: Operadora A, Operadora B, Operadora N…

considerando as menores alocações possíveis atualmente:

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.

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.

normalmente tenho trabalhado "quebrando" o /32 em prefixos /36 para serem anunciados nos Upstreams, que até o momento tem atendido perfeitamente.

como falei no primeiro e-mail, é uma dúvida boba que acabou surgindo hoje quando vi muitos anúncios de/38  /40 e /44,  /46  na tabela global e que acabou me levantando a questão de se existe um tamanho de prefixo padrão orientado por alguma BCOP ou RFC?

https://labs.ripe.net/Members/dbayer/visibility-of-prefix-lengths

Se posso continuar “quebrando" o /32 para anúncios no BGP dos meus trânsitos da forma que eu achar melhor, sem que haja o questionamento:  “ah fulano, precisa trabalhar com anúncio de prefixos maiores que /XPTO”.

Pois pelo que eu pesquisei, não existe nem certo nem errado no tamanho da fragmentação dos prefixos para anúncios no BGP, somente que devem ser maiores que /48 para que seja possível o anúncio nas Operadoras de Trânsito. soa estranho pois no IPv4 os padrões de tamanho do prefixo de anúncio já eram amplamente consolidados.

porém agora com o IPv6 com uma quantidade gigantesca de IPs, onde dentro de um simples /32 temos 4.294.967.296 prefixos /64. ou seja todos os IPv4 existentes na “equivalem" a um simples /32 de IPv6.  e ao ver essa proporção sinto ao anunciar um /36 como se eu estivesse anunciando o equivalente ao /8 no IPv4. são dúvidas que surgem quando se começa a ter a dimensão do tamanho de um simples /32 de IPv6.


Abs,




Em 12 de jun de 2018, à(s) 4:08 PM, Eduardo Schoedler <listas at esds.com.br<mailto:listas at esds.com.br>> escreveu:

Assista a palestra do Luis Balbinot na penúltima GTER, ele trata
justamente sobre isso.

Abs,

Em 12 de junho de 2018 10:30, Roosvelt David
<roosveltdavid at hotmail.com<mailto:roosveltdavid at hotmail.com>> escreveu:
Senhores

Acredito ser um assunto bobo, porém pesquisando nas RFCs e documentações da IANA, RIPE, ARIN, LACNIC  não vi um consenso sobre qual o mínimo prefixo aceito como boa prática em anúncios BGP de IPv6. o equivalente ao /24 do IPv4.

as menores delegações de IPv6 feitas pelas RIRs estão sendo um /48 para usuários finais, logo pressupõe-se logicamente que o mínimo aceitável é o /48.

porém vi em fóruns do reedit e em alguns blogs discussões acaloradas defendendo o uso de /44, /40, /36, como anúncios mínimos por quem tem blocos maiores.

na visão dos Senhores, qual seria a melhor boa prática nos anúncios de IPv6 por ISPs? neste caso aqui vamos excluir os usuários finais que tem essa especificidade de receber no mínimo um /48 e focar nos ISPs que possuem prefixos delegados em médio de tamanho /32.

Qual a menor fragmentação adequada e que seria uma "boa prática” ou um consenso aceito para se fazer dos /32? assim como “quebramos" um bloco grande de ipv4 em diversos /24 para anúncios nos Upstreams. o que é hoje aceito como adequado no cenário de IPv6?

desde já agradeço o feedback dos senhores
--
gter list    https://eng.registro.br/mailman/listinfo/gter



--
Eduardo Schoedler
--
gter list    https://eng.registro.br/mailman/listinfo/gter



More information about the gter mailing list