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

Thu Jun 14 17:46:00 -03 2018

Olá Roosvelt.

Creio que entendi perfeitamente a tua dúvida... E faz todo sentido.
Na verdade, se for analisar essa preocupação tem a ver com o tamanho da FIB
que é usada pela DFZ(Full-Routing Internet).

Em palavras mais grosseiras:
"Se todo zé que pega um /32(v6) começara quebrar ele loucamente em
pouquinho tempo a FIB da DFZ v6 estará batendo 10 milhões de rotas."
É por aí?

Essa é uma preocupação extremamente válida!
Eu não sei se existem estudos sobre isso, mas certamente a curva de
crescimento da capacidade da FIB dos Routers certamente não acompanha a Lei
de Moore.
Acho que nem se quer acompanha o crescimento de capacidade computacional
básica (Proc+Mem+Disco) dos últimos anos.

Exatamente o porque esse crescimento ser menor eu não sei não...
Mas desconfio que esteja relacionado aos métodos de desenvolvimento de
ASICs e FPGAs.
Colocar 20 milhões de rotas na memória é "fácil", mas fico imaginando que
colocar 20 milhões dentro de ASICs lá na NIC não seja tão fácil assim.

Uma coisa que me deixou "encucado" foi sobre o porque do /24 ser "o maior
prefixo aceito" na DFZ...
Tenho a lembrança de ter papeado com alguém sobre isso e alguém terem me
dito que não existe RFC que explicite que prefixos mais longos que /24(v4)
e /48(v6) sejam descartados...

Até perguntei para um grupo de amigos, e um dos Jedi mencionou a BCP 194.
Só que ela é de 2015, e ela não define explicitamente qual é o tamanho
máximo do prefixo que deve estar na DFZ.
Ela(194) fala que isso deve ser acertado entre as partes do Peer...

Então fica aí a pergunta para a galera:
Aonde tá escrito que /24 é ponto de corte dos prefixos de Internet?

Em 12 de junho de 2018 21:50, Roosvelt David <roosveltdavid at hotmail.com>
escreveu:

> 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
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação