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

Fri Jun 15 20:26:27 -03 2018

Concordo com a preocupação de todos os colegas.
Se pensarmos que em um futuro próximo o IPv6 estará predominante em
praticamente todos os ambientes, somado à falta de conhecimento de alguns
profissionais que não sabem trabalhar com seus prefixos, será questão de
tempo até chegarmos rapidamente na casa do milhão.
Aqui fazemos questão de propagar o mínimo possível de prefixos, tanto em v4
quanto em v6. Inclusive há um bom tempo já mudamos nossas políticas de
controle de downstream do ipv4 para outros atributos que não seja o prefixo
mais específico.
Hoje anunciamos em nossos upstreams apenas os /22 e trabalhamos bem com os
atributos. Tem sido sucesso puro, visto que o tráfego fica bem menos
sensível a mudanças, e também fazemos a nossa parte de colaborar com a
tabela.
E a mesma política tem seguido com o IPv6, onde prefixos mais específicos
(/36 e /44) são propagados apenas para peerings e ATM (IXs).

A implantação de uma política por parte dos ASs será muito importante (y).

On Fri, Jun 15, 2018 at 7:13 PM Davi Nunes <cahet.davi at gmail.com> wrote:

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

-- 

Gustavo Stocco
NAXI TELECOMUNICAÇÕES
+55 (47) 3054-2233
0800-932-0000 R.3322
INOC-DBA BR 53001*100
ASN 53001