[GTER] Morte às mensagens de NAT tipo 3 - DANOS - CGNAT OpenSource com BPA EIM/EIF e UPnP/PCP

[Vinicius Gruske Dorneles]

Eu não possuo console, mas tenho uma bela coleção de jogos no PC. E nesse
pouco mais de um ano de CGNAT pela NET, não possuo problema de jogar com
CGNAT. Mas provavelmente teria problema se tivesse um console.



Acredito que o único impacto do CGNAT (fora o incremento de latência) para
jogos, é a quebra do peer-to-peer. Jogos que possuem servidores, com IPv4
público, nunca ouvi reclamação de conectividade. O problema é os jogos que
não possuem servidores públicos, e que utilizam do próprio
computador/console como um servidor para iniciar uma partida online.



Para isso, em um computador, basta você instalar uma VPN (Hamachi, Radmin,
etc), abrir o Age of Empires 2, e colocar o IP (da VPN) do coleguinha
Hosteando a partida. A latência vai pra 150-200ms? Vai, mas tu consegue
jogar.

Em um console, não existe (salvo melhor juízo) a opção de instalar uma VPN
para jogar online.



No console, até para iniciar uma sala com chat de voz, a conexão é
peer-to-peer. Em contra partida, no computador, temos Discord, Skype,
TeamSpeak, etc.



Sobre “bater forte nas empresas de games”, eu tenho uma ponderação. Ativar
o IPv6 em servidores de um jogo que tem servidores públicos em IPv4, não
vai mudar em nada a conectividade. (Destacando que conectividade não é
qualidade da conexão, e sim sobre funcionar ou não).



Vou citar o exemplo do League of Legends. Quem aqui tem problema de
conectividade ou NAT com o Lolzinho? Não tem, por que possuem IPv4 público.
A uns 6-8 meses mandei um ticket perguntando sobre o IPv6 pro suporte da
Riot, e eles responderam que não tinham previsão de implementação.

Por mais que eu ache uma vergonha a Riot (subordinada da gigantesca
Tencent) não possuir suporte a IPv6, ela não é um problema imediato.



Quais são os jogos então onde o problema é imediato? Os jogos que não
possuem servidores públicos e/ou que permitem criação de partidas online,
onde o servidor é o próprio console/computador.



Por exemplo, se o Age of Empires 2 tivesse suporte a IPv6, eu não
precisaria instalar um Hamachi/Radmin. Bastaria eu colocar o IPv6 do
coleguinha Hosteando a partida.

Pra criação de chat de voz, a mesma coisa, se tivesse suporte a IPv6, o
peer-to-peer para a chamada de voz, funcionaria.



Logo, vale a pena bater forte na Riot? Se ela não se mexer, vai ter que,
mas a prioridade é as outras empresas que possuem jogos hosteaveis.



As novas gerações de console da Microsoft e Sony chegam (ou deveriam
chegar) no final do ano. Vamos ver o que nos aguarda.



Acho que o NIC.br vem fazendo um ótimo trabalho para treinar o pessoal dos
provedores, e acho que está surgindo efeito, mas acho que está faltando um
trabalho para treinar os programadores.



Eu tenho alguns amigos programadores, e se não fosse eu encher o saco
deles, provavelmente eles não saberiam até hoje o que é IPv6.

E digo mais (sem querer ofender ninguém), hoje, a maioria dos programadores
não programam. Se eles precisam que aplicação X que estão programando tenha
a funcionalidade online, eles catam na internet um framework pronto
(leia-se código pronto) e aplicam no código. Normalmente o framework que
está disponível na internet só funciona o IPv4. Se o programador quisesse
que funcionasse IPv6, eles teriam que programar do zero ou catar um
framework em IPv6, o que, aparentemente, está em falta na internet.



Além disso, seria interessante a NIC.br estar perto das faculdades.

Por exemplo, na minha graduação de Telecomunicações (SENAI/RS), eu vi
BEEEEM por cima sobre endereçamento IPv6.

Também fiz dois semestre de Jogos Digitais (Unisinos/RS), e lá, não existia
NENHUM interesse sobre IPv6. A resposta que ouvi foi: “Pegue o framework de
network da Unity, tu não precisa de mais nada”. A pergunta é, o framework
de network da Unity funciona com IPv6?



