TESTES DE COMUNICAÇÃO EM IPV6

UNIVERSIDADE FEDERAL DO PARANÁ SETOR DE TECNOLOGIA

DEPARTAMENTO DE ENGENHARIA ELÉTRICA

JOÃO PAULO FERNANDES INAGAKI LUANN HANNS HAMMERLE

TESTES DE COMUNICAÇÃO EM IPV6

Curitiba 2010

JOÃO PAULO FERNANDES INAGAKI LUANN HANNS HAMMERLE

TESTES DE COMUNICAÇÃO EM IPV6

Trabalho de Conclusão de Curso realizado pelos alunos João Paulo Fernandes Inagaki e Luann Hanns Hammerle, orientado pelo Professor Dr. Eduardo Parente Ribeiro, para obtenção de grau no Curso de Engenharia Elétrica da Universidade Federal do Paraná, UFPR.

Curitiba 2010

JOÃO PAULO FERNANDES INAGAKI LUANN HANNS HAMMERLE

TESTES DE COMUNICAÇÃO EM IPV6

Trabalho de Conclusão de Curso aprovado pela Banca Examinadora para obtenção de Grau dos alunos João Paulo Fernandes Inagaki e Luann Hanns Hammerle, no Curso de Engenharia Elétrica da Universidade Federal do Paraná.

BANCA EXAMINADORA

________________________________________

Professor Dr. Eduardo Parente Ribeiro – Orientador

________________________________________

Professor Dr. Evelio Martín García Fernandez

________________________________________

Professor M.Sc. Waldomiro Soares Yuan

Curitiba, 10 de dezembro de 2010.

RESUMO

Este trabalho visa explorar práticas de conectividade utilizando o protocolo de rede IPv6, e estudar a co-existência entre este protocolo e o protocolo em utilização atualmente, o IPv4. É fornecida uma visão geral da implementação do IPv6 no Brasil e no mundo.

São realizados testes de conectividade em ambientes de rede diferentes, capturas de pacotes das duas versões, e também do pacote tunelado. São feitas análises sobre os dados obtidos.

Palavras-chave: IPv4, IPv6, Internet, Transição, 6to4.

ABSTRACT

This paper aims to explore connectivity techniques using IPv6 network protocol, and to study the co-existence between this version of the Internet Protocol and version 4 which is currently in use. A

Connectivity tests are performed in different network environments. Captured packages of both versions, and also the tunneled packet are analyzed.

Keywords: IPv4, IPv6, Internet, Transition, 6to4.

SUMARIO

1. Introdução ... 6

1.1 Motivação ... 6

1.2 Objetivo ... 10

1.3 Estrutura... 10

2. Fundamentação ... 11

2.1 Netkit ... 11

2.2 Packet Tracer ... 11

2.3 Wireshark ... 12

2.4 Comparativo entre IPv4 e IPv6 ... 12

2.5 Tipos de Endereços IPv6 ... 14

2.5.1 Endereços Unicast ... 15

2.5.2 Agregatable Global Unicast Address ... 15

2.5.3 Loopback Address ... 15

2.5.4 Unspecified Address ... 16

2.5.5 Site Local Unicast Address ... 16

2.5.6 Link Local Unicast Address ... 17

2.5.7 Endereços Anycast ... 17

2.5.8 Endereço Multicast ... 17

2.6 Transição e coexistência entre IPv4 e IPv6 ... 18

2.6.1 Pilha Dupla ... 19

2.6.2 Túnel ... 20

2.6.2.1 Túnel configurado ... 21

2.6.2.2 Túnel automático ... 21

2.6.2.3 Tunnel Broker ... 21

2.6.2.4 ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) ... 22

2.6.2.5 Teredo ... 22

2.6.2.6 Tunelamento 6to4 ... 23

2.6.3 Tradução ... 23

2.6.3.1 SIIT (Stateless IP/ICMP Translation Algorithm) ... 23

2.6.3.2 NAT-PT (Network Address Translation - Protocol Translation) ... 23

2.6.3.4 BIS (Bump in the Stack)... 24

2.6.3.5 BIA (Bump in the API) ... 26

2.6.3.5 DNS-ALG (Domain Name Service-Application Layer Gateway) ... 27

2.6.3.6 TRT (Transport Relay Translator) ... 27

2.6.3.7 SOCKS ... 28

2.6.3.8 Classificação dos mecanismos de tradução ... 28

3. Metodologia ... 30

3.1 Testes com o Netkit ... 30

3.2 Testes com o Packet Tracer ... 34

4. Resultados ... 37

4.1 Resultados dos testes com Netkit ... 40

4.2 Resultados dos testes com Packet Tracer ... 46

5. Conclusões ... 48

Referências ... 49

1. INTRODUÇÃO

Hoje, as redes de computadores são imprescindíveis para o modo de vida que predomina na sociedade mundial. Dependemos dessa troca constante de dados para que nossos sistemas bancários funcionem, nossos e-mails circulem, ou até mesmo para que continuemos neste ritmo acelerado de desenvolvimento educacional.

A versão do protocolo IP utilizada atualmente é a versão 4. Segundo Vint Cerf(2010), vice-presidente do Google, os endereços de IP podem acabar em até um ano. Para solucionar essa questão, uma nova versão do protocolo IP já está sendo difundida, a versão 6. Nesta versão o tamanho dos endereços mudarão de 4 bytes para 16 bytes. O número de endereços que o IPv4 pode fornecer é de 2

(pouco mais de 4 bilhões de endereços), enquanto o IPv6 pode fornecer 2

(aproximadamente 3.40282367 × 10

endereços) , o que solucionaria de vez a falta de endereços disponíveis.

1.1 Motivação

A IANA redistribui os números para entidades regionais, que por sua vez, fazem o mesmo para entidades nacionais, ou os designam diretamente para usuários finais. Por exemplo, a IANA assinala um bloco de números para o LACNIC, que é a entidade responsável pela distribuição na América Latina e no Caribe. O LACNIC assinala uma parte desse bloco para o NIC.br, que é o responsável por distribuí-lo no Brasil. Finalmente, o NIC.br designa blocos de endereços IP para os usuários finais ou provedores Internet. Entenda-se então que quando os endereços acabarem no IANA, ainda haverá endereços no LACNIC e no NIC.br, mas esses também se acabarão após 1 ou 2 anos.

Com base nos dados retirados da nro.net foi possível criar um gráfico que

indica a previsão de esgotamento do IPV4. Essa tendência está representada na

Figura 1

Figura 1: Blocos de IPs livres /8 na Iana e tendência de esgotamento.

Atualmente, a maioria dos blocos de endereços IPv4 /8 estão associados ao APNIC. O estado atual da distribuição desses blocos está representada na Figura 2, a seguir.

Figura 2: Distribuição dos blocos de endereços IPv4 /8 entre as entidades regionais.(nro.net)

Outro dado interessante é o que diz respeito ao número de alocações desses blocos, e onde estes estão sendo alocados. Abaixo temos um gráfico do

0 5 10 15 20 25 30 35 40

dez/08 fev/09 abr/09 jun/09 ago/09 out/09 dez/09 fev/10 abr/10 jun/10 ago/10 out/10 dez/10 fev/11 abr/11

Blocos de IPs livres /8

Blocos de IPs livres /8

Polinômio (Blocos de IPs livres /8)

número de alocações IPv4 ao longo dos anos para cada região. Nota-se que a demanda é crescente e não linear.

Figura 3: Total de alocações realizadas, ano a ano, por cada regional.. (nro.net)

Quanto aos endereços IPv6, temos uma representação percentual da distribuição de blocos entre as regiões na Figura 4 a seguir.

Figura 4: Distribuição de blocos IPv6 entre as entidades regionais.(ipv6.br)

Note-se que o LACNIC e o AFRINIC estão muito atrás das outras regiões

em alocações. Quanto à distribuição interna entre os países que são atendidos pelo

LACNIC, temos uma representação na Figura 5 a seguir.

Figura 5: Distribuição de blocos IPv6 entre os países atendidos pelo LACNIC. (ipv6.br)

Outro dado interessante a ressaltar diz respeito ao uso de fato dos endereços alocados. Abaixo temos um gráfico que compara historicamente o número de alocações no total com o número de endereços IPv6 de fato roteados.

Figura 6: Número de alocações em comparação com o número de IPv6 roteados. (ipv6.br)

Podemos observar que o esgotamento dos endereços IPv4 está muito

próxima e que a Internet continua a se expandir de forma acelerada. Isto fará com

que inevitavelmente migremos para a versão 6. Outro ponto a se destacar é que

mesmo que a demanda por endereços IPv4 seja cada vez maior, poucas regiões estão solicitando e uma baixa porcentagem está sendo de fato utilizada.

Especialmente os países representados pelo LACNIC e pelo AFRINIC estão muito atrás em relação resto das regiões, nessa transição iminente e essencial para o contínuo avanço das tecnologias de comunicação.

1.2 Objetivo

O objetivo deste trabalho é testar o funcionamento da comunicação IPv6 e formas de transição entre as versões 6 e 4 do Protocolo de Internet (IP).

1.3 Estrutura

Primeiramente é feita uma contextualização sobre a situação do protocolo de Internet (Internet Protocol), o IP, cuja versão mais utilizada atualmente é a versão 4.

Em seguida é feita uma fundamentação, passando os conceitos necessários sobre

as plataformas de testes utilizadas e uma breve comparação entre as duas versões

do protocolo em análise. Também são conceituadas as possíveis formas de

transição entre os protocolos. Então, são apresentados os testes a serem realizados

e os resultados obtidos, com suas devidas conclusões.

2. FUNDAMENTAÇÃO 2.1 Netkit

Uma das plataformas escolhidas para a realização dos testes é o Netkit.

O software Netkit é um emulador de redes que permite a criação de experimentos de redes de computadores virtuais, incluindo os dispositivos de hardwares necessários para seu suporte como roteadores, servidores, switches, e da criação dos enlaces.

Além do hardware, estes equipamentos virtuais são inicializados com softwares reais que em execução oferecem experiência real ao estudante para a realização de diversos estudos, mesmo que tenha apenas um computador em sua casa.

O Netkit utiliza softwares de código aberto, principalmente licenciados pela GPL, usando em suas máquinas uma variação do kernel Linux chamada UML (User Mode Linux). Para montar uma rede o Netkit usa um conjunto de arquivos de configurações e pastas, que formam um laboratório virtual. Um laboratório também pode ser inicializado através de scripts ou através da linguagem NetML que é uma linguagem baseada em XML para descrição de redes.

Uma máquina virtual iniciada pelo Netkit é um computador completo rodando uma distribuição mono usuário da distribuição Debian GNU/Linux. Para transformar essa máquina num dispositivo específico basta executar o software adequado.(

GURGEL, 2010)

2.2 Packet Tracer

O Packet Tracer é uma aplicação produzida pela Cisco que provê uma simulação virtual de equipamentos e situações da vida real. É muito usado pelo Cisco Net Academy (Programa usado para ensinar o Curriculum Cisco nas escolas de treinamento CCNA). Enquanto o Packet Tracer é comumente usado em ambientes educacionais, muitas empresas usam esta ferramenta, para mapear o layout de sua rede e como base para sua configuração. Com o Packet Tracer você pode visualizar a simulação da rede, tráfego, devices e servidores. Você pode configurar roteadores, switches, wireless access points, servers e dispositivos.

(RAMA, 2008)

2.3 Wireshark

O Wireshark é uma ferramenta (programa) para administradores de redes controlarem o tráfego da rede. Verificação dos pacotes transmitidos pelo dispositivo de comunicação (placa de fax modem, placa de rede, etc.) do computador. Também conhecido como sniffer, detecta problemas de rede, conexões suspeitas, auxilia no desenvolvimento de aplicativos.

O programa analisa o tráfego de pacotes recebidos e organiza-os por protocolo. Todo o tráfego de entrada e saída é analisado e mostrado em uma lista de fácil navegação.(LIBERATO,2008)

2.4 Comparativo entre IPv4 e IPv6

Davies (2004) utiliza um quadro enfocando as diferenças, equivalências e comparações entre IPv4 e IPv6. Este comparativo pode ser encontrado na Tabela 1, a seguir.

IPv4 IPv6

Endereços de origem e destino com 32 bits de comprimento.

Endereços de origem e destino com 128 bits de comprimento.

Representação: notação ponto decimal Representação: notação hexadecimal de dois pontos com supressão de zeros e compressão de zeros.

Representação de redes: mascara de subrede em notação ponto decimal ou comprimento de prefixo (Ex.: /48, /16).

Representação de redes: somente comprimento de prefixo (Ex.: /48, /112).

Suporte a segurança utilizando IPsec (é opcional).

Suporte a segurança utilizando IPsec.

(é requerido.).

Fragmentação feita no host de origem e pelos roteadores intermediários.

Fragmentação não é feita por roteadores, apenas no host de origem.

Inclui verificação de erros no cabeçalho (checksum).

Não inclui verificação de erros no cabeçalho.

Inclui campos opcionais no cabeçalho. Campos opcionais transferidos para os cabeçalhos de extensão.

Utiliza protocolo ARP para descobrir endereços em rede local.

Utiliza um novo protocolo Neighbor Discovery para descobrir endereços em rede local.

Internet Group Management Protocol (IGMP) é usado para gerenciar membros de uma sub-rede.

IGMP foi substituído pelo MULTICAST Listener Discovery (MLD).

ICMP usado para determinar a melhor rota. (é opcional).

ICMP foi substituído pelo ICMPv6.

(é obrigatório).

Utiliza BROADCAST. Utiliza endereços especiais de MULTICAST como forma de efetuar BROADCAST.

Necessita de configuração manual o através de DHCP.

Não requer configuração manual ou DHCP, embora ambos sejam possíveis.

No DNS, utiliza registros de pesquisa do tipo Host (A) para tradução de nomes.

No DNS, utiliza registros de pesquisa do tipo Host (AAAA) para tradução de nomes.

Mapeamento reverso feito através do INADDR- ARPA no DNS.

Mapeamento reverso feito através do IP6.INT no DNS.

Suporta pacotes de 576 bytes (possivelmente fragmentados).

Suporta pacotes de 1280 bytes (sem fragmentação).

Possui Classes de endereçamento de Internet. Não possui classes de endereçamento, ao invés disso, usa uma hierarquia de prefixos.

Endereços MULTICAST (224.0.0.0/4) Endereços MULTICAST IPv6 (FF00::/8) Endereço não definido é 0.0.0.0 Endereço não definido é 0:0:0:0:0:0:0:0 ou ::

Endereços de Loopback (127.0.0.0/8) Endereço de Loopback é 0:0:0:0:0:0:0:1 ou ::1 Endereçamento IP Privado

(10.0.0.0/8,172.16.0.0/12 e 192.168.0.0/16).

Endereços Site-local (FEC0::/48)

Endereços Auto-configurados (169.254.0.0/16). Endereços Link-local (FE80::/64)

Tabela 1: Diferenças, equivalências e comparações entre IPv4 e IPv6. (Davies, 2004)

Davies utiliza ainda outro quadro para demonstrar as diferenças entre os

cabeçalhos do protocolo IPv4 e o IPv6. Este, representado na Tabela 2 a seguir.

Campos do Cabeçalho IPv4 Campos do Cabeçalho IPv6

Version Mesmo campo, porém informa versão diferente.

IHL - Internet Header Length Campo removido no IPv6. O IPv6 não inclui o IHL porque o seu cabeçalho básico é sempre de tamanho fixo, 40 bytes. Cada cabeçalho de extensão também possui tamanho fixo ou seu tamanho é indicado.

TOS - Type of Service Substituído pelo campo Traffic Class - Classe de Tráfego.

Total Length Substituído pelo campo Payload Length, que apenas indica o tamanho do payload.

Identification

Fragmentation Flags Fragment Offset

Campos removidos no IPv6. Informações de fragmentação estão contidos no cabeçalho de extensão correspondente a fragmentação.

TTL - Time to Live Substituído pelo campo Hop Limit.

Protocol Substituído pelo campo Next Header.

Header Checksum Campo removido no IPv6. A detecção de erros é feita para todo o pacote e é executado pela camada de link.

Source Address Mesmo campo, porém com tamanho maior, 128 bits.

Destination Address Mesmo campo, porém com tamanho maior, 128 bits.

Options Campo removido no IPv6. Este campo foi substituído pelos cabeçalhos de extensão.

Tabela 2: Diferenças e equivalências entre o cabeçalho IPv4 e IPv6. (Davies, 2004)

Conforme Comer (1998) destaca, o IPv6 retém muitos dos conceitos básicos do IPv4, porém muda a maioria dos detalhes. Como o IPv4, o IPv6 fornece um serviço de entrega de datagramas baseado na técnica

Entretanto, o formado do datagrama IPv6 é completamente diferente do formato do IPv4. Além disso, o IPv6 fornece novas opções.

2.5 Tipos de Endereços IPv6

Segundo a RFC 2374, uma mesma interface, que utiliza o protocolo IPv6, pode utilizar mais de um endereço, diferentemente do IPv4, onde tal característica só era possível em roteadores. Essa característica é importante porque na versão 6 algumas aplicações, em geral de controle, utilizam-se de endereços especiais que veremos adiante. Para o endereçamento das interfaces existem então 3 tipos de endereços:

 Unicast;

 Anycast;

 Multicast.

Outra característica marcante do IPv6 é que não existem mais os

endereços broadcast, que endereçavam todos os hosts de um mesmo domínio de

colisão, isto é, uma pacote com endereço de destino do tipo broadcast era enviado para todos os hosts de seu domínio de colisão. Com a abolição desse tipo endereço, outro protocolo muito comum no IPv4 também ficou em desuso, o ARP – Address Resolution Protocol, que usava endereços broadcast para descoberta do endereço MAC da interface referente ao endereço de destino do pacote.

2.5.1 Endereços Unicast

Esse tipo de endereço é comumente usado em IPv4, que identifica apenas uma única interface. Desta forma um pacote destinado a um endereço do tipo Unicast é enviado diretamente para a interface associada a esse endereço.

Os tipos de endereços locais mais importantes são os seguintes:

 Agregatable Global Unicast Address

 Loopback Address

 Unspecified Address

 Site-local Unicast Address

 Link-local Unicast Address

2.5.2 Agregatable Global Unicast Address

Esse tipo de endereço unicast é equivalente ao endereço global unicast usado em IPv4. Sendo assim é o endereço que será usado globalmente na Internet. O prefixo utilizado por esse tipo de endereçamento é o

“2000::/3”.

2.5.3 Loopback Address

Esse tipo de endereço, como o próprio nome já diz, é o endereço da própria interface. Porém ele só pode ser usado quando um nó envia um pacote para ele mesmo. No IPv4 esse tipo de endereço era geralmente o 127.0.0.1, em IPv6 é indicado por:

0:0:0:0:0:0:0:1

ou simplesmente:

::1

Esse endereço não pode ser associado a nenhuma interface física, nem como endereço de fonte, nem como endereço de destino, mas pode ser imaginado como sendo de uma interface virtual, a interface loopback. Um pacote IPv6 com endereço destino do tipo loopback address também não deve deixar o próprio host, sendo que esse endereço nunca será repassado por um roteador IPv6.

2.5.4 Unspecified Address

Esse tipo de endereço indica exatamente a ausência de um endereço. Ele nunca deverá ser utilizado como um endereço válido para nenhum host. A sua utilidade é para que estações que ainda não foram inicializadas, sejam identificadas com endereços deste tipo, ou seja, hosts que ainda não tenham aprendido seus próprios endereços globais, utilizem tais endereços para se autoconfigurar. Além disso, esse tipo de endereço não deve ser utilizado como endereço de destino ou em cabeçalho de roteamento de pacotes IPv6. Seu formato é o seguinte:

0:0:0:0:0:0:0:0

ou simplesmente:

::

2.5.5 Site Local Unicast Address

O endereço do tipo Site Local é similar aos endereços privados usados em IPv4, como as redes 10.0.0.0 /8, 172.16.0.0/16 e 198.168.0.0/16. Esses endereços podem ser usados para uma comunicação restrita dentro de um domínio específico.

Este tipo de endereço é identificado pelo

prefixo “FEC0::/10” ou “1111111011” em binário. Este tipo de endereçamento pode ser considerado como privado, visto que ele está restrito a um domínio sem ligação à Internet.

No IPv4 esse tipo de endereço era geralmente o 127.0.0.1, em IPv6 é indicado por:

0:0:0:0:0:0:0:1

2.5.6 Link Local Unicast Address

Este tipo de endereço é automaticamente configurado em

qualquer host IPv6, através da conjugação do seu

prefixo “FE80::/10” ou “1111111010” em binário. Este endereçamento permite também a comunicação entre nós pertencentes ao mesmo enlace. Como nos endereços Site Local, esse tipo de endereço não deve ser enviado como endereço de origem ou destino em pacotes. Além disso esses endereços não são repassados pelos roteadores.

2.5.7 Endereços Anycast

Esse tipo de endereço é utilizado para identificar um grupo de interfaces pertencentes a hosts diferentes. Um pacote destinado a um endereço Anycast é enviado para um das interfaces identificadas pelo endereço. Especificamente, o pacote é enviado para a interface mais próxima, de acordo com o protocolo de roteamento.

Um endereço do tipo Anycast não pode ser utilizado como endereço de origem de um pacote IPv6. Este tipo de endereçamento será útil na detecção rápida de um determinado servidor ou serviço. Por exemplo, poderá ser definido um grupo de servidores de DNS configurados com endereçamento Anycast, assim um host irá alcançar o servidor mais próximo utilizando este tipo de endereço.

Existe um prefixo mais longo desse mesmo endereço para cada endereço Anycast atribuído que identifica a região ao qual todas as interfaces pertencem.

Abaixo, na Figura 7, é mostrada a estrutura básica deste tipo de endereço.

Figura 7: Estrutura básica dos endereços anycast IPv6.(ipv6.br)

2.5.8 Endereço Multicast

Da mesma forma que o endereço Anycast, este endereço identifica um

grupo de interfaces pertencente a diferentes hosts, mas um pacote destinado a um

endereço Multicast é enviado para todas as interfaces que fazem parte deste grupo.

Um endereço do tipo Multicast Address é um endereço IPv6, que é indicado pelo “FF0X::/8”. Dentro dos endereços Multicast já reservados, podemos identificar alguns endereços especiais utilizados para funções específicas. Foi criado uma tabela com base nos principais endereços utilizados, onde estes estão sendo mostrados na tabela abaixo.

Byte X Escopo

X=1 Interface-local

X=2 Link-local

X=5 Site-local

X=E global

Tabela 3: Tipos de escopo de acordo com o Byte X.

2.6 Transição e coexistência entre IPv4 e IPv6

A palavra chave na transição entre as duas versões do protocolo IP é interoperabilidade. As duas versões devem poder permanecer na rede simultaneamente, se comunicando e endereçando. A segunda palavra chave é facilidade. Deve ser fácil se poder fazer um upgrade nos softwares da versão 4 para a 6, tanto para administradores de rede, técnicos, como para o usuário final (SCALABRIN, 2004).

Os objetivos da transição são (SCALABRIN, 2004):

 Roteadores e máquinas devem ter seus programas de rede trocados

sem que todos os outros no mundo tenham que trocar ao mesmo tempo;

 Pré-requisitos mínimos. O único pré-requisito é que os servidores de

DNS (Domain Name System) devem ter a sua versão trocada antes.

Para os roteadores não existem pré-requisitos;

 Quando as máquinas sofrerem o upgrade devem poder manter seus

endereços IPv4, sem a necessidade de muitos planos de um re- endereçamento;

 Custos baixos;

 Nodos IPv6 devem poder se comunicar com outros nodos IPv6,

mesmo que a infra-estrutura entre eles seja IPv4.

Cada mecanismo de transição pode ser classificado como pertencente a uma das seguintes categorias:

 Pilha dupla (dual stack);

 Tunelamento (encapsulation ou tunnel);

 Tradução (translation).

Cada categoria descreve a metodologia básica do mecanismo, já que um mecanismo de transição pode pertencer a mais de uma categoria e, freqüentemente, trabalhar junto com outros mecanismos, assim como sobrepor ou oferecer funções diversas.

2.6.1 Pilha Dupla

Com esse mecanismo, nodos IPv6 devem ter as duas pilhas TCP/IP internamente, a pilha da versão 6 e a da versão 4. Através da versão do protocolo, se decide qual pilha processará o datagrama. Esse mecanismo permite que nodos já atualizados com IPv6 se comuniquem com nodos IPv4, e realizem roteamento de pacotes de nodos que usem somente IPv4.

Contudo, ele tem as seguintes desvantagens: cada máquina precisa ter as duas ilhas rodando separadamente, o que demanda poder de processamento adicional e memória, assim como tabelas de roteamento para os dois protocolos.

Este mecanismo é apresentado nas figuras 8 e 9:

Figura 8: Representação de interoperabilidade com roteador pilha dupla.(SANTOS, E., 2004).

Figura 9: Representação de camadas do fluxo de tratamento em pilha dupla.(JAMHOUR, 2004)

2.6.2 Túnel

Esse mecanismo consiste em transmitir um datagrama IPv6 como parte de dados de um datagrama IPv4, a fim de que dois nodos IPv6 possam se comunicar através de uma rede que só suporte IPv4. A rede IPv4 é vista como um túnel, e o endereço IPv4 do nodo final deste túnel consta como destino do datagrama. Neste nodoo pacote IPv6 volta a trafegar normalmente a seu destino. Esse nodo final, portanto, deve ter a pilha que suporte IPv6. O pacote IPv6, que é transmitido desta forma, é encapsulado em um pacote IPv4, tunelado até o destino, onde é desencapsulado e o pacote original IPv6 encaminhado, conforme mostra Figura 10.

O tunelamento apresenta a seguinte desvantagem: a carga adicional colocada no roteador, já que cada ponto de entrada e de saída precisa de tempo e poder de CPU para encapsular e desencapsular pacotes.

Figura 10: Tunelamento de pacotes IPv6 sobre IPv4. (SANTOS, 2004)

2.6.2.1 Túnel configurado

Túnel configurado é um tunelamento IPv6 sobre IPv4, onde o endereço IPv4 final do túnel é determinado pela configuração da máquina responsável pelo encapsulamento. O nó encapsulado precisa manter informação sobre todos os endereços finais dos túneis. Este tipo de túnel é ponto-a-ponto e precisa de configuração manual.

2.6.2.2 Túnel automático

Pode ser usado somente em comunicações router-to-host e host-to-host, que são esquemas onde qualquer ponto final do túnel também é o receptor dos pacotes. Este tipo de túnel usa endereços IPv6 IPv4-compatible nas extremidades do túnel. Em razão do uso de endereços privados, este túnel funciona somente em tunelamento IPv6 over IPv4, e não o contrário (SANTOS, 2004).

2.6.2.3 Tunnel Broker

A filosofia básica do tunnel broker é permitir a um usuário entrar em contato com o servidor web, opcionalmente entrar com detalhes de autenticação e receber de volta um script para estabelecer um túnel IPv6-in-IPv4 até o servidor tunnel broker.

O provedor de um serviço tunnel broker precisa prover (SANTOS, 2004):

 Servidor de web (disponível sobre IPv4);

 Roteador pilha dupla, capaz de aceitar comandos de setup para criar

novos túneis para clientes finais de túnel.

A operação típica de um serviço tunnel broker é ilustrada na Figura 11 a seguir:

Figura 11: Topologia Tunnel Broker.(SANTOS, 2004)

2.6.2.4 ISATAP (Intra-Site Automatic Tunnel Addressing Protocol)

É uma alternativa ao 6over4, já que conecta máquinas e roteadores IPv6 dentro de redes IPv4, sem introduzir impacto no tamanho da tabela de roteamento e exigir serviços especiais IPv4. Cada máquina precisa de um roteador ISATAP no enlace para obter endereço e informação de roteamento.

Este mecanismo é ilustrado na Figura 12 a seguir.

Figura 12: Topologia ISATAP. (WILLIAMS; OKAJIMA, 2002)

2.6.2.5 Teredo

Teredo provê um mecanismo de transição, que permite a usuários, em umambiente IPv4 NAT com endereçamento privado, obter conectividade IPv6. A idéia básica do Teredo é um nó encapsular pacotes IPv6 em UDP IPv4 e tunelá-los para um servidor Teredo na Internet IPv4. É função deste servidor desencapsular e entregar o pacote IPv6 (SANTOS, 2004).

A Figura 13 a seguir ilustra este mecanismo.

Figura 13: Topologia Túnel Teredo. (DOYLE, 2003)

2.6.2.6 Tunelamento 6to4

O mecanismo 6to4 é uma forma de tunelamento roteador-a-roteador, que permite a comunicação entre hosts IPv6 através de uma infra-estrutura IPv4. O 6to4 fornece um endereço IPv6 único, formado pelo prefixo de endereço global “2002:wwxx:yyzz::/48”, onde “wwxx:yyzz” é o endereço IPv4 público do host convertido para hexadecimal. De uma forma geral, o host IPv6 envia um pacote IPv6 ao roteador 6to4, que o encapsula em um pacote IPv4 utilizando o protocolo do tipo 41, e o encaminha ao host de destino IPv6 através de uma rede IPv4. (ipv6.br)

2.6.3 Tradução

É necessário que haja uma máquina IPv4/IPv6 que interaja com as máquinas que desejam estabelecer comunicação, traduzindo os pacotes IPv4 em IPv6 e vice-versa.

Esse mecanismo apresenta as seguintes falhas: não suporta características avançadas de IPv6 como segurança fim-a-fim e impõe limitações à topologia da rede, pois as respostas de qualquer mensagem enviada pelo roteador de tradução devem retornar para o mesmo roteador de tradução.

2.6.3.1 SIIT (Stateless IP/ICMP Translation Algorithm)

O mecanismo de tradução SIIT usa um tradutor localizado na camada de rede da pilha de protocolos e funciona traduzindo cabeçalhos de datagramas IPv4 em cabeçalhos de datagramas IPv6 e vice-versa.

2.6.3.2 NAT-PT (Network Address Translation - Protocol Translation)

É um serviço que permite às máquinas IPv6 e suas aplicações nativas se

comunicarem com máquinas IPv4 e suas aplicações, ou vice-versa. Ele possui uma

combinação de tradução de cabeçalho e conversão de endereço. A tradução do

cabeçalho é necessária para converter o cabeçalho IPv4 no formato do cabeçalho

IPv6 e vice-versa. O resultado é um novo cabeçalho, que é semanticamente

equivalente ao cabeçalho original, porém não é igual. A conversão do endereço é útil

para máquinas da rede IPv4 saberem identificar as máquinas da rede IPv6, através

de endereços de sua própria rede, sendo que o contrário também ocorre (SANTOS,

2004). NAT-PT usa um conjunto de endereços, que são dinamicamente designados para datagramas traduzidos.

Para tanto, é utilizado um gateway de tradução de protocolo, cuja funcionalidade garante a transparência ao nível da camada de rede.

Sua idéia é bem similar à realizada com NAT nas redes IPv4. A rede IPv6 ficaria do lado de fora, enquanto que a rede IPv4 ficaria na rede interna. A interface externa desta firewall ficaria com um endereço IPv6 válido, enquanto que a interna ficaria com endereço IPv4. Na firewall ficaria uma tabela relacionando um endereço IPv6 para cada endereço IPv4 existente na rede interna - desta maneira seria possível mapear todas as estações que trabalhem com IPv4. A tarefa desta firewall não seria simplesmente repassar os endereços IPv6 que chegam para os IPv4 que estão no outro lado, mas convertê-los para este protocolo. O caminho inverso aconteceria também quando os pacotes requisitados retornassem.

Este tipo de solução se mostrará extremamente útil no caso de aplicações com dificuldades se serem convertidas para o novo protocolo, ou então no caso de aplicações críticas, que necessitem de mais tempo para serem adaptadas e devidamente testadas.

A Figura 14 a seguir ilustra este mecanismo.

Figura 14: Topologia NAT-PT. (SANTOS, 2004)

2.6.3.3 BIS (Bump in the Stack)

É um mecanismo de tradução, similar ao NAT-PT combinado com o SIIT,

implementado na pilha de protocolos do sistema operacional, assumindo uma

estrutura de rede IPv6.

Seu mecanismo é baseado na pilha dupla, com a adição de três módulos (SANTOS, 2004):

 Translator: traduz cabeçalhos IPv4 saintes em cabeçalhos IPv6 e

cabeçalhos entrantes IPv6 em cabeçalhos IPv4;

 Extension name resolver: monitora as perguntas IPv4 de DNS, com o

objetivo de criar novas perguntas para resolver registros A e AAAA, enviando o registro A retornado para a aplicação IPv4. Se apenas o registro AAAA é retornado, o resolver pede ao address mapper para designar um endereço IPv4 correspondente ao endereço IPv6;

 Address mapper: mantém um pool de endereços IPv4 e as

associações entre endereços IPv4 e IPv6. Ele designará um endereço quando o translator receber um pacote IPv6 da rede para o qual não existe entrada mapeada para o endereço origem. Já que os endereços IPv4 nunca são transmitidos na rede, eles não precisam ser endereços válidos, podendo usar um pool de endereços privados.

A Figura 15 ilustra este mecanismo.

Figura 15: Address mapper. (SANTOS, E., 2004)

As limitações deste mecanismo são:

 Permite comunicação de IPv4 para máquinas IPv6, porém não o

contrário, já que não envia tampouco recebe pacotes IPv4 na rede;

 Mesmo que uma aplicação IPv4 tente se comunicar com outra

aplicação IPv4 usando BIS, isto não será possível sem mecanismos adicionais de tradução em algum lugar entre as duas aplicações;

 Não funciona para comunicações multicast.

2.6.3.4 BIA (Bump in the API)

Este mecanismo insere um tradutor API entre o socket API e os módulos TCP/IP da pilha da máquina. Desta forma, as funções do socket API IPv4 são traduzidas em funções do socket API IPv6, e vice-versa. BIA também é baseado na adição de três módulos (SANTOS, 2004):

 Extension name resolver: monitora as perguntas IPv4 de DNS, com o

objetivo de criar novas perguntas para resolver registros A e AAAA, enviando o registro A retornado para a aplicação IPv4. Se apenas o registro AAAA é retornado, o resolver pede ao address mapper para designar um endereço IPv4 correspondente ao endereço IPv6;

 Function mapper: mapeia chamadas de socket IPv4 em chamadas de

socket IPv6 e vice-versa. Ele intercepta as chamadas de funções socket API IPv4 e invoca as correspondentes chamadas de funções socket API IPv6;

 Address mapper: mantém um pool de endereços IPv4 e as

associações entre endereços IPv4 e IPv6. Ele designará um endereço quando o translator receber um pacote IPv6 da rede para o qual não existe entrada mapeada para o endereço origem. Já que os endereços IPv4 nunca são transmitidos na rede, eles não precisam ser endereços válidos, podendo usar um pool de endereços privados.

O mecanismo BIA é desenvolvido para sistemas que tem uma pilha IPv6, contudo não tem aplicações que foram atualizadas para IPv6.

A Figura 16 ilustra este mecanismo.

Figura 16: Mecanismo BIA. (SANTOS, 2004)

As vantagens deste mecanismo sobre BIS são:

 Ser independente do driver da interface de rede;

 Não introduzir overhead na tradução dos cabeçalhos dos pacotes.

Entretanto, ele apresenta limitações similares ao BIS, como não suporta comunicações multicast.

2.6.3.5 DNS-ALG (Domain Name Service-Application Layer Gateway)

Trabalha como um proxy HTTP, onde o cliente primeiramente inicia a conexão com o ALG, que, então, estabelece uma conexão com o servidor, retransmitindo as requisições de saída e os dados de entrada. Em redes apenas IPv6, o ALG habilita a comunicação dos hosts com serviços em redes apenas IPv4, configurando o ALG em nós com pilha dupla. Este tipo de mecanismo e normalmente utilizado quando o host que deseja acessar a aplicação no servidor IPv4, está atrás de NAT ou de um firewall.

2.6.3.6 TRT (Transport Relay Translator)

Permite que máquinas IPv6-only troquem tráfego com máquinas IPv4-only.

Um TRT que roda em uma máquina pilha dupla pode usar um protocolo quando se comunicar com o cliente e usar outro protocolo quando se comunicar com o servidor da aplicação.

A tradução em TCP inclui recalcular o checksum, manter estado necessário

sobre qual cliente está conectado com qual socket do servidor e remover este

estado quando o cliente finalizar a comunicação. A tradução em UDP inclui recalcular o checksum também, pois em IPv6 é obrigatório, porém em IPv4 é opcional.

A Figura 17 a seguir ilustra este mecanismo.

Figura 17: Topologia TRT. (SANTOS, 2004)

2.6.3.7 SOCKS

É um transport relay, referenciado como um protocolo proxy para ambiente cliente/servidor. Permite a duas máquinas, cliente e servidor, estabelecerem conexões TCP e UDP via um proxy, denominado Socks Server.

Quando um cliente deseja se conectar a um servidor de aplicação, ele primeiro configura uma conexão com um servidor proxy, usando um protocolo Proxy especial. O cliente informa ao proxy o endereço IP e o número da porta do servidor de aplicação com quem ele deseja se comunicar. O servidor proxy agora é responsável por configurar uma conexão com o servidor de aplicação.

2.6.3.8 Classificação dos mecanismos de tradução

Os mecanismos de tradução podem ser distribuídos conforme abaixo (SANTOS, 2004):

 Tradução (rede) - é o método de tradução, que ocorre na camada de

rede. Os mecanismos, que fazem parte desta classe são SIIT, NAT- PT e NAPT-PT;

 Tradução (transporte) - é o método de tradução, que ocorre na

camada de transporte. Os mecanismos, que integram esta classe,

são TRT e SOCKS;

 Tradução (aplicação) - é o método de tradução, que ocorre na

camada de aplicação. O mecanismo, que constitui esta classe, é o ALG;

 Tradução (camada adicional) - é o método de tradução, que recebe a

adição de uma nova camada na pilha de protocolos. Os mecanismos,

que fazem parte desta classe, são BIS e BIA.

3. METODOLOGIA

O primeiro passo para estabelecer uma plataforma de testes seria o estabelecimento de comunicação simples IPv4. Em seguida a implementação do IPv6. E então a inserção de mais elementos de rede para testarmos o roteamento e o tunelamento.

Dessa forma, para familiarização com o protocolo será estabelecida e testada uma rede IPv4. E em seguida habilitado o protocolo IPv6. Serão utilizados dois computadores com sistema operacional LINUX com a distribuição Ubuntu. Os primeiros testes a serem realizados focam a comunicação com os endereços de links locais. Essa forma de comunicação é mais conhecida como pilha dupla, pois pode processar as duas versões dos IP.

3.1 Testes com o Netkit

Logo após este teste, o objetivo será testar uma das formas de tunelamento, como a mais conhecida e prática (devida ao menor processamento) seria a técnica de tunelamento “6to4”, escolheu-se realizar testes com esse modelo de transição.

Como haverá acesso à roteadores, escolheu-se implementar o tunelamento em máquinas virtuais com o Netkit.

Para instalar o Netkit primeiramente deve-se fazer o download e descompactar os arquivos, Netkit, kernel e filesystem.

Para isso será utilizado o comando “wget” nos host com LINUX para efetuar o download, como segue os comandos abaixo:

user@host:~$ wget http://www.netkit.org/download/netkit/netkit- 2.6.tar.bz2

user@host:~$ wget http://www.netkit.org/download/netkit- filesystem/netkitfilesystem-F4.0.tar.bz2

user@host:~$ wget http://www.netkit.org/download/netkit- kernel/netkit-kernel-K2.5.tar.bz2

Depois será utilizado o comando “tar jxvf” para descompactar os arquivos:

user@host:~$ tar jxvf netkit-2.6.tar.bz2

user@host:~$ tar jxvf netkit-filesystem-F4.0.tar.bz2 user@host:~$ tar jxvf netkit-kernel-K2.5.tar.bz2

Depois disso devemos criar variáveis de ambiente apropriadas (editando

“.bashrc” por exemplo) com os comandos a seguir:

export NETKIT_HOME=/home/user/netkit export MANPATH=:/home/user/netkit/man export PATH=/home/user/netkit/bin:$PATH

Podemos testar se a instalação foi corretamente executada, acessando o diretório do Netkit e rodando o seguinte comando:

./check_configuration.sh

Se tudo estiver corretamente instalado, a tela do host deverá estar conforme a Figura 18.

Figura 18: Resultado esperado do comando “check configuration”.

Depois de instalado o Netkit, devemos criar as máquinas virtuais. Iremos criar três máquinas virtuais, duas para os computadores que irão se comunicar e uma para atuar como roteador entre os dois computadores.

Será criada uma máquina virtual chamada “virtual1”, com uma placa de rede

“eth0”, ligada ao domínio de colisão “A”, para isso realizamos o seguinte comando:

user@host:~$ vstart virtual1 --eth0=A

Feito isso será criada outra máquina virtual chamada “virtual2”, com uma placa de rede “eth0”, ligada ao domínio de colisão “B”, utilizando-se o seguinte comando:

user@host:~$ vstart virtual2 –-eth0=B

Então, será criada uma máquina virtual que terá a função de roteador, ligando os dois domínios de colisão, com o seguinte comando:

user@host:~$ vstart vrouter –-eth0=A --eth1=B

Cada máquina virtual usa inicialmente 16M de memória (um pouco mais no host) e um disco virtual de aproximadamente 1Gb.

Depois que as máquinas virtuais forem criadas, devemos configurar as máquinas e o roteador para testar a comunicação do tunelamento 6to4. A Figura 19 a seguir ilustra o laboratório prático que iremos testar.

Figura 19: Topologia para testes em tunelamento 6to4.

O host “virtual1”, na Figura19 representado por “PC1”, será configurado com os comandos a seguir:

ifconfig eth0 10.0.0.10 netmask 255.255.255.0 route add default gw 10.0.0.1

O host “virtual2”, que na Figura 19 está representado como “PC2”, será configurado da mesma forma, mas com os IPs diferentes:

ifconfig eth0 10.0.1.10 netmask 255.255.255.0 route add default gw 10.0.1.1

E no PC3, que é o roteador, serão configuradas as 2 interfaces “eth0” e a

“eth1”.

ifconfig eth0 10.0.0.1 netmask 255.255.255.0 ifconfig eth1 10.0.1.1 netmask 255.255.255.0

Depois que as máquinas virtuais estiverem configuradas, poderemos testar a conectividade em ipv4. Será testada a conectividade em IPv6, e para isso precisamos configurar o PC1 e o PC2 para ser possível essa comunicação.

O PC1 será configurado da seguinte forma:

modprobe ipv6

sysctl -w net.ipv6.conf.default.forwarding=1 mcedit /etc/network/interfaces

auto sit0

iface sit0 inet6 static address 2002:0a00:000a::1 netmask 16

ifup sit0

Com esses comandos, habilitamos a pilha dupla e criamos uma interface virtual 6to4. No PC2 iremos realizar o mesmo procedimento do PC1, mas no campo do endereço iremos alterar para o seguinte IP: “2002:0a00:010a::1”.

Feito isso, poderemos testar a conectividade em IPv6, tanto para o endereço

pilha dupla quanto para o endereço de tunelamento.

3.2 Testes com o Packet Tracer

Outro teste a ser realizado será uma comparação entre os protocolos IPv4 e IPv6. Uma mesma topologia de rede será montada duas vezes no ambiente de testes Packet Tracer. Então, serão configurados os protocolos paralelamente, uma em cada topologia. Utilizando o mesmo tipo de roteamento (RIP) para ambos, podemos ter uma medida do desempenho e conectividade.

Na Figura 20 segue uma ilustração das topologias montadas:

Figura 20: Topologia para testes no Packet Tracer.

Os comandos a serem inseridos nos dispositivos para testar a versão 6 são os seguintes.

No roteador R1:

Enable

Configure terminal ipv6 unicast-routing interface FastEthernet0/0

ipv6 address 2001:12:12:12:12:12:12:1/112 ipv6 rip LAB enable

ipv6 router rip LAB end

No roteador R2:

Enable

Configure terminal ipv6 unicast-routing ipv6 rip LAB enable

interface FastEthernet0/0

ipv6 address 2001:12:12:12:12:12:12:2/112 ipv6 rip LAB enable

interface FastEthernet0/1

ipv6 address 2001:23:23:23:23:23:23:2/112 ipv6 rip LAB enable

ipv6 router rip LAB end

No roteador R3:

Enable

Configure terminal pv6 unicast-routing

interface FastEthernet0/0

ipv6 address 2001:23:23:23:23:23:23:3/112 ipv6 rip LAB enable

ipv6 router rip LAB end

Os comandos a serem inseridos nos dispositivos para testar a versão 4 são os seguintes.

No roteador R1:

Enable

Configure terminal

interface FastEthernet0/0

ip address 192.168.0.1 255.255.255.0 exit

router rip

network 192.168.0.0 end

No roteador R2:

Enable

Configure terminal

interface FastEthernet0/0

ip address 192.168.0.1 255.255.255.0 exit

interface FastEthernet0/1 ip address 10.0.0.1 255.0.0.0 exit

router rip

network 192.168.0.0 network 10.0.0.0 end

No roteador R1:

Enable

Configure terminal

interface FastEthernet0/0

ip address 10.0.0.2 255.255.255.0 exit

router rip

network 10.0.0.0 end

Então, estaremos aptos a verificar as duas versões do protocolo em uma

mesma plataforma, com os mesmos equipamentos.

4. RESULTADOS

Como descrito anteriormente, o primeiro objetivo seria estabelecer comunicação entre dois hosts. Utilizando dois computadores conectados em uma LAN foram realizados testes com o aplicativo “ping” e medidos os resultados com o aplicativo de monitoramento de interfaces “Wireshark”, além da obtenção da resposta do próprio “ping”.

Neste primeiro teste, foi utilizado o comando ping para o computador com o IP 200.17.220.102. O resultado foi como esperado, logo após o ping no host de destino recebemos 4 confirmações de que os pacotes chegaram ao destino, como mostra a figura 21.

Figura 21: Resultado dos testes com “Ping”.

Em seguida, verificamos a configuração do protocolo IPv6 nos dois computadores, utilizando do aplicativo „ping6‟, e testamos a conectividade IPv6.

No início deste procedimento, surgiram complicações quanto ao uso do

aplicativo „ping6‟. Aparentemente alguns sistemas confundem-se se não

especificada a interface pela qual serão enviados os pacotes, mesmo que haja

apenas uma interface instalada no computador. Foi necessário para tanto especificar a interface.

O comando utilizado ficou então da seguinte forma:

Ping6 –I <interface> <ip da máquina de destino>

Da mesma maneira que realizamos o teste com o ping em IPv4 na figura 21, realizamos esse procedimento novamente mas agora com o protocolo versão 6. O resultado foi exatamente o que tínhamos obtido no teste anterior, ou seja, 100% dos pacotes enviados foram recebidos pelo host de destino, exatamente o que estamos esperando. A figura 22 mostra o envio de pacotes ICMP para o host de destino fe80::20c:6eff:fe29:e2ad.

Figura 22: Resultados dos testes com “Ping6”.

O desvio padrão dos pacotes dos protocolos da versão 6 e da versão 4 foram desprezíveis. O tempo de envio dos pacotes nas duas versões foram próximos, como esperado, pois como os dois hosts estão na mesma rede não há roteamento de pacotes fazendo com que os tempos sejam próximos um do outro.

Para uma melhor compreensão e análise, foram capturados os detalhes dos pacotes IPv4 e IPv6 no Wireshark. As Figuras 23 e 24 a seguir representam essa captura.

Figura 23: Detalhe do pacote IPv6 no Wireshark.

Na figura 23 podemos observar que foi estabelecida uma comunicação IPv6,

devido ao protocolo utilizado ser o ICMPv6. Podemos notar também que o host de

origem está enviando um pacote de Echo request para o host de destino e esse está

encaminhando um pacote de Echo reply.

Figura 24: Detalhe do pacote IPv4 no Wireshark.

A mesma comunicação está ocorrendo na figura 24, com exceção que o protocolo utilizado é o ICMPv4.

No pacote IPv4 podemos perceber que o cabeçalho é de 20 bytes, começando do hexadecimal 0E indo até o 21 (na parte inferior da Figura 24), Enquanto que o do ipv6 é de 40 bytes, começando do 0E indo até o 36.

Apesar do pacote IPv6 ser maior que o pacote IPv4 ele é roteador mais rápido por ter menos campos de verificação.

4.1 Resultados dos testes com Netkit

O próximo passo então foram os testes com o Netkit. Utilizando duas máquinas virtuais e um roteador nesta plataforma, fizemos uma topologia com dois domínios de broadcast.

Como explicitado anteriormente, com o Netkit testou-se o tipo de

encapsulamento 6to4. A configuração dos computadores e do roteador, conforme

metodologia, para estes testes está mostrada na Figura 25.

Figura 25: Configuração das interfaces para testes 6to4 no Netkit.

Então configurados os dois computadores em IPv4 e IPv6 e a interface Sit 6to4, o primeiro teste foi sobre conectividade IPv4.

Os resultados desta primeira etapa com o Netkit foram satisfatórios, pois

todos os pacotes ICMP enviados pela virtual1 chegaram ao destino. E o vrouter está

monitorando todos os pacotes que são roteados por ele. Esses resultados estão

ilustrados na Figura 26 a seguir.

Figura 26: Resultados com ping IPv4.

Então, foram testadas as conectividades em IPv6 dentro dos domínios de

broadcast, efetuando um ping a partir do host direcionado ao seu gateway no

roteador. O resultado foi positivo, conforme podemos observar na Figura 27.

Figura 27: Resultados com ping6 dentro do domínio de broadcast.

E em seguida a conectividade em IPv6 de um

portanto pelos dois domínios de broadcast. Como podemos observar, não obtivemos conectividade neste modo, pois estavam configurados nos

domínio de link local (pacotes com este tipo de endereço na origem são descartados ao chegarem no roteador), além das características do roteador utilizado. Uma ilustração desta tentativa pode ser observada na Figura 28, no detalhe da máquina

“virtual1”.

Figura 28: Tentativa de ping6 através dos domínios de broadcast.

E para finalizar, testamos a conectividade de um host ao outro porém agora utilizando-se da técnica 6to4. Neste caso foi possível um resultado positivo, devido à abertura de um “túnel” de um host ao outro e da característica do roteador utilizado.

Podemos observar esse sucesso na Figura 29, no detalhe da “virtual1”.

Figura 29: Testes com ping6 utilizando encapsulamento 6to4.

Como esperado os pacotes enviados e recebidos estão na versão 4.

Podemos verificar isso no vrouter e na virtual1, onde com o comando tcpdump –x foi possível verificar os bytes dos pacotes que estavam trafegando na rede, pois o primeiro bit do pacote indica o número do protocolo que está sendo usado, ou seja, no nosso caso a versão 4.Tentamos utilizar endereços válidos nos dispositivos finais, com prefixo “2000::”, para tentarmos a comunicação puramente ipv6. Mas como previsto esses pacotes não foram roteados. Pois o roteador 6to4, o qual estávamos utilizando, não possuia como gateway um relay 6to4.

O relay 6to4 é responsável por rotear pacotes 6to4 endereçados por roteadores para a rede ipv6 nativa.

Como pudemos observar, o tunelamento funciona da seguinte maneira: o

host de origem cria um cabeçalho IPv4 com o pacote IPv6 encapsulado e o

transmite através da rede IPv4. Quando esse pacote chega ao roteador 6to4 ele

desencapsula o pacote e verifica se o endereço de destino é para um endereço 6to4

(2002::), se possuir ele o encapsula novamente e encaminha o pacote para o

destino final, caso não possua esse pacote é descartado, a não ser que o gateway

desse roteador seja um relay. Depois que o pacote chega no host de destino o pacote é desencapsulado, retira o cabeçalho IPv4 e processa o pacote IPv6 recebido.

Este processo de encapsulamento, conhecido como 6in4, é identificado como protocolo do tipo 41 e sua utilização é comum em algumas técnicas de tunelamento, como 6to4, ISATAP e Tunnel Broker. (ipv6.br)

A estrutura de pacote IPv6 encapsulado em IPv4 é representada na Figura 30 a seguir.

Figura 30: Estrutura de um pacote IPv4 encapsulado em IPv4.

Deste modo, o processo de desencapsulamento torna-se muito simples.

Quando o pacote chega na saída do túnel (endereço IPv4 de destino), é verificado que ele utiliza protocolo do tipo 41 (6in4), então remove-se o cabeçalho IPv4, restando apenas o pacote IPv6, o qual é enviado para processamento na camada IPv6 e conseqüentemente encaminhado ao destinatário IPv6. (ipv6.br)

4.2 Resultados dos testes com Packet Tracer

Já na plataforma de testes montada no Packet Tracer, conforme explicitado

anteriormente, foram testados as duas versões do protocolo sendo roteadas de

forma nativa. Na Figura 31 a seguir seguem os resultados com ping em protocolo

IPv4. E na Figura 32 os resultados com ping em protocolo IPv6.

Figura 31: Resultados de ping em IPv4.

Figura 32: Resultados de ping em IPv6.

Como podemos observar, em ambas configurações obtivemos resultados

positivos quanto a conectividade. Todos os pacotes enviados foram recebidos. E o

tempo de roteamento do pacote IPv6 mostrou-se inferior ao do pacote IPv4.

5. Conclusões

Nesse trabalho foi testado o funcionamento da comunicação IPv6, além das técnicas de transição existentes.

As técnicas de transição entre IPv4 e IPv6 configuram-se em casos um tanto quanto distintos e na maioria das técnicas há uma dificuldade de configurar equipamentos para a realização dos testes.

A técnica de transição 6to4 mostrou-se bastante simples, de fácil implementação, não possuindo muitos requerimentos.

Quanto a latência, nos testes realizados no netkit, o protocolo IPv6 mostrou um tempo inferior ao IPv4 quando os hosts de origem e destino estavam em domínios de colisão distintos. Já quando os hosts de origem e destino estiverem no mesmo domínio de colisão não houve diferença de latência entre os dois protocolos.

Quanto à facilidade de configuração do IPv6 em dispositivos finais (hosts), este protocolo mostrou um bom desempenho. Todos sistemas operacionais utilizados neste trabalho possuíam uma pré-configuração e suporte a esse protocolo, adotando um modelo de pilha dupla. No entanto, houve uma grande dificuldade em encontrar, até mesmo para testes em dispositivos virtuais, equipamento intermediários de rede (roteadores e relays) que trabalham com esta versão do protocolo.

Concluímos que, apesar da urgência alardeada em disseminar esse novo

protocolo, e apesar das melhorias observadas, os dispositivos intermediários de

rede ainda impõem um grande desafio para seu total estabelecimento.

REFERÊNCIAS

CERF, Vint. 2010. Google vice-president issues stark internet warning: Disponível em:

<http://www.guardian.co.uk/technology/2010/nov/11/google-vint-cerf-internet>. Acessado em 12/11/2010.

DAVIES, Joseph. Introduction to IP version 6. Microsoft Corporation: 2004. Disponível em

<www.microsoft.com/windowsserver2003/technologies/ipv6/introipv6.mspx> Acessado em 15/10/2010.

DOYLE, J. Issues in IPv6 Deployment, 2003. Disponível em <http://www.nanog.org/mtg- 0306/pdf/doyle.ppt> Acessado em 02/05/05.

GOMES, Alexandre J. K.; TRINDADE, Carlos B. de 2009. Melhores práticas de migração de uma rede IPv4 e IPv6. Brasília.

GURGEL, Paulo H. M. 2010 Introdução ao Netkit. Disponível em:

<www.paulogurgel.com.br/instalacao.pdf>. Acessado em 25/11/2010.

KUROSE, James F. 2006 Redes de Computadores e Internet: uma abordagem top-down. 3ª Ed.

São Paulo: Pearson Addison Wesley.

LIBERATO, Taiz. Tecnologia em Gerenciamento de Redes de Computadores. Disponível em:

<http://artigos.netsaber.com.br/resumo_artigo_16247/artigo_sobre_wireshark>. Acessado em 13/11/2010.

MOREIRAS, Antonio M. Emulação de redes IPv6. Disponível em:

<http://www.ipv6.br/IPV6/ArtigoEmulacaoderedesIPv6>. Acessado em 23/10/2010.

NRO. IPv6 Statistics. Disponível em: <www.nro.net/statistics >. Acessado em: 20/10/2010.

RAMA, Mario A. Packet Tracer 4/4.1. Disponível em:

<http://livros.marionunes.co.cc/2008_10_01_archive.html>. Acessado em 25/11/2010.

SANTOS, E. 2004. IPv6 Mecanismos de coexistência e transição. Disponível em <http://www.

vsix.net/other/summit/Brazil2004/www.ipv6summit.com.br/en/index.html>. Acessado em 12/01/2005.

SANTOS, Rodrigo R. 2008 Estatísticas sobre IPv6. Disponível em:

<http://www.ipv6.br/IPV6/ArtigoEstatisticaIPv6. Acessado em 03/11/2010.

SANTOS, Rodrigo R. 2008 Técnicas de Transição. Disponível em:

<http://www.ipv6.br/IPV6/ArtigoTecnicasTransicao>. Acessado em 23/10/2010.

SANTOS, Rodrigo R. ROCHA, Ailton S.2008 Túneis 6to4. Disponível em:

<http://www.ipv6.br/IPV6/ArtigoTuneis6to4>. Acessado em 23/10/2010.

WILLIAMS, C. E.; OKAJIMA, I. IPv6 and Wireless Networks, 2002. Disponível em

<http://www.leearmstrong.com/DSRC%20Home/General%20Info/Internet%20protocol%20info/IP V6/02-IPv6-tutorial-part2-transition.ppt> Acessado em 09/05/2005.