Estudo da Aplicação das Técnicas de Transição e Coexistência entre Redes IPv4/IPv6 na rede do ICEA. Lúcio Flávio de Miranda

Transcrição

1 Universidade Federal de Ouro Preto Instituto de Ciências Exatas e Aplicadas Colegiado de Sistemas de Informação Estudo da Aplicação das Técnicas de Transição e Coexistência entre Redes IPv4/IPv6 na rede do ICEA Lúcio Flávio de Miranda TRABALHO DE CONCLUSÃO DE CURSO ORIENTAÇÃO: Theo Silva Lins Agosto, 2018 João Monlevade/MG

2

3 Lúcio Flávio de Miranda Estudo da Aplicação das Técnicas de Transição e Coexistência entre Redes IPv4/IPv6 na rede do ICEA Orientador: Theo Silva Lins Coorientador: Marlon Paolo Lima Monografia apresentada ao curso de Sistemas de Informação do Departamento de Computação e Sistemas da Universidade Federal de Ouro Preto como requisito parcial para obtenção do grau de Bacharel em Sistemas de Informação Universidade Federal de Ouro Preto João Monlevade Agosto de 2018

4 M672e Miranda, Lúcio Flávio de. Estudo da Aplicação das Técnicas de Transição e Coexistência entre Redes IPv4/IPv6 na rede do ICEA [manuscrito] / Lúcio Flávio de Miranda f.: il.: color; grafs; tabs; mapas. Orientador: Prof. MSc. Theo Silva Lins. Coorientador: Prof. Dr. Marlon Paolo Lima. Monografia (Graduação). Universidade Federal de Ouro Preto. Instituto de Ciências Exatas e Aplicadas. Departamento de Computação e Sistemas de Informação. 1. Arquitetura de redes. 2. Rede de computador - Protocolos. 3. Comutação por pacotes (Transmissão de dados). 4. Conectividade (Computadores). I. Lins, Theo Silva. II. Lima, Marlon Paolo. III. Universidade Federal de Ouro Preto. IV. Titulo. Catalogação: ficha.sisbin@ufop.edu.br CDU: 004.7

5

6

7 Dedico este trabalho a todos que de algum modo me ajudaram até aqui.

8

9 Agradecimentos Agradeço primeiro a Deus por tudo. À minha mãe Maria Aparecida pelo amor e ensimanentos, meu irmão Lucas e minha namorada Lúcia, pelos incentivos e paciência. Aqui, gostaria de lembrar as pessoas queridas e que já partiram, minhas tias Ivani Miranda, Zita Miranda e meu pai José Lucas, que partiu num momento de alegria, um dia após minha apresentação e aprovação no TCC I. Todos vocês ajudaram a moldar meu caráter. Aos professores Theo Lins, Marlon Paolo e Vinícius Mota pelos ensinamentos e orientações recebidos durante a realização deste trabalho. Aos professores Vicente e Gilda pelas orientações repassadas na banca de avaliação e que tornaram esse trabalho melhor. E aos demais professores com quem tive oportunidade de compartilhar conhecimento nesta jornada acadêmica. Agradeço aos colegas do núcleo de Informática do ICEA, que me ajudaram no levantamento das informações do cenário de rede do instituto, principalmente ao Plínio com quem tive mais contato. À Sílvia Regina administradora de edifícios, demais funcionários do ICEA e à todas as amizades que conquistei na UFOP. Muito obrigado!

10

11 Os endereços IPv4 existentes estão acabando, e agora?

12

13 Resumo Estamos inseridos em um período de constante e necessário crescimento da Internet. Em contrapartida, vivenciamos a escassez dos endereços do Protocolo IPv4 para atender às novas demandas. Assim, a adoção do IPv6 é primordial para garantir essa evolução. Neste contexto, conhecer e aplicar técnicas que possibilitem uma transição entre versões, garantindo o crescimento da Internet e continuidade de serviços tornou-se uma tarefa árdua, principalmente devido ao atraso vivenciado desde o lançamento dos primeiros planos de transição. Este trabalho objetiva realizar um estudo das principais técnicas de transição e coexistência em IPv6, por meio da coleta de dados que possibilitam avaliar o uso aplicado à arquitetura de rede do ICEA (Instituto de Ciências Exatas e Aplicadas), na UFOP. Para isso, foi realizado um levantamento do cenário de rede do ICEA, e posteriormente foi utilizado o software CORE (Common Open Research Emulator) para os testes usando as técnicas de Pilha Dupla, túneis 6over4 e Generic Routing Encapsulation. Foi executada também uma implementação de Tunnel Broker, oferecido pela Hurricane Electric, fora do ambiente de emulação. Os resultados obtidos demonstraram em geral, um melhor desempenho usando IPv4, que apresentou médias gerais mais baixas em relação ao IPv6. Estes resultados serviram para avaliar as métricas de Latência, Jitter e Perdas de Pacotes, o que permitiu uma análise comparativa entre técnicas. Palavras-chaves: IPv4, IPv6, Técnicas de Transição, CORE, Latência, Perda de Pacotes, Jitter.

14

15 Abstract We are inserted in a period of constant and necessary growth of the Internet. On the other hand, we have experienced the scarcity of IPv4 address to meet new demands. Thus, the adoption of IPv6 is essential to guarantee this evolution. In this context, knowing and applying techniques that allow a transition between versions, ensuring the growth of the Internet and service continuity, has become a difficult task, mainly due to the delay experienced since the launch of the first transition plans. This work aims to carry out a study of the main techniques of transition and coexistence in IPv6, through the collection of data that make it possible to evaluate the use applied to the network of the ICEA (Institute of Exact and Applied Sciences) in UFOP. For this purpose, a survey of the was conducted over the network scenerio of the ICEA network and later it was used the software CORE (Common Open Research Emulator) for testing by using the Dual Stack, 6over4, and GRE techniques. It was also run an implementation of Tunnel Broker, offered by Hurricane Electric, outside the environment of emulation. The obtained results demonstrated, in general, a better performance using IPv4, which presented lower general averages in relation to IPv6. These results were used to evaluate the metrics of Latency, Jitter and Packet Loss, allowing a comparative analysis between techniques. Key-words: IPv4, IPv6, Transition Techniques, CORE, Latency, Packet Loss, Jitter.

16

17 Lista de ilustrações Figura 1 Representação geográfica das RIRs Figura 2 Previsão de esgotamento de endereços IPv4 ainda presentes nos RIRs.. 29 Figura 3 Projeção de Esgotamento blocos IPv4, Fase 3 - Lacnic Figura 4 Mapa da Adoção do IPv Figura 5 Posição do Brasil Figura 6 Cabeçalho IPv Figura 7 Representação Endereçamento IPv Figura 8 Cabeçalho IPv Figura 9 Servidor operando em Pilha Dupla Figura 10 Túnel manual 6over4 entre dois roteadores Figura 11 Túnel manual 6over4 entre dois dispositivos Figura 12 Pacote com Cabeçalho GRE Figura 13 Topologia Lógica do Tunnel Broker Figura 14 Topologia Física do Tunnel Broker Figura 15 Topologia e funcionamento do túnel 6to Figura 16 Estabelecimento de Túnel Teredo Figura 17 Tradução de endereço IPv4 para IPv6 no Teredo Figura 18 Topologia de rede ISATAP Figura 19 Exemplo Topologia DS-Lite Figura 20 Topologia 4rd Figura 21 Topologia de rede 6PE Figura 22 Túnel automático 6rd Figura 23 Topologia da rede com a utilização do divi e divi-pd Figura 24 Diagrama de Sequência do NAT64/DNS Figura 25 Topologia de Rede do NAT64/DNS Figura 26 Diagrama de Sequência do 464XLAT Figura 27 Topologia de Rede do 464XLAT Figura 28 Topologia de rede A+P Figura 29 Topologia de rede NAT Figura 30 Topologia/Experiência Figura 31 Resultados trasmissão tráfego streaming Figura 32 Área de Trabalho, CORE Figura 33 Software iperf operando Figura 34 Representação do Cenário usado para testes Figura 35 Representação Técnica de Pilha Dupla Figura 36 Comparação de Latência - Computador Cliente-1 - Pilha Dupla

18 Figura 37 Comparação de Jitter - Computador Cliente-1 - Pilha Dupla Figura 38 Comparação de Latência - Computador Cliente-2 - Pilha Dupla Figura 39 Comparação de Jitter - Computador Cliente-2 - Pilha Dupla Figura 40 Representação Técnica 6over Figura 41 Comparação de Latência - Computador Cliente-1-6over Figura 42 Comparação de Jitter - Computador Cliente-1-6over Figura 43 Comparação de Latência - Computador Cliente-2-6over Figura 44 Comparação de Jitter - Computador Cliente-2-6over Figura 45 Comparação de Latência - Computador Cliente-1 - GRE Figura 46 Comparação de Jitter - Computador Cliente-1 - GRE Figura 47 Comparação de Latência - Computador Cliente-2 - GRE Figura 48 Comparação de Jitter - Computador Cliente-2 - GRE Figura 49 Tentativa de Ping IPv6 à serviços de Internet Figura 50 Teste de Ping IPv6 com êxito após configuração de Tunnel Broker Figura 51 Teste de acesso com IPv6 bem sucedido a um site Figura 52 Média de Latência IPv4xIPv6 usando Tunnel Broker Figura 53 Média Jitter IPv4xIPv6, usando Tunnel Broker Figura 54 Relação de Perda de Pacotes X Pacotes Enviados Figura 55 Percental de Perda de Pacotes Figura 56 Tela Inicial Figura 57 Tela Cadastro Figura 58 Criação do túnel Figura 59 Resumo das configurações do túnel Figura 60 Escolha do SO Figura 61 Informações de configuração do túnel Figura 62 Informações de configuração do túnel no terminal Linux

19 Lista de tabelas Tabela 1 Área de abrangência das RIRs Tabela 2 Situação atual dos Blocos IPv4 no Lacnic Tabela 3 Modelo TCP/IP Tabela 4 Opções de campos definidas na versão original do IPv

20

21 Lista de abreviaturas e siglas AFRINIC AFTR AP APNIC ARIN ARPANET A+P BSD B4 CERNET2 CIDR CGI.br CGN CLAT CORE CPE DCC DECSI DHCP African Network Information Centre Address Family Transition Router Access Point Asia Pacific Network Information Centre American Registry for Internet Numbers Advanced Research Projects Agency Network Address Plus Port Berkeley Software Distribution DS-Lite Basic Bridging BroadBand China Education and Research Network Classless Inter-Domain Routing Comitê Gestor da Internet no Brasil Carrier Grade NAT Customer side translator Common Open Research Emulator Customer Premises Equipment Departamento de Ciência da Computação Departamento de Computação e Sistemas Dynamic Host Configuration Protocol DHCPv6 Dynamic Host Configuration Protocol version 6 DNS DS-Lite FTP Domain Name System Dual Stack Lite File Transfer Protocol

22 GB GRE HTTP IANA ICANN ICEA IHL IoT IP GigaBytes Generic Routing Encapsulation Hypertext Transfer Protocol Internet Assigned Numbers Authority Internet Corporation for Assigned Names and Numbers Instituto de Ciências Exatas e Aplicadas Internet Header Length Internet of Things Internet Protocol IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 ISATAP Lacnic LSN LSPs MB MBGP MOS ms NAT NAT444 NAT64 Nic.br NIR OSI Intra-Site Automatic Tunnel Addressing Protocol Latin America and Caribbean Network Information Centre Large Scale NAT Label Switch Paths MegaBytes Multiprotocol BGP Mean Opinion Score Milissegundo Network Address Translation Network address translations at customer s private network and carrier s private network Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers Núcleo de Informação e Coordenação do Ponto BR National Internet Registry Open Systems Interconnection

23 PLAT QoS RAM RCTS REDUnB RFC RIPE NCC RIR SMTP TCP TTL UBI UDP UFLA UFOP ULA ULHT UnB VoIP VPN 6in4 6over4 6PE 6rd 6to4 Provider side translator Quality of Service Random Access Memory Rede Ciência, Tecnologia e Sociedade Rede de Dados da UnB Request for Comments Réseaux IP Européens Network Coordination Centre Regional Internet Registry Simple Mail Transfer Protocol Transmission Control Protocol Time to Live Universidade da Beira Interior User Datagram Protocol Universidade Federal de Lavras Universidade Federal de Ouro Preto Unique Local Address Universidade Lusófona de Humanidades e Tecnologias Universidade de Brasília Voice over Internet Protocol Virtual Private Network IPv6-in-IPv4 IPv6-over-IPv4 IPv6 Provider Edge router IPv6 Rapid Deployment Connection of IPv6 Domains via IPv4 Clouds

24

25 Sumário 1 INTRODUÇÃO Problema Justificativa Objetivos Estrutura do Trabalho REFERENCIAIS TEÓRICOS Modelo de Camada TCP/IP IPv Cabeçalho IPv Endereçamento IPv Cabeçalho IPv Cabeçalhos de Extensão Endereçamento IPv Tipos de Endereços definidos em IPv Técnicas de Transição e Coexistência Técnica de Pilha Dupla Técnicas de Tunelamento Túnel 6over4 IPv6-over-IPv Túneis GRE Tunnel Brokers to TEREDO ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) Dual Stack Lite (DS-Lite) rd PE e 6VPE rd Técnicas de Tradução IVI, divi e divi-pd NAT64 e DNS XLAT (draft-ietf-v6ops-464xlat-01) A+P(Address Plus Port) NAT

26 2.5 Trabalhos Relacionados Um Modelo de Migração de Ambiente IPv4 para IPv6 em uma Rede Acadêmica Heterogênea Proposta de Implantação do Protocolo IPv6 na Rede da Universidade Federal de Lavras Estudo da eficiência da comunicação IPv4 versus IPv6 na rede de investigação e ensino Portuguesa RCTS entre Lisboa e Covilhã METODOLOGIA Métricas Softwares CORE iperf Ping Testes EXPERIMENTOS E RESULTADOS Cenário de Testes Pilha Dupla over GRE Tunnel Broker Limitações CONCLUSÃO REFERÊNCIAS APÊNDICES 93 APÊNDICE A CONFIGURAÇÕES UTILIZADAS A.1 6over A.2 GRE A.3 Tunnel Broker APÊNDICE B MÉDIAS GERAIS E CÁLCULO DE DESVIO PA- DRÃO

27 ANEXOS 103 ANEXO A PLANTA DE IMPLANTAÇÃO DO ICEA

28

29 27 1 Introdução Tecnologias voltadas para a comunicação entre redes de computadores e Internet surgiram ou foram modificadas visando melhoria em seus processos. Uma das principais tecnologias que permitiram esse avanço foi o surgimento do IP (Internet Protocol). O IP (POSTEL, 1981), permite a identificação de cada dispositivo conectado em uma rede de computadores, assim é possível a comunicação entre eles. Atualmente se encontra amplamente operacional a versão 4 do protocolo (IPv4). Dados recentes publicados pela We are Social e Hootsuite (KEMP, 2018) apontam que mais de 4 bilhões de pessoas no mundo usam a Internet. Além desse crescente aumento de usuários, avanços na área de pesquisas sobre IoT (Internet of Things), que prometem interligar os mais diversos tipos de aparelhos à rede mundial de computadores, denotam o quanto as tecnologias devem ser aperfeiçoadas para suportarem o futuro que se aproxima, de forma a incluírem novos usuários à rede. 1.1 Problema O esgotamento dos endereços IPv4 existentes é um fato preocupante. A questão se agrava devido ao notório atraso da implantação do IPv6. Algumas medidas foram estudadas e implementadas visando mitigar os problemas causados por este esgotamento, como por exemplo, o uso do NAT (Network Address Translation) (EGEVANG; FRANCIS, 1994). A ICANN (Internet Corporation for Assigned Names and Numbers) (ICANN, 2018) é uma entidade sem fins lucrativos, constituída em 1998 responsável pela alocação de endereçamento IP, através da IANA (Internet Assigned Numbers Authority) (IANA, 2018), autoridade global responsável pela coordenação dos servidores DNS (Domain Name System) Raiz, endereçamento IP, bem com outros assuntos correlatos ao protocolo. Estão sob sua tutela direta as RIRs (Regional Internet Registry), que cumprem o papel regional, como pode ser visto na Figura 1.

30 28 Capítulo 1. Introdução Figura 1 Representação geográfica das RIRs. Fonte: Imagem extraída do site Ainda existem as NIRs (National Internet Registry), no Brasil por exemplo, cabe ao NIC.Br - Núcleo de Informação e Coordenação do Ponto BR, subordinado ao LACNIC (Latin America and Caribbean Network Information Centre), dentre outras funções a de alocação de endereços IP. A Tabela 1 descreve a área de abrangência das RIRs Regional Internet Registry ARIN Lacnic AFRINIC APNIC RIPE NCC Área de Atuação América do Norte e partes do Caribe América Latina e partes do Caribe África Ásia e Pacífico Europa, Oriente Médio e Ásia Central Tabela 1 Área de abrangência das RIRs. Fonte: Elaborada pelo autor. Os blocos IP da versão 4 estão acabando nas RIRs. Segundo (BRITO, 2013b), em 2011 a IANA distribuiu os últimos blocos IPv4 para as RIRs, esgotando assim seu estoque. A Figura 2 mostra previsão desse esgotamento nas RIRs. Ressaltando que as mesmas têm feito o trabalho de recuperarem blocos IPv4 que não estão em uso. Atualmente a AFRINIC (African Network Information Centre) é quem constitui maior número de blocos ainda disponíveis. As outras RIRs estudam a possibilidade de adquirirem parte desses blocos.

31 1.1. Problema 29 Figura 2 Previsão de esgotamento de endereços IPv4 ainda presentes nos RIRs. Fonte: Imagem extraída do site (IPV6.BR, 2018). Segundo informações divulgadas pelo LACNIC, a região sob sua jurisdição passa no momento pela fase 3 de esgotamento do IPv4, fase esta que se iniciou em 15 de Fevereiro de Isso quer dizer que a regional detém poucos blocos IPv4 que ainda podem ser distribuídos, agora com muito mais rigor na concessão. Esses blocos advém da última partilha feita pela IANA, bem como de blocos devolvidos ou recuperados. A Tabela 2 reproduz informações contidas no site do LACNIC acerca da quantidade de endereços e operações nesta Fase 3 do processo. Data de Atualização 28/06/2018 Endereços IPv4 Totais Endereços IPv4 devolvidos/revogados nesta fase: Endereços IPv4 alocados nesta fase: Endereços IPv4 disponíveis nesta fase: Tabela 2 Situação atual dos Blocos IPv4 no Lacnic. Fonte: Dados extraídos de (LACNIC, 2018). Dados estatísticos do Lacnic (LACNIC, 2018) apontam uma previsão de quando podem se esgotar os endereços remanecentes em seu centro, com data prevista para 11/2019, como pode ser visualizado na Figura 3.

32 30 Capítulo 1. Introdução Figura 3 Projeção de Esgotamento blocos IPv4, Fase 3 - Lacnic. Fonte: Imagem extraída do site (LACNIC, 2018). 1.2 Justificativa Com o surgimento do IPv6, surgiu também um novo questionamento: Como implantar essa nova versão garantindo que haja os menores danos possíveis, ou seja, iniciar um processo complexo de migração, sem deixar a rede atual inoperante e garantir que todos os serviços existentes continuem operacionais pós transição? Diversas técnicas foram criadas com este fim, classificadas em 3 categorias: Pilha Dupla, Tunelamento e Tradução. Pilha Dupla consiste que todos os dispositivos presentes na rede estejam configurados com as duas versões do protocolo (IPv4/IPv6) e foi indicada como técnica preferida para que houvesse um processo gradual de mudança, sendo amplamente indicado seu uso sempre que possível. Entender as características do IPv6, das técnicas existentes à necessidade e importância desse momento de transição tornou-se primordial para o sucesso desse projeto. O processo tem sido complexo e está de forma geral atrasado, já que o plano inicial era implantar o IPv6 em toda Internet antes do esgotamento do IPv4 (SANTOS et al., 2012). Mas é de primordial importância para o crescimento da Internet, principalmente com os recentes estudos e avanços sobre IoT.

33 1.2. Justificativa 31 A Figura 4 mostra como está a adoção do IPv6 no mundo, segundo dados estatísticos levantados pela APNIC. Quanto mais clara a cor representada no mapa maior é a porcentagem de uso. Figura 4 Mapa da Adoção do IPv6. Fonte: Imagem extraída do site O Brasil figura entre os 10 primeiros países com maior utilização do IPv6 segundo este levantamento, conforme pode ser visto na Figura 5. Figura 5 Posição do Brasil. Fonte: Imagem extraída do site

34 32 Capítulo 1. Introdução 1.3 Objetivos Neste contexto, objetiva-se com este trabalho realizar um estudo geral de algumas das principais características do IPv6, bem como de algumas técnicas de transição e coexistência entre redes IPv4/IPv6. Permitindo um embasamento teórico sobre as áreas estudadas, possibilitando entender como o novo protocolo pode contribuir para o crescimento e evolução da Internet. Como forma de exemplificar o funcionamento das técnicas de transição e coexistência, pretende-se realizar um estudo de caso com quatro das técnicas estudadas: Pilha Dupla, 6over4, GRE (Generic Routing Encapsulation) e Tunnel Broker, utilizando para isso uma representação de parte da estrutura de rede do ICEA, que será emulada por meio do CORE. Buscando obter dados fora do ambiente emulado, a experimentação com Tunnel Broker será realizada utilizando um serviço de túnel IPv6 fornecido pela Hurricane Eletric (ELECTRIC, 2018). 1.4 Estrutura do Trabalho Demais textos deste trabalho estão ordenados da seguinte forma: Capítulo 2: relata os referenciais teóricos para realização do trabalho, como por exemplo, IPv4, IPv6, técnicas de transição e coexistência e trabalhos relacionados. Capítulo 3: descreve a metodologia seguida para elaboração dos testes, Softwares usados, e métricas estudadas. Capítulo 4: estão contidos os experimentos e resultados obtidos em cada técnica e limitações encontradas. Capítulo 5: descreve a conclusão e trabalhos futuros.

35 33 2 Referenciais Teóricos 2.1 Modelo de Camada TCP/IP Segundo (WETHERALL; TANENBAUM, 2011), o modelo TCP/IP (Transfer Control Protocol/Internet Protocol) teve seu surgimento ainda na era da ARPANET (Advanced Research Projects Agency Network), em meio à visível preocupação do Comando de Defesa dos Estados Unidos em garantir o funcionamento de comunicação de sua rede. Originalmente é composto por 4 camadas e seu nome advém de dois protocolos que fazem parte do modelo: TCP e IP. Este modelo é apresentado na Tabela 3. O modelo TCP/IP composto por quatro camadas: 4 Aplicação 3 Transporte 2 Internet 1 Enlace Tabela 3 Modelo TCP/IP. Fonte: Elaborada pelo autor Camada de Aplicação Nesta camada estão presentes os protocolos de alto nível, como por exemplo: FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol) e HTTP (HyperText Transfer Protocol). Essa camada realiza a ligação com as aplicações dos usuários. Camada de Transporte Abaixo da camada de Aplicação encontramos a camada de Transporte, e esta tem por preceito a comunicação origem/destino na rede TCP/IP. O TCP e o UDP (User Datagram Protocol) compõem esta camada. O TCP ao receber uma mensagem a subdivide em pacotes menores e os encaminha. O protocolo oferece confiabilidade em conexão, sequenciamento, conferência e retransmissão dos pacotes. O UDP não é orientado à conexão, e portanto não garante confiabilidade. Seu uso é mais empregado em aplicações onde a rapidez nas entregas dos pacotes é mais essencial do que a precisão, (WETHERALL; TANENBAUM, 2011) Camada Internet Aqui ocorrem os envios dos pacotes recebidos pela camada de transporte da rede de origem para um destino, mesmo em redes diferentes. Essa camada não pretende garantir

36 34 Capítulo 2. Referenciais Teóricos que os pacotes sejam entregues na ordem em que são enviados, mas que eles cheguem ao destino independente dos caminhos percorridos. Aqui está presente a atuação do IP. Camada de Enlace A camada de rede do modelo TCP/IP, engloba as funções da camada Física e a de Enlace em relação ao modelo OSI (Open Systems Interconnection). Por esse motivo, ela apresenta funções como: permitir conexões de cabeamento, bem como conversões de sinais elétricos. Também controla o fluxo, evitando a sobrecarga e provendo controle de erros ao enviar os arquivos recebidos. Alguns autores incluíndo (WETHERALL; TANENBAUM, 2011), adotam o uso do modelo com 5 camadas, com a camada Física separada da Enlace. 2.2 IPv4 A versão 4 do IP é datada de Setembro de 1981 e suas especificações referenciadas na RFC791 (POSTEL, 1981). Sua utilização tem sido ainda predominante na Internet. Segundo (COMER, 2015), desde sua criação em meados da década de 70, o escopo do seu projeto não passou por muitas modificações, mostrando-se flexível e robusto. A Figura 6 mostra o cabeçalho IPv Cabeçalho IPv4 Figura 6 Cabeçalho IPv4 Fonte: Elaborado pelo autor com base em (POSTEL, 1981). Com base em (POSTEL, 1981) e (BARRETO, 2015) obtivemos as informações sobre os campos do Cabeçalho IPv4.

