[GTER] IPv6 MTU

Wed Mar 10 11:22:01 -03 2021

Douglas,

Realmente, o Bradesco é complicado com IPV6.
Pessoal acha que ipv6 possui a mesma dinâmica do ipv4 e acabam aplicando as
mesmas regras de firewall.  Fico me perguntando como um cara de TI de um
banco enorme não sabe disso.

Sobre a implementação de Ipv6 na sua rede com ip publico, apenas coloque
ips aleatórios no range, nao use final 1 ou 2 , redes "fáceis" de chutar
para rastreamento.

Em qua., 10 de mar. de 2021 às 08:01, Douglas Fischer <
fischerdouglas at gmail.com> escreveu:

> A resposta do Moreiras me deu uma ideia inicial sobre "o que podemos fazer
> para melhorar a adoção de IPv6"...
> (Outra thread que tá rolando aqui na GTER)
>
> Existe organizações na Internet (cof cof, Bradesco, cof cof) que tem
> integrantes em sua equipe de operações de rede que foram forjados nos
> How-To de IPtables do sites de Linux...
> Onde um cabra dizia "Nessa linha você bloqueia todas as resposta de ICMP
> porque vai te deixar mais seguro" e eles adotaram aquilo como
> pratica irremovível de suas vidas.
>
> A ideia:
> Até nem sei se já não existe... Mas o http://ipv6.br/(ou alguma outra boa
> alma) poderia bolar umas probes que ficariam fazem PMTUD contra blocos IPv6
> usados no Brasil.
> Com isso se descobriria os Hops que estão "dando vassourada" nesse lance de
> Responder ou não ICMPv6, e as organizações que estão com essa prática de
> Clampear em 1280.
>
> Nisso teríamos uma lista de coleguinhas que precisam ser avisados que
> "poxa, arrume suas configs de IPv6".
>
>
>
> (P.S.1: Se alguém tiver um amigo que trabalha na T.I do Bradesco e quiser
> printar esse texto e mandar para ele só para atazanar um pouco, além de
> engraçado, talvez ajude eles a ajustarem nas regras de firewall IPv6
> deles.)
> (P.S.2: Se você trabalha no Bradesco: E já arrumou essa bagaça, compartilhe
> essa informação de alguma forma para a gente saber. Se não arrumou essa
> bagaça ainda, fale com os colegas aqui da lista. Sempre tem alguém disposto
> a ajudar.)
>
>
>
> Em ter., 9 de mar. de 2021 às 10:14, Antonio M. Moreiras <moreiras at nic.br>
> escreveu:
>
> > Olá.
> >
> > > 2) Problema:
> > > - Alguns sites não abrem IPv6, já notei que é algo relacionado a MTU;
> >
> > É muito provável ser relacionado a MTU. Alguma falha no PMTUD. Talvez
> > algum bloqueio de ICMPv6. Pode ser na sua infra. Ou nos sites
> > "problemáticos".
> >
> > Eu não confiaria de cara na conclusão de que são os sites, sem testes
> > adicionais. Os que funcionam podem simplesmente ter configurado um MTU
> > baixo do lado deles e estar enviando por padrão pacotes, por exemplo, de
> > 1280 bytes no máximo. Esse tamanho funciona sempre no IPv6
> > independentemente do PMTUD. Em algum momento do passado isso foi
> > considerado "boa prática" para os sites, isso numa época remota da
> > pré-história da Internet em que o conhecimento sobre IPv6 era menor e os
> > bloqueios de ICMPv6 mais comuns. Então suponho que ainda existam sites
> > por aí assim, não sei se são a maioria ou se são uns gatos pingados,
> > nunca medi isso e não lembro de ter visto alguém medir.
> >
> > Talvez você possa incrementar o seu laboratório e usar um site fora da
> > sua rede que você mesmo administra pra testes, podendo capturar pacotes
> > lá. Pode subir um nginx em um desses VPS genéricos de USD 2.50/mês, por
> > exemplo.
> >
> >
> > > - Usando roteador cliente intelbras eu consigo acessar tudo;
> > > - Usando roteador cliente Multilaser eu só consigo acessar após incluir
> > no
> > > RADVD a informação de MTU 1492;
> > > - Usando roteador cliente Mikrotik eu só consigo acessar quando faço
> > Mangle
> > > Change MSS Clamp to PMTU ou se no IPv6-ND eu inclua a informação de MTU
> > 1492
> > Se com alguns roteadores você acessa tudo, e com outros não, e
> > aparentemente em todas as situações vocês está mantendo localmente o MTU
> > de 1492, e em só uma delas você teve que mexer no tamanho do MSS, isso
> > me parece um indício de que o problema pode estar no seu lado.
> >
> > Minha hipótese é que o seu concentrador, em certas situações, a depender
> > da CPE, está ciente ou não de que o MTU do PPPoE é 1492.
> >
> > Quando não funciona:
> >
> > (a) Você vê os pacotes maiores que o MTU de 1492 vindos dos sites que
> > não abrem chegarem ao concentrador e serem descartados, porque ele não
> > consegue enviar via PPPoE pras CPEs por causa do MTU menor desse enlace?
> >
> > (b) Você vê os pacotes ICMPv6 que avisam o site que precisa baixar o MTU
> > saírem do concentrador rumo à Internet, quando acontece isso? Eles
> > passam por sua borda rumo à Internet?
> >
> > Se (a) e (b) estão acontecendo, então está tudo perfeito na sua infra, e
> > o problema é do outro lado. Se não, tem que checar localmente a origem
> > do problema.
> >
> > Note que estou supondo aqui que o problema são pacotes que (não) chegam
> > nas CPEs, vindos do site quebrado, muito grandes. O handshake tcp/ip não
> > vai ter problemas com MTU. As requisições http/https normalmente são bem
> > pequenas e vão ser enviadas também sem problemas.
> >
> >
> > > 3) Questão:
> > > - Já encontrei muito conteúdo sugerindo paliativos, como o CHANGE MSS,
> > > inclusive em discussões aqui no GTER;
> > > - Não me conformo em fazer ajustes no roteador de acesso do cliente,
> pois
> > > cada um tem o paramento em um lugar diferente e um resete põe tudo a
> > perder;
> > > - Ao meu entender o ICMPv6 Type 2 deveria agir nesse momento e baixar a
> > MTU
> > > para se encaixar no PPPoE1492, porém, parece não ocorrer. Justamente
> por
> > > isso montei um LAB com tudo limpo para minimizar os erros.
> >
> > Se é comprovado que o problema é bloqueio de ICMPv6 ou outro relacionado
> > no lado do site, o correto é notificá-los e explicar a situação pra que
> > corrijam. É de interesse deles também.
> >
> > O único caso mais ou menos recente e notório de que me lembro é o site
> > do Bradesco. Houve o problema, com recorrências, sempre comentado aqui
> > na lista. Mas até onde é do meu conhecimento corrigiram há uns anos e
> > permanece funcionando.
> >
> > []s
> > Moreiras.
> > --
> > 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
>

-- 

Atenciosamente;

*Guilherme de Menezes Jardin*
*Engenheiro de Telecom*
CREA MG 162478D
*( *Cel: (31) 99107-8277
** *gmenezesjardin at gmail.com