Upload
others
View
8
Download
0
Embed Size (px)
Citation preview
0
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
1
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
2
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.
3
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.
4
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. An overview of the implementation of
IPv6 in Brazil and worldwide is provided.
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.
5
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
6
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 232
(pouco mais de 4 bilhões de endereços), enquanto o IPv6 pode fornecer 2128
(aproximadamente 3.40282367 × 1038 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
7
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
ou
t/0
9
dez
/09
fev/
10
abr/
10
jun
/10
ago
/10
ou
t/1
0
dez
/10
fev/
11
abr/
11
Blocos de IPs livres /8
Blocos de IPslivres /8
Polinômio(Blocos deIPs livres /8)
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.
9
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
10
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.
11
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)
12
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.
13
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.
14
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 best-effort, sem conexão.
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
15
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
16
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
17
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.
18
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.
19
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).
20
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)
21
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)
22
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)
23
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,
24
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.
25
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;
26
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.
27
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
28
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;
29
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.
30
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
31
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:
32
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.
33
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.
34
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
35
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
36
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.
37
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
38
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”.
39
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.
40
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.
41
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.
42
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.
43
Figura 27: Resultados com ping6 dentro do domínio de broadcast.
E em seguida a conectividade em IPv6 de um host ao outro, passando
portanto pelos dois domínios de broadcast. Como podemos observar, não obtivemos
conectividade neste modo, pois estavam configurados nos host endereços do
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”.
44
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”.
45
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
46
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.
47
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.
48
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.
49
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/IPV6/02-IPv6-tutorial-part2-transition.ppt> Acessado em 09/05/2005.