Migração do IPv4 para o IPv6 Formas, Benefícios e Implantação 1

Transcrição

1 V SRST SEMINÁRIO DE REDES E SISTEMAS DE TELECOMUNICAÇÕES INSTITUTO NACIONAL DE TELECOMUNICAÇÕES INATEL ISSN SETEMBRO DE 2016 Migração do IPv4 para o IPv6 Formas, Benefícios e Implantação 1 Clayton Gonçalves Coelho 1, Evandro Luis B. Gomes 2 Abstract This article aims to present a brief history of the appearance, features and benefits of IPv6, as well as a comparison with its predecessor IPv4 and describe the main differences between them. Also will present some forms of migration to IPv6, with practical examples of the techniques Dual Stack, NAT and Tunnel. Especially highlighting the benefits that Dual Stack technique offers this time of transition in relation to other techniques, to allow operate natively with both protocols simultaneously. At the end it will be displayed as is the membership will increase to IPv6 by countries through traffic on the Internet data. Index Terms Dual Stack, IPv4, IPv6, Migration. Resumo Este artigo tem como objetivo apresentar uma breve história do surgimento, das características e benefícios do protocolo IPv6, assim como uma comparação com seu antecessor IPv4 e descrever as principais diferenças entre eles. Também serão apresentadas algumas formas de migrações para o IPv6, com exemplos práticos das técnicas Dual Stack, NAT e Túneis. Destacando principalmente os benefícios que a técnica Dual Stack oferece neste momento de transição em relação as outras técnicas, por permitir operar nativamente com os dois protocolos de forma simultânea. No final será apresentado como está o crescimento à adesão ao IPv6 pelos países, através de dados de tráfegos na Internet. Palavras chave Dual Stack, IPv4, IPv6, Migração. I. INTRODUÇÃO O rápido avanço tecnológico que o mundo vem vivendo há alguns anos, tem gerado a necessidade que mais dispositivos estejam conectados a Internet. Esta demanda tende a aumentar ainda mais com o avanço da Internet das Coisas (IoT Internet of Things), em que diversos objetos conectados a Internet permitirão trazer facilidades no cotidiano e melhorias de desempenhos em diversas atividades. Quando a Internet foi desenvolvida, no início dos anos 70, não foi imaginado à proporção que a mesma iria tomar e muito menos que a arquitetura desenvolvida para o protocolo IP (Internet Protocol) não iria oferecer o melhor suporte às demandas futuras. [1] A versão 4 do protocolo IP, ou IPv4 (Internet Protocol version 4), vem sofrendo ao longo dos anos para sustentar esta nova Internet, surgindo a necessidade do desenvolvimento de 1 Trabalho de Conclusão de Curso apresentado ao Instituto Nacional de Telecomunicações, como parte dos requisitos para a obtenção do Certificado de Pós-Graduação em Engenharia de Redes e Sistemas de Telecomunicações. Orientador: Prof. Evandro Luis B. Gomes. Trabalho aprovado em 09/2016. um novo protocolo IP com arquitetura adequada para suprir o crescimento. [1] O protocolo IPv6 (Internet Protocol Version 6) foi desenvolvido no início da década de 90, sendo planejado para oferecer maior escalabilidade, mobilidade e agregar mais funcionalidades de segurança que seu antecessor IPv4. Este trabalho tem como objetivo apresentar um pouco da história do surgimento do IPv6, mostrando as motivações e ideias que levaram ao seu desenvolvimento. Serão mostradas suas características e as diferenças com o IPv4, assim como os benefícios idealizados por seus desenvolvedores. Também serão apresentadas formas de migração das redes IPv4 para IPv6, e quais são os desafios ao adotar cada modelo com exemplos em laboratórios e um cenário real. Ao final do trabalho são apresentados gráficos e dados estatísticos de como estão as adoções do protocolo IPv6 no Brasil e Mundo. II. SURGIMENTO DO IPV6 No inicio da década de 90, o IETF (Internet Enginneering Task Force) organizou um grupo de trabalho para começar a desenvolver um sucessor para IPv4, chamado IPng (IP Next Generation). [2] O IPng foi gerado a partir de diversas propostas de trabalhos para um novo protocolo de Internet, onde foram agregados os pontos positivos de cada proposta. As principais ideias foram retiradas das seguintes propostas: CATNIP (Common Architecture for Next Generation Internet Protocol), definida na RFC (Request For Comments) 1707; TUBA (TCP and UDP with Bigger Addresses), definida na RFC 1347; e SIPP (Simple Internet Protocol Plus), definida na RFC [3] Em 1994, o IPng divulgou um conjunto de recomendações que incluíam um protocolo com cabeçalho simplificado, uma estrutura hierárquica com possibilidade de agregação de rotas e que possuísse uma grande quantidade de endereçamentos para atender as futuras demandas, principalmente, devido ao grande crescimento da Internet. Outras funcionalidades especificadas foram a capacidade de autenticação em nível de pacotes em conjunto com criptografia e métodos de configurações automáticas (autoconfiguração). O IPng também incluiu a capacidade de classificar fluxos de tráfegos através de rótulos e alterações do campo opções do cabeçalho IP visando aumentar a flexibilidade e possibilidade de incluir