Eu concordo com o Carvalho em tratar o IPv4 como legado. Nos quase dois
anos que fui responsável técnico por um provedor, logo que implementei o
IPv6 + CGNAT, sempre que surgia alguém solicitando redirecionamento de
porta, eu me negava a fazer, e não fiz. Sinceramente, não me lembro de
nenhum cancelamento referente a isso. No final das contas, devo ter gastado
uns 15 minutos com cada um dos ~50 “técnicos” de clientes ensinando eles a
mexer em câmera/DVR em IPv6. Hoje são ~50 “técnicos” que instalam
câmeras/DVR em IPv6, e ~50 regras que eu não precisei colocar no CGNAT.



Hoje, prestando consultoria a provedor, eu vejo que a maioria dos donos de
provedores, que se o cliente bate o pé que quer em IPv4, ele vai lá, baixa
as calças, e faz o redirecionamento estático no CGNAT. E assim, perpetua-se
o uso do IPv4.



A um tempo se discutia que o “gargalo” do IPv6 era os provedores de acesso.
Não querendo isentar os provedores de acesso do trabalho que eles tem que
fazer, mas acho que hoje o gargalo é outro: são os programadores e usuários
finais.

Em qui., 23 de jul. de 2020 às 23:15, Fernando Frediani <
fhfrediani at gmail.com> escreveu:

> Sinceramente até agora eu não vi nenhum, nenhum mesmo, (zero) game dos
> mais conhecidos suportarem IPv6.
> Uma coisa é o Sistema Operacional do console ter suporte à IPv6, outra é
> o jogo funcionar em cima de IPv6. Isso ainda parece que a maioria, senão
> a totalidade dos jogos de console estão longe.
>
> Empresas como a Valve por exemplo distribuem conteúdo de Download dos
> jogos em cima de IPv6, mas os jogos em si não funcionam em cima do
> protocolo. Ao menos eu nuca vi um só. Muito possivelmente é por isso que
> elas possuem sessões BGP, então se eles derrubarem sessão BGP só vai
> impactar a distribuição de conteúdo por ali, não o gameplay que segue
> sendo em IPv4.
>
> Com relação a Playstation tem um tempo eu li um relato de uma pessoa que
> trabalha com redes publicou no blog dele e ele dizia o seguinte: que ele
> capturou pacotes do Playstation dele disse que quando o console iniciava
> ele se conectava à uma URL específica da Sony cujo FQDN tem suporte à
> IPv6 e não fazia mais nada. Ele imagina que isso seja apenas uma
> ferramenta para a Sony conseguir medir quantos consoles possuem
> conectividade à IPv6 funcionando para quem sabe pensarem e adicionarem
> suporte aos jogos.
> Outro ponto que ele deduziu foi: console pegava IP não apenas por SLAAC,
> mas por DHCPv6 Client também, ou seja, na visão dele o Sistema
> Operacional do console passar a ter suporte à IPv6 não foi "acidental",
> mas intencional, possivelmente para poder medir a penetração de IPv6 na
> base de usuários.
>
> Fernando Frediani
>
> On 23/07/2020 22:41, Douglas Fischer wrote:
> > Sobre forçar a barra com os Games...
> >
> > Informações que eu sei até agora:
> >
> > 1- XBox Live tem suporte a IPv6, mas pouquíssimos games online fazer uso
> do
> > IPv6.
> > 2- PSN não alega ter suporte a IPv6, mas "por baixo dos panos" sabemos
> que
> > o Playstation pega IPv6 e faz algumas comunicações com a Internet em v6
> > (ouvi relatos de testes com apenas os DNSs v6 respondendo e que ele
> > "funcionou")
> > 3- A parte complicada das comunicações de Games é o Peer-to-Peer.
> > 4- Para as empresas de Games multi-console(que são quase todas),
> suportarem
> > IPv6 no Xbox e não terem acesso ao IPv6 no Playstation não é uma coisa
> > simples...
> > (abriria muita margem para mi-mi-mis do tipo "jogo tal não toca audio
> > quando jogo com alguém que joga com console tal")
> > 5- Algumas empresa de games tem atitudes bem vergonhosas com relação a
> > IPv6... Já vi algumas fazendo pouco caso de fechar a sessão BGP em IPv6.
> > (experimenta derrubar só a sessão v6 no PNI com qualquer uma das OTTs
> para
> > ver quanto tempo leva para eles te aporrinharem)
> >
> > Então, minha sugestão?
> > 1- BATER FORTE NA PSN!
> > 2- BATER FORTE NAS EMPRESAS DE GAMES.
> >
> > MAAAAAAS, por melhor que sejam os resultados de uma campanha de pegação
> no
> > pé dessas empresas.
> > ESQUEÇAM que o suporte com mais de 75% dos recursos desses games vai
> > acontecer antes de 2024.
> >
> > E até lá? Vivemos como?
> > Temos que pensar em um CGNAT bem feito sim!
> >
> > Em qui., 23 de jul. de 2020 às 22:26, Douglas Fischer <
> > fischerdouglas at gmail.com> escreveu:
> >
> >> Como o Rubens falou...
> >> Um IP para cada assinante Gamer não escala!
> >> Um ISP com 5000 clientes em um /22, que tenha 300 clientes games já
> >> gastaria 30% dos IPs públicos só com Gamers.
> >>
> >> E uma coisa é certa:
> >> Caixas de CGNAT de marcas renomadas RESOLVEM QUASE TOTALMENTE o problema
> >> de Gamers e CGNAT com o suporte correto a PCP/UPnP e EIM/EIF.
> >>
> >> A quesão aqui é não ter que pagar 100K numa caixa pra 10Gbps de CGNAT.
> >>
> >>
> >> Em qui., 23 de jul. de 2020 às 22:15, Rubens Kuhl <rubensk at gmail.com>
> >> escreveu:
> >>
> >>> Só que atribuir um IPv4 para cada assinante gamer não escala... a
> >>> diferença de valor de assinatura que conseguiria pagar aquisição de
> >>> blocos no mercado secundário não é admitida pelo mercado.
> >>>
> >>>
> >>> Rubens
> >>>
> >>> On Thu, Jul 23, 2020 at 10:08 PM Renato Frederick
> >>> <renato at frederick.eti.br> wrote:
> >>>> Uma pergunta:
> >>>>
> >>>> Não desmerecendo o quão interessante é fazer o estudo e os resultados
> >>> obtidos, mas levando pro lado de quem não tem poder de ficar testando,
> seja
> >>> lá os motivos:
> >>>> Notei o foco em jogos online e SIP.
> >>>> Para os gammer's e empresas que precisam de RTP/SIP, a solução seria
> >>> alocar além do IPv6, 1 IPv4, tirar o GCNAT e menos 1 cliente amolando?
> >>>> Pergunto pois aqui quando por engano colocaram o GCNAT, por coindencia
> >>> fiquei jogando pra passar tempo, até o vendedor conseguir fazer "o
> >>> sistema"(este ser místico, que usam quando não querem admitir o erro
> >>> humano) entregar pro técnico o pedido e pagamento do IPv4. A Tela de
> status
> >>> do psn ficou ruim.
> >>>> Depois que pus o IPv6 ficou mais ou menos e a qualidade perfeita veio
> >>> com o IP público. As telas de teste ficam joia quando ativa UpnP.
> >>>> Pra quem hoje não aguenta mais cliente que fala que paga 300M pra
> jogar
> >>> e bla blá blá, a solução é tirar CGNAT, fornecer IPv4 público, daí
> ativar
> >>> no Equipamento dele Nat plug and play, salvar este IP nós logs e menos
> 1
> >>> problema?
> >>>> Pois estes dias vivendo "do outro lado" notei que CGNAT(ou como
> fizeram
> >>> aqui) não flui com jogos.
> >>>>
> >>>>
> >>>> ⁣Enviado do meu celular. Desculpe a brevidade.
> >>>>
> >>>> Em 23 de jul de 2020 14:56, em 14:56, Douglas Fischer <
> >>> fischerdouglas at gmail.com> escreveu:
> >>>>> Eu escrevi essa montoeira de siglas ali em cima...
> >>>>> Mas tenho certeza que o que chamou atenção dos coleguinhas foi a
> parte
> >>>>> do
> >>>>> "Morte às mensagens de NAT tipo 3".
> >>>>> -> 3 vivas para os tickets de suporte que os usuários de PSN e XBOX
> >>>>> abrem
> >>>>> por causa das mensagens de NAT Tipo 3, não é mesmo?
> >>>>>
> >>>>> TL;DR:
> >>>>> Se você manja bem dos paranauê de linux, nat/iptables e similares, e
> >>>>> está
> >>>>> disposto a fazer uma tentativa uma ferramenta opensource que promete
> >>>>> resolver muitos problemas que o CGNAT trás, eu gostaria de contar com
> >>>>> sua
> >>>>> ajuda! Arranje um servidor BOM(não bom venha com velharia) e "bora si
> >>>>> ajudá" a parar de passar raiva com CGNAT.
> >>>>>
> >>>>> A importancia do CGNAT para ISPs no dia de Hoje
> >>>>> -----------------------------------------------
> >>>>> Se você está no mercado atual de ISPs e nunca ouviu falar de CGNAT,
> >>>>> PARE O
> >>>>> QUE ESTÁ FAZENDO E VÁ PROCURAR SABER SOBRE CGNAT!
> >>>>> Pois existe um grande risco de você estar fazendo as coisas de um
> jeito
> >>>>> errado, e logo-logo ter problemas legais por conta disso.
> >>>>>
> >>>>> Se você já ouviu falar CGNAT, deve saber que existem basicamente 2
> >>>>> tipos de
> >>>>> CGNAT.
> >>>>> (vou ser muito muito muito conciso nessa descrição)
> >>>>> - Determinístico(ou Predefined) - Onde ranges de portas UDP e TCP de
> >>>>> IPs
> >>>>> Públicos/Válidos são préviamente alocadas para as conexões saintes de
> >>>>> cada
> >>>>> um dos IPs de uso reservado do CGNAT.
> >>>>>    A principal vantagem desse modelo é (se ele for implementado
> >>>>> corretamente) não precisar da guarda de LOGs.
> >>>>> - BPA - Bulk Port Allocation - Onde as portas vão sendo alocadas de
> >>>>> Tanto-em-Tanto para os   IPs de uso reservado do CGNAT conforme ele
> vai
> >>>>> precisando, e cada vez quem um grupo de portas é alocado, o mecanismo
> >>>>> de
> >>>>> CGNAT deve fazer um LOG disso, e esse log deve armazenado
> >>>>> adequadamente.
> >>>>> A principal vantagem desse modelo é o excelente nível de relação
> entre
> >>>>> IPs Válidos/Públicos e os IPs reservados do CGNAT.
> >>>>>
> >>>>> Os dois modelos tem vantagens, os dois modelos tem desvantagens...
> >>>>> Sinceramente sou adepto do BPA, pois apesar de exigir recursos extras
> >>>>> de
> >>>>> Log, tem uma melhor utilização das portas dos IPs públicos, e a
> >>>>> alocação
> >>>>> dinâmica reduz a dor de cabeça com usuários que usam muitas portas.
> >>>>>
> >>>>> P.S.: Alerta de problemas jurídicos!
> >>>>> Uma coisa que tenho visto muito por aí é uma galerinha que tá fazendo
> >>>>> uns
> >>>>> mapeamento maroto sem uma lógica reversível e sem fazer log.
> >>>>> Quando chegar uma ordem judicial especificando
> >>>>> IPDeOrigem/PortaDeOrigem/DataeHora, e você não conseguir fazer a
> >>>>> identificação INEQUÍVOCA responsável do contrato daquele assinante...
> >>>>> A coisa tente a ficar feia pro seu lado... CUIDADO!
> >>>>>
> >>>>>
> >>>>> Aonde está a maior parte das dores que o CGNAT trás?
> >>>>> ----------------------------------------------------
> >>>>> CONEXÕES ENTRANTES AUXILIARES formadas para comunicação Peer-to-Peer.
> >>>>> Geralmente esses mapeamento de conexões auxiliares entrantes são
> feitos
> >>>>> ALGorítimos que ficam escutando as comunicações nas portas
> determinadas
> >>>>> e
> >>>>> "preparam uma regrinha dinâmica" para conexão entrante...
> >>>>> Os protocolos mais comuns de ver isso são:
> >>>>> - SIP/H323
> >>>>> - FTP ativo/passivo
> >>>>> - DCCP(que é o que a maioria dos games usa)
> >>>>> Porém para esses ALGs funcionarem, além de o equipamento de NAT tem
> que
> >>>>> ter
> >>>>> todos os ALGs habilitados, e a comunicação nesse protocolo de
> controle
> >>>>> não
> >>>>> pode ser criptografada.
> >>>>> -> Para exemplificar, SIP-ALG não vai funcionar se for SIP over TLS
> >>>>>     (a não ser que ele abra a criptografia do TLS).
> >>>>>
> >>>>> Para contornar essa complexidade que esse ALGs trazem para fazer
> >>>>> funcionar o P2P com regras de firewall e CGNAT foram criados padrões
> e
> >>>>> protocolos como PCP/UPnP, EIM/EIF (antes era o NAT-PMP).
> >>>>>
> >>>>>
> >>>>> A ESPERANÇA
> >>>>> -----------
> >>>>> Já tem muito tempo que eu venho buscando uma solução OpenSource para
> >>>>> CGNAT
> >>>>> que concorresse com a soluções proprietárias como "A10/F5/Hillstone"
> >>>>> para
> >>>>> ambientes de CGNAT com suporte a BPA e PCP.
> >>>>> Inclusive eu e mais alguns amigos chegamos a propor um vakinha
> on-line
> >>>>> para
> >>>>> comprar o desenvolvimento disso no formato OpenSource.
> >>>>>
> >>>>> Bom... Felizmente acredito que tenhamos achado a solução OpenSource
> que
> >>>>> eu
> >>>>> procurava...
> >>>>>
> >>>
> https://danosproject.atlassian.net/wiki/spaces/DAN/pages/421101573/CGNAT+and+PCP
> >>>>> Ainda estou preparando um ambiente de testes dessa ferramenta.
> >>>>> Mas estou bastante otimista com o que pude ver dela.
> >>>>>
> >>>>> Dentre a diversas coisas boas que posso falar sobre esse projeto, é
> que
> >>>>> mesmo sendo opensource ele tem uns empurrõezinhos de grandes ISPS e
> >>>>> carriers como a AT&T.
> >>>>>
> >>>>> O PEDIDO DE AJUDA
> >>>>> -----------------
> >>>>> No momento, a melhor maneira que eu encontrei de ajudar esse projeto
> >>>>> OpenSource é fazer um apelo aos colegas brasileiros que tenham
> >>>>> expertise
> >>>>> para manter um ambiente de NAT em Linux, que mantenham redes de ISP
> que
> >>>>> usem CGNAT, e que queiram ajudar a validar se essa ferramenta é
> >>>>> realmente
> >>>>> tão PORRETA, colocando ele para rodar em algum ambiente de teste e
> >>>>> compartilhando com o pessoal do projeto o resultado.
> >>>>> <
> >>>
> https://danosproject.atlassian.net/wiki/spaces/DAN/pages/421101573/CGNAT+and+PCP
> >>>>>
> >>>>> NÃO É UMA TELA DO WINBOX
> >>>>> ------------------------
> >>>>> Minha sugestão sobre a quem seria indicado embarcar nesses testes.
> >>>>>
> >>>>> P.S.: Antes que venham me achincalahar de metido... Já adianto:
> >>>>> Estou pedindo a colaboração aqui na lista porque, sendo sicero, tenho
> >>>>> dúvidas se eu tenho conhecimento técnico suficiente para segurar esse
> >>>>> rojão.
> >>>>> E também porque sei que temos vários colegas aqui na lista que tem um
> >>>>> nível
> >>>>> Master-Pica-Jedi e que conseguiriam lidar com os prossíveis problemas
> >>>>> que
> >>>>> surgirão com se estivessem descascando amendoim.
> >>>>>
> >>>>> - Se for querer usar um hardware velharia/lixo, com mais de 10-12
> >>>>> anos...
> >>>>> Fora da lista de compatibilidade do projeto.
> >>>>>   ou
> >>>>> - Se você não tem um bom conhecimento para conseguir fazer
> >>>>> troubleshooting
> >>>>> em ambientes mais elaborados de Fowarding, NAT, e Firewall de Linux.
> >>>>>
> >>>>> -> NÃO SE META!
> >>>>>    Você vai passar raiva...
> >>>>>    Depois vai pedir ajuda...
> >>>>>    Vai fazer os coleguinhas passarem raiva,
> >>>>>    que irão usar palavras pesadas com você...
> >>>>>    E depois você vai sair falando baoseiras sobre o projeto!
> >>>>>
> >>>>> Ao meu entender o projeto é bastante robusto e maduro!
> >>>>> Mas nesse momento ainda não é algo que esteja mastigadinho no nível
> >>>>> "tutorial do underlinux ou do vivaolinux" que seja só copiar e
> colar...
> >>>>>
> >>>>>
> >>>>> --
> >>>>> 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
> >>>
> >>
> >> --
> >> Douglas Fernando Fischer
> >> Engº de Controle e Automação
> >>
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>