To NAT or not to NAT? That's the question for HSPA/HSPA+
Autor: J. R. Smolka | Publicado: 2011-11-09T18:10:00-02:00

No artigo anterior eu defendi a tese que a opção menos ruim (porque boa, boa mesmo, de verdade, não tem) para a migração do serviço de acesso móvel à Internet através das redes de acesso celulares 3G (HSPA e HSPA+) era a abordagem dual-stack&nbsp;(ver RFC 4213).

Nos comentários daquele artigo o Rubens Kuhl e o Juliano defenderam que a melhor opção é o uso do NAT64. Certamente que eu acho possível usar o NAT64 neste contexto, mas tenho dúvidas se ele vai funcionar tão bem.

Antes de começar a discutir prós e contras relativos de cada abordagem, pelo bem daqueles leitores que não tenham familiaridade com o assunto (afinal este blog tem uma finalidade basicamente instrutiva), vou fazer uma breve apresentação do que se trata o NAT64.

NAT significa Network Address Translation. Na Internet v4 o uso extensivo de NAT (ver RFC 2663) e dos blocos de endereçamento privado definidos na RFC 1918&nbsp;permitiram um considerável aumento da sobrevida do espaço de endereçamento do IPv4, mas também criaram uma sensação de falsa segurança, e muito pouca coisa concreta foi feita para que a transição IPv4-IPv6 ocorresse de fato. Resultado: muito tempo perdido, e agora vamos ter que fazer correndo o que podia ter sido feito com calma.

Na Internet v6 não existe motivo para o uso de NAT, como é destacado na RFC 4864. Já a questão de como um host v6 pode estabelecer conexão com um host v4, e vice-versa, só pode ocorrer mediante alguma forma de NAT para fazer a "ponte" entre as duas Internets (v4 e v6).

O NAT64 permite que aplicações em um host&nbsp;que seja&nbsp;single-stack IPv6 consigam acessar aplicações que residem em hosts também single-stack, porém IPv4. Os recursos necessários para usar o NAT64 são:


Um Well-Known Prefix&nbsp;(WNP) IPv6. Conforme a seção 2.1 da RFC 6052, o WNP para o NAT64 é 64:ff9b::/96 (se você já penou pra entender a notação dotted decimal dos endereços IPv4, então prepare-se, porque a notação dos entereços IPv6 é bem mais críptica. Sugiro dar uma olhada aqui).
Servidor DNS que suporte as extensões DNS64 (RFC 6052 e RFC 6146)


A figura abaixo mostra o esquema geral de funcionamento do NAT64.










O fluxo de mensagens mostrado é para quando o host de destino só possui conectividade IPv4 (o que fica evidente pela resposta de erro do servidor DNS para o servidor DNS64 quando ele pede o registro AAAA do host de destino). Se o host de destino possuísse conectividade IPv6 haveria uma resposta válida para a query pelo registro AAAA no servidor DNS, e (mesmo que o host de destino fosse dual-stack e também houvesse uma resposta com o registro A associado) a conectividade IPv6 seria possível - logo o gateway NAT64 não seria usado.



Bonito, porém vejo um problema sério nesta abordagem. Ele é muito bom quando os UEs estão querendo acessar servidores IPv4 no regime client-server habitual (ex.: web surfing e&nbsp;verificação da caixa postal de e-mails). Mas a situação muda quando a direção do início da sessão é invertida (da Internet v4 para dentro da "ilha" IPv6 que é a rede interna da operadora). E, no quadro de funcionamento peer-to-peer típico das aplicações de telefonia &nbsp;(tanto na conexão bearer quanto na conexão de sinalização SIP) isto vai ocorrer a toda hora - Exemplo: o IMS de uma operadora, ainda usando IPv4, tentando negociar o estabelecimento de uma sessão com o IMS de outra operadora, que já migrou a plataforma para IPv6.



Aí a solução será o que? Incorporar suporte a NAT64 stateless, mais algum mecanismo de NAT traversal, tipo STUN ou TURN? Vai ficar complicado. E talvez não escale bem.



No geral ainda simpatizo mais com a solução puramente &nbsp;dual-stack apresentada no post anterior. É certo que também é necessário o suporte do DNS64, mas fica muito mais simples para as aplicações decidirem como estabelecer conexão. Se ela recebe um registro AAAA, então a conectividade é estabelecida pelo socket v6, e se recebe apenas um registro A, ela usa o socket v4. E não há obrigatoriedade que o servidor DNS64 tenha conectividade IPv6, como é o caso na solução NAT64.



Outro problema óbvio para a solução dual-stack no ambiente das redes de acesso HSPA/HSPA+ é que cada UE precisa receber endereçamento IPv4 e IPv6, só que nenhuma operadora tem (nem vai ter)&nbsp;pool de endereços IPv4 públicos suficientes para atender à demanda de todos os clientes conectados. Neste caso creio que a saída menos ruim (porque também tem problemas de escalabilidade) é a proposta Dual-Stack Lite (DS-Lite, RFC 6333). Veja a figura abaixo.







Na proposta DS-Lite o endereçamento IPv4 dos UEs (que são dual-stack) é feito com endereços de alguma das faixas privadas definidas na&nbsp;RFC 1918&nbsp;(ex.: 10.0.0.0/8). O tráfego IPv4 é destinado para a Internet v4 através de um Carrier-Grade NAT (CGN) gateway&nbsp;de forma muito parecida com o que já é feito hoje. E o tráfego IPv6 é encaminhado diretamente à Internet v6. Possivelmente a "ilha" IPv6 da operadora estará conectada às demais "ilhas" IPv6 por mecanismos de tunelamento sobre a Internet v4. Destes todos, o que me parece mais utilizado no momento é, como já disse no post anterior, o Teredo (RFC 4380), mas também existem outras opções, como, por exemplo, o 6rd (RFC 5569 e RFC 5969).



E, para não alongar muito, se for o caso deixo para mais tarde a análise do SIIT (Stateless IP/ICMP Translation - RFC 6052, RFC 6144 e RFC 6145) no contexto das redes de acesso HSPA/HSPA+.



Para fechar, então. um resumão do problema, conforme a minha opinião (o 3GPP e os fornecedores podem divergir - só que a operadora deve ter suas próprias idéias, não andar a reboque do que dizem os fornecedores), e é o que eu recomendaria às operadoras:


O grande fator decisivo da estratégia é o roadmap de disponibilidade do IPv6 pelos fornecedores dos UEs. Computadores convencionais não são problema, porque todos os sistemas operacionais relevantes (MS-Windows, Apple MacOS, Linux em vários "sabores", Solaris, HP-UX, AIX, zOS, etc.) já oferecem suporte ao dual-stack. O problema são os smartphones e os tablets. Todo o resto, para mim, é legacy.
Se a questão da duplicidade dos PDP contexts não for um problema, minha sugestão é: vá para uma solução dual-stack. Se o pool de endereços IPv4 apertar, cá para DS-Lite.
Se UEs dual-stack forem escassos, ou a duplicidade dos PDP contexts for um problema, vá para o NAT64. Separe os UEs legacy para usarem apenas PDP contexts IPv4, e, para todos que suportarem, use apenas PDP contexts IPv6.


Por ora é isso. Mas este é o tipo do assunto que ainda pode render mais posts, então até a qualquer momento, em edição extraordinária.