[GTER] IPV6 Bradesco

Thu May 23 11:50:25 -03 2019

Complementando essa thread...
De acordo com a RFC 2460,

8.3 <https://tools.ietf.org/html/rfc2460#section-8.3> Maximum
Upper-Layer Payload Size
  [...]When using TCP over IPv6, the MSS must be computed as the
maximum packet size minus 60 octets.

Isso significa que se você usar 1492 de MTU nos seus clientes, você
pode alterar a regra enviada para para alterar apenas pacotes que
derem match com tcp-mss > 1432

/ipv6 firewall mangle
add action=change-mss chain=forward comment="change mss" in-interface=all-ppp \

new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn
tcp-mss=1433-65535
add action=change-mss chain=forward comment="change mss"
out-interface=all-ppp \

new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn
tcp-mss=1433-65535

Já se você usa 1480 de mtu nos seus clientes, ai a regra deveria ser:

1480 - 60 = 1420

Como não queremos dar match nos 1420, mas sim acima disso, ai por isso
foi usado 1421 na regra enviada pelo @Décio Colli.

Agradecido pela resolução!

Aplicamos aqui em RouterOS 6.43.14 (ainda sem implementação disso
diretamente como é no IPv4)

Andre Almeida

Em seg, 24 de set de 2018 às 15:59, Décio Colli <deciocolli at gmail.com>
escreveu:

> O mikrotik a partir dessa versão 6.41 começou a fazer a tratar o MTU
> do pppoe via kernel, mas esqueceram do IPV6, conversei com eles, e
> eles falaram que realmente não há esta implementação do tratamento de
> MTU no IPV6, então quando temos um servidor pppoe Mikrotik e um
> cliente pppoe mikrotik, o site do Bradesco simplesmente não funciona
> direito, sei de apenas este mas deve ter outros, pois o único banco
> que funciona realmente em ipv6 é o Bradesco., interessante que quando
> o cliente pppoe é outro roteador que não seja mikrotik, não há
> qualquer problema, o site funciona perfeitamente, acredito que esses
> roteadores façam o tratamento do MTU. Abaixo changelog e conversa que
> tive com o pessoal da Mikrotik.
>
> Att,
>
> Décio
>
> Changelog
> What's new in 6.41 (2017-Dec-22 11:55):
> ....
> *) ppp - fixed "change-mss" functionality when MSS option is missing
> on forwrded packets;
> .....
>
>
> Hello,
>
> Yes, the fix applies for IPv4 only, it is not present for IPv6 yet.
>
>
> Best regards,
> Sergejs B.
> Em dom, 23 de set de 2018 às 15:00, Emerson Barea
> <emerson.barea at gmail.com> escreveu:
> >
> > Senhores, bom dia.
> >
> > Não afirmando que este é o motivo, mas dando uma ideia de possível causa
> > para este problema é a necessidade de fragmentação de pacotes.
> >
> > Já peguei um caso bem interessante desses há algum tempo atrás e o
> problema
> > é que havia um firewall no meio do caminho bloqueando os ICMPs dos
> routers
> > que pediam para fragmentar o datagrama, por isso, algumas coisas eu
> > conseguia acessar, outras não (resumindo, datagramas pequenos passavam e
> os
> > grandes não, pois, tinha um router com redução de MTU no caminho, ele
> > mandava o ICMPv6 pedindo ao emissor para reduzir o pacote, mas esse
> ICMPv6
> > nunca chegava, pois, um firewall no caminho bloqueava.)
> >
> > Esse pdf dá uma boa ideia do que estou falando:
> > https://labs.apnic.net/presentations/store/2017-10-25-xtn-hdrs-dns.pdf
> >
> > Bom, o troubleshooting não é trivial, pois, precisa analisar os pacotes
> nas
> > duas pontas da rede (ou em partes diferentes) para ver se há pacotes
> ICMPv6
> > sendo enviados em algum ponto, dai tentando entender onde eles são
> > bloqueados.
> >
> > Mais uma vez alerto que esta é apenas uma ideia do que pode estar
> > acontecendo.
> >
> > Abraço.
> >
> > Em sex, 21 de set de 2018 às 18:23, Alan Mendes <alan at zuknet.com>
> escreveu:
> >
> > > Bradesco está há mais de 3 anos assim, única forma que encontrei de
> fazer
> > > funcionar é fazer um change mms para 1420 o MTU do pacote.
> > >
> > > Ai vai de boa.
> > > Já cansei de passar isso para eles, está com algum problema na
> negociação
> > > do MTU , mas não resolvem.
> > >
> > >
> > >
> > >
> > >
> > >
> > > *ZUKNET NETWORKS LTDA. MEAlan Mendes Morais*
> > > *Email:* alan at zuknet.com
> > > *Tel:* 15 3376-9893
> > >
> > >
> > > www.zuknet.com
> > > http://as262333.peeringdb.com
> > > http://bgp.he.net/AS262333
> > >
> > >
> > >
> > > Em sex, 21 de set de 2018 às 17:19, Michel Castro <
> > > michelfdecastro at gmail.com>
> > > escreveu:
> > >
> > > > Ping vai de boa, acessa até a página, o problema é a hora que o
> cliente
> > > vai
> > > > acessar a conta que não vai.
> > > >
> > > > Em sex, 21 de set de 2018 15:27, Danton Nunes <
> danton.nunes at inexo.com.br
> > > >
> > > > escreveu:
> > > >
> > > > > On Fri, 21 Sep 2018, Renan Menezes wrote:
> > > > >
> > > > > > Por aqui não estou com problemas para acessar, mas o Ping está
> dando
> > > > > 137ms.
> > > > >
> > > > > da minha estação de trabalho (e, admito, lazer também):
> > > > >
> > > > > $ ping -6 -n www.bradesco.com.br
> > > > > PING www.bradesco.com.br(2600:1419:0:4a1::2f9) 56 data bytes
> > > > > 64 bytes from 2600:1419:0:4a1::2f9: icmp_seq=1 ttl=56 time=5.66 ms
> > > > > 64 bytes from 2600:1419:0:4a1::2f9: icmp_seq=2 ttl=56 time=5.09 ms
> > > > > 64 bytes from 2600:1419:0:4a1::2f9: icmp_seq=3 ttl=56 time=5.08 ms
> > > > > 64 bytes from 2600:1419:0:4a1::2f9: icmp_seq=4 ttl=56 time=5.05 ms
> > > > > ^C
> > > > > --- www.bradesco.com.br ping statistics ---
> > > > > 4 packets transmitted, 4 received, 0% packet loss, time 3003ms
> > > > > rtt min/avg/max/mdev = 5.052/5.225/5.668/0.261 ms
> > > > >
> > > > > Via Algar.
> > > > > --
> > > > > 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
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>