Quem sou eu

Minha foto
Salvador, BA, Brazil
Analista de sistemas, expert em telecom, formado em Eng. Elétrica e nerd assumido

quarta-feira, 9 de novembro de 2011

To NAT or not to NAT? That's the question for HSPA/HSPA+

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 (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 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 que seja 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 (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 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  (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  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) 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 RFC 1918 (ex.: 10.0.0.0/8). O tráfego IPv4 é destinado para a Internet v4 através de um Carrier-Grade NAT (CGN) gateway 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.

2 comentários:

  1. Minha defesa de IPv6+NAT64 é apenas como uma melhor alternativa ao IPv4privado+Teredo para operadoras que queiram apenas um PDP context por terminal; dual-stack é a solução de melhor funcionamento quanto há suporte de rede e endereços IPv4 públicos suficientes.

    ResponderExcluir
  2. Nisto vc está certo Rubens. Se o jeito é um único PDP context por usuário, é melhor que seja IPv6 (desde que os UEs suportem), e aí a saída é mesmo o NAT64.

    Mas uma observação: o Teredo está no cenário pela necessidade de conectar a "ilha" v6 da operadora com as demais "ilhas" v6 através do "mar" v4 (situação 1 da migração, conforme o desenho do posto anterior). Ele será necessário sempre, mesmo (ou especialente) no caso do NAT64, porque ele resolve o problema de conectividade cruzada v6 x v4. Ms a questão da interconexão das "ilhas" v6 permanece.

    ResponderExcluir