37 2.2. IPv4 35 Versão - 4 bits: Indica a versão do Protocolo. Tamanho do Cabeçalho - 4 bits: O tamanho do cabeçalho é variável. Este campo marca o início dos dados. O valor mínimo é 5. Tipo de Serviço - 8 bits: Este campo e destinado para indicar parâmetros de qualidade de serviço desejada aos datagramas. Como por exemplo, fornecer indicações baixo atraso, alta confiabilidade e alto rendimento. Tamanho Total - 16 bits: Indica o tamanho total do datagrama, máximo de bytes. Identificação - 16 bits: Responsável pela identificação do datagrama. Flags - 3 bits: Sinais de Controle. Bit 0: Bit reservado, seu valor deve ser 0. Este Bit já foi indicado para ser utilizado como Bit para detecção de tráfego malicioso. Bit 1 [DF] (Don t Fragment) Não Fragmentar: Um indicativo para que roteadores não consigam fragmentar os datagramas. Bit 2 [MF] (More Fragments) Mais Fragmentos: Com este campo é possível verificar quando todos os fragmentos do datagrama chegaram ao destino. Isso porque apenas o último fragmento não contém este conjunto de bits. Deslocamento de Fragmento - 13 bits: Este campo fornece um valor sequencial a cada parte do datagrama. Isso permite que ao final os fragmentos sejam montados em sua ordem. Tempo de Vida - 8 bits: Um campo com função contador, que é decrementado em uma unidade a cada salto. Quando chega a 0 (zero), o pacote é então descartado. Protocolo - 8 bits: Mostra o protocolo responsável pela montagem e envio dos pacotes. Soma de verificação do Cabeçalho - 16 bits: Usado para controle e verificação do datagrama. A cada Hop na rede este campo deve ser recontado, isso porque o campo Tempo de Vida é alterado. Endereço de Origem - 32 bits: Endereço de Origem. Endereço de Destino - 32 bits: Endereço de Destino. Opções - Tamanho Variável: Este campo teve seu propósito pensado para utilização futura, ou seja, permitiria a outras versões do protocolo acrescentar dados que não compunham a primeira versão. Em seu projeto original haviam algumas opções definidas, como mostra a Tabela 4 à seguir.

38 36 Capítulo 2. Referenciais Teóricos Opção Security Strict Source Routing Loose Source Routing Record Route Timestamp Descrição Nível de segurança do datagrama. Caminho completo desde a origem ao destino. Contém uma lista com todos os roteadores que obrigatoriamente o pacote deve passar, mas não proíbe que o pacote passe por outros roteadores. Este campo mostra que cada roteador deverá registrar seu id no campo opções. Cada roteador deve registrar além do seu ID, também seu registro de tempo. Tabela 4 Opções de campos definidas na versão original do IPv4 Fonte: Elaborado pelo autor Endereçamento No IPv4 o tamanho de endereçamento igual a 32 bits, resultando em uma geração de números IP possíveis. Seu campo é representado por 4 blocos de 8 bits cada e pode ser escrito por números decimais (para maior legibilidade) que vão de 0 a 255 sendo cada bloco separado por um ponto (.), como pode ser visto na Figura 7. Figura 7 Representação Endereçamento IPv4 Fonte: Elaborado pelo autor. 2.3 IPv6 Atualmente referenciado na RFC8200 (HINDEN, 2017), o IPv6 passou por alterações se comparado à versão anterior, como por exemplo, número de campos no cabeçalho e na capacidade de geração de endereços. O campos receberam um valor fixado, de tamanho 40 bytes e foram reduzidos a apenas 8. Mudanças que garantiram ao protocolo maior simplicidade e seu cabeçalho

39 2.3. IPv6 37 ficou apenas duas vezes maior. Pelo fato de possuir com valores fixados houve a remoção do campo Tamanho do Cabeçalho (IHL). Os campos Identificação, Deslocamento de Fragmento, Flags, Opções e Complementos, também deixaram de existir na versão IPv6 e suas informações passaram a constar nos cabeçalhos de extensão. O campo Limite de Encaminhamento substitui o campo Tempo de Vida. O campo Tipo de Serviço foi substituído pelos campos Classe de Tráfego e Identificador de Fluxo, sendo este último responsável por implementação e suporte a Qualidade de Serviço (QoS). Campo Tamanho dos Dados substitui o antigo campo Tamanho Total. Os campos Versão, Endereço de Origem e Endereço de Destino, sofreram alteração apenas em seus tamanhos. A Figura 8 mostra o cabeçalho IPv Cabeçalho IPv6 Figura 8 Cabeçalho IPv6. Fonte: Reprodução baseada no material do Curso IPv6 Básico. (SANTOS et al., 2012) Com base em (HINDEN, 2017), (BARRETO, 2015) e (SANTOS et al., 2012), obtemos as características dos campos presentes no Cabeçalho IPv6. Versão - 4 bits: Responsável pela identificação da versão de protocolo. Esse campo possui valor 6. Classe de Tráfego - 8 bits: Responsável por indicar a classe ou prioridade de um pacote IPv6. Continua implementando as mesmas funcionalidades do campo Tipo de Serviço do antecessor IPv4.

40 38 Capítulo 2. Referenciais Teóricos Identificador de Fluxo - 20 bits: Identifica os pacotes contidos em um mesmo fluxo de comunicação, presentes na camada de rede. Isso garante que um roteador possa discernir qual o fluxo de cada um dos pacotes, sem a necessidade de verificação da aplicação. Tamando de Dados - 16 bits: Mostra o tamanho dos dados que são encaminhados no cabeçalho do IPv6, em Bytes. Cabeçalhos de Extensão também podem ser combinados neste campo. Próximo Cabeçalho - 8 bits: Mostra qual o tipo de cabeçalho de extensão seguinte. Este campo substitui o campo Protocolo (IPv4). Limite de Encaminhamento - 8 bits: Mostra a quantidade máxima de roteadores que um pacote deve percorrer antes de seu descarte. Este campo tem seu valor decrementado a cada salto. Diferencia-se do campo TTL do IPv4 pelo fato deste último indicar essa marcação em segundos. Endereço de Origem bits: Endereço de Origem dos Pacotes. Endereço de Destino bits: Endereço de Destino dos Pacotes Cabeçalhos de Extensão No IPv6 opções podem ser resolvidas utilizando Cabeçalhos de Extensão. Esse tipo de cabeçalho está inserido entre os cabeçalho base e o da camada superior. Possuem tamanhos variados e não há limitação de quantidade. O campo Próximo Cabeçalho contido no IPv6, aponta para o primeiro cabeçalho de extensão e cada um dos Cabeçalhos de Extensão inseridos deve conter um campo Próximo Cabeçalho, constituindo assim uma ramificação, Cadeia de Cabeçalhos (SANTOS et al., 2012). Isso permitiu uma operacionalidade mais eficiente e maior velocidade ao IPv6, isso porque, somente o Hop-by-Hop é tratado em cada um dos roteadores, deixando o tratamento dos outros à cargo do nó destino que esta indicado no cabeçalho base (SANTOS et al., 2012). Seis cabeçalhos são definidos pelo IPv6: Hop-by-Hop Options: Registrado com valor 0 no campo Próximo Cabeçalho e colocado posteriormente ao cabeçalho IPv6. Contém diversas informações que serão processadas por todos os demais nós presentes no caminho entre a origem e destino dos pacotes. Destination Options: Possui valor 60 no campo Próximo Cabeçalho, possui informações que serão processadas pelo nó destino que está contido no campo Endereço de Destino. Routing: Gravado com valor 43 no campo Próximo Cabeçalho, foi criado visando

41 2.3. IPv6 39 identificar os nós intermediários por onde passariam os pacotes até o destino. Por motivos relacionados à segurança, essa particularidade foi descontinuada e seu registro feito na RFC5095 (ABLEY; SAVOLA; NEVILLE-NEIL, 2007). Recentemente, um Type 2 foi especificado e é utilizado como suporte à mobilidade do IPv6. Fragmentation: Registrado com valor 44 no campo Próximo Cabeçalho, possui informações de fragmentos dos pacotes IPv6. Authetication Header: Possui valor 51 no campo Próximo Cabeçalho, garante autenticação e integridade aos pacotes IPv6. Encapsulating Security Payload: Possui valor 52 no campo Próximo Cabeçalho, visa dar integridade e confidencialidade aos pacotes IPv6. Esses dois últimos cabeçalhos são usados pelo IPSec. Aspectos Importantes É uma boa prática o emprego dos Cabeçalhos de Extensão na ordem a seguir: Hop-by-Hop Options; Routing; Fragmentation; Authentication Header; Encapsulating Security Payload; Destination Options. Isso permite que os hosts existentes no caminho necessitem explorar a cadeia de cabeçalhos por inteiro. Cabeçalhos de relevância para todos os hosts são posicionados à frente, já os que tm sua importância apenas ao host destinatário, têm seu posicionamento ao final. Assim, ao encontrar um cabeçalho endereçado a um host destinatário específico que não ele, o host que está realizando a análise pare seu processamento, elevando o desempenho no processamento dos pacotes. Pacotes com destino Multicast terão seus cabeçalhos analisados por todos o hosts deste grupo Endereçamento IPv6 A versão 6 do Protocolo IP apresenta um espaço de endereçamento fixado em 128 bits, o que proporciona a geração de

42 40 Capítulo 2. Referenciais Teóricos , (340 Undecilhões) de endereços possíveis. Quantidade bem superior em relação ao antecessor que gerava uma combinação de de endereços. Um endereço IP gerado em IPv6 é subdividido em oito grupos de contendo 16 bits (Duplo-Octetos ou Hexadecatetos), que são escritos em formato Hexadecimal (0-F) maiúsculo ou minúsculos, sendo que cada grupo deve ser separado por um sinal de (:). Para mais legibilidade há algumas particularidades que podem ser adotadas no momento de escrever um endereço IPv6: Omissão de 0 à esquerda em cada grupo de 16 bits, Separação por (::) em cadeias longas de 0. Este último tipo de abreviação deve ser considerado apenas uma única vez em um endereço, para não gerar ambiguidade. Ex: 2001:0DB8:AD1F:25E2:CADE:CAFE:F0CA:84C1 2001:0DB8:0000:0000:130F:0000:0000:140B 2001:db8:0:0:130f::140b (Endereço acima omitindo-se os zeros e usando a notação (::).) Ex: Gerando ambiguidade: Válido: 2001:0DB8:0000:0000:130F:0000:0000:140B Usando Notação (::): Ambiguidade: 2001:DB8::130F::140B Não seria possível determinar se o endereço corresponderia por exemplo à: 2001:DB8:0:0:130F:0:0:140B, 2001:DB8:0:0:0:130F:0:140B, 2001:DB8:0:130F:0:0:0:140B. O IPv6 faz a representação de prefixos de rede utilizando o formato estabelecido na notação CIDR (Classless Inter-Domain Routing), ou seja, endereço-ipv6/tamanho do Prefixo. Ex: Prefixo 2001:db8:3003:2::/64 O número contido após o sinal de /, refere-se ao valor da quantidade de Bits que representam a rede.

43 2.4. Técnicas de Transição e Coexistência Tipos de Endereços definidos em IPv6. em: Unicast: Identifica um único host na rede. Esta categoria de endereço subdivide-se Global Unicast: Este tipo de endereço é aquele que é roteável em uma rede IPv6. Está faixa de endereços está estabelecida hoje dentro do limite: 2000:: a 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, nos dando uma taxa de 13% do total de endereços que podem ser gerados no IPv6. Link Local: Registrado sob o prefixo: FE80::/64, este tipo de link é exclusivamente usado em uma rede local. Unique Local Address (ULA): Usado unicamente em operações locais, em um mesmo enlace ou conjunto de enlaces. Anycast: São utilizados para identificar um grupo de hosts em uma rede. Não há uma faixa de endereços destinados a essa categoria, podendo ser usado qualquer endereço Unicast. Podem ser usados quando se necessita realizar balanceamento de carga ou mesmo redundância de dados. Por exemplo, o uso em servidores DNS, caso um servidor desses falhe em uma determinada região, haverá uma outra máquina do grupo com o mesmo número IP que fornecerá a solução. Multicast: Em IPv6, não há a presença de Endereços Broadcast, onde uma mensagem enviada para essa faixa era vista por todos o nós desta rede. Endereços Multicast tem seu funcionamento parecido, identificado um grupo de hosts que em uma determinada interface, e um ou mais hosts podem estar presentes em outro grupo Multicast. Quando se envia uma mensagem a esta faixa de endereços, todos os hosts que estão contidos nesta faixa receberam a mensagem. Estão na faixa FF00::/8 e são de extrema importância em uma rede IPv6. Através deles por exemplo, o protocolo consegue desempenhar a descoberta de vizinhança. 2.4 Técnicas de Transição e Coexistência Técnica de Pilha Dupla A técnica de Pilha Dupla foi a implementação escolhida para ser utilizada no processo de transição, logo quando os endereços IPv4 davam sinais de que não seriam suficientes para o rápido crescimento da Internet. De acordo com (BRITO, 2013b), essa técnica visa permitir a interoperabilidade de dispositivos usando IPv4 e IPv6 simultaneamente, e com sua adoção o que se esperava era um processo de transição gradual e limpo.

44 42 Capítulo 2. Referenciais Teóricos Dessa forma, todos os dispositivos interligados na rede possuem as duas versões dos protocolos nas duas pontas, garantindo a possibilidade de envio e recebimento de ambos pacotes. Quando implementado dessa forma um host possui artifícios que realizam configurações IPv4 (ex:. DHCP), e mecanismos próprios para configurações IPv6 (DHCPv6, configurar manualmente), se comportando da seguinte maneira: O host terá o comportamento de uma das duas versões do protocolo de acordo com qual tipo de implementação de IP o seu interlocutor estiver utilizando. Ex: O host A se comportará como um host IPv4, se o host B, for um host IPv4. O mesmo vale para o IPv6. Alguns serviços devem ser configurados de forma específica para cada versão na Pilha Dupla, como por exemplo, firewalls e Protocolos de Roteamento. Contudo, apesar de ser umas das formas mais aceitas para a coexistência das redes, implementar uma Pilha Dupla significa manter duplo gerenciamento, duas tabelas de roteamento, resultando em elevar a complexidade da rede e muitas vezes em queda de desempenho (FLORENTINO, 2012). Segundo (SANTOS et al., 2012), há situações onde a implementação dessa técnica não é possível, por exemplo: Inexistência de IP s da versão 4 e há necessidadede inserir novos usuários usando IPv4 e IPv6, Equipamentos que não ofereçam suporte ao IPv6. A Figura 9 demonstra o funcionamento da técnica de Pilha Dupla Figura 9 Servidor operando em Pilha Dupla. Fonte:(BRITO, 2013b)

45 2.4. Técnicas de Transição e Coexistência Técnicas de Tunelamento Segundo (BRITO, 2013b), tunelamento permite que um conteúdo baseado em uma tecnologia possa trafegar em um canal constituído em outra tecnologia. É uma modalidade muito utilizada nesse período de transição, permitindo que redes puramente IPv6 possam se comunicar através de redes IPv4, ou vice-versa (SANTOS et al., 2012). Existem inúmeras implementações de túneis, que podem ser configurados de forma manual ou automática Túnel 6over4 IPv6-over-IPv4 O 6over4 documentado na RFC4213 (GILLIGAN; NORDMARK, 2005) utiliza a técnica 6in4 também presente na RFC4213. Para encapsular seus pacotes, usa um túnel configurado manualmente entre dois hosts puramente IPv4. Normalmente empregado quando equipamentos ou mesmo a rede só oferecem suporte ao IPv4 ou quando é preciso interligar dois hosts IPv6 por meio de uma rede IPv4. As Figuras 10 e 11 mostram configurações do 6over4 entre roteadores e dispositivos respectivamente. Figura 10 Túnel manual 6over4 entre dois roteadores. Fonte:(NIC.BR, 2012) Figura 11 Túnel manual 6over4 entre dois dispositivos. Fonte:(NIC.BR, 2012)

46 44 Capítulo 2. Referenciais Teóricos Túneis GRE O túnel GRE referenciado na RFC2784 (HANKS et al., 2000), é um tipo de implementação de tunelamento estático. Permite realizar o transporte de inúmeros tipos de protocolos, como IPv4, IPv6, etc, e pode ser transportado em vários tipos de protocolos. Grande maioria dos sistemas operacionais e roteadores suportam GRE. Para realizar um encapsulamento de um protocolo IPv6 para IPv4 é necessário apenas acrescentar o cabeçalho GRE depois o cabeçalho IPv4. Enumerar o campo Protocolo no cabeçalho IPv6 para 47 (2F), indicando que o IPv4 carrega GRE, e realizar o envio. No host destino ocorre o desencapsulamento do GRE e IPv4 e o pacote original é por fim direcionado (SANTOS et al., 2012). A Figura 12 demonstra a montagem de um pacote com cabeçalho GRE. Figura 12 Pacote com Cabeçalho GRE. Fonte:(NIC.BR, 2012)

47 2.4. Técnicas de Transição e Coexistência Tunnel Brokers Definida na RFC3053 (GUARDINI; DURAND; LENTO, 2001), essa modalidade visa fornecer acesso IPv6 por meio de um túnel provido geralmente por provedor de acesso e permite desde dispositivos individuais até mesmo que redes inteiras IPv4 consigam se comunicar com uma rede IPv6. De acordo com (SANTOS et al., 2012), é necessário que o usuário faça um cadastro em um dos provedores de túnel, que posteriormente realiza a configuração em sua ponta. Esse provedor envia as instruções e/ou um programa cliente para o acesso. O usuário realiza as configurações no lado cliente. Esse tipo de serviço é indicado para aqueles que desejam implantar em modo teste a adoção do IPv6, mas que ainda não dispõem de blocos fornecidos por suas operadoras de redes ou suporte ao mesmo. Acessos por meio de Tunnel Broker podem ser lento, já que todo tráfego é realizado por meio de uma VPN segundo (FLORENTINO, 2012). Alguns provedores de Tunnel Broker: As Figuras 13 e 14 mostram as topologias lógica e físicas de um Tunnel Broker, respectivamente. Figura 13 Topologia Lógica do Tunnel Broker. Fonte:(NIC.BR, 2012)

48 46 Capítulo 2. Referenciais Teóricos Figura 14 Topologia Física do Tunnel Broker. Fonte:(SANTOS et al., 2012) to4 Prevista na RFC3056 (CARPENTER; MOORE, 2001), essa técnica utiliza a implementação de túneis 6in4 configurados automaticamente, auxiliados por inúmeros relays que implementam pilha dupla distribuídos na Internet permitido redes IPv4 acessarem redes IPv6 (SANTOS et al., 2012). O 6to4 apresentou diversos problemas como lentidão, e aqueles relacionados à segurança (BRITO, 2013b). Não recomenda-se uso desta técnica. A Figura 15 demonstra o funcionamento e topologia de túnel 6to4. Figura 15 Topologia e funcionamento do túnel 6to4. Fonte:(SANTOS et al., 2012)

49 2.4. Técnicas de Transição e Coexistência TEREDO Criado pela Microsoft, estabelece conexões IPv6 por meio de túneis IPv4, encapsulados os pacotes com o Protocolo UDP. Técnica está regulamentada na RFC4380 (HUITEMA, 2006) O servidor Teredo se comunica utilizando a porta UDP 3544 e através dele que são feitas as conexões por meio de NAT (SANTOS et al., 2012). O relay Teredo é responsável pelo interfaceamento entre hosts cliente e destino. Há críticas a essa técnica que estão relacionados aos fatores segurança e desempenho, como por exemplo: um conteúdo que está encapsulado e que deveria ser bloqueado em uma rede IPv4, consegue atingir seu destinatário (NIC.BR, 2012). Figura 16 Estabelecimento de Túnel Teredo. Fonte:(SANTOS et al., 2012) Figura 17 Tradução de endereço IPv4 para IPv6 no Teredo. Fonte:(SANTOS et al., 2012) De acordo com (BRITO, 2013b) pelo fato de usar NAT, torna-se possível a existência de riscos à segurança, principalmente em um ambiente organizacional, já que conteúdos não autorizados presentes nas redes poderiam obter acesso através de túnel automático em hosts que estejam operando sistema operacional Windows.

50 48 Capítulo 2. Referenciais Teóricos ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) Essa técnica de tunelamento prevista na RFC5214 (TEMPLIN et al., 2005), é empregada permitindo construção de túneis internos na rede (BRITO, 2013b). Segundo (SANTOS et al., 2012), por não haver uma implementação de serviço público dessa técnica, ela é usada nas organizações. Principalmente quando há IPv6 na borda da rede mas não possua suporte na infraestrutura interna. Ainda segundo (SANTOS et al., 2012), ISATAP tem por premissa interligar diversos dispositivos aos roteadores. Figura 18 Topologia de rede ISATAP. Fonte:(SANTOS et al., 2012) Dual Stack Lite (DS-Lite) Referenciada na RFC6333 (DURAND et al., 2011), essa técnica tem seu uso indicado caso um provedor já possua e ofereça aos usuários a rede IPv6 nativa. Nesse cenário a quantidade de IPv4 já não está mais disponível e a quantidade de usuários ainda é uma demanda em crescimento (SANTOS et al., 2012). É criado um túnel que envia pacotes IPv4 sobre uma rede IPv6. Ao desejar acesso a uma rede que ofereça conteúdo IPv6 o cliente B4 (DS-Lite Basic Bridging BroadBan) estabelece um túnel e envia o pacote pela rede. No destino por meio de um equipamento AFTR (Address Family Transition Router) o pacote é submetido a um processo CGN (Carrier Grade NAT) e então é entregue ao destinatário. A Figura 19 mostra a topologia do DS-Lite.

51 2.4. Técnicas de Transição e Coexistência 49 Figura 19 Exemplo Topologia DS-Lite. Fonte:(SANTOS et al., 2012) Ainda segundo (DURAND et al., 2011), o uso dessa técnica permite: Desacoplar implantações de IPv6 na rede do provedor, quando já tem a implantação do mesmo na Internet, aplicações e dispositivos do cliente; Gerenciamento simplificado às redes de acesso de provedores de serviços, devido ao espaço de endereçamento IPv6; Flexibilidade para adaptação à mudança de carga de tráfego rd Prevista na RFC7600 (CHEN et al., 2015), essa técnica possui um comportamento equivalente ao DS-Lite e é baseado no 6rd. Segundo (SANTOS et al., 2012), utiliza o compartilhamento dos endereços IP com restrições de portas e tem características que direcionam seu emprego a provedores de acesso. Essa técnica também é destinada ao uso em redes puramente IPv6, pois consegue manter uma conexão fim-a-fim. Utiliza stateless, mas quando se precisa usar o statefull essa técnica emprega no lado do usuário o compartilhamento de endereços por meio de NAT e restrições de porta. A Figura 20 ilustra a topologia do 4rd.

52 50 Capítulo 2. Referenciais Teóricos Figura 20 Topologia 4rd. Fonte:(SANTOS et al., 2012) PE e 6VPE Por meio do uso de core MPLS IPv4, utilizando LSPs (Label switch Paths), essas técnicas conseguem realizar as comunicações. Para implementação dessas técnicas usam-se MBGP(Multiprotocol BGP) em cima dos pacotes IPv4 sendo necessário que os roteadores de bordas implementem Pilha Dupla. Em 6PE prevista na RFC7498 (FAUCHEUR et al., 2007) há somente uma tabela de roteamento, ao contrário do 6VPE (CARUGI; CLERCQ; OOMS, 2006). A Figura 21 mostra a topologia desta técnica. Figura 21 Topologia de rede 6PE. Fonte:(NIC.BR, 2012)

53 2.4. Técnicas de Transição e Coexistência rd Segundo (SANTOS et al., 2012), emprega-se 6rd (DESPRES, 2010) para garantir que usuários consigam acesso a redes IPv6 mesmo quando a rede ofertada é puramente IPv4. O software do CPE 6rd passou por uma modificação que permitiu o uso de 6rd. O 6rd Replay realiza o encapsulamento e desencapsulamento dos pacotes. A Figura 22 mostra uma demonstração do 6rd. Figura 22 Túnel automático 6rd. Fonte:(ACOSTA et al., 2014) De acordo com (BRITO, 2013b), 6rd se diferencia de 6to4 pela inexistência de relays públicos na Internet, assim, trafegam pelos gateways da operadora todo conteúdo que é destinado aos clientes Técnicas de Tradução Técnicas de tradução utilizam o conceito de NAT para realização da tradução de pacotes. Segundo (CARVALHO, 2015), com essa técnica, equipamentos usando IPv6 consiguem se comunicar com outros que usam IPv4 por meio da conversão de pacotes. Apesar de ser uma solução paliativa, devido a existência de muitos problemas ocasionados pelo seu uso, é também uma categoria ainda muito utilizada, no cenário de esgotamento do IPv4 vivenciado IVI, divi e divi-pd Aqui, as metodologias divi (draft-xli-behave-divi-04 ) e divi-pd (draft-xli-behavedivi-pd-01 ) são extensões da RFC 6052 (BAO et al., 2010), utilizando técnicas stateless

54 52 Capítulo 2. Referenciais Teóricos de pilha dupla em tradução de pacotes. Tratam-se de extensões IVI (BAO et al., 2011), uma técnica desenvolvida pelo CERNET2, rede puramente IPv6 chinesa (SANTOS et al., 2012). No divi-pd é possível utilizar um prefixo IPv6, e somente a atribuição de um único endereço IPv4. A Figura 23 demonstra a topologia dessa técnica. Figura 23 Topologia da rede com a utilização do divi e divi-pd. Fonte:(SANTOS et al., 2012) NAT64 e DNS64 Com especificações previstas em RFC6146 (BAGNULO; MATTHEWS; BEIJNUM, 2011) e 6147 (BAGNULO et al., 2011), essas técnicas também são usadas quando se necessita permitir o acesso de nós IPv6 em redes IPv4. De acordo com (SANTOS et al., 2012), a NAT64 age simultaneamente com o DNS64 e realiza a tradução de Pacotes IPv6 para IPv4. É aconselhado que se utilize blocos de endereços na faixa 64:ff9b::/96, que é designada justamente para o uso em mapeamento IPv4/IPv6. Usa-se o processo IVI para conversão IPv6/IPv4. A Figura 24 mostra o diagrama de sequência desta técnica.

55 2.4. Técnicas de Transição e Coexistência 53 Figura 24 Diagrama de Sequência do NAT64/DNS64. Fonte:(NIC.BR, 2012) A Figura 25 mostra a topologia de rede NAT64/DNS64. Figura 25 Topologia de Rede do NAT64/DNS64. Fonte:(NIC.BR, 2012) Segundo (FLORENTINO, 2012), a incompatibilidade de alguns aplicativos com a implementação de NAT utilizada torna-se um inconveniente ao uso dessa abordagem XLAT (draft-ietf-v6ops-464xlat-01) 464XLAT (MAWATARI; KAWASHIMA; BYRNE, 2013), utiliza uma técnica stateful e stateless na tradução de pacotes IPv4/IPv6 e é destinada a permitir o comparti-

