IPv6: A experiência de Telecom

03/02/2011

Introdução

Quando fomos convidados para compartilhar com a comunidade como se está vivendo a transição de IPv4 para IPv6 na Telecom Argentina, nos trouxeram de volta as lembranças de como foi explicar “a grande Empresa” que esse recurso tão apreciado como são os endereços IPv4, estaria se esgotando.
Organizar os começos do IPv6 nos demonstrou que as comunidades IP não são apenas um assunto técnico. IPv6 é uma mudança sem eleição e sem volta atrás, que envolve tanto aos que administram as redes quanto ao resto da companhia.

Nos inícios, cada vez que o assunto “IPv6” era introduzido, recebíamos comentários como:
– Ainda há tempo…. falamos mais adiante.
– Como é que vão se esgotar os IPs!
– Tem certeza? Quando?

A data tem chegado e graças ao trabalho desenvolvido e aos planos em andamento, a Telecom Argentina está preparada para começar afrontar a transição para IPv6.

Telecom Argentina

Telecom Argentina S.A. é uma empresa prestadora de serviços de comunicações na Argentina e no Paraguai, que apresenta resultados consolidados até 30 de setembro de 2010 de 17.843.000 clientes móveis, 1.330.000 acessos de banda larga, 4.087.000 linhas telefônicas fixas e 18% de crescimento nas vendas líqüidas de serviços de voz, dados, Internet e telefonia móvel no último ano.
Segundo a estimativa de crescimento dos serviços de dados e Internet (móvel e fixo), em 2011 vai ser necessária a designação de 1.000.000 de novos endereços IP para abastecer os nossos clientes.

Transição para IPv6

Antecedentes Históricos na Telecom:

Desde a atividade de inovação tecnológica que desenvolve a empresa, as projeções de esgotamento do pool de IPv4 começaram a ser analisadas no ano de 2005, momento a partir do qual foi adotado como objetivo requerer o cumprimento dos diferentes padrões que compõem IPv6 em todas as futuras concorrências de novo equipamento relacionados com serviços de acesso a Internet, desde o Backbone até os CPE corporativos. Essa decisão permitiu começar a contar com as ferramentas formais necessárias para começar um futuro desdobramento.
Para finais de 2007, começou o processo de desenvolvimento da engenharia, focado no backbone. Essa fase envolveu a análise detalhada das condições de suporte do IPv6 existentes na infra-estrutura, identificando as partes de hardware e de software que deviam ser substituídas por ficar obsoletas. Conseqüentemente, foi elaborado um plano de substituição para ser executado junto com o processo de ampliação de infra-estrutura necessária anual dos períodos seguintes. Desta forma, o investimento requerido foi absorvido de forma gradual pelo processo ordinário de crescimento.

Durante 2008 e 2009 foram executados os planos de capacidade que dotaram à rede do hardware e software necessário para suportar IPv6, entre outros “drivers”. Ao mesmo tempo, durante 2008 e 2009 também foram realizadas as provas de laboratório e a elaboração dos diferentes parâmetros de configuração a serem aplicados na rede através das engenharias elaboradas ad-hoc. Nesta etapa trabalhou-se em parceria com o provedor já que várias das funcionalidades necessárias encontravam-se em seu roadmap interno de desenvolvimento, ainda não liberadas para seu uso.
No último trimestre de 2009 começou a implementação na rede em produção da engenharia com as configurações lógicas previamente provadas, começando com o padrão RFC 4798 denominado “6PE” (IPv6 packets transported from PE to PE inside MPLS network) .
No segundo trimestre de 2010 foi atingido o grau de desdobramento e confiabilidade necessário diretamente em campo para conseguir o estado operativo de serviço regular no backbone. Para isso, foi fundamental o trabalho em conjunto com um cliente, RIU (Redes de Interconexão Universitária) e nosso upstream provider TIS (Seabone é o backbone internacional da Telecom Itália, propriedade e operado pela Telecom Italia Sparkle).
Nos finais de 2010, foram acabados em laboratório os ensaios de homologação sobre o padrão RFC 4659, denominado “6VPE” (IPv6 packets transported from PE to PE inside VPN-MPLS network) e está prevista a prova diretamente em campo e o desdobramento na rede no primeiro trimestre de 2011.

Gestão de endereços IPv4

Mesmo que a Telecom Argentina sempre tenha mantido seus processos de designações nos termos  das políticas do LACNIC, em 2008 e 2009 trabalhou em reorganizar as designações de todos os produtos que requeressem IPv4 para superar o esgotamento do pool de IPv4 e, visando incrementar a eficiência no uso dos espaços de endereços IPv4, foi definido um plano de adequação:

• Reorganização das designações de todos os produtos com IPv4 público
• Plano de recuperação de endereços IP
• Conscientização sobre esgotamento de IPv4 e um plano de introdução de IPv6
• Análise de impacto nos sistemas da companhia

Reorganização das designações de todos os produtos com IPv4 público

A execução do primeiro item do plano, modificou as designações de todos os produtos da Empresa que requeressem IPv4; para isso se trabalhou com as áreas de marketing e desenvolvimento de produtos dos diferentes segmentos de clientes, redefinindo que quantidade de endereços IPv4 seriam designados a cada serviço fazendo o lineamento à última política do LACNIC. O maior impacto foi provocado pelo ponto 2.3.2.8. Webhosting da atual política que afetava os clientes de Data Center.
Essas modificações foram coordenadas pela área de processos corporativos, que documentou e publicou os processos acordados no portal interno.

Plano de recuperação de endereços IP

Para levar adiante um plano de recuperação de endereços IPv4 sub-usados, foi coordenada uma Task Force, resultando na recuperação de uma grande quantidade de redes.
Conscientização sobre esgotamento de IPv4 e um plano de introdução de IPv6
Reuniões com diferentes áreas da empresa nas que lhes foi transmitida “a notícia”, resolvendo dúvidas e mitos sobre o assunto:

• Internet não vai se deter.
• Haverá endereços IPv4 em produção nas redes por muitos anos (de diferentes formas)
• IPv6 não substitui o IPv4
• IPv6 é e evolução do IPv4
• Não se trata de desabilitar o IPv4 para habilitar o IPv6. NÃO É UMA MIGRAÇÃO

A implementação do IPv6 implica que IPv4 estará coexistindo com IPv6, sendo as aplicações as responsáveis de decidir qual protocolo vão usar.

Análise de impacto nos sistemas da companhia
Foi realizada uma análise para saber quais sistemas seriam impactados e qual o prazo para realizar um plano de adequação.

Experiência em Ativação de Serviço com IPv6
Foi requerido um período de prova de campo para estabilizar o serviço.
As provas deram começo na modalidade de túneis manuais IPv6 sobre IPv4. A solução foi estendida até o upstream provider. Os resultados nesta etapa não foram muito satisfatórios devido à instabilidade no roteamento e à dificuldade operativa em identificar problemas.
(complexidade e roteamento sub-ótimo).
Resolução DNS para endereços IPv6
Deve-se contar com um software de DNS Resolver que for pilha dupla (dual stack), isto é, que suporte todos os elementos de resolução de endereços IPv4 e IPv6 indistintamente (registros A, AAAA, ptr, etc.) e que estiver dentro do domínio IPv6 (0.d.3.1.1.0.0.2.ip6.arpa). Também deve ser realizada a resolução inversa do prefixo /32 designado, a resolução inversa e direta dos inversos de cada host IPv6. Para a resolução autoritativa também deve-se contar software pilha dupla.
Como parte da experiência em ativação de serviço em IPv6, durante outubro de 2010 desenvolvemos provas de campo para verificar o estado de suporte da resolução pilha dupla em alguns servidores de conteúdos usando nosso resolver de dns pilha dupla.

A operação foi verificada em alguns sites, os que podem ser alcançados com serviço de navegação web tanto em IPv4 quanto em IPv6: www.isoc.org, www.ietf.org, www.iana.org, www.arin.net y www.lacnic.net
Porém, em sites como www.yahoo.com.ar, www.ebay.com, www.flickr.com, www.linkedin.com e www.facebook.com ainda não é possível alcançá-los com serviço de navegação web em IPv6, dado que não estão oferecendo resolução dns para IPv6, somente para IPv4.
Para o caso www.youtube.com e www.google.com, é usada uma politica de IPv6 AAAA DNS Whitelist (para qualificar requer DNS servers afastados para os usuários de IPv6, não compartilhados com usuários apenas de IPv4)

Desafios na Interconexão
Hipótese:
“ Quando certa quantidade de clientes tiverem a possibilidade de ter acesso a IPv6, uma parte de suas comunicações vão apresentar falhas…”.
Existem vários fatores que determinam a qualidade do conjunto das inter-conexões na Internet. Em particular, devido ao estágio precoce do desdobramento de IPv6, resulta importante levar em consideração a existência de trajetórias com baixa latência, a simetria em trajetos IPv4 e IPv6 para o mesmo site, a confiabilidade do estado operativo (suporte com processos industriais) e a conectividade de DNS.

A partir dessa hipótese, e como parte da experiência, verificamos a qualidade das rotas e trajetórias em alguns pontos da Internet de forma comparativa tanto em IPv4 quanto em IPv6.
Como conclusão geral, observamos que as trajetórias em IPv6 possuem uma latência da mesma ordem de magnitude que as do IPv4. Em relação à simetria na trajetória IPv4-IPv6 para o mesmo site, são observadas assimetrias, sendo um aspecto a melhorar para a confiabilidade a futuro.

Considerações finais

Para finalizar, salientamos pontos importantes para levar em conta na transição para IPv6 desenvolvidos (recomendações tiradas da IETF RFC 6036, outubro de 2010- Emerging Service Provider Scenarios for IPv6 Deployment, informational, survey of a number of ISPs carried out in early 2010).

“Sem clientes que queiram o IPv6, fica difícil conseguir o respaldo de negócio, o crescimento e a segurança do IPv6 não foi um foco para os vendedores até há  muito pouco tempo. Os operadores não têm experiência real no uso do IPv6 com seus clientes, e a conseguinte falta de confiança faz com que a adoção fique demorada…”

“O atendimento ao cliente deve ser consciente de que o IPv6 está se iniciando na rede ou servidores. Temos experimentado muitos bloqueios de aplicações em IPv6, aplicações que não fazem fallback no IPv4…”

“A evangelização continua sendo uma necessidade já que parece que muitos ISPs ainda não estão cientes da necessidade de um plano de introdução do IPv6 e estão inclinados a tomar o esgotamento do IPv4 como uma falsa alarme, e parece também que não estão cientes de que NAT cria requisitos de suporte muito caros”

E finalmente:

• Why bother moving to IPv6?
• Ready or not, here is IPv6
• Don’t panic! The web isn’t full to capacity – yet

Agradecimentos:

A nossos gerentes e diretores que nos apóiam incondicionalmente neste projeto e a equipe de trabalho que o torna possível.

Eng. Gabriel Castro
Gerência Engenharia de Transporte – Gerência Engenharia- Direção de Tecnologia- Direção Rede –TELECOM ARGENTINA
Eng. Marta Astaco
Gerência Asseguramento de Redes e Serviços- Direção de Asseguramento e Provisão de Redes e Serviços- Direção Rede- TELECOM ARGENTINA