2 novas funcionalidades no futuro. Essas funcionalidades foram definidas na RFC [2] No ano de 1995, a IETF publicou a primeira versão das especificações do IPv6 na RFC 1883, que mais tarde, em 1998, seria substituída pela RFC 2460 com as especificações atuais do protocolo. [2] Em 1995, o IETF também formou um grupo com o objetivo de realizar testes com o IPv6, conhecidos como 6bone. [2] O 6bone, à princípio, começou usando IPv6 encapsulado sobre IPv4 e posteriormente migrou para links IPv6 nativos. [2] O 6bone foi extinto em 2006, e seus trabalhos estão documentadas nas RFC 2471 e RFC [2] O IPv6 teve sua distribuição iniciada pelas RIR`s (Regional Internet Registry) em meados de [1] A figura 1 ilustra a evolução das propostas desenvolvidas pelos grupos de trabalhos até chegar ao IPv6. Fig. 1. Evolução das propostas até o IPv6. [3] Uma curiosidade sobre o novo protocolo não receber em seu nome a versão 5 e ter ido direto para versão 6. Isto ocorreu devido a versão 5 ter sido alocada para um protocolo de stream experimental, também conhecido como ST2 (Internet Stream Protocol Version 2), quando o mesmo é encapsulado em IP. As especificações do protocolo estão documentadas na RFC 1819 e RFC [2] III. MOTIVAÇÕES O surgimento do IPv6 teve como principal motivação o esgotamento dos endereçamentos do seu antecessor IPv4, este último desenvolvido na década de 1970 (definido na RFC 791), onde à época a Internet não era algo muito desenvolvida e muito menos chegava ao alcance de usuários domésticos (não se utilizava computadores pessoais), tinha a função de atender a conectividade de algumas instituições universitárias e governamentais e com um endereçamento com capacidade de aproximadamente 4,3 bilhões de endereços únicos, não imaginavam que um dia estes endereços não seriam suficientes. [1] Com o grande crescimento da Internet no início da década de 90, devido a popularização dos computadores pessoais e a utilização da Internet para fins comerciais, ficou evidente os problemas estruturais com o protocolo IPv4. [1] Então surgiram necessidades que antes não existiam, como segurança na comunicação para dados sigilosos e funcionalidade de mobilidade. Com a rápida utilização dos blocos de endereços IP`s disponíveis, também foram criados mecanismos para tentar atrasar este esgotamento, tais como DHCP (Dynamic Host Configuration Protocol), CIDR (Classless Inter-Domain Routing) e NAT (Network Address Translation). Porém já estava evidente que seria necessário um novo protocolo para manter a Internet escalável, segura, com mobilidade e flexível para tecnologias futuras. [1] Atualmente temos uma grande quantidade de dispositivos conectados na rede, e trocando informações através da Internet e também, com o conceito da Internet das Coisas, onde eletrodomésticos, roupas, acessórios, automóveis entre outros objetos estarão conectados, todos esses dispositivos ou objetos necessitam possuir ao menos um endereçamento IP para comunicação, aumentando cada vez mais a demanda por endereços. [2] A IANA (Internet Assigned Numbers Authority) é a organização mundial responsável pelo gerenciamento de recursos, endereçamentos e DNS (Domain Name System) da Internet mundial, que tem o apoio das RIR`s (Regional Internet Registry) e das NIR`s (National Internet Registry). As RIR`s são órgãos responsáveis pelo gerenciamento da Internet à nível continental e respondem diretamente para IANA. As NIR`s, também conhecidas como LIR`s (Local Internet Registry), são órgãos responsáveis pelo gerenciamento da Internet local de cada pais, os mesmos reportam-se para a RIR de seu continente. [1] No Brasil, o NIC.BR (Núcleo de Informação e Coordenação do Ponto BR) é a NIR responsável por administrar os recursos de Internet, a mesma se reporta para RIR LACNIC (Latin American and Caribbean Addresses Registry). [1] Em meados de 2011 a IANA anunciou a atribuição dos últimos blocos de IPv4 para as RIR`s, porém a IANA tem adotado uma política de recuperação de blocos IPv4, pois no início da Internet era comum a distribuição de blocos grandes (/8) para empresas e universidades, principalmente americanas. Em 2015 a RIR ARIN (American Registry for Internet Numbers) informou o esgotamento dos seus endereços IPv4. As outras RIR`s ainda possuem alguns blocos de endereçamentos IPv4, porém são quantidades pequenas para atenderem as demandas futuras, o que tem levado algumas RIR`s a adotarem as mesmas políticas de recuperações de endereçamentos IPv4 e políticas de contenção de endereçamentos. As NIR`s também estão adotando políticas de retenções de endereçamentos IPv4; a NIC.BR, por exemplo, solicita comprovações de utilizações dos endereçamentos IPv4 para realizar as aprovações e bloqueia em 6 meses uma instituição de realizar novos pedidos de blocos IP`s. Atualmente a RIR AFRINIC (African Network Information Center) é a que possui a maior quantidade de endereçamentos

3 IPv4 disponíveis, o que levou algumas RIRs à discutirem sobre a possibilidade de comprarem blocos IPv4 da RIR AFRINIC. [1] A figura 2 ilustra um mapa com as áreas onde cada RIR opera. Fig. 2. Mapa distribuição das RIRs. [4] IV. ESTRUTURA DO CABEÇALHO IPV6 A figura 3 ilustra o formato do cabeçalho IPv6 definido na RFC 2460, com 8 campos e com tamanho fixo de 40 bytes. O fato de ter menos campos e um tamanho fixo traz uma melhora no desempenho nos equipamentos de redes que precisam fazer a tratativa do protocolo IP, pois o cabeçalho IPv4 contém 12 campos e tamanho variável entre 20 e 60 bytes. Outra novidade foi a opção de adicionar cabeçalhos de extensões que serão apresentados mais a frente. Fig. 3. Estrutura do cabeçalho IPv6. [5] A seguir é apresentada uma breve descrição sobre cada campo: Version (Versão): Este campo contém a versão do protocolo IP e possui tamanho de 4 bits. No IPv6, sempre terá o valor de 0110 (6 em decimal). [5] Traffic Class (Classe de Tráfego): Este campo é usado para identificar e separar diferentes classes ou prioridades de pacotes IPv6. Ele possui 8 bits de tamanho e faz uso das técnicas de Serviços Diferenciados definidos na RFC [5] Flow Label (Identificador de Fluxo): Este campo é usado para marcar um fluxo ou sequências de pacotes IPv6 de uma origem para um ou mais destinos. Este campo possui tamanho de 20 bits e ajuda a assegurar que os pacotes dos mesmos fluxos recebam os mesmos tipos de tratamentos pelos roteadores IPv6. As especificações sobre o uso do identificador de Fluxo são definidas na RFC [5] Payload Length (Tamanho dos Dados): Este campo especifica o tamanho em octetos (bytes) dos dados do pacote, sem incluir o tamanho do cabeçalho IPv6 principal que é fixo em 40 bytes. Porém caso existam um ou mais cabeçalhos de extensões, eles são incluídos no número de bytes do campo, pois os cabeçalhos de extensões são considerados partes da porção de dados. O campo é composto por um tamanho de 16 bits e permite especificar um tamanho de dados de até bytes. Para tamanhos de dados maiores, ele tem suporte a Jumbo Frame através do uso de cabeçalhos de extensões definidos na RFC [5] Next Header (Próximo Cabeçalho): Este campo é composto por 8 bits e identifica o tipo do próximo cabeçalho. No caso de não existir cabeçalhos de extensões, este campo irá identificar o protocolo que esta na porção de dados, similar ao campo Protocolo do cabeçalho IPv4, que tem os valores de cada protocolo descritos na RFC [5] Hop Limit (Limite de Saltos): Este campo possui um tamanho de 8 bits e utiliza números inteiros para decrementar o valor 1 a cada salto (roteador) que o pacote atravessar até o seu destino. Caso o roteador que receber um pacote com este campo com valor igual a 1 e decrementar ele para 0, o pacote é descartado e o mesmo envia um ICMPv6 (Internet Control Message Protocol) com a mensagem de tempo excedido. [5] Source Address (Endereço de Origem): Este campo é composto por 128 bits, sendo usado para identificar o endereço IP de origem. [5] Destination Address (Endereço de Destino): Este campo é composto de 128 bits, sendo usado para identificar o endereço IP de destino. [5] V. COMPARAÇÕES ENTRE OS CABEÇALHOS IPV4 E IPV6 Conforme mencionado anteriormente, o cabeçalho IPv6 sofreu diversas alterações para possibilitar as implementações das novas funcionalidades que estão ausentes no cabeçalho IPv4. Realizando um paralelo entre as figuras 3 e 4, é fácil notar que o cabeçalho IPv6 ficou com um número menor de campos comparado ao seu antecessor. Fig. 4. Estrutura do cabeçalho IPv4. [6]

4 As tabelas I, II, III e IV, respectivamente, listam as diferenças no cabeçalho IPv6 em comparação com o cabeçalho IPv4, mostrando campos que foram removidos, alterados os nomes, inseridos e mantidos. TABELA I Campos que foram removidos no cabeçalho IPv6 CAMPOS IPV4 hexadecimal, e divididos em 8 blocos de 16 bits cada (ex: 2001:0DB8:CAFE:1020:CAFE:3030:8080:1234). [8] Também temos o surgimento dos endereços Anycast, que consistem nas comunicações de um host para o host mais próximo do mesmo grupo. Mais detalhes sobre as características do Anycast podem ser encontrados nas RFC 3513 e RFC [8] A figura 5 é um diagrama detalhado da estrutura do endereçamento IPv6, assim como suas divisões. IHL Identification Flags Fragmento Offset Checksum Options Padding TABELA II Campos que tiveram nomes e posição alterados no cabeçalho IPv6 CAMPOS IPV4 CAMPOS IPV6 Type os Service Total Length Protocol TTL Traffic Class Payload Length Next Header Hop Limit Fig.5 Estrutura do endereçamento IPv6. [8] TABELA III Campos que foram adicionados no cabeçalho IPv6 CAMPOS IPV6 Flow Label TABELA IV Campos que foram mantidos no cabeçalho IPv6 CAMPOS IPV4/IPV6 Version Source Address Destination Address VI. FUNCIONALIDADES NOVAS NO IPV6 A. Estrutura do Endereçamento IPv6 Um dos principais motivos da criação de um novo protocolo IP deu-se devido ao esgotamento dos endereçamentos IPv4, com isso, foi revista toda a estrutura dos endereços no IPv6 que agora possuem 128 bits de endereçamentos, contra os 32 bits do seu antecessor, o IPv4. Isso representa algo em torno de 3,4x1038 de endereços IP`s, enquanto o IPv4 disponibiliza algo em torno de 4,3 bilhões de endereços IP`s. Para se ter uma ideia, atualmente existem aproximadamente 7,4 bilhões de pessoas no mundo [7], isso daria algo em torno de 4,5x1028 de endereços IPv6 por pessoa no mundo. [1] Outra novidade acompanhando o IPv6 foi a forma de representação dos endereços IP`s, que passou a ser no formato B. Autoconfiguração Conforme a RFC 2462, uma grande novidade no IPv6 é a facilidade de um host se conectar à rede devido a funcionalidade de autoconfiguração. O dispositivo ao ser conectado envia uma mensagem de descoberta de vizinhança através do protocolo ICMPv6, o roteador responde com as informações do prefixo de rede (neste caso precisa ser /64) e do gateway da rede. O host utiliza o próprio mac-address para formar o endereço IPv6 em um processo chamado EUI-64 (64bit Extended Unique Identifier), podendo também ser utilizado o DHCPv6 para fornecer parâmetros complementares (ex: servidor DNS), ou operar igual a um DHCP em redes IPv4. A autoconfiguração faz uso das funcionalidades dos endereçamentos unicast link local FE:80::/64 para as comunicações iniciais entre os elementos do mesmo enlace. [9] C. Suporte a Protocolos de Segurança O protocolo IPv6 não é necessariamente mais seguro que o IPv4, por ser relativamente um protocolo novo existem menos vulnerabilidades conhecidas comparado ao IPv4 que é muito mais antigo e utilizado. Porém algo que ajuda na segurança dos dados está na obrigatoriedade de todos os equipamentos que suportam o IPv6 também terem suporte nativo ao protocolo IPsec (IP Security Protocol). Mas, não necessariamente ao utilizar o protocolo IPv6, o IPsec estará habilitado e funcionando automaticamente. O IPsec precisa ser configurado manualmente para funcionar. O Protocolo IPsec é definido na RFC 4301, e traz consigo

5 um conjunto de especificações para descrever requisitos e mecanismos de segurança para camada de rede, protocolo de criptografia com ESP (Encapsulating Security Payload), protocolo de autenticação AH (Authentication Header), gerenciamento de chaves, definições de politicas de segurança e segurança entre comunicações de peers. [1] O IPv4 também suporta IPsec, porém o suporte é opcional e devido a grande utilização de NAT`s por parte das redes IPv4, o desempenho e o funcionamento do IPsec são prejudicados. Com a proposta do IPv6 de reestabelecer o conceito da comunicação fim-a-fim, com a não necessidade de utilização de NAT`s, o protocolo IPsec poderá ser utilizado para agregar mais segurança às comunicações. A RFC 3715 descreve as incompatibilidades conhecidas entre NAT e IPsec. [1] D. Cabeçalhos de Extensões No cabeçalho IPv6 foram removidos os campos Opção e Complemento, que tornavam o cabeçalho IPv4 com tamanho variável; toda vez que um pacote passava pelo roteador, o mesmo precisava verificar o tamanho do cabeçalho no campo IHL[2]. Com o IPv6, não há mais a necessidade de se verificar o tamanho do cabeçalho, pois o mesmo é fixo em 40 bytes, e com isso melhora-se o desempenho no encaminhamento dos pacotes. [5] Conforme descrito na RFC 2460, foram adicionados cabeçalhos de extensões para carregar algumas informações que em sua maioria serão analisados pelos hosts de origem ou destino, deixando os elementos intermediários sem as necessidades de examinarem estes cabeçalhos. Os cabeçalhos de extensões são opcionais, ou seja, podem conter nenhum, um ou mais cabeçalhos em um pacote. Atualmente são descritos seis tipos de cabeçalhos de extensões, porém a funcionalidade foi desenhada para aceitar futuros cabeçalhos que surgirem conforme as necessidades. [5] A RFC 2460 descreve os seguintes cabeçalhos de extensão: Hop-by-Hop Options: O cabeçalho Hop-by-Hop Options é usado para transportar informações opcionais a serem analisados por cada elemento ao longo do caminho do pacote. Routing: O cabeçalho Routing é usado para listar os elementos intermediários que podem fazer parte do caminho do pacote até o destino desejado. Fragment: O cabeçalho Fragment é usado pelo host origem para verificar o MTU (Maximum Trasmition Unit) do caminho e informar para o destino que o pacote enviado esta fragmentado. Destination Options: O cabeçalho Destination Options é usado para transportar informações opcionais a serem analisados somente pelo host de destino. Authetication: O cabeçalho Authentication, descrito na RFC 4302, é usado quando há necessidade de usar métodos de autenticação. Encapsulation Security Protocol: O cabeçalho Encapsulation Security Protocol, descrito na RFC 4303, é usado quando há necessidade de usar métodos de criptografia. A figura 6 ilustra um exemplo de posicionamento dos cabeçalhos de extensões no pacote IPv6. Fig. 6. Exemplo de posicionamento dos cabeçalhos de extensões. [5] E. Mobilidade A RFC 6275 descreve o Mobile IPv6 como um protocolo que possibilita a um host móvel movimentar-se entre duas redes diferentes sem perder a conectividade. Se um host móvel conecta a uma outra rede, ele irá precisar de um novo endereço IP. O endereço IP móvel aborda o desafio de movimentar um host de uma rede para outra sem perder a conexão adicionando a interface deste host um novo endereço IP. O host ainda conhece seu endereço IP original chamado de endereço home, que é usado para identificar a conexão e o mesmo não é alterado. O IP adicional alocado é chamado de endereço Care-of, este é atribuído dinamicamente e muda a cada rede que o host se movimentar. Como o IPv4 foi desenvolvido em uma época que não se pensava em dispositivos móveis, o mesmo não opera bem com mobilidade de dispositivos, tendo que ter uma arquitetura mais complexa para prover essa funcionalidade. Com o protocolo Mobile IPv6 nativo, a arquitetura fica mais simplificada e melhora a experiência de movimentações entre redes. [1] VII. FUNCIONALIDADES REMOVIDAS NO IPV6 A. Eliminação do Broadcast Conforme a RFC 919, o broadcast é utilizado quando um host tem a necessidade de se comunicar com todos os hosts do mesmo enlace local ou está procurando alguma informação de outro host sem conhecê-lo. O problema está na grande quantidade de pacotes desnecessários enviados na rede, pois também é utilizado para o processo de descoberta de ARP (Address Resolution Protocol). Também existem alguns protocolos de roteamento que utilizam da função broadcast para controle, trazendo vulnerabilidades onde alguém não autorizado pode interceptar os pacotes. O protocolo IPv6 faz uso das funcionalidades do multicast para comunicar-se com diversos hosts simultaneamente. O multicast envia pacotes identificados com endereços IP`s reservados para alcançar um grupo de destinatários, ou seja,

6 diferente do broadcast que envia pacotes para todos os hosts do enlace, o multicast realiza o envio apenas para os destinos desejáveis. Desta forma, evita-se pacotes desnecessário na rede e também a interceptação de pacotes por pessoas não autorizadas. O multicast é definido na RFC [10] B. Eliminação da necessidade de se utilizar NAT As técnicas de NAT surgiram como formas paliativas de atrasarem o esgotamento dos endereços IPv4, sendo definidas na RFC 3022, onde os dispositivos podem compartilhar um mesmo IP público para acessar a internet. As técnicas de NAT consistem em traduzir diversos endereços IP para outro endereço IP, com a finalidade de reduzir o uso de endereços IPv4 roteáveis na Internet. Os equipamentos que realizam NAT`s, precisam realizar um mapeamento dos endereços traduzidos para a fim de identificar os pacotes de respostas das comunicações. Estas técnicas quebram o modelo de comunicação fim-a-fim, atrapalham o funcionamento de diversas aplicações, dificultando a utilização do protocolo IPsec e também demanda muito mais processamento dos equipamentos que estão realizando o NAT. [11] Como o principal motivo do surgimento do NAT foi a proximidade do esgotamento dos endereçamentos IPv4, com a implantação do IPv6 não se faz necessário o uso do NAT, assim aumentando a possibilidade de implantação do modelo de comunicação fim-a-fim nos desenhos de redes. [12] C. Eliminação das Fragmentações de pacotes nos elementos intermediários O IPv6 foi desenvolvido para diminuir a quantidade de processamento com análise de pacotes por parte dos elementos intermediários no caminho dos pacotes, conforme definido na RFC Umas das medidas foram às eliminações das fragmentações de pacotes por parte dos elementos intermediários, conforme a RFC 2460, as fragmentações de pacotes com IPv6 passaram a acontecer apenas nos hosts de origem através do cabeçalho de extensão Fragment. Eliminando as fragmentações dos elementos intermediários, os roteadores podem realizar o encaminhamento dos pacotes com mais eficiência, uma vez que não precisam verificar as necessidades de realizarem fragmentações, e também diminuem o processamento nos equipamentos intermediários. [1] VIII. FORMAS DE MIGRAÇÕES DO IPV4 PARA O IPV6 Com o passar dos anos foram desenvolvidas diversas técnicas de migrações para o IPv6 e de coexistências com o IPv4. Nas próximas seções serão apresentadas algumas das técnicas mais utilizadas para migrações. Porém, deve-se ter conhecimento que existem muitas outras técnicas que atendem a diversas necessidades conforme a arquitetura de cada infraestrutura e provavelmente ainda surgiram muitas outras ao passar do tempo. A. Dual Stack Dual Stack ou Pilha Dupla, é uma das muitas técnicas criadas para realizar a transição de uma rede IPv4 para uma IPv6. O Dual Stack, como o próprio nome sugere, é a coexistência das duas pilhas de protocolos (IPv4 e IPv6), neste caso todos os equipamentos na infraestrutura terão que ter suportes aos dois protocolos (roteadores, switches, servidores de aplicação e dispositivos de usuários). Hoje em dia, a maioria das aplicações suporta operar com os dois protocolos, incluindo os browsers atuais, facilitando a implantação desta técnica. Esta técnica é bem vista, pois aos poucos a tendência são as paginas web, aplicações e outros serviços começarem a disponibilizar seus conteúdos em IPv6 e a longo prazo o tráfego IPv6 ultrapassar o IPv4. [1] Também traz mais maturidade para aplicações trabalharem com IPv6, uma vez que o mesmo sistema pode estar disponível para ambos os protocolos, tendo a possibilidade de comparações de desempenho e melhorias das funcionalidades. Porém, é uma técnica que agrega uma maior complexidade na infraestrutura, pois será necessário lidar com tabelas de roteamentos, regras de firewalls e documentações duplicadas. Em alguns casos, pode ser necessário um investimento inicial em equipamentos que suportem os dois protocolos e em capacitações dos funcionários para lidarem com a sustentação da infraestrutura. [1] Um ponto importante está no funcionamento do DNS, pois a experiência do usuário ao acessar um site ou uma aplicação que utiliza resoluções de nomes estará relacionada a qual versão do endereçamento IP o DNS irá entregar. Pois quando se utiliza Dual Stack, ao realizar uma solicitação de resolução de nome, o host cliente irá realizar tanto para registro A do IPv4 quanto para o registro AAAA do IPv6 [13]. Se as requisições A e AAAA forem respondidas, o host cliente preferencialmente utilizará o IPv6 [14]. Caso o retorno seja apenas uma das requisições, a conexão será estabelecida no protocolo que respondeu. Conforme representado na figura 7, os elementos na rede irão operar com duas pilhas de protocolos. Fig. 7. Ilustração da operação da pilha de protocolos com Dual Stack. [15] B. NAT (Network Address Translation) NAT são técnicas que já existiam com o IPv4 e que foram criadas como forma de tentar prolongar a vida útil do IPv4. Para o IPv6 segue o mesmo principio do IPv4, porém neste caso irá traduzir endereços entre protocolos de famílias

7 diferentes. C. NAT-PT (Network Address Translation Protocol Translation) NAT-PT é utilizado quando há necessidade de comunicação entre uma rede somente IPv6 com uma outra rede somente IPv4, definido pela RFC É baseado no algoritmo SIIT (Stateless IP/ICMP Translation), definida na RFC 2765, e tem o funcionamento similar ao NAT praticado com IPv4, onde pode-se utilizá-lo de modo estático ou dinâmico. No modo estático é realizado um mapeamento de um endereço IPv6 para um endereço IPV4 e no dinâmico é utilizado um pool de endereços para serem designados a múltiplos mapeamentos dinamicamente. [2] De acordo com a RFC 4966, a implantação do NAT-PT traz inúmeros problemas para a comunicação na rede e existe a recomendação para não ser utilizado. D. NAT64 NAT64 é uma técnica utilizada para permitir a comunicação de redes originalmente IPv6 com redes IPv4, funcionando de forma stateful e definida na RFC Utilizando da abordagem de tradução de endereços de redes e portas para que possam ser mapeados um endereço IPv4 para muitos endereços IPv6, diferenciados pelos números de portas TCP/UDP de origem. [2] A técnica é utilizada em conjunto com o DNS64, que auxilia na resolução DNS e está definida na RFC A figura 8 ilustra o funcionamento do NAT64 em conjunto com o DNS64. Fig. 8. Diagrama da técnica NAT64 com a técnica DNS64. [16] Conforme ilustrado na figura 8, a rede de origem opera apenas com IPv6 e quando o Cliente IPv6 realiza uma consulta de registro AAAA para o DNS64, ele encaminha a consulta para o DNS Autoritativo do domínio. Caso não tenha resposta para o registro AAAA, o DNS64 realiza uma consulta de registro A para o domínio solicitado. Com a resposta do registro A do endereço IPv4, o DNS64 "transforma" o endereço IPv4 recebido para um IPv6, utilizando uma rede IPv6 /96, que pode ser a rede 64:ff9b::/96 reservada na RFC 6052 para este propósito e complementa os últimos 32 bits com o endereço IPv4 recebido. Na figura 8, a composição mostra o endereço IPv4 junto com o prefixo IPv6, porém na prática, o DNS64 converte o endereço IPv4 em hexadecimal para realizar a composição dos últimos 32 bits. No exemplo ilustrado na figura 8, o endereço 64:ff9b:: é encaminhado para o Cliente IPv6 na forma hexadecimal 64:ff9b::c800:711. [16] O Cliente IPv6 entende que o domínio solicitado pode ser acessado através deste endereço IPv6 e encaminha o pacote para o roteador configurado com o NAT64. O roteador NAT64, ao receber o pacote IPv6 verifica pelo prefixo do endereçamento de destino e realiza a conversão dos últimos 32 bits para IPv4 novamente. Com esta informação, o roteador realiza um mapeamento do endereço em sua tabela e também faz a alocação de um endereço IPv4 do pool configurado para ser o endereçamento IPv4 de origem. [16] O roteador NAT64 mantem este mapeamento em sua tabela para realizar a conversão quando receber pacote de resposta. Para o Cliente IPv6 aparenta que o domínio esta disponível em IPv6, porém ele esta disponível apenas em IPv4 e a comunicação é possível graças a técnica de conversão do NAT64 em conjunto com o DNS64. [16] Esta solução é funcional para quem optar por migrar toda a rede interna para IPv6 e com certeza ainda terá que se comunicar com o mundo IPv4. Porém, ela traz bastante complexidade e pode dificultar futuros troubleshooting, e também, os serviços que estão disponíveis apenas em IPv4 necessariamente precisam ser acessados via domínio para serem utilizados as funções do DNS64. [2] E. CGN (Carrer-Grade NAT) O CGN não é uma técnica para implementação do IPv6, mas sim, uma abordagem para dar mais tempo ao IPv4 utilizando várias camadas de NAT. O CGN ou também conhecido NAT444 (devido as várias camadas de NAT) é definido na RFC 6264 e consiste na operadora entregar para os clientes um IP privado na rede /10 definido na RFC Esta faixa de IP não é roteável na Internet e está em uso exclusivo das operadoras, ou seja, o CGN faz referência ao processo de realização do NAT dos endereços privados, descritos na RCF 1918, para um IP da faixa de endereços descritos na RC 6598 e depois mais um NAT para um IP público definido pelas operadoras. Com isso, a operadora coloca diversos clientes utilizando o mesmo endereço IP público, ao invés de disponibilizar um ou mais IP`s públicos para cada cliente. [1] A figura 9 ilustra a topologia utilizando o CGN.

8 Fig. 9. Ilustração Topologia com CGN. Segundo BRITO [1] o NAT "é uma agressão aos princípios arquiteturais da Internet por quebrar o modelo fim-a-fim e tornar o funcionamento de algumas aplicações mais complexo". O CGN não é uma técnica que irá ajudar na migração para o IPv6, pelo contrário, ela tenta prolongar o uso do IPv4 na Internet. Além de trazer diversos problemas para as comunicações, como rastreabilidade e limite de acessos para os clientes devido ao limite de portas que podem ser utilizadas. O recomendável é que se utilize técnicas que irão possibilitar a migração (gradual ou direta) para o IPv6. F. Túneis Os Túneis são técnicas que basicamente consistem em transportar pacotes encapsulados dentro de outros pacotes. As técnicas de tunelamentos já são bem conhecidas via túneis VPN`s (Virtual Private Networks) que são muito usadas. No cenário para migração do IPv6, existem diversas formas de implementarem os tunelamentos e provavelmente irão surgir muitas outras, porém, são técnicas para promoverem as interoperabilidades entre os protocolos, ajudando muito mais nas coexistências das redes IPv6 com redes IPv4. As técnicas de tunelamentos podem ser utilizadas para transportarem pacotes IPv6 por nuvens IPv4, ou vice-versa. Provavelmente o cenário inicial sejam os transportes dos tráfegos IPv6 pela Internet IPv4, mas para o futuro esse cenário deve mudar, sendo necessário transportar tráfegos IPv4 pela Internet IPv6 devido as comunicações IPv4 legadas. [2] G. Tunnel Broker Tunnel Broker é uma técnica definida na RFC 3053, e tem como objetivo fornecer acesso de forma simples e automática para redes IPv6 aos usuários com acessos a Internet apenas em IPv4. O Tunnel Broker é um provedor que disponibiliza um servidor de túnel na Internet, onde os usuários realizam um cadastro e recebem o procedimento para estabelecer o túnel com o servidor Broker. Após as configurações iniciais, o gerenciamento e manutenção do túnel fica a cargo do provedor e o mesmo fornece um bloco de IPv6 que pode variar entre /48, /67 ou /128 para os usuários navegarem. Os servidores de Tunnel Broker são espalhados por diversos lugares, e são escolhidos os mais próximos dos usuários, além de trabalharem com Dual Stack (IPv4 e IPv6). [1] Os dois provedores de Tunnel Broker mais populares são Hurricane Electrics e o SixXs. O Hurricane Electrics além de fornecer o serviço de Tunnel Broker de forma simples, possui provas teóricas e práticas para adquirir certificações de conhecimentos sobre implantações de IPv6. Possui ainda diversos POP`s (Point of Presence) pelo mundo, porém não possui POP no Brasil, o que torna a conectividade para usuários brasileiros com um desempenho baixo devido a latência, principalmente para acessos a sites brasileiros via túnel Broker. [17] O SixXs é outro provedor de serviço Tunnel Broker, que também possui POP`s pelo mundo e entre eles existe um POP no Brasil, o que o torna a melhor opção para os brasileiros. Porém, em 2016, ao acessar a página do provedor [18] e tentar realizar o cadastro eles informam que não estão aceitando novos cadastros e orientam aos usuários procurarem seus provedores de Internet para obter acessos a Internet IPv6. A figura 10 ilustra como é o funcionamento do Tunnel Broker. Fig. 10. Demonstração do funcionamento do Tunnel Broker. [33] H. Túnel 6over4 O 6over4 traz a abordagem de comunicar uma rede inteiramente IPv6 com outra também IPv6, sobre uma Internet IPv4. Ele faz uso da técnica de encapsulamento 6in4, definida na RFC 4213, onde é possível o tunelamento de um pacote IPv6 dentro de outro pacote com cabeçalho IPv4. Esta abordagem comumente é utilizada quando se tem a administração das duas redes IPv6, por exemplo uma comunicação entre uma Matriz e Filial através de uma Internet IPv4, as configurações são realizadas manualmente nos roteadores de borda. [2] Neste tunelamento, os cabeçalhos IPv6 não são alterados, contendo os endereços de origem e destino montados pelos hosts de origem. Quando chegar ao roteador de borda, o mesmo irá encapsular estes pacotes com cabeçalhos IPv4 contendo endereços de origem e destino que serão utilizados para os pacotes serem roteados dentro da Internet IPv4. Quando chegarem ao roteador de bordar da rede de destino, os cabeçalhos IPv4 serão removidos e o roteador irá analisar os cabeçalhos IPv6 para realizar a entrega dos pacotes na rede IPv6 interna. [2] A figura 11 ilustra uma topologia utilizando túnel 6over4.

9 Fig. 11. Topologia túnel 6over4 A figura 12 ilustra pacotes capturados de uma comunicação com túnel 6over4 com o cabeçalho IPv6 encapsulado dentro do cabeçalho IPv4 (técnica 6in4). pacote é similar e os relays utilizam das informações do endereço IPv6 que foram formados pelo endereço público IPv4 do usuário para realizar o roteamento de retorno na Internet IPv4. Esta técnica é caracterizada como stateless, pois ela não precisa ficar armazenando informações das conexões para prover as conectividades, o que também permite que se utilize um relay para o pacote chegar ao destino e outro relay para devolver para a origem. [2] [19] A figura 14 ilustra o funcionamento do túnel 6to4. Fig. 12. Pacotes com o cabeçalho IPv6 encapsulado no cabeçalho IPv4. Conforme ilustra a figura 13, o campo protocolo no cabeçalho IPv4 é mostrado com o valor 41, indicando que o próximo protocolo é um cabeçalho IPv6. Fig. 13. Campo protocolo do cabeçalho IPv4 preenchido com 41. I. Túnel 6to4 O 6to4 é uma técnica de tunelamento que transporta IPv6 sobre IPv4 utilizando um prefixo de endereço IPv6 reservado, 2001::/16. [2] [19] A técnica é definida na RFC 3056 e utiliza um endereço IPv4 público para formar túneis automáticos com uma rede IPv6 /48, transformando os 32 bits IPv4 em IPv6, agregando com o prefixo IPv6 /16 (2002::/16), formando assim um bloco com a notação 2002::XXX:XXX::/48. Os 6to4 utilizam de relays públicos para formarem os tuneis automáticos, que são divulgados pelo endereço e são responsáveis pela divulgação dos endereçamentos do bloco 2002::/16. Os relays públicos também possuem conectividades em pilha dupla para fornecerem estes acessos entre as duas Internets IPv4 e IPv6. [2] [19] A técnica funciona quando o host de origem encaminha o pacote IPv6 para o gateway, o mesmo fecha um túnel com o relay público mais próximo e encapsula o endereço IPv6 dentro do pacote IPv4. O relay ao receber o pacote encaminha o pacote IPv6 ao seu destinatário. O processo de volta do Fig. 14. Topologia funcionamento túnel 6to4. [20] Esta técnica ainda é utilizada atualmente, porém traz consigo alguns riscos de segurança. Como os relays são públicos e seus endereços são bem conhecidos, podem sofrer ataques DDoS (Distributed Denial-of-Service) ou mesmo de falsificação do endereço do relay por alguma pessoa malintencionada, podendo capturar os dados trafegados e obter informações sigilosas. [1] J. Túnel 6rd (IPv6 Rapid Deployment) A solução de 6rd foi criada por uma operadora Francesa chamada Free, que conseguiu em um curto período de tempo disponibilizar acessos IPv6 para mais de clientes, por isso a solução ficou conhecida como Rapid Deployment. [21] A solução é similar ao 6to4, porém não utiliza prefixo reservado, sendo utilizado o próprio prefixo /32 da operadora e complementa com mais 32 bits do endereço IPv4 público do cliente para fornecer um endereço IPv6 /64 para o usuário. Diferente do 6to4, o 6rd utilizam relays da própria operadora, o que traz um pouco mais de segurança comparados aos relays públicos utilizados pela técnica 6to4. Porém, uma desvantagem é a necessidade de o cliente possuir um endereço IPv4 público, o que para atualidade significa um grande entrave. [21] A solução teve uma enorme aceitação na comunidade, que em janeiro de 2010 a mesma foi definida na RFC 5569 e atualmente muitos fabricantes utilizam desta técnica nos roteadores domésticos. A figura 15 ilustra um roteador D-Link DSL-2730R disponibilizando as configurações de 6rd.

10 as tabelas de roteamentos são tratadas separadamente para cada protocolo, mantendo os encaminhamentos e roteamentos dos pacotes IPv6 independentes dos pacotes IPv4. [1] Fig. 15. Modo de configuração do roteador D-Link DSL-2730R com o 6rd disponível. IX. IMPLEMENTAÇÕES A. Dual Stack Ambiente Virtual Com base nos conceitos descritos sobre o Dual Stack, será demonstrado o funcionamento da técnica utilizando o simulador de redes GNS3 [22] para simular o acesso de um host cliente a um serviço HTTP (Hypertext Transfer Protocol) que suporte conexões em IPv4 e IPv6. O papel do DNS é importante na escolha do protocolo a ser utilizando pelo host cliente, por isso será utilizado um DNS com suporte aos dois protocolos. A topologia será composta por um host cliente com sistema operacional Ubuntu [23], um host como servidor HTTP com sistema operacional Debian [24] e um servidor de DNS com Virtual Edition BIG-IP da F5 [25], todos rodando como máquinas virtuais sobre VMware Fusion [26]. Também serão utilizados 4 roteadores emulados no GNS3 para simularem duas nuvens, uma IPv4 e uma IPv6, assim como dois switches como acesso também emulados. A figura 16 representa a topologia proposta. Fig. 17. Tabela roteamento roteador A. Fig. 16. Topologia laboratório Dual Stack. Nos hosts foram feitas as configurações de endereçamento de modo manual, porém pode ser usado autoconfiguração no caso do IPv6, ou servidor DHCP com suporte a IPv4 e IPv6 (DHCPv6) na atribuição de endereçamento. Nos roteadores, foram feitas as configurações estáticas dos endereçamentos IP`s e para o roteamento foi utilizado o protocolo de roteamento dinâmico OSPF. Para o OSPF, foi utilizado a sua versão 2 para o roteamento IPv4 e a versão 3 para o roteamento IPv6. O roteador D irá simular uma nuvem IPv6 rodando o OSPFv3 e o roteador B está simulando uma nuvem IPv4 utilizando o OSPFv2. Os roteadores A e C estão simulando roteadores de borda com conectividade nas duas nuvens e rodando os dois processos OSPF, uma para cada protocolo. Conforme mostrado nas figuras 17 e 18, nos roteadores A e C Fig. 18. Tabela roteamento roteador C. Para utilizar o Dual Stack os hosts devem possuir a capacidade de operar com os protocolos IPv4 e IPv6 simultaneamente. Com isso, na rede interna, não há a

11 necessidade de possuir duas interfaces físicas por host, uma para cada protocolo. Sobre a mesma interface física, foram configurados ambos os endereçamentos. As figuras 19, 20, 21 e 22 ilustram como ficaram configuradas as interfaces dos hosts cliente e servidor HTTP. Fig. 22. Configuração IPv6 na interface do servidor HTTP. Foi utilizada a ferramenta Wireshark [27] para visualização da conexão a uma página (paginateste.com.br) criada apenas para a demonstração no cenário de teste. A figura 23 ilustra o host cliente (IPv e IPv6 2001:db8:123:2::20) realizando consultas DNS para os dois IP`s configurados nos registros A e AAAA. O servidor DNS responde consultas dos dois registros. Fig. 19. Configuração IPv4 na interface do Host Cliente. Fig. 23. Consultas DNS`s realizadas pelo Host Cliente. A figura 24 demonstra que a conexão foi estabelecida preferencialmente com IPv6, conforme descrito na RFC Fig. 24. Conexão entre o Host Cliente e o Servidor HTTP em IPv6. Fig. 20. Configuração IPv6 na interface do Host Cliente. Depois foi feita a simulação da queda da nuvem IPv6 (Router D), com isso o host cliente não terá conectividade com o servidor DNS e o servidor HTTP por meio do protocolo IPv6, conforme ilustra a figura 25. Fig. 25. Topologia sem a nuvem IPv6 Fig. 21. Configuração IPv4 na interface do servidor HTTP. A figura 26 ilustra que o host cliente realizou as consultas DNS para os dois IP`s configurados, porém desta vez apenas o IPv respondeu as consultas com os registros A e AAAA. Como a nuvem IPv6 está indisponível, os pacotes utilizando o IPv6 não irão chegar ao seu destino.

12 Fig. 26. Queries DNS realizadas pelo Host Cliente e resposta apenas do IP Como foi recebido um IPv6 no registro AAAA, preferencialmente a tentativa de conexão será com o IPv6. Porém, como a nuvem IPv6 está indisponível esta conexão não irá estabelecer e como foi recebido também um IPv4 no registro A, será realizado um failover para IPv4 e a conexão será estabelecida com IPv4 (em menos de 300ms) e não irá impactar a experiência do usuário na navegação. Esta técnica é conhecida como "Happy Eyballs dual stack", definida na RFC A Figura 27 ilustra este processo, e mesmo depois de estabelecer a conexão com IPv4, é encaminhado tentativas de conexão com IPv6 por meio de retransmissões TCP. [28] Fig. 28. Configuração do VS no BIG-IP. Fig. 29. Associação do VS com o pool, onde está configurado o servidor HTTP. Fig. 27. Conexão entre o Host Cliente e o Servidor HTTP em IPv4 e tentativas de conexão em IPv6. Conforme demostrado, a técnica de migração Dual Stack mostra-se como uma boa escolha, por ser uma técnica de substituição do IPv4 pelo IPv6, e não um prolongador do IPv4. Conforme os sistemas e serviços forem sendo disponibilizados em IPv6 a migração vai acontecendo de forma transparente para o usuário final e também caso haja ainda sistemas legados em IPv4 os mesmos continuaram funcionando sem impacto. Mais adiante será descrita a experiência feita com dual stack em ambiente real, realizado em um POC (Proof of Concept). B. NAT64 Ambiente Virtual Será demonstrado as funcionalidades da técnica de NAT para disponibilizar uma página na Internet em IPv6, porém sem precisar implementar o IPv6 na sua rede interna. Iremos apenas disponibilizar o IPv6 na borda da rede, e os elementos da rede interna seguirá operando somente com IPv4. A topologia será a mesma utilizada no laboratório do Dual Stack, demonstrada na figura 16, porém agora será utilizado o modulo de LTM (Local Traffic Manager) do BIG-IP para realizar o NAT64. Foi criado um VS (Virtual Server) no BIG-IP com IP 2001:db8:123::40 na porta 80, onde irá receber as conexões HTTP em IPv6 e depois direcionar para o servidor HTTP na porta 81. [25] As figuras 28 e 29 ilustram como ficou configurado o VS no BIG-IP. Quando o pacote HTTP passar pelo virtual server no BIG- IP, o mesmo irá adicionar o campo X-forwarded-For no cabeçalho HTTP com o IP de origem da conexão, antes de encaminhar para o servidor WEB, isso será realizado pelo profile HTTP. A figura 30 ilustra as configurações do profile HTTP associado ao virtual server. Fig. 30. Configuração do profile HTTP com a opção Insert X-Forwarded- For habilitada.

13 No modulo de GTM (Global Traffic Manager), onde são realizadas as funções de DNS, será configurado para entregar apenas o endereço IPv6 2001:db8:123::40 quando for realizado uma consulta DNS para URL paginateste.com.br. [25] IPv4, ou seja, ele realiza um NAT64 para realizar esta conexão e adiciona o campo X-Forwarded-For no cabeçalho HTTP com o endereço IP de origem, que foi o IPv6 2001:db8:123::40. Fig. 34. Pacote da comunicação entre o BIG-IP e o servidor HTTP em IPv4, com o campo X-Forwarded-For com o IPv6 do host cliente. Também pode ser visto no próprio BIG-IP, a lista de conexões que mostra o registro do NAT64 que foi realizado nesta comunicação. Fig. 31. Configuração do modulo GTM para entregar apenas o endereço IPv6. Durante os testes, foram capturados os pacotes utilizando novamente o Wireshark para demostrar qual o comportamento do tráfego na rede. A figura 32, ilustra a consulta DNS para a URL paginateste.com.br e conforme demonstrado no laboratório do Dual Stack, o host cliente realiza consultas DNS para os registros A e AAAA. Como temos apenas o IPv6 configurado no DNS, apenas a consulta AAAA retornará com sucesso. A consulta A será respondida como refused. Fig. 35. Registro do NAT64 realizado no BIG-IP. C. Dual Stack Ambiente Real Neste tópico, será descrito a experiência com a implantação de um POC de IPv6 em uma empresa real. Pelo fato da empresa possuir um ASN (Autonomous System Numbers), e também um bloco IPv4 /24 e um bloco IPv6 /48, decidiu-se utilizar da técnica de Dual Stack. A figura 36 representa a topologia adotada. Fig. 32. Tráfego DNS enviado pelo host cliente. A figura 33 ilustra o tráfego da comunicação estabelecida entre o host cliente e o VS do BIG-IP em IPv6. Fig. 36. Topologia POC Dual Stack. Fig. 33. Comunicação entre o host cliente e o VS do BIG-IP. A figura 34 ilustra a comunicação do VS do BIG-IP com o servidor HTTP. O BIG-IP encaminha os pacotes recebidos em A construção da topologia não demandou novos investimentos, pois os equipamentos da empresa já possuem suporte a IPv6. Foi solicitado à operadora que presta serviço de acesso adicionar um trânsito IPv6 entre os roteadores de borda e a configuração do protocolo de roteamento BGP (Border Gateway Protocol) para troca de tabelas de roteamentos. Foi utilizado um firewall para realizar a parte de controle à Internet e proteção da rede interna, e nesta última, foi utilizado

14 uma rede /64 do IPv6 para utilizarmos os mecanismos EUI-64 e autoconfiguração e uma rede /24 privado para o IPv4. Nas redes de trânsitos entre o firewall e os roteadores de borda, foram utilizadas redes /127 para IPv6 e redes /30 para IPv4. Neste primeiro momento também foi adicionado o servidor de DNS interno operando com os dois protocolos e apontando para os DNS da Google (IPv e IPv6 2001:4860:4860::8888). O tráfego IPv4 da rede interna para Internet sofre NAT de origem no firewall para um IP público. Para o IPv6 não foi necessário utilizar NAT, uma vez que o endereçamento IPv6 da rede interna é roteável pela Internet, sendo isto uma das características do IPv6, uma vez que o NAT foi criado devido a falta de endereçamento IPv4. Foram realizados os testes de acessos a Internet e também testado o comportamento de acessos aos serviços da rede interna em IPv4. Todos os testes foram bem-sucedidos, não se percebeu a diferença entre os acessos IPv6 e os acessos IPv4. Boa parte dos sites acessados (portais, bancos, e até alguns blogs) já possuem conectividade IPv6. Os acessos de ferramentas e serviços internos em IPv4, continuaram funcionando normalmente. Este POC foi um primeiro passo e atendeu as expectativas para continuidade no processo de testes em outros serviços. A abordagem do Dual Stack permitiu acesso as funcionalidades do IPv6, sem perder ou impactar os serviços utilizados atualmente sobre o IPv4 e conforme mencionado, não foi necessário um investimento em equipamentos. Na parte de configuração, ainda parece um pouco confusa, devido a mudança de notação no IPv6 com o hexadecimal, mas com o tempo e maior experiência, será normal como atualmente é no IPv4. X. IMPLANTAÇÕES DO IPV6 NO BRASIL E NO MUNDO Neste capítulo são mostradas algumas estatísticas de adesão ao tráfego IPv6 fornecidos pelos sites das empresas Cisco [29] e Akamai [30], pelo fato destas empresas concentrarem boa parte do tráfego da Internet em suas infraestruturas, também serão mencionados partes das apresentações realizadas no VI Fórum Brasileiro de IPv6 realizado em São Paulo na data 09 de dezembro de 2015 [31]. A figura 37, retirada do site da Akamai [30], onde eles realizaram um ranking de tráfego total versus quantidade de tráfego em IPv6 que passam pela sua estrutura em cada país. Pode-se notar que alguns países europeus estão com uma adesão bem superior ao resto do mundo. Fig. 37. Ranking trafego IPv6 por país. [30] Na figura 38 é mostrado o histórico de crescimento do tráfego IPv6 no Brasil que atualmente possui algo em torno de 8,2% de tráfego IPv6. Pelos dados, o Brasil começou a ter um crescimento significativo apenas no início de 2015, passando a ter um crescimento rápido desde então. Fig. 38. Gráfico com histórico de trafego IPv6 no Brasil. [30] Este crescimento a partir do ano de 2015 provavelmente está relacionado à baixa quantidade de endereços IPv4 disponíveis no LACNIC alcançada em meados de junho de 2014, conforme mostra a figura 39. Fig. 39. Gráfico com histórico de esgotamento IPv4 nas RIRs. [32] Também, conforme apresentado no VI Fórum Brasileiro de IPv6 [31] em 2015, algumas das principais empresas

15 nacionais prestadoras de acessos (Vivo, Algar Telecom, TIM e NET) intensificaram as implantações de IPv6 em suas infraestruturas e disponibilizaram para seus clientes acessos IPv6. Também no fórum, foram apresentados os avanços dos planos de implantações de IPv6 de alguns dos principais provedores de conteúdo (Globo, Netflix e UOL), o que contribui muito para o aumento do tráfego em IPv6. A figura 40 mostra os dez sites mais acessados no Brasil, apresentado pelo Sr. Fabio Scartoni, da operadora Vivo, no fórum IPv6. Dos dez sites mais acessados, oito já estão disponíveis em IPv6. A figura 43 ilustra outra informação apresentada pelo Sr. Fabio Scartoni da Vivo, no fórum IPv6, mostrando os dez países com maior percentual de acesso em IPv6 ao Google e também a quantidade no Brasil. [31] Fig. 40. Top 10 Sites acessados no Brasil. [31] A figura 41 mostra mais estatísticas sobre IPv6 no Brasil reportada pela Cisco. Pode ser observado que 57,79% dos trânsitos dos AS (Autonomous System) no Brasil suportam IPv6, além de 60,07% dos conteúdos estarem disponíveis em IPv6. Também temos 8,2% de tráfego de usuários em IPv6. [29]. Fig. 41. Estatísticas trafego IPv6 Brasil. [29] Já a figura 42 mostra uma visão global do tráfego de usuário em IPv6 pela Cisco. Quanto mais escuros os tons verdes na escala, maior a % de tráfego IPv6 naquela região. [29] Fig. 42. Visão global de acesso de usuários ao IPv6 pela Cisco. [29] Fig. 43. % de acesso ao Google em IPv6 por país. [31] As informações mostram que tanto no Brasil quanto em boa parte dos maiores países, temos uma quantidade significativa de tráfego IPv6. Estes tráfegos tiveram um crescimento considerável nos últimos anos, que foram movidos pelos anúncios do fim do IPv4 pela IANA em 2011 e posteriormente, o esgotamento ou o baixo número de IPv4 ainda disponíveis nas RIRs. A exceção fica por conta da RIR AFRINIC, que ainda possui um número considerável de IPv4 disponível e por isso também não possui um desenvolvimento de infraestrutura em IPv6 significativo. No Brasil, estamos em uma curva de crescimento considerável, que vem sendo impulsionado com as adequações de infraestrutura pelas provedoras de acessos e a disponibilizações de paginas e serviços em IPv6. XI. CONCLUSÃO Neste artigo, foram apresentados um pouco da história do IPv6 e os motivos para seu desenvolvimento, que teve a origem na necessidade de fornecer uma maior quantidade de endereços IP para atender as demandas que não foram previstas quando foi criado seu antecessor IPv4. Também foram apresentadas algumas formas de realizarem migrações e a coexistência entre as duas versões do protocolo. Conforme apresentado, ao longo dos anos foram criadas diversas técnicas para migrações para IPv6 ou até mesmo para postergar o esgotamento do IPv4. Entre as técnicas apresentada recomenda-se que a Dual Stack ou Pilha Dupla, quando possível (demanda recursos que suportem os dois protocolos), seja a técnica adotada. Pois é a técnica que apresenta a abordagem de ter uma arquitetura nativamente IPv6 e também IPv4, o que possibilita a utilização dos recursos do protocolo IPv6 sem impactar o funcionamento do