56 54 Capítulo 2. Referenciais Teóricos lhamento IPv4 a usuários IPv6. De acordo como (SANTOS et al., 2012), o CLAT (customer side translator) (BAO et al., 2016) realiza uma tradução 1:1 é stateless (Um endereço IPv6 tem apenas um IPv6 análogo), já o PLAT (Provider Side Translator) é statefull e realiza uma tradução 1:N (inúmeros IPv6 globais tem sua representação em um único IPv4), que conversa com a rede IPv4. As Figuras 26 e 27 à seguir mostram o diagrama de sequência e topologia do 464XLAT respectivamente. Figura 26 Diagrama de Sequência do 464XLAT. Fonte:(NIC.BR, 2012) Figura 27 Topologia de Rede do 464XLAT. Fonte:(NIC.BR, 2012)

57 2.4. Técnicas de Transição e Coexistência A+P(Address Plus Port) Referenciada na RFC6346 (CITTADINI et al., 2011), utiliza-se A+P para garantir que aos usuários acesso IPv4 neste momento de transição. Por meio de NAT essa técnica consegue compartilhar um mesmo endereço IP com vários usuários na rede simultaneamente (SANTOS et al., 2012). A Figura 28 representa a topologia A+P. Figura 28 Topologia de rede A+P. Fonte: (SANTOS et al., 2012) NAT444 Também conhecida como LSN (Large Scale NAT), o NAT444 (KUARSINGH et al., 2013) permite que blocos de IP s sejam usados amplamente por meio de compartilhamento simultâneo. Isso poderia ser um grande aliado na fase de transição e prolongaria a vida útil dos endereços IPv4 (SANTOS et al., 2012), mas trata-se de um artifício que demanda equipamentos de alto custo, além de fatores técnicos como provável colisões de endereços. Essa visão é também compartilhada por (CORDEIRO, 2014), em seu trabalho intitulado Comparação de técnicas de transição do IPv4 para o IPv6 de A Figura 29 demonstra a tolopogia do NAT444.

58 56 Capítulo 2. Referenciais Teóricos 2.5 Trabalhos Relacionados Figura 29 Topologia de rede NAT444. Fonte: (SANTOS et al., 2012) Para realização deste trabalho foram pesquisados além de outros materiais, artigos relacionados ao assunto aqui proposto. Principalmente abordando as experiências no processo de implantação do IPv6 nas diversas esferas, em especial nas Universidades Brasileiras, justamente por se tratar de uma das recomendações do CGI.br (Comitê Gestor da Internet no Brasil) em sua resolução que trata do tema (CGI.BR, 2013) Um Modelo de Migração de Ambiente IPv4 para IPv6 em uma Rede Acadêmica Heterogênea. Nesta dissertação de Mestrado (BARRETO, 2015), o autor realiza um trabalho de experimentação de implantação do IPv6 na rede da Universidade de Brasília (REDUnB). O mesmo conseguiu expor uma grande fundamentação teórica sobre o tema, descrevendo as principais características do IPv6 e de seu antecessor, bem como das principais técnicas de transição e coexistência entre IPv4 e IPv6. Nos estudos realizados, tendo como base o cenário da Universidade de Brasília (UnB) em 2014, onde segundo o autor, a Universidade dispunha ainda de uma quantidade considerável de endereços IPv4, optou-se por adotar a técnica de Pilha Dupla, para a metodologia pensada, permitindo uma migração gradual. A REDUnB é uma rede ampla inclusive interligando campus geograficamente distantes, sob uma tecnologia IPv4 e que segundo o autor, havia recebido naquele ano por meio do Registro.br um bloco (/48) de endereços IPv6. Para os testes de transição preferiu-se montar um laboratório físico para realização

59 2.5. Trabalhos Relacionados 57 dos experimentos e em uma fase inicial foi definido um plano de endereçamento e roteamento de endereços. Esse laboratório em questão simulava o cenário real de rede da UnB e essa metodologia foi escolhida justamente por fornecer essa possibilidade. O laboratório era composto por switches e computadores que simulariam a rede, sendo que um deles foi configurado como servidor DNS, um tablet com um software responsável por testes de desempenho de redes. Como métricas sugeridas e avaliadas o autor resolveu estudar a latência entre nós da rede, utilizando para isso um cenário de comunicação de serviços HTTP. Um outro cenário de avaliação proposto pelo autor mediria além da latência, índice MOS (Mean Opinion Score), jitter, perdas de pacotes, indicador R-Value e medição de taxa de pacotes fora da sequência, por meio de simulação de um ambiente VoIP. Para mensuração da latência utilizando a comunicação e requisição de HTTP, foram empregados os softwares Ping e HTTPing. Análise com aplicativo Ping Foram feitas um total de 30 capturas dividas em 3 grupos em dias diferentes com um intervalo de no mínimo 5 minutos entre capturas. Obteve-se um resultado positivo em relação a essa métrica, não havendo perdas de pacotes, com uma ressalva de que no Protocolo IPv6 houve uma taxa ligeiramente maior em comparação ao obtido com o IPv4. Em relação ao jitter, as análises colhidas pelo autor mostraram que o IPv6 obteve um índice médio 17,38% maior que o IPv4. Análise com aplicativo HTTPing Foram aplicados métodos semelhantes para esse aplicativo, também totalizando 30 capturas. De acordo com o que foi pretendido pelo autor, obteve-se para o IPv6 um resultado mais satisfatório. Contudo, apresentando taxa média superior em relação o índice conseguido com o IPv4. Em relação ao jitter o IPv4 apresentou melhores resultados. Em relação à simulação de uma rede VoIP, houve uma ligeira perda de pacotes nos testes realizados sob o IPv6, mas aceitável. A mensuração do jitter esteve dentro do limite aceitável e aconselhado. Os resultados sobre latência atribuía um resultado um pouco mais elevado no IPv6 (32,38%) maior que no IPv4, no entanto, ainda dentro da faixa limite. Os indicadores específicos para avaliação de serviços VoIP, empregados R-Value e MOS, tiveram excelentes números, demonstrando um serviço de qualidade VoIP na rede. Em relação aos resultados obtidos e com base nas métricas aplicadas pelo autor, foi possível verificar que apesar da ligeira diferença de desempenho do IPv4 nos testes com requisições HTTP e das variações no segundo experimento, permitiu observar o comportamento e desempenho entre as duas versões e que segundo o autor utilizar um ambiente físico para experimentação, permitiu aproximar de forma realista o cenário vivenciado pela rede da UnB, apesar de não ter sido possível a implementação e testes de

60 58 Capítulo 2. Referenciais Teóricos outros tipos de serviços. No geral, concluiu-se que nos testes realizados o IPv4 obteve um melhor desempenho em relação ao IPv6, contudo, diante da situação atual a migração para a nova versão se faz necessária em todas as esferas. A técnica escolhida para a migração de rede da UnB foi a Pilha Dupla. O autor verificou também o quanto ainda é precário a disponibilidade de serviços e sites ofertados para IPv6, demonstrando que ainda há muito o que fazer para atingir um cenário de transição de qualidade Proposta de Implantação do Protocolo IPv6 na Rede da Universidade Federal de Lavras Um segundo trabalho estudado foi realizado por (ABREU, 2014). Trata-se de uma dissertação de conclusão do curso de Sistemas de Informação da Universidade Federal de Lavras (UFLA) e pretendia realizar um levantamento da implantação do IPv6 na Universidade. Em um cenário semelhante à UnB, a UFLA também dispunha de uma quantidade endereços IP ainda disponível no ano de elaboração do trabalho (2014), o que levou o autor a escolher a técnica de Pilha Dupla. Foi realizado uma pesquisa junto ao setor responsável da UFLA, a respeito de informações pertinentes relacionadas ao tema, como plano de endereçamento, recursos etc. Para realização e planejamento das pesquisas utilizou-se a rede implantada no DCC-UFLA (Departamento de Ciência da Computação da Universidade Federal de Lavras). Onde já havia a existência de um ponto IPv6 rodando em Pilha Dupla. Buscou-se avaliar a latência e quantidade média de dispositivos que acessavam a rede simultaneamente. Como já havia um ponto IPv6 foram testados também a disponibilidade de serviços na tentativa de acesso a diversos sites por meio de IPv6 e o tempo de resposta à solicitação. Para o cálculo da latência, o autor fez uso do aplicativo Ping. Resultados Obtidos. No acesso aos sites, pretendeu-se o acesso unicamente em IPv6 dos 20 sites mais acessados no Brasil. Com base nos resultados verificou-se que dos 20 sites pesquisados, nas 10 primeiras colocações, 30% não estava acessível por IPv6, chegando a 60% no total pesquisado. Foram feitas tentativas de acesso a sites como globo.com, Yahoo, Facebook, dentre outros. Para os testes de latência, usando o aplicativo Ping, utilizou-se o disparo dos comandos nos dois sites mais acessados: google.com e facebook.com, chegando aos seguintes resultados.

61 2.5. Trabalhos Relacionados 59 Segundo o autor de acordo com os resultados houve uma diferença bem significativa entre a utilização do IPv4 em relação ao IPv6 disparado contra o site: google.com. Por outro lado, é praticamente imperceptível essa diferença quando disparado contra o facebook.com. Como conclusão do trabalho segundo descrição do autor, foi permitido verificar que a estrutura de serviços web ainda não estava estruturada por completo para serviços puramente IPv6, com poucos sites acessíveis por esta tecnologia. A implantação do IPv6 na UFLA era um projeto a ser considerado e aplicado, obteve-se bons resultados nos testes realizados no laboratório do DCC, contudo, por motivos que abrangiam hardware e o uso do firewall da instituição que não oferecia suporte ao IPv6, não seria viável naquele momento estender a implantação da rede em toda instituição Estudo da eficiência da comunicação IPv4 versus IPv6 na rede de investigação e ensino Portuguesa RCTS entre Lisboa e Covilhã Esse trabalho estudado é uma dissertação apresentada a Universidade Lusófona de Humanidades e Tecnologias (ULHT), em Portugal defendida por (GALEGO et al., 2016). Neste trabalho o autor pretendeu exemplificar as métricas relacionadas ao requisito de Qualidade de Serviços envolvendo os protocolos IPv4 e IPv6, aplicados à rede de investigação e ensino Portuguesa, entre a Universidade Lusófona e Universidade da Beira Interior (UBI), localizada na cidade portuguesa de Covilhã. Como métricas a serem avaliadas pelo autor estão a taxa de atraso, perda de pacotes, e quantidade de pacotes transferidos, envolvendo a transferência de pacotes UDP, TCP, comunicação VoIP e transmissão streaming de áudio e vídeo. Segundo (GALEGO et al., 2016), a Rede Ciência, Tecnologia e Sociedade (RCTS) possui alto desempenho voltada para experimentação e soluções avançadas de comunicações, oferecendo vários serviços aos membros, que vão desde Universidades, Institutos Politécnicos, etc. A rede já possui um bloco IPv6 atribuído pelos órgãos responsáveis locais alocado e operando em Pilha Dupla. Para o experimento utilizou-se 2 computadores, um ligado a roteadores em ULHT, Lisboa e outro em UBI, Covilhã, conforme pode ser verificado na Figura 30 extraída de seu trabalho.

62 60 Capítulo 2. Referenciais Teóricos Figura 30 Topologia/Experiência. Fonte:(GALEGO et al., 2016) Serão apresentados os dados obtidos nos experimentos referentes à: transmissão de dados streaming utilizando IPv4 e IPv6. O autor estabeleceu que os testes seriam aplicados com duração de 30 minutos, de forma simultânea (transmissão de todos os fluxos de dados). Um dos testes foi aplicado entre 15:30h e 16:00h definido com horário laboral e outro entre 22:00h e 22:30h, em um horário pós-laboral, ambos ocorridos em 21/07/2016. Em ambos os horários para o experimento envolvendo transmissão de tráfego streaming, foram gerados 120,3 pacotes por segundo com tamanho médio de 1352,56 bytes cada. Abaixo segue tabela comparativa com os dados extraídos da dissertação. A Figura 31 mostra os resultados aplicados aos testes realizados na transmissão de tráfego streaming em redes IPv4 e IPv6. Figura 31 Resultados trasmissão tráfego streaming. Fonte: Dados extraídos de acordo com (GALEGO et al., 2016). Em ambas os cenários de experimentação, houve um número um pouco maior de pacotes transmitidos na rede IPv4, e em decorrência disso verifica-se que há uma taxa

63 2.5. Trabalhos Relacionados 61 ligeiramente maior na rede IPv4 nos tópicos de Atraso médio, variação média do atraso, bytes recebidos. Em relação à taxa de transferência, notamos uma variação semelhante entre protocolos como uma pequena taxa maior atribuída ao IPv4. Fato observado também na médias de pacotes transmitidos. Já em relação ao descarte de pacotes foi notado uma substancial diferença entre protocolos, chegando a 111 pacotes perdidos a mais na rede IPv6, verificado no cenário Laboral, bem como uma ligeira diferença de perda de pacotes maior em IPv6 em horário pós-laboral. Nesse estudo, o foco do autor foi verificar a Qualidade de Serviços, apresentadas nas duas redes. O que é um fator de extrema importância neste momento de transição. Apesar de não ter apresentado aqui os resultados dos outros experimentos que o autor realizou, o mesmo apurou por meio deles que o IPv6, obteve uma ligeira superioridade em relação ao IPv4, considerando o cenário experimentado com base nas métricas definidas e aferidas. Baseado nos trabalhos aqui apresentados verificamos os seguintes pontos a seguir: Necessidade de implantação do protocolo IPv6, num cenário de extinção de endereços IPv4; Preferência pela técnica de Pilha Dupla para esse momento de transição; Ligeira vantagem no quesito latência no protocolo IPv4, contudo, os índices atingidos pelo IPv6, não são alarmantes; Necessidade de melhoria constante e disponibilidade de mais serviços na rede para acesso IPv6. Isso mostra ainda uma deficiência enfrentada pelas empresas fornecedoras desses serviços.

64 3 Metodologia Após pesquisas sobre as diversas técnicas de transição, direcionamos os estudos para os testes usando como base o cenário de redes do ICEA. Para isso foi realizado o levantamento da rede do instituto. Após essa etapa, utilizamos o software CORE para reproduzir o cenário e posterior emulação com algumas técnicas existentes. Os resultados obtidos a cada execução dos testes foram utilizados para avaliação das métricas e comparação entre protocolos e técnicas. Um dos principais motivos ao usar testes é mostrar que após aplicadas as configurações de uma técnica, é possível obter a comunicação entre os hosts na rede. Utililizar um software para emulação de redes permite vantagens, como por exemplo: Possibilidade de montar diversas arquiteturas; Preservação da rede real, caso haja erros em configurações; Ambiente para testes de novas tecnologias antes de implementações; Economia em custos, ao não ter que comprar equipamentos para realização de testes. 3.1 Métricas As seguintes métricas serão avaliadas: Latência: Tempo necessário que um pacote leva para trafegar entre a máquina origem e destino. jitter: Segundo (FOROUZAN, 2009) jitter é a variação de atraso de um pacote em um mesmo fluxo na rede. Cada pacote trafegado na rede pode sofrer tempos diferentes de atraso até sua chegada ao destinatário. Taxas descontroladas de jitter influenciam nas aplicações que reproduzem áudio e vídeo. Perda de Pacotes: Obter dados de taxa de pacotes que não chegaram ao seu destino. Essas são métricas importantes quando falamos de qualidade de serviço e comunicação em redes. Elas podem afetar aplicações em tempo real, serviços de áudio e vídeo na Internet (TANEMBAUM, 2003).

65 3.2. Softwares Softwares CORE O emulador de redes CORE é desenvolvido por uma divisão de Pesquisas e Tecnologia da Boeing com apoio da Naval Research Laboratory (LAB, 2017). Segundo (EQUIPE, 2015), através do CORE é possível criar arquiteturas diversas, bem como interligá-las à cenários reais. Podemos também realizar simulações envolvendo topologias por meio da integração de máquinas Unix e equipamentos de redes, como por exemplo, roteadores. O CORE proporciona um ambiente de trabalho bem enxuto, de fácil manuseio e configuração, tornando possível também usá-lo em conjunto com outras ferramentas como por exemplo, o Wireshark para análises de pacotes trafegados em uma rede. A Figura 32 representa o ambiente de trabalho do emulador CORE. Figura 32 Área de Trabalho, CORE. Fonte: Elaborado pelo autor.

66 64 Capítulo 3. Metodologia iperf O software iperf (IPERF, 2018) foi criado originalmente pelo National Laboratory for Applied Network Research (NLANR), sob licença BSD usado para medições de largura de banda em redes IP, além de funcionar também como um gerador de tráfego de redes. Oferece suporte aos protocolos IPv4 e IPv6 e podem ser utilizados testes por meio de UDP, TCP e SCTP (Stream Control Transmission Protocol). Nos testes realizados obtêm-se parâmetros como perda de pacotes, jitter e largura de banda. A Figura 33 demonstra o software iperf funcionando, acima temos um terminal executando um cliente iperf, abaixo um servidor iperf. Figura 33 Software iperf operando. Fonte: Elaborado pelo autor. 3.3 Ping Encontrado em diversos sitemas operacionais, o software Ping é empregado para testar a conectividade entre os hosts em uma rede. Utiliza protocolo ICMP (Internet Control Message Protocol). O teste consiste no envio de pacotes entre o host emissor,

67 3.4. Testes 65 que espera a resposta do host destinatário. Se houver comunicação entre eles, o emissor receberá a resposta. Segundo (BRITO, 2013a), além de testar a comunicação, é possível obter dados úteis para avaliação de uma rede, como por exemplo, o valor de latência exibido em cada linha de resposta, valores baixo, médio e alto de latência, (rtt min, avg e max). No sistema operacional Linux o parâmetro mdev, presente no relatório final demonstra a medida de do jitter. 3.4 Testes Foram utilizados neste trabalho os testes nas seguintes técnicas: Pilha Dupla, Tunnel Broker, 6over4, e GRE. Os testes consistiram em utilizar o Ping para verificar a comunicação entre os hosts no cenário de rede empregado. Após configuração de cada técnica foram executados 10 comandos Ping de forma sequencial de um host cliente ao servidor na rede. Em cada comando foram emitidos 10 pacotes e assim mensurados os resultados. Através desse teste é possível obtermos informações de Latência e jitter da rede. Para medição de perda de pacotes foi utilizado o software iperf. Os testes consistiram em fazer trafegar pela rede uma quantidade de 200MB em modo cliente servidor. Ao final obtivemos a quantidade de pacotes enviados e a perda de pacotes, caso haja. Para os testes usando Tunnel Broker, foram efetuados os comandos de Ping contra os servidores do site utilizando IPv4 e IPv6, tendo respondido servidores com os endereços: IPv4 ( ) e IPv6 (2800:3f0:4001:80c::2003). Foi utilizado um notebook, com as seguintes configurações: sistema operacional Linux Ubuntu Lts, processador Intel CORE i7, 8GB de memória RAM (Random Access Memory). Os gráficos finais gerados trazem uma comparação entre execução utilizando IPv4 e IPv6.

68 4 Experimentos e Resultados Esta seção descreve o cenário de testes, resultados obtidos, apresentando uma análise comparativa entre as técnicas escolhidas. 4.1 Cenário de Testes Basicamente podemos representar o cenário de redes do ICEA em duas partes, a conexão e comunicação de equipamentos via Ethernet e Wi-Fi. Na rede Ethernet estão ligados os equipamentos dos laboratórios, secretarias, biblioteca e demais salas. Já a rede Wi-Fi temos além das conexões da rede adminitrativa o acesso dos alunos através da MinhaUfopWi.Fi. Para demonstração neste trabalho, nos preocupamos apenas na representação da parte de entrada para a rede, ou seja, conexão dos Switches, Access Points e roteadores. Não serão elencados aqui configurações relacionados à segurança, algoritmos de roteamento, métodos de autenticação à rede, configurações de classificação e endereçamento de pacotes em switches e roteadores. O acesso à rede Wi-Fi é feito através da conexão sem fio dos equipamentos aos diversos APs posicionados nos andares de cada prédio do instituto. Os APs estão conectados aos switches. Os switches de cada 1 o andar se conectam a um switch instalado no 2 o andar do Bloco B. O campus do Instituto de Ciências Exatas e Aplicadas está localizado na cidade de João Monlevade-MG e atualmente oferece os cursos de Engenharia da Computação, Elétrica, Produção e Sistemas de Informação. É composto por 8 blocos. Os blocos em sua maioria possuem 3 andares, exceto o bloco G (administrativo) que possui 4 andares. Neste bloco funcionam as secretarias diversas, salas dos colegiados e dos professores, auditório, biblioteca. Para os experimentos utilizamos uma representação em menor porte desse cenário. Decidimos por este tipo de abordagem pelo fato de legibilidade do desenho e principalmente pelos problemas enfrentados com a questão de desempenho do emulador, como pode ser melhor explicado na seção de Limitações neste texto. A Figura 34 mostra como ficou o cenário de testes utilizados no CORE.

69 4.2. Pilha Dupla 67 Figura 34 Representação do Cenário usado para testes. Fonte: Elaborada pelo autor. O host Cliente1 representa os equipamentos que acessam a rede sem fio, já o Cliente2 os equipamentos conectados via rede cabeada. Ao lado direito da figura temos dois equipamentos representando a Internet. 4.2 Pilha Dupla Ao utilizar a Pilha Dupla, temos todos equipamentos da rede configurados com as duas pilhas do protocolo IP, (IPv4 e IPv6). Assim um host poderá se comunicar via IPv4 com outro host IPv4 na outra ponta, e vice-versa. Caso haja algum de erro e uma das pilhas, a outra funcionará perfeitamente. A Figura 35 representa o cenário de Pilha Dupla montado para testes. Os testes de Ping partiram do Cliente-1 e Cliente-2 com destino ao host SERVIDOR-EXTERNO, que está representando um host na Internet.

70 68 Capítulo 4. Experimentos e Resultados Figura 35 Representação Técnica de Pilha Dupla Fonte: Elaborada pelo autor. A Figura 36 mostra os resultados de latência obtidos para Pilha Dupla. Gráfico de Latência Cliente-1 - Utilizando Pilha Dupla Figura 36 Comparação de Latência - Computador Cliente-1 - Pilha Dupla Fonte: Elaborada pelo autor. Em relação aos resultados de latência obtidos pelo Cliente-1 utilizando as duas

71 4.2. Pilha Dupla 69 pilhas do protocolo IP, percebemos que não houveram divergências muito grandes testes. O IPv4 obteve médias menores nos 10 testes executados, variando entre 41,107ms e 41,166ms e obteve média geral de 41,128ms contra 41,242ms do IPv6. A Figura 37 mostra os resultados de jitter para Cliente-1. Gráfico de Jitter Cliente-1 - Utilizando Pilha Dupla Figura 37 Comparação de Jitter - Computador Cliente-1 - Pilha Dupla Fonte: Elaborada pelo autor. Na comparação de jitter médio obtido, já temos momentos de variação entre as pilhas. Há testes em que o IPv4 obteve pior média de jitter, outros em que o IPv6 obteve resultado pior. Dois pontos com resultados discrepantes para cada protocolo: no teste 3 observamos uma média de jitter de 0,030ms para IPv4 contra 0,226ms para o IPv6. O fato se inverte no teste 7, onde o IPv6 obteve apenas 0,020ms de média contra 0,207ms do IPv4. Para esse quesito, o IPv6 obteve maior número de testes com menores médias de jitter e média de geral de 0,154ms.

72 70 Capítulo 4. Experimentos e Resultados A Figura 38 exibe os resultados de latência para Cliente-2. Gráfico de Latência Cliente-2 - Utilizando Pilha Dupla Figura 38 Comparação de Latência - Computador Cliente-2 - Pilha Dupla Fonte: Elaborada pelo autor. Comparando os resultados do Cliente-2 que se comunica através de uma conexão cabeada, em relação à latência nas duas pilhas do protocolo observamos valores médios próximos nos testes realizados. Cada protocolo obteve 5 resultados com melhor média em relação ao outro. A média geral obtida pelo IPv4 foi de 1,030ms contra 1,033ms do IPv6.

73 4.3. 6over4 71 A Figura 39 mostra os resultados de jitter para Cliente-2 utilizando Pilha Dupla. Gráfico de Jitter Cliente-2 - Utilizando Pilha Dupla Figura 39 Comparação de Jitter - Computador Cliente-2 - Pilha Dupla Fonte: Elaborada pelo autor. Valores médios de jitter obtidos pelo Cliente-2 nas duas pilhas de protocolo não apresentaram valores tão discrepantes em relação de um ao outro. Se observarmos que no teste 6 houve um empate nas taxas, podemos perceber que em relação à quantidade de testes emitidos a pilha IPv6 obteve médias mais baixas, incluive com média geral obtida de 0,046ms, quando o IPv4 obteve 0,048ms over4 No cenário montado para representação da técnica 6over4, temos os hosts, Cliente- 1, Cliente-2 e Servidor-Externo configurados com as duas pilhas do protocolo. Contudo, o meio para que esses hosts possam se comunicar possuem apenas endereços IPv4, e precisamos interligá-los por meio de IPv6. É necessário que haja uma forma de fazer esses hosts se comunicarem. A Figura 40 mostra a representação do cenário 6over4.

74 72 Capítulo 4. Experimentos e Resultados Figura 40 Representação Técnica 6over4. Fonte: Elaborada pelo autor. 6over4. A Figura 41 exibe os resultados obtidos para latência pelo Cliente-1 utilizando Gráfico de Latência Cliente-1 - Utilizando 6over4 Figura 41 Comparação de Latência - Computador Cliente-1-6over4 Fonte: Elaborada pelo autor.

75 4.3. 6over4 73 Dados obtidos pelo Cliente-1 utilizando 6over4, mostraram um melhor desempenho do IPv4 em relação ao IPv6, estando essa pilha à frente com médias menores em todos os 10 testes executados. A média geral do IPv4 foi de 41,185ms, o IPv6 atingiu média geral de ms. A Figura 42 mostra os resultados obtidos pelo Cliente-1 para jitter utilizando 6over4. Gráfico de Jitter Cliente-1 - Utilizando 6over4 Figura 42 Comparação de Jitter - Computador Cliente-1-6over4. Fonte: Elaborada pelo autor. As médias de jitter comparativas para o Cliente-1, em ambos os protocolos utilizando 6over4 demonstraram um empate se relacionarmos à quantidade de testes executados. No teste 9, notamos que o IPv6 se destaca negativamente com uma média mais elevada em relação as demais testes. Notamos no teste 4 uma média quase 3 vezes maior de jitter por parte da pilha IPv4 em relação ao IPv6. Esse fato também pode ser observado no teste 6 porém com média maior a pilha IPv6, obtendo 0,256ms de média. IPv4 e IPv6 obtiveram médias gerais bem próximas: 0,196ms e 0,197ms respectivamente.

76 74 Capítulo 4. Experimentos e Resultados técnica. A Figura 43 mostra os resultados de latência obtidos pelo Cliente-2 utilizando esta Gráfico de Latência Cliente-2 - Utilizando 6over4 Figura 43 Comparação de Latência - Computador Cliente-2-6over4. Fonte: Elaborada pelo autor. Em relação ao Cliente-2, os testes de latência utilizando 6over4, obtivemos um menores médias com IPv4, estando à frente em 9 dos 10 testes executados. Com média geral de 1,067ms contra 1,147ms utilizando IPv6. A Figura 44 mostra os resultados de jitter para o Cliente-2 utilizando 6over4.

77 4.3. 6over4 75 Gráfico de Jitter Cliente-2 - Utilizando 6over4 Figura 44 Comparação de Jitter - Computador Cliente-2-6over4. Fonte: Elaborada pelo autor. Valores de média de jitter do Cliente-2, demonstraram um melhor desempenho nessa métrica usando IPv4, com menor média em 6 dos 10 testes executados. No teste 1 o IPv4 apresentou resultado quase 4 vezes maior de média em relação ao IPv4, com resultado cerca de 26% mais elevado. A média geral dos protocolos foram de 0,045ms para IPv4 e 0,042ms para IPv6.

78 76 Capítulo 4. Experimentos e Resultados 4.4 GRE O cenário montado para os testes utilizando GRE é idêntico ao usado em 6over4, o que diferencia as técnicas é que em GRE podem ser encapsulados vários tipos de protocolos, ao contrário do 6over4, onde só é permitido o encapsulamento do protocolo IPv6. Após inseridas as configurações do túnel obtivemos os seguintes resultados. A Figura 45 mostra as médias de latência do Cliente-1. Gráfico de Latência Cliente-1 - Utilizando GRE Figura 45 Comparação de Latência - Computador Cliente-1 - GRE. Fonte: Elaborada pelo autor. Pelos valores de média resultantes nas duas pilhas utilizadas, sendo o IPv6 executado por meio de um túnel GRE, a pilha IPv4 obteve melhor desempenho em todos os testes. Visto que a difernça de valores não são discrepantes, a pilha IPv6 também obteve boas médias em relação às médias atingidas com IPv4. Já no teste 9, houve um índice médio um pouco maior para IPv6. Aqui a média geral do para IPv4 foi de ms frente a 41,275ms obtida pelo IPv6.

79 4.4. GRE 77 A Figura 46 mostra as médias de jitter do Cliente-1. Gráfico de Jitter Cliente-1 - Utilizando GRE Figura 46 Comparação de Jitter - Computador Cliente-1 - GRE. Fonte: Elaborada pelo autor. Já em relação às médias de jitter, quando comparadas a quantidade de testes executados, obtemos um empate entre os protocolos utilizados. Contudo, observamos uma taxa bem elevada de média jitter do IPv6 em relação ao IPv4, atingindo taxa de pouco mais de 6 vezes superior no teste 7. O mesmo fato pode ser observado no teste 9 com taxa de um pouco mais de 2,4 vezes. A médias gerais obtidas pelos protocolos IPv4 e IPv6 foram de 0,206ms e 0,234ms respectivamente.

80 78 Capítulo 4. Experimentos e Resultados A Figura 47 mostra as médias de latência do Cliente-2. Gráfico de Latência Cliente-2 - Utilizando GRE Figura 47 Comparação de Latência - Computador Cliente-2 - GRE Fonte: Elaborada pelo autor. Quando comparamos os resultados obtidos pelo Cliente-2 utilizando a técnica GRE, obtivemos menores médias com IPv4, em todos testes executados, mas por apresentar valores aproximados, não podemos considerar que a pilha IPv6 tenha se saído mal. Observamos média geral de 1,061ms pelo IPv4 e 1,118ms com IPv6.

81 4.4. GRE 79 A Figura 48 mostra as médias de jitter do Cliente-2. Gráfico de Jitter Cliente-2 - Utilizando GRE Figura 48 Comparação de Jitter - Computador Cliente-2 - GRE Fonte: Elaborada pelo autor. Em relação ao jitter, o IPv4 esteve melhor em 8 dos 10 testes. Destaque para o teste 4 onde o resultado foi cerca de 7 vezes menor que o IPv6 e no teste 6, com resultado ainda mais expressivo, cerca de quase 14 vezes menor. Já no teste 10, a pilha IPv6 obteve índice cerca de 2,75 vezes menor. As médias gerais dentre os testes execitados foram de 0,027ms utilizando IPv4 e de 0,042ms com IPv6.

82 80 Capítulo 4. Experimentos e Resultados 4.5 Tunnel Broker Para este trabalho foram utilizados os serviços da Hurricane Electric. Para isso, é necessário que se faça um pequeno cadastro no site da empresa, Antes de realizar as configurações para acesso, foram executados testes de Ping contra dois serviços na Internet e tentativas de acessar sites que permitem acesso via IPv6. A Figura 49 mostra a falha na tentativa de Ping6 contra os serviços na Internet. Figura 49 Tentativa de Ping IPv6 à serviços de Internet. Fonte: Elaborada pelo autor. Após a confirmação de configuração do Tunnel, foram feitos os testes Ping contra os mesmos serviços, agora obtendo êxito, conforme pode ser visto na Figura 50: Figura 50 Teste de Ping IPv6 com êxito após configuração de Tunnel Broker Fonte: Elaborada pelo autor.

83 4.5. Tunnel Broker 81 Já na Figura 51 temos o êxito do acesso ao site via IPv6. Figura 51 Teste de acesso com IPv6 bem sucedido a um site. Fonte: Elaborada pelo autor. A mesma metodologia descrita na seção Testes, também foi empregada aqui. O intuito é obter os resultados das métricas avaliadas fora do ambiente virtualizado do emulador CORE.

84 82 Capítulo 4. Experimentos e Resultados A Figura 52 mostra os resultados obtidos para latência utilizando esta técnica. Gráfico de Latência - Utilizando Tunnel Broker Figura 52 Média de Latência IPv4xIPv6 usando Tunnel Broker. Fonte: Elaborada pelo autor. Os resultados para Latência apresentaram menores médias utilizando IPv4. Com média geral de 24,954ms frente a 239,306ms obtidos com IPv6. O fato das médias utilizando IPv6 serem tão elevadas pode ser explicado justamente porque todo o conteúdo trafegado na rede necessita passar primeiro pela estrutura do servidor contratado para oferecer os serviços, tornando a rede lenta (FLORENTINO, 2012).

85 4.5. Tunnel Broker 83 A Figura 53 apresenta resultados para a jitter utilizando Tunnel Broker. Gráfico de itter - Utilizando Tunnel Broker Figura 53 Média Jitter IPv4xIPv6, usando Tunnel Broker Fonte: Elaborada pelo autor. Já no quesito de jitter, a pilha IPv4 obteve nemores médias em 7 dos 10 testes executados. Atingindo média geral de 5,376ms contra 5,387ms do IPv6. Resultados de Perda de Pacotes X Técnica Utilizada. A taxa de perda de pacotes em qualquer rede é um item importante. Altas taxas de pacotes perdidos podem afetar o desempenho da rede em inúmeros quesitos como, por exemplo, comunicação via Internet e streaming de vídeos. Para as técnicas de Pilha Dupla, 6over4 e GRE, que foram implementadas utilizando o CORE, os testes consistiram em fazer trafegar pela rede uma quantidade de 200MB de dados gerados (datagramas UDP) pelo iperf e ao final foram avaliados se houveram perdas. Foram avaliadados os dois computadores clientes com IPv4 e IPv6. Já para a técnica de Tunnel Broker, foi utilizado um servidor gratuito na Internet, que responde às requisições via IPv4 e IPv6 de clientes iperf. Escolhemos o servidor que está configurado no endereço iperf.he.net, localizado na Califórnia (USA) da Hurricane Electric. A dinâmica dos testes foi a mesma anterior. Os seguintes resultados obtidos estão representados na Figura 54.

86 84 Capítulo 4. Experimentos e Resultados Figura 54 Relação de Perda de Pacotes X Pacotes Enviados. Fonte: Elaborada pelo autor. Um dado importante ao analisar a figura, é que o número de pacotes gerados e enviados pela rede nem sempre foi o mesmo. No entanto, a quantidade de informação trafegada foi de 200 MBytes. Em relação às técnicas que foram testadas no CORE, de maneira geral podemos verificar que ao utilizarmos Pilha Dupla, obtivemos um melhor resultado. Do total de pacotes enviados, considerando os clientes 1 e 2, resultaram em pacotes perdidos, o que leva a uma média de 25,87% de perda. Nos testes utilizando 6over4, obtivemos média de 26,47% e com túnel GRE, 26,53% de perda total. Os piores índices obtidos nesse quesito foram ao utilizar a técnica de Tunnel Broker, gerando médias elevadas de perda de pacotes. Dos pacotes totais enviados, foram perdidos, uma taxa média de 88,85%.

87 4.6. Limitações 85 A Figura 55 mostra a porcentagem de perda de pacotes em cada técnica utilizada. Figura 55 Percental de Perda de Pacotes Fonte: Elaborada pelo autor. Aqui podemos ver o desempenho de cada técnica, mesmo com resultados bem próximos comparando as técnicas testadas no CORE, a técnica de Pilha Dupla teve desempenho pouco melhor. Já ao utilizar Tunnel Broker, obtivemos índice de 94% de perda de pacotes nos testes com IPv6. Com base nos dados apresentados concluímos que, comparando os resultados em relação ao números de testes executados em cada técnica nos quesitos de Latência e jitter, os melhores resultados foram obtidos utilizando IPv4. Contudo, observamos que a diferença entre pilhas é muita vezes estreita, com episódios de picos em alguns testes para cada lado, assim, não podemos dizer que ao utilizar IPv6 teremos índices baixos sempre, a ponto de impedir seu uso. Em relação à perda de pacotes, também obtivemos melhores resultados utilizando IPv4, apresentando menores taxas em todos os testes executados. 4.6 Limitações No decorrer do trabalho, um dos problemas enfrentados foi quanto ao desempenho do CORE para carregar e executar uma representação do cenário de redes com muitos componentes. Quando inserimos os componentes montados para a rede do ICEA e interligamos

88 86 Capítulo 4. Experimentos e Resultados os mesmos, o processo de execução do software se tornava extremamente lento, chegando ao ponto de travamento do CORE e até mesmo em alguns casos da própria máquina. Isso pode ter explicação no fato de estarmos trabalhando com emulação/virtualização, processo que muitas vezes exige alto poder de processamento de hardware. Devido a essa limitação resolvemos usar nos nossos testes parte da representação do cenário, como explicado na seção Metodologia. Outra limitação foi encontrada ao tentarmos representar a técnica de Tradução, NAT64/DNS64. A preparação para este teste teria como base experimentos apresentados em (EQUIPE, 2015). Para que pudesse funcionar a tradução de pacotes IPv6 para IPv4, seria necessário configurarmos o TAYGA (LUTCHANSKY, 2018) software livre que realiza esse processo. Já para executar o DNS64 (BAGNULO et al., 2011), usaríamos o software BIND (CONSORTIUM, 2018). Contudo, após realizarmos a instalação desses programas e posteriormente tentar configurá-los para os testes, houveram algumas incompatibilidades que não conseguimos sanar, por este motivo não foi contemplado nesse trabalho os testes com uma técnica de Tradução. Não foram aplicados testes aleatórios pelos seguintes motivos: utilizando o CORE justamente por ser um ambiente virtual dependíamos apenas do processamento do software e do computador hospedeiro. Já os testes com Tunnel Broker tentamos aplicar os comandos em momentos diferentes, dia e horário. Contudo, os servidores que estavam respondendo às duas requisições do protocolo, nem sempre estavam em operação. Assim, quando estavam em operação aproveitamos para realizar os comandos de forma sequencial.

89 87 5 Conclusão Os estudos empregados para realização deste trabalho, buscaram mostrar de forma geral algumas das principais características do IPv6, das Técnicas de Transição e Coexistência em redes IPv4/IPv6, apresentando um comparativo entre algumas dessas técnicas usando como base um modelo do cenário de redes do Instituto de Ciências Exatas e Aplicadas. O IPv6 vem para suprir um dos grandes problemas enfrentados hoje mundialmente em relação à Internet, a falta de endereços IPv4. O que certamente irá permitir o iminente avanço e o crescimento natural da rede com a inclusão de novas tecnologias como Internet of Things, bem como demanda por novos usuários. Com o espaço de endereçamento oferecido pelo IPv6 é possivel gerar cerca de 340 undecilhões de IPs. As técnicas de transição estão subdivididas em 3 categorias: Pilha Dupla, Tunelamento e Tradução. Ao utilizar Pilha Dupla, todos os equipamentos na rede estarão operando com as duas versões do protocolo simultâneamente. Essa foi a técnica escolhida para um processo gradual de transição. Um conceito geral sobre tunelamento, é permitir que redes operando com versões diferentes do protocolo possam se comunicar. Todo o tráfego gerado irá transitar por um túnel entre as redes. Há diversas implementações dentro dessa categoria. Já em Tradução percebemos a utilização do NAT, uma medida paliativa à falta de endereços IPv4. Foram testadas neste trabalho as seguintes implementações, Pilha Dupla, túneis 6over4 e GRE, utilizando o Emulador CORE, onde reproduzimos parte do cenário de rede do instituto e realização dos testes. Foi utilizado também uma configuração de Tunnel Broker oferecido pela Hurricane Electric. No decorrer dos estudos, enfrentamos algumas limitações, principalmente na queda de desempenho do emulador ao executar um cenário com muitos hosts configurados, bem como, ao tentar representar a técnica de Tradução NAT64/DNS64, duas implementações que trabalham em conjunto na tradução de pacotes. Não foi possível a correta configuração dos softwares adicionais necessários para o funcionamento. Devido a e est,e fato, não foi contemplado uma prática envolvendo uma técnica de Tradução. Através dos testes foram mensurados: Latência, jitter e Perda de Pacotes, sendo as duas primeiras métricas usando o aplicativo Ping e o software iperf para perda de pacotes. De forma geral, os testes apontaram um melhor desempenho do IPv4, sendo a Pilha Dupla apresentando números mais satisfatórios em relação às demais técnicas abordadas. Contudo, obtivemos resultados bem parecidos em inúmeros testes, inclusive com valores favoráveis ao IPv6, assim, não podemos afirmar que ao utilizar IPv6 teremos resultados

90 88 Capítulo 5. Conclusão ruins sempre. Como trabalhos futuros, propõe-se os testes dessas e outras técnicas no ambiente real de rede do ICEA, para um eventual processo de migração/implantação do IPv6. Em suma, no mundo todo está crescendo a adoção do novo protocolo de forma gradual, mesmo com todo atraso existente. Implantar IPv6 é uma necessidade imprescindível em todos os âmbitos, assim, promoveremos o crescimento da Internet.

91 89 Referências ABLEY, J.; SAVOLA, P.; NEVILLE-NEIL, G. Deprecation of Type 0 Routing Headers in IPv Disponível em: < Citado na página 39. ABREU, D. H. S. Proposta de implantação do protocolo ipv6 na rede da universidade federal de lavras. Lavras: [s.n.], Citado na página 58. ACOSTA, A. et al. IPv6 para operadores de Red. [S.l.: s.n.], ISBN Citado na página 51. BAGNULO, M.; MATTHEWS, P.; BEIJNUM, I. van. Stateful NAT64: Network address and protocol translation from IPv6 clients to IPv4 servers Disponível em: < Citado na página 52. BAGNULO, M. et al. DNS64: DNS extensions for network address translation from IPv6 clients to IPv4 servers Disponível em: < Citado 2 vezes nas páginas 52 e 86. BAO, C. et al. IPv6 addressing of IPv4/IPv6 translators Disponível em: < Citado na página 51. BAO, C. et al. IP/ICMP translation algorithm Disponível em: <https: //tools.ietf.org/html/rfc6145>. Citado na página 54. BAO, C. et al. The China education and research network (CERNET) IVI translation design and deployment for the IPv4/IPv6 coexistence and transition Disponível em: < Citado na página 52. BARRETO, J. d. S. Um modelo de migração de ambiente IPv4 para IPv6 em uma rede acadêmica heterogênea. Dissertação (Dissertação de Mestrado) Universidade de Brasília, Instituto de Ciências Exatas, Departamento de Ciência da Computação, Citado 3 vezes nas páginas 34, 37 e 56. BRITO, S. H. B. Interpretação dos Resultados do Ping Disponível em: < Citado na página 65. BRITO, S. H. B. IPv6-O novo protocolo da Internet. São Paulo: Novatec Editora, Citado 8 vezes nas páginas 28, 41, 42, 43, 46, 47, 48 e 51. CARPENTER, B.; MOORE, K. Connection of IPv6 domains via IPv4 clouds Disponível em: < Citado na página 46. CARUGI, M.; CLERCQ, J. D.; OOMS, D. BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN Disponível em: < Citado na página 50. CARVALHO, D. D. P. d. Implantação e análise do protocolo ipv6 com foco na mobilidade Citado na página 51.

92 90 Referências CGI.BR, C. G. da Internet no B. Resolução CGI.br/RES/2013/ Disponível em: < Citado na página 56. CHEN, M. et al. IPv4 Residual Deployment via IPv6-A Stateless Solution (4rd) Disponível em: < Citado na página 49. CITTADINI, L. et al. The A+ P Approach to the IPv4 Address Shortage Disponível em: < Citado na página 55. COMER, D. Interligação de Redes com TCP/IP : Princípios, Protocolos e Arquitetura. [S.l.]: Elsevier Brasil, v. 1. Citado na página 34. CONSORTIUM, I. I. S. BIND - Versatile, Classic, Complete Name Server Software Disponível em: < Citado na página 86. CORDEIRO, E. S. Comparação de técnicas de transição do ipv4 para o ipv Citado na página 55. DESPRES, R. IPv6 rapid deployment on IPv4 infrastructures (6rd) Disponível em: < Citado na página 51. DURAND, A. et al. Dual-stack lite broadband deployments following IPv4 exhaustion Disponível em: < Citado 2 vezes nas páginas 48 e 49. EGEVANG, K.; FRANCIS, P. The IP network address translator (NAT). [S.l.], Citado na página 27. ELECTRIC, H. Hurricane Electric Free IPv6 Tunnel Broker Disponível em: < Citado na página 32. EQUIPE, N. Laboratório de IPv6: aprenda na prática usando um emulador de redes. São Paulo: Novatec Editora, Citado 2 vezes nas páginas 63 e 86. FAUCHEUR, F. L. et al. Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) Disponível em: < Citado na página 50. FLORENTINO, A. A. IPv6 na prática. São Paulo: Linux New Media do Brasil, Citado 4 vezes nas páginas 42, 45, 53 e 82. FOROUZAN, B. A. Comunicação de dados e redes de computadores. [S.l.]: AMGH Editora, Citado na página 62. GALEGO, N. M. C. et al. Estudo da eficiência da comunicação IPv4 versus IPv6 na rede de investigação e ensino Portuguesa RCTS entre Lisboa e Covilhã. Dissertação (Mestrado) Universidade Lusofona de Humanidades e Tecnologias, Escola de Comunicacao, Arquitetura, Artes e Tecnologias de Informacao, Lisboa, Citado 2 vezes nas páginas 59 e 60. GILLIGAN, R. E.; NORDMARK, E. Basic transition mechanisms for IPv6 hosts and routers Disponível em: < Citado na página 43.

93 Referências 91 GUARDINI, I.; DURAND, A.; LENTO, D. IPv6 Tunnel Broker Disponível em: < Citado na página 45. HANKS, S. et al. Generic routing encapsulation (GRE) Disponível em: < Citado na página 44. HINDEN, R. Internet protocol, version 6 (IPv6) specification Disponível em: < Citado 2 vezes nas páginas 36 e 37. HUITEMA, C. Teredo: Tunneling IPv6 over UDP through network address translations (NATs) Disponível em: < Citado na página 47. IANA. About us Disponível em: < página 27. Citado na ICANN. What Does ICANN Do? Disponível em: < resources/pages/what en>. Citado na página 27. POSTEL, J. (Ed.). RFC 791 Internet Protocol - DARPA Inernet Programm, Protocol Specification. [S.l.], Citado 2 vezes nas páginas 27 e 34. IPERF. iperf - The ultimate speed test tool for TCP, UDP and SCTP Disponível em: < Citado na página 64. IPV6.BR. Previsão de esgotamento de endereços IPv4 nos RIR Disponível em: < Citado na página 29. KEMP, S. Digital in 2018: World s internet users pass the 4 billion mark Disponível em: < Citado na página 27. KUARSINGH, V. et al. Assessing the Impact of Carrier-Grade NAT on Network Applications Disponível em: < Citado na página 55. LAB, U. N. R. Common Open Research Emulator (CORE) Disponível em: < Citado na página 63. LACNIC. Projeção de esgotamento - Fase Disponível em: <http: // Citado 2 vezes nas páginas 29 e 30. LUTCHANSKY, N. TAYGA - Simple, no-fuss NAT64 for Linux Disponível em: < Citado na página 86. MAWATARI, M.; KAWASHIMA, M.; BYRNE, C. 464XLAT: Combination of stateful and stateless translation Disponível em: < Citado na página 53. NIC.BR. Transição Transição. Disponível em: < Acesso em: 23 mar Citado 7 vezes nas páginas 43, 44, 45, 47, 50, 53 e 54. SANTOS, R. R. d. et al. Curso ipv6 básico. IPv6. br, São Paulo, Citado 17 vezes nas páginas 30, 37, 38, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 54, 55 e 56.

94 92 Referências TANEMBAUM, A. S. Redes de computadores-quarta edição. Amsterdam: Vrije Universiteit, Citado na página 62. TEMPLIN, F. et al. Intra-site automatic tunnel addressing protocol (ISATAP) Disponível em: < Citado na página 48. WETHERALL, J.; TANENBAUM, A. Redes de computadores. 5 a edição. Rio de Janeiro: Editora Campus, Citado 2 vezes nas páginas 33 e 34.

95 Apêndices

96 APÊNDICE A Configurações Utilizadas A.1 6over4 Cliente1 ip addr add : 1 : : 2 0 dev l o ip tunnel add toserv mode s i t t t l 64 remote l o c a l ip l i n k s e t dev toserv up ip 6 route add : 3 : : 1 0 dev toserv SERVIDOR-EXTERNO ip addr add : 3 : : 1 0 dev l o ip tunnel add t o C l i e n t e 1 mode s i t t t l 64 remote l o c a l ip l i n k s e t dev t o C l i e n t e 1 up ip 6 route add : 1 : : 2 0 dev t o C l i e n t e 1 Cliente2 ip addr add : 0 : : 2 0 dev l o ip tunnel add toserv mode s i t t t l 64 remote l o c a l ip l i n k s e t dev toserv up ip 6 route add : 3 : : 1 0 dev toserv SERVIDOR-EXTERNO ip addr add : 3 : : 1 0 dev l o ip tunnel add t o C l i e n t e 2 mode s i t t t l 64 remote l o c a l ip l i n k s e t dev t o C l i e n t e 2 up ip 6 route add : 0 : : 2 0 dev t o C l i e n t e 2

97 A.2. GRE 95 A.2 GRE Cliente1 ip addr add : 1 : : 2 0 dev l o ip tunnel add toserv mode gre t t l 64 remote l o c a l ip l i n k s e t dev toserv up ip 6 route add : 3 : : 1 0 dev toserv SERVIDOR-EXTERNO ip addr add : 3 : : 1 0 dev l o ip tunnel add t o C l i e n t e 1 mode gre t t l 64 remote l o c a l ip l i n k s e t dev t o C l i e n t e 1 up ip 6 route add : 1 : : 2 0 dev t o C l i e n t e 1 Cliente2 ip addr add : 0 : : 2 0 dev l o ip tunnel add toserv mode gre t t l 64 remote l o c a l ip l i n k s e t dev toserv up ip 6 route add : 3 : : 1 0 dev toserv SERVIDOR-EXTERNO ip addr add : 3 : : 1 0 dev l o ip tunnel add t o C l i e n t e 2 mode gre t t l 64 remote l o c a l ip l i n k s e t dev t o C l i e n t e 2 up ip 6 route add : 0 : : 2 0 dev t o C l i e n t e 2

98 96 APÊNDICE A. Configurações Utilizadas A.3 Tunnel Broker Cadastro no site Hurricane Electric Para utilizar o serviço de túnel IPv6 da Hurricane Electric é necessário realizaro um cadastro no site Na primeira tela do site, você deverá clicar em Register para ser direcionado à página de cadastro, como pode ser visto nas Figuras 56 e 57. Figura 56 Tela Inicial. Fonte: Figura 57 Tela Cadastro. Fonte:

99 A.3. Tunnel Broker 97 Após o cadastro, basta clicar no botão de Login para ter acesso à página de configuração o túnel. Clique em Create Regular Tunnel, forneça as informações de seu endereço IPv4 e o servidor que deseja se conectar, Figura 58. Logo abaixo clique em Create Tunnel. Figura 58 Criação do túnel. Fonte: Logo após será exibida uma tela contendo as informações do túnel criado, como pode ser verificado na Figura 59. Figura 59 Resumo das configurações do túnel. Fonte:

100 98 APÊNDICE A. Configurações Utilizadas Em Examples Configurations escolha o sistema operacional, logo após será gerado o código cliente para ser implementando em seu computador, Figura 60. Figura 60 Escolha do SO. Fonte: figura 61. Para o nosso exemplo foi escolhido a opção Linux-net-tools, como demonstrado na Figura 61 Informações de configuração do túnel. Fonte: