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

Fri Jun 15 18:43:17 -03 2018

Rapaz,

Pode ser legado em conta no caso do v4 que o "corte" veio a ocorrer devido
a como foi evoluindo e acabou um entendimento ir se transformando em uma
regra sem padronização oficial..

Quanto ao v6, a unica forma que imagino no momento seria, adotar algo
similar ao que foi feito com o v4, mas ao lugar de você se imaginar sendo
um ISP no cenário, você seria a IANA. Vejo isso pelo menos como um possível
caminho de barro meio formado até que você(a gente) consiga de fato
imaginar a melhor forma e ir evoluindo o caminho até ser asfalto, se deu
pra entender a analogia.

[]'s

Em 15 de junho de 2018 15:36, Roosvelt David <roosveltdavid at hotmail.com>
escreveu:

> É exatamente essa linha de raciocínio Douglas!
>
> por enquanto ainda não é uma questão que chame tanto a atenção pois a
> adoção do IPv6 ainda está engatinhando.
>
> a tabela FULL do v4 contém mais de 725000 prefixos. ( vide:
> https://www.cidr-report.org/as2.0/ )
>
> a tabela de IPv6 ainda possui cerca de 52000 prefixos. ( Vide:
> http://www.cidr-report.org/v6/as2.0/)
>
> analisando no espaço-tempo, o IPv4 sempre teve um crescimento linear,
> constante ao longo dos anos. como pode ser visto nesse gráfico desde 15 de
> junho de 2005 - Hoje
>
> https://www.cidr-report.org/cgi-bin/plota?file=%2Fvar%
> 2Fdata%2Fbgp%2Fas2.0%2Fbgp-active.txt&descr=Active+BGP+
> entries+%28FIB%29&ylabel=Active+BGP+entries+%28FIB%29&
> range=--OR--&StartDate=15-Jun-2005+1715&EndDate=15-Jun-2018+
> 1715&yrange=Auto&ymin=&ymax=&Width=1&Height=1&with=Step&
> color=auto&logscale=linear<https://www.cidr-report.org/cgi-
> bin/plota?file=/var/data/bgp/as2.0/bgp-active.txt&descr=
> Active+BGP+entries+(FIB)&ylabel=Active+BGP+entries+(
> FIB)&range=--OR--&StartDate=15-Jun-2005+1715&EndDate=15-
> Jun-2018+1715&yrange=Auto&ymin=&ymax=&Width=1&Height=1&
> with=Step&color=auto&logscale=linear>
>
> e deve chegar a 1 milhão de prefixos dentro de uns 5 anos, seguindo a
> tendência. um crescimento de certa forma previsível.
>
> se analisarmos a tabela global de prefixos de IPv6, no mesmo espaço tempo
> da tabela do IPv4, 15 junho/2005 - hoje
>
> http://www.cidr-report.org/cgi-bin/plota?file=%2Fvar%
> 2Fdata%2Fbgp%2Fv6%2Fas2.0%2Fbgp-active.txt&descr=Active%
> 25+BGP%25+entries%25+%25%28FIB%25%29&ylabel=Active%25+
> BGP%25+entries%25+%25%28FIB%25%29&range=--OR--&StartDate=
> 15-Jun-2005+1715&EndDate=15-Jun-2018+1715&yrange=Auto&
> ymin=&ymax=&Width=1&Height=1&with=Step&color=auto&logscale=linear<
> http://www.cidr-report.org/cgi-bin/plota?file=/var/
> data/bgp/v6/as2.0/bgp-active.txt&descr=Active%+BGP%+
> entries%+%(FIB%)&ylabel=Active%+BGP%+entries%+%(FIB%)&
> range=--OR--&StartDate=15-Jun-2005+1715&EndDate=15-Jun-2018+
> 1715&yrange=Auto&ymin=&ymax=&Width=1&Height=1&with=Step&
> color=auto&logscale=linear>
>
> podemos perceber um crescimento mais agressivo da tabela de IPv6 nos
> últimos anos,o que tem sido bem positivo. e sabemos que há muito mais
> espaço para crescimento no V6 do que no v4,  já que qualquer AS consegue um
> /32 de v6 que é uma “equivalência" a todos os ipv4 existentes.
>
>  e o que não torna um cenário da FIB da DFZ bater “10 milhões de rotas”
> nada impossível dentro dos próximos anos com a adoção crescente do v6.
>
>  E isso pode justamente “gerar” um problema com caixas de menor capacidade
> de FIB, principalmente legadas.
>
> Por essa questão que acabou surgindo essa dúvida se sair picando o bloco
> em trocentos bloquinhos menores vai ser uma boa prática no decorrer dos
> anos no caso do IPv6. E ao procurar uma definição do que seria o ponto de
> corte ideal do tamanho do prefixo que me deparei com essa nebulosidade, sem
> um cenário muito definido do que seria o “IDEAL”.
>
> Apenas discussões que mais estão para “Acordo de cavalheiros” do que para
> uma Boa prática referendada de fato. a BCP 194, foi o que chegou mais perto
> de dar uma definição, mas é justamente essa em palavras mais simples: “se
> acertem ai entre os peers” e o “se acertem ai” acaba remetendo a situação
> dos menores prefixos delegados.  E isso me deixou encucado sobre o ponto de
> corte ideal do tamanho dos prefixos.
>
>
>
> Em 14 de jun de 2018, à(s) 5:46 PM, Douglas Fischer <
> fischerdouglas at gmail.com<mailto:fischerdouglas at gmail.com>> escreveu:
>
> 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<
> mailto: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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>