2015 JuvenaldosSantosBarreto

Universidade de Braslia
Instituto de Cincias Exatas

Departamento de Cincia da Computao
Um Modelo de Migrao de Ambiente IPv4 para IPv6

em uma Rede Acadmica Heterognea
Juvenal dos Santos Barreto
Dissertao apresentada como requisito parcial
para concluso do Mestrado Prossional em Computao Aplicada
Orientadora
a a
Prof. Dr. Priscila Amrica Solis Mendez Barreto
Braslia
2015
B268m Barreto, Juvenal dos Santos.
Um Modelo de Migrao de Ambiente IPv4 para IPv6 em uma
Rede Acadmica Heterognea / Juvenal dos Santos Barreto ;
orientador Priscila Amrica Solis Mendez Barreto. -- Braslia,
2015.
145 p.
Dissertao (Mestrado Mestrado Profissional em

Computao Aplicada) Universidade de Braslia, 2015
1. Interconexo de redes. 2. Migrao de IPv4 para Ipv6. 3.

Pilha Dupla. 4. Redes Locais. 5. IPv6. I. Barreto, Priscila Amrica
Solis Mendez, orient. II. Ttulo.
CDU 004.738
Dissertao apresentada como requisito parcial
para concluso do Mestrado Profissional em Computao Aplicada
Dedicatria
Este trabalho dedicado a minha famlia: minha me Helenita dos Santos Barreto,
em memria do meu pai Aloisio Barreto, aos irmos Ana Claudia, Carlos Luis, Humberto
Lcio e Neila Carla pelo amor incondicional dispensado a mim, e ainda por todo o esforo
e dedicao dispensados desde a infncia para que eu pudesse ter uma formao na qual
me realizasse prossionalmente e pessoalmente.
iv
Agradecimentos
A Deus, por todas as conquistas obtidas, por me dar fora pra superar os obstculos
na vida, enfrentando minhas fraquezas e inseguranas.
A todos os professores do Mestrado Prossionalizante em Computao Aplicada, em
especial, aos professores Marcelo Ladeira e Jacir Bordim pelo permanente apoio, e no
diferente minha orientadora, professora Priscila Solis, que me deu importantssimo sub-
sdio no desenvolvimento do estudo em questo e por ter acreditado na minha vontade de
realizar este trabalho e na conana demonstrada durante toda a pesquisa.
A todos os colegas do curso, em especial ao Andrei, Arthur, Antonio, Eduardo, Jack-
son, Jobe, Karam e Riane, pelo constante companheirismo.
Aos colegas de trabalho Alex Fidelis, Alessandro Caldeira, Alessandro Cordeiro, Anto-
nio Vasconcelos, Claudio Garcia, Claudio Xavier, Domingos Costa, Erasmo Losi, Erivando,
Fernando Brito, Justino Mendona, Hugo Chaves, Ivan Viotti, Luiz Capdeville, Maurcio
Hiroaki, Samuel Oliveira e Vincius Cesrio, pela compreenso em momentos de presses
intensas e contribuies pelo zelo s funes conadas.
Aos meus amigos Pricles Amador, Fabrcio Gonalves, Bruno Cardoso, Edson Roxo
e outros aqui no mencionados, e a prima Eliene Santos, pelas constantes palavras de
motivao e compartilhamento de bons momentos.
Enm, a todos que contriburam diretamente ou indiretamente neste trabalho com
simples apoios e incentivos.
v
Resumo
A crescente demanda por informaes e, particularmente, o aumento exponencial de
redes conectadas Internet, faz com que as instituies tenham que modernizar suas
infraestruturas frequentemente. A sensvel limitao do endereamento disponvel desta
rede contribui para que essas instituies estudem a implantao da nova verso do pro-
tocolo da Internet, o IPv6. A Universidade de Braslia, como grande provedor de acesso
e de informaes, e procurando manter-se conectada ao maior nmero de usurios pos-
svel e em alta disponibilidade, v a necessidade de introduo de novas solues em seu
ambiente, mas por ser um ambiente muito complexo e heterogneo, precisa ater-se a um
modelo de implementao que permita execuo de uma transio para o IPv6 de forma
segura, gradual e suave.
Neste trabalho de pesquisa apresentada uma metodologia para criar um ambiente de
experimentos dentro da REDUnB (Rede de Dados da UnB) para implementao do IPv6,
analisando aspectos relacionados s tcnicas de transio com anlises de desempenho
destas comunicaes. Por meio desta metodologia busca-se uma base para um modelo de
migrao do ambiente de IPv4 para IPv6 em um ambiente de rede acadmica heterognea,
com perspectivas concretas de implementao no ambiente REDUnB.
Palavras-chave: Transio para o IPv6, Migrao de IPv4 para IPv6, Pilha Dupla, Dual
Stack, IPv6
vi
Abstract
The growing demand for information and, particularly, the exponential increase in the
number of networks connected to the Internet, makes the institutions have to modernize
their infrastructures often. The sensitive limitation of available addressing this network
contributes to these institutions to study the implementation of the new version of Internet
protocol, IPv6. The University of Brasilia, as leading provider of access and information,
and trying to keep connected to the largest number of users as possible and high availability,
see the need to introduce new solutions in your environment, but because it is a very
complex environment and heterogeneous, need to concentre to a deployment model that
allows implementation of a transition to IPv6 in a secure manner, gradually and smoothly.
In this research work presents a methodology to create an environment of experiments
within the REDUnB (Data Network of UNB) for IPv6 implementation, analyzing aspects
related to the techniques of transition with performance analysis of these communications.
Through this methodology seeks to a basis for a model of migration from the environment
of IPv4 to IPv6 in a heterogeneous academic network environment, with concrete prospects
of implementation in REDUnB environment.
Keywords: IPv6, transition techniques
vii
Lista de Siglas
6RD IPv6 Rapid Deployment

ACL Access Control List
:
APF
:
API Application Programming Interface

: Administrao Pblica Federal
ARP Address Resolution Protocol

:
AS Autonomous System
:
ASN Autonomous System Number

:
BIS Bump in the Stack

:
BGP Border Gateway Protocol

:
BRs Borders Relay

:
CERNET2 China Education and Research Network 2

:
CGI.br
:
CIDR Classless Inter-Domain Routing

: Comit Gestor de Internet no Brasil
CLNS Connectionless-mode Network Service

:
CPD
:
CPU Central Processing Unit

: Centro de Informtica
DDoS Distributed Denial of Service

:
DHCP Dynamic Host Conguration Protocol

:
DHCPv4 Dynamic Host Conguration Protocol for IPv4

:
DHCPv6 Dynamic Host Conguration Protocol for IPv6

:
DNS Domain Name System

:
DNS64 Domain Name System IPv6-IPv4

:
DSCP DiServ Code Point

:
e-PING
:
ECN Explicit Congestion Notication

: Padres de Interoperabilidade de Governo Eletrnico
EGP Exterior Gateway Protocol

:
FINATEC
:
FT
: Fundao de Empreendimentos Cientcos e Tecnolgicos
FTP File Transfer Protocol

: Faculdade de Tecnologia
viii
HTTP Hypertext Transfer Protocol
IANA Internet Assigned Numbers Authority
:
ICC
:
ICMP Internet Control Message Protocol

: Instituto Central de Cincias
ICMPv6 Internet Control Message Protocol version 6

:
IETF Internet Engineering Task Force

:
IGMP Internet Group Management Protocol

:
IGPs Interior Gateway Protocols

:
I Internet Protocol
:
IPSec Internet Protocol Security

P:
IPv4 Internet Protocol version 4

:
IPng Internet Protocol next generation

:
IPv6 Internet Protocol version 6

:
IS-IS Intermediate System to Intermediate System

:
ISATAP Intra-Site Automatic Tunnel Addressing Protocol

:
ISP Internet Service Provider

:
ITU-T International Telecommunication Union

:
LAN Local Area Network

:
LSA Link State Advertisement

:
MAC Media Access Control

:
MAP-E Mapping of Address and Port-Encapsulation

:
MOS Mean Opinion Score

:
MTU Maximum Transmission Unit

:
NAT Network Address Translator

:
NAT44 Network Address Translator from IPv4 to IPv4

:
NAT-PT Network Address Translation-Protocol Translation

:
ND Neighbor Discovery
:
NDP Neighbor Discovery Protocol

:
NIC.br
:
N Network Layer Protocol IDentier

: Ncleo de Informao e Coordenao do Ponto BR
NTP Network Time Protocol

LPID:
OSPF Open Shortest Path First

:
PAMS Perceptual Analysis Measurement System

:
PDU Protocol Data Unit

:
PESQ Perceptual Evaluation of Speech Quality

:
PoC Proof of Concept

:
QoS Quality of Service

:
ix
RARP Reverse Address Resolution Protocol
REDECOMEP
:
REDUnB
: Redes Comunitrias de Educao e Pesquisas
RFC Request for Comments

: Rede de Dados da UnB
RIP Routing Information Protocol

:
RNP
:
SEND Secure Neighbor Discovery

: Rede Nacional de Ensino e Pesquisa
SIIT Stateless IP/ICMP Translation

:
SIP Session Initiation Protocol

:
SLAAC Stateless Address Autoconguration

:
SPF Shortest Path First

:
SSH Secure Shell

:
SSL Secure Socket Layer

:
TCP Transmission Control Protocol

:
TCP/IP Transmission Control Protocol/ Internet Protocol

:
ToS Type of Service

:
TTL Time to Live

:
UDP User Datagram Protocol

:
UnB
:
URL Uniform Resource Locator

: Universidade de Braslia
VLAN Virtual Local Area Network

:
VoIP Voice over Internet Protocol

:
VPN Virtual Private Network

:
x
Sumrio
1 Introduo 1
1.1 Justicativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Contribuio Esperada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Reviso de Literatura 5
2.1 Protocolo IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Protocolo IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Cabealho do IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Protocolo IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Endereamento IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 Estrutura do Cabealho IPv6 . . . . . . . . . . . . . . . . . . . . . 15
2.3.3 Funcionalidades Bsicas do IPv6 . . . . . . . . . . . . . . . . . . . 18
2.3.4 Roteamento no IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.5 Segurana com IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3 Transio entre os protocolos IPv4 e IPv6 33

3.1 Tunelamento ou Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2 Traduo ou Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 Pilha Dupla ou Dual Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4 Consideraes sobre as Tecnologias de Transio . . . . . . . . . . . . . . . 40
3.5 IPv6 em Hardwares e Sistemas Operacionais . . . . . . . . . . . . . . . . . 41
3.6 Migrao de Aplicaes para o protocolo IPv6 . . . . . . . . . . . . . . . . 41
3.7 Resoluo de Nomes no IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4 Estado da Arte 44
4.1 Concluses sobre as tcnicas utilizadas nos artigos . . . . . . . . . . . . . . 50
xi
5 Proposta de Modelo para Migrao Gradual 51
5.1 Ambiente de Aplicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 Proposta de Implementao . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.1 Fase 1: Endereamento e Roteamento . . . . . . . . . . . . . . . . . 55
5.2.2 Fase 2: Organizao do Ambiente de Rede . . . . . . . . . . . . . . 57
6 Cenrio de Avaliao 60
6.1 Caracterizao do Laboratrio . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.2 Conguraes de Equipamentos no Laboratrio . . . . . . . . . . . . . . . 61
6.3 Certicaes do Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.4 Avaliao de Desempenho no Ambiente de Experimentos . . . . . . . . . . 67
6.4.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.4.2 Anlise dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . 77
7 Concluses 79
Referncias 81
I Apndices 85
A 86
B 104
C 106
D 109
II Anexos 114
A 115
B 121
C 127
D 129
xii
Lista de Figuras
2.1 Modelo TCP/IP em camada com suas respectivas funes e protocolos . . 5
2.2 Endereamento IPv4 representado em bits . . . . . . . . . . . . . . . . . . 7
2.3 Cabealho IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Endereamento IPv6 representado em bits . . . . . . . . . . . . . . . . . . 11
2.5 Estrutura de um pacote IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6 Estrutura geral de cabealho de mensagem ICMPv6 . . . . . . . . . . . . . 19
2.7 Exemplo de Autocongurao de host . . . . . . . . . . . . . . . . . . . . . 22
2.8 Formato do pacote DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.9 Formato do pacote DHCPv6 em Relay Agents e mensagens de servidores . 25
2.10 Exemplo de topologia de rede sob protocolo OSPF . . . . . . . . . . . . . . 27
2.11 Exemplo de mltiplas instncias do OSPF em execuo em um Link . . . . 27
2.12 Formatos de cabealhos dos protocolos OSPFv3 e OSPFv2 . . . . . . . . . 28
2.13 Interao entre protocolos de roteamento BGP e OSPF . . . . . . . . . . . 29
2.14 Exemplo de gerao de endereo temporrio em sistema operacional Linux 30
2.15 Gerao de endereo criptogrco com par de chave pblico-privada . . . . 31
3.1 Tunelamento de pacotes IPv6 atravs de rede IPv4 . . . . . . . . . . . . . 34
3.2 Cenrio de rede em Pilha Dupla . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Modelo de Pilha Dupla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1 Implantao do IVI em ambiente descrito pelo primeiro modelo [1] . . . . . 45
5.1 Alcance da REDUnB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Topologia da REDUnB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3 Atribuio de blocos de endereos IPv4 e IPv6 na REDUnB . . . . . . . . 55
5.4 Atribuio de reas de roteamento OSPF verses 2 e 3 na REDUnB . . . . 56
5.5 Alocao de prexos IPv6 e reas de concentradores de redes . . . . . . . . 57
6.1 Topologia do Laboratrio - Pilha Dupla . . . . . . . . . . . . . . . . . . . . 61
6.2 Laboratrio prtico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.3 Desempenho da latncia de rede na comunicao entre hosts ZETA e ALFA 70
xiii
6.4 Desempenho do Jitter de rede na comunicao entre hosts ZETA e ALFA . 71
6.5 Desempenho da latncia de rede na comunicao do servio HTTP entre
hosts ZETA e ALFA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.6 ndices de desempenhos de trfego VoIP nos protocolos IPv4 e IPv6 . . . . 75
6.7 Relatrio de perda de pacotes no trfego VoIP nos protocolos IPv4 e IPv6 75
6.8 Indicadores de mtodos de avaliao de desempenho do trfego VoIP nos
protocolos IPv4 e IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
D.1 Alcance do ALFA

host hosts
para os demais do ambiente de teste por meio
host GAMA host ALFA

do comando 'Ping' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
D.2 Alcance do para o por meio do comando 'Ping'
Host ALFA host BETA

e 'Ping6' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
host TETA host ALFA

D.3 alcana o por meio do comando 'Ping' . . . . . . 110
Host BETA host CAPA

D.4 Resoluo de nome do para o . . . . . . . . . . . 111
switch router R1
D.5 traa rota para o por meio do comando 'Tracert' 111
D.6 Tabela de rotas consultada no . . . . . . . . . . . . . . . 112
switches
hosts ALFA ZETA
D.7 Nvel de utilizao de CPU nos do laboratrio . . . . . . . . . . . 112
zona lab.unb.br
D.8 Acesso mtuo a servio HTML entre e . . . . . . . . . 113
D.9 Conguraes de resoluo de nome para a e habilitao
de IPv6 no DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
A.1 Grupo de coleta 01 - IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
B.1 Grupo de coleta 07 - IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
C.1 Relatrio VoIP - IPv4 pag 01 de 02 . . . . . . . . . . . . . . . . . . . . . . 127
C.2 Relatrio VoIP - IPv4 pag 02 de 02 . . . . . . . . . . . . . . . . . . . . . . 128
D.1 Relatrio VoIP - IPv6 pag 01 de 02 . . . . . . . . . . . . . . . . . . . . . . 129
xiv
D.2 Relatrio VoIP - IPv6 pag 02 de 02 . . . . . . . . . . . . . . . . . . . . . . 130
xv
Lista de Tabelas
2.1 Alguns Endereos Multicast Permanentes . . . . . . . . . . . . . . . . . . . 13
6.1 Particularidades de hosts no Laboratrio . . . . . . . . . . . . . . . . . . . 64
6.1 Particularidades de hosts no Laboratrio (continuao) . . . . . . . . . . . 65
xvi
Captulo 1
Introduo
Este captulo expe a evoluo das redes de computadores, e com esse objetivo, a sute
de protocolos TCP/IP (Transmission Control Protocol/Internet Protocol ) desempenha um

papel fundamental na conectividade de redes de tecnologias distintas, o que contribuiu
substancialmente para o crescimento da Internet, dada a transparncia que este protocolo
d s redes, facilitando o desenvolvimento contnuo de novas aplicaes e servios.
A denominao TCP/IP provm dos nomes dos dois protocolos essenciais da sequncia
de protocolos, os protocolos TCP (Transmission Control Protocol ) e IP (Internet Proto-

col ). Este ltimo, o protocolo IP, foco do estudo em questo, tem por propsito conceder
aos dispositivos na grande rede um endereo nico, possibilitando que sejam identicados
e encontrados e, consequentemente, que a comunicao possa ocorrer.
Os sistemas que se comunicam com a rede pblica necessitam do protocolo IP para
compartilharem arquivos e recursos, mas este vem apresentando um sensvel esgotamento
de endereamento IP na verso 4 [2]. Para o enfrentamento deste obstculo, uma nova
verso de protocolo foi desenvolvida e j se apresenta como parte das necessidades de
comunicao. A verso 6 do protocolo IP, mais conhecida como IPv6 (Internet Protocol
version 6 ), se torna um avano importante devido a implementaes de novas caractersti-
cas, permitindo mais ecincia e segurana, alm de solucionar o problema da insucincia
de endereos do protocolo IPv4 (Internet Protocol version 4 ). Com sua utilizao uma
nova questo dever ser discutida, a forma como as verses diferentes podero se comu-
nicar sem a gerao de incompatibilidades.
Esta comunicao dever ser alcanada por meio de mecanismos de transio, mas
necessrio avaliar com prudncia se estes mecanismos de transio conseguiro minimizar
o impacto e as diculdades que o processo de migrao ocasionar.
Com isso, o propsito deste trabalho de pesquisa aprofundar no conhecimento sobre a
verso mais recente do protocolo IP, subsidiando a elaborao de um modelo de migrao
do ambiente IPv4 para IPv6 em rede acadmica heterognea. Para tal, imprescindvel a
1
comprovao de viabilidade do modelo por meio de avaliao em ambiente experimental
de rede connada em laboratrio. Posteriormente, pretende-se implementar um ambiente
piloto em produo na REDUnB, com base no modelo de referncia tcnica produzido
neste trabalho.
1.1 Justicativa
Com a grande evoluo da computao e da Internet, as redes de informao ganharam
espao nas atividades mais simples do dia-a-dia, ensejando interao entre os dispositivos
ligados grande rede pblica, e com imprescindvel papel nas empresas, com capacidade
de trafegar dados, imagem, voz, vdeo, por meio de uma infraestrutura nica. Isso foi
possvel em funo do protocolo IP, que permite a comunicao entre hardwares e sistemas
de diferentes arquiteturas, o que o tornou muito difundido, fazendo-se necessria a criao
de mecanismos de convergncia de tecnologias.
Mesmo com muitos mecanismos disponveis, inclusive para melhoria da alocao dos
endereos pblicos, a demanda pelo uso da Internet segue crescendo expressivamente,
com a iminncia do esgotamento de alocao de novos endereos IPv4, o que inibe o de-
senvolvimento da chamada Internet das Coisas (Internet of Things ). Por outro lado, o
IPv4 no foi projetado para suportar servios como os que atualmente tem sido muito de-
mandados, como servios mveis, de tempo real, multimdia, dentre outros, apresentando
como um desao para a Internet do Futuro [2]. A m de integrar plenamente essas novas
tecnologias, a rede deve suportar recursos altamente variveis dentro de curtos perodos
de tempo, ou ainda atrasos de propagao extremamente longos.
Abordagens para uma Internet do Futuro vo de pequenos passos evolutivos incre-
mentais at uma remodelagem completa nos princpios arquiteturais, onde as tecnologias
aplicadas no podem ser limitadas por normas existentes ou paradigmas. Nesse contexto,
o protocolo IPv6 pode ser visto como um passo na evoluo das redes de computadores,
sendo necessrio na infraestrutura da Internet, uma questo de continuidade de negcios,
para provedores, empresas e instituies.
Um grande benefcio da adeso ao IPv6 a disponibilidade de um nmero extrema-
mente maior de endereos se comparado ao IPv4. A alta disponibilidade de endereos
e prexos de rede fornece uma exibilidade na arquitetura de redes que permite uma
organizao hierrquica e inclusive geogrca, onde um prexo de rede pode ser usado
para enderear um pas ou at mesmo um continente e segment-los em diversos nveis,
permitindo que seja feita hierarquizao da estrutura com objetivo de reduzir o tamanho
das tabelas de roteamento, aumentando a escalabilidade.
2
Um outro ponto chave da adeso ao protocolo IPv6 quanto a segurana, pois na
arquitetura deste protocolo, este aspecto j provido de forma nativa, sobretudo sob
suporte do protocolo IPSec (Internet Protocol Security ). Mecanismos de autenticao e
encriptao passaram a fazer parte do protocolo IPv6, disponibilizando para qualquer
par de dispositivos de uma conexo m-a-m, mtodos que visam garantir a segurana
dos dados que trafegam pela rede, no entanto, o aprimoramento do aspecto segurana no
IPv6 continua sendo um desao. Contudo, o IPv6 traz novidades para as quais as equipes
tcnicas e os equipamentos de segurana ainda no esto bem preparados.
Com base em aspectos diversos relacionados rea de tecnologia, incluindo a migrao
para o protocolo IPv6, foi elaborado um conjunto de premissas, polticas e especicaes
tcnicas que regulamentam a utilizao da Tecnologia da Informao e Comunicao no
governo federal do Brasil, resultando em um documento de referncia denominado como e-
PING (Padres de Interoperabilidade de Governo Eletrnico). Este documento estabelece
as condies de interao com os demais poderes e esferas de governo e com a sociedade em
geral, proporcionando a operao integrada entre equipamentos, programas e sistemas de
informao, visando o aproveitamento irrestrito dos potenciais de intercmbio de dados
e informaes na esfera da APF (Administrao Pblica Federal) direta, autrquica e
fundacional [3].
No contexto das polticas tcnicas para interconexo de ativos das redes de dados, o
documento de referncia expe que os rgos da APF devero se interconectar utilizando
IPv4 e planejar sua futura migrao para IPv6. Novas contrataes e atualizaes de
redes devem prever suporte coexistncia dos protocolos IPv4 e IPv6 e a produtos que
suportem ambos os protocolos.
Somando a estas orientaes advindas do Comit Executivo de Governo Eletrnico
desde os idos anos de 2004, a RNP (Rede Nacional de Ensino e Pesquisa) que coordena
infraestrutura de rede Internet voltada para a comunidade brasileira de ensino e pesquisa,
vem fazendo coro a esta linha de pensamento, muito embora no tenha avanado o su-
ciente em aes no sentido de prover a seus clientes, como a prpria UnB, a alternativa
de sada pela Internet IPv6.
Todavia, a transio do protocolo IPv4 para o IPv6 vista como um passo impor-
tante para o futuro da Internet, mas ambos coexistiro por um bom tempo ainda, e esta
transio dever ocorrer de forma gradual e transparente para o usurio nal.
1.2 Contribuio Esperada

A proposta espera contribuir com:
3
A criao de um ambiente de rede experimental dentro da REDUnB onde seja
possvel estudar e avaliar o protocolo IPv6 como PoC (Proof of Concepts );
Elaborao de um modelo tcnico-administrativo consistente de migrao gradual
do protocolo IPv4 para o IPv6 em ambiente de rede heterogneo da REDUnB, que
possa ser tomado como caso de sucesso para aplicao;
Produo de documento nal que sirva como referncia terica para compreender o
IPv6 e guia de implementao prtica do protocolo como meta de transferncia de
tecnologia para prossionais de tecnologia da informao;
Avaliao de conjunto bsico de servios sobre IPv6 como DNS (Domain Name
System ) e HTTP (Hypertext Transfer Protocol ).
1.3 Resumo do Captulo

Esta seo abordou de forma breve o atual contexto em que se insere os protocolos
TCP/IP nas redes de computadores, mencionando as principais verses do protocolo IP e
sua intercomunicao. Neste ensejo citada uma proposta de trabalho para um modelo de
migrao, seguida de justicativas que fundamentam o aprofundamento do conhecimento
desta nova verso do protocolo IP e as contribuies que se espera deste estudo.
4
Captulo 2
Reviso de Literatura
O propsito aqui realizar um detalhado estudo sobre o protocolo IPv6 visando a
praticidade de sua aplicao nas redes atuais, descrevendo os recursos e funcionalidades
bsicas, apontando diferenas signicativas e suas vantagens em relao ao protocolo
IPv4, alm de buscar uma compreenso das tcnicas de transio e o comportamento dos
protocolos IPv4 e IPv6 quanto interoperabilidade.
2.1 Protocolo IP
A Internet um grande aglomerado de computadores espalhados ao redor do mundo
disponibilizando servios diversos a quem tiver interesse e autorizao para acess-los.
Para que computadores distintos rodando sistemas operacionais diferentes possam se co-
municar, preciso que tenham os mesmos padres de comunicao, e neste mbito que o
protocolo IP desempenha um papel fundamental, concedendo aos dispositivos na grande
rede um endereo IP globalmente nico e de formato uniforme, possibilitando que sejam
identicados e, consequentemente, que a comunicao possa ocorrer [4].
Sucintamente, considerando o uso dos mesmos padres de comunicao, quando um
pacote IP recebido por um roteador, seu endereo de destino procurado na tabela
de roteamento. Se o destino for uma rede distante, o pacote ser encaminhado para o
Figura 2.1: Modelo TCP/IP em camada com suas respectivas funes e protocolos
5
prximo roteador da interface fornecida na tabela. Caso o destino seja um host local, por
exemplo, na LAN (Local Area Network ) do roteador, o pacote ser enviado diretamente
para l. Se a rede no estiver presente, o pacote ser enviado para um roteador predenido
que tenha tabelas mais abrangentes [5].
2.2 Protocolo IPv4

A verso 4 do protocolo IP no sofreu alteraes substanciais desde a sua criao
na dcada de 1980, e passou a ser um dos protocolos mais amplamente difundidos e
implementados em todo o mundo por se tratar de um projeto exvel e poderoso no
qual foi possvel conciliar as constantes mudanas tecnolgicas, provando ser robusto, de
fcil implementao e muito escalvel [6]. O protocolo IPv4 o mecanismo responsvel
pela comunicao da pilha TCP/IP, tendo relacionamento basicamente com a camada de
Internet do modelo TCP/IP.
Como citado anteriormente, para que os dispositivos de uma rede possam trocar infor-
maes necessrio que todos adotem os mesmos padres de comunicao para o envio
e recebimento de informaes, podendo ser entendidos tambm como um conjunto de
regras, estas denominadas como protocolo de comunicao. Neste contexto, o TCP/IP
tornou-se padro de fato na Internet e utiliza um esquema de comunicao concebido
em quatro camadas: Aplicao, Transporte, Internet e Interface de Rede, como se v na
ilustrao adaptada Figura 2.1 [5].
A camada de Aplicao contm todos os protocolos para um servio especco, utili-
zada pelos programas para enviar e receber informaes de outros programas atravs da
rede. Nesta camada so identicadas aplicaes para resoluo de nomes de domnios em
endereos IP, para transferncia de arquivos, correio eletrnico, navegao na Internet,
dentre outras, cada tipo de programa se comunicando com um protocolo de aplicao
diferente, dependendo da nalidade do programa.
Aps processar a requisio do programa, o protocolo na camada de Aplicao se
comunicar com um outro protocolo na camada de Transporte, usando TCP ou UDP
(User Datagram Protocol ). A camada de Transporte responsvel por pegar os dados
enviados pela camada superior, dividi-los em pacotes e envi-los para a camada inferior,
a camada Internet. Alm disso, a camada de Transporte responsvel por ordenar os
pacotes recebidos da rede e tambm vericar se o contedo dos pacotes est intacto.
Na camada de Internet h o protocolo IP que pega os pacotes recebidos da camada de
Transporte e adiciona informaes de endereos IP de origem e destino, gerando assim,
o que chamamos de datagrama. Em seguida os datagramas so enviados para a camada
imediatamente inferior, a camada Interface de Rede.
6
Figura 2.2: Endereamento IPv4 representado em bits
Na camada Interface de Rede os datagramas sero enviados para a rede, ou receber
os dados da rede, caso o computador esteja recebendo dados. Os protocolos inclusos nesta
camada dependero do tipo de rede que o computador estiver usando, com uma grande
predominncia do protocolo Ethernet.
Como visto, o protocolo IP reside na camada Internet do modelo TCP/IP, e em
sua verso 4, o IPv4, a cada computador associado um endereo de 32 bits, cha-
mado endereo IP, como pode ser visualizado na Figura 2.2. No exemplo, o endereo
11001000011110000010100001111101 em notao binria pode ser difcil de compreender,
ento dividi-lo em 4 partes de 8 dgitos binrios, ou seja, 4 octetos 11001000.01111000.
00101000.01111101, e ento converter estes endereos binrios em formato decimal faci-
litar bastante. Estes endereos IP so habitualmente escritos com 4 nmeros decimais
entre 0 e 255 separados por pontos, por exemplo, o endereo IP 200.120.40.125 [5].
Para tornar ecaz o encaminhamento dos datagramas os endereos IP so arranjados
em duas partes, uma que o prexo que identica a rede e outra que identica o n
nessa mesma rede. As decises de encaminhamento dos datagramas baseiam-se na parte
que identica a rede. Tomando o exemplo do endereo IP citado, todos os endereos dos
ns dessa rede comeam por 200.120.40, s o ltimo byte diferente, ento endereos
200.120.40.125 e 200.120.40.135 correspondem a dois ns distintos da rede 200.120.40.
Uma rede IP 200.120.40.0 com mscara de subrede 255.255.255.0 composta por
endereos que vo de 200.120.40.1 at 200.120.40.254, sendo que o endereo 200.120.40.0
usado para designar a rede inteira e o endereo 200.120.40.255 usado para o broadcast
da rede. Esta rede s se comunica com as mquinas que estejam nesta faixa de IP e para
isso no precisam de nenhum dispositivo para auxili-los a encontrar essas mquinas, tal
como um roteador.
7
2.2.1 Cabealho do IPv4
Um datagrama IP consiste em duas partes, o cabealho e os dados. O cabealho inclui
campos adicionais mensagem a ser transmitida. O cabealho de um pacote IPv4 tem
tamanho que varia entre 20 e 60 bytes, e apresentado mediante ilustrao adaptada
na Figura 2.3 [5]. Uma breve descrio de cada campo no cabealho IPv4 segue abaixo
conforme descreve [7]:
Version (4 bits ): aponta a verso do protocolo, no caso, a verso 4 do protocolo
IP;
Internet Header Length (4 bits ): como um datagrama IPv4 pode conter um n-

mero varivel de opes includas no seu cabealho, esses quatro bits so necessrios
para determinar onde, no datagrama IP, os dados realmente comeam;
Type of Service (8 bits ): especica informaes especiais para diferenciar os dis-
tintos tipos de datagramas IP, como tipos que requerem particularmente, baixo
atraso, alta vazo ou conabilidade, devendo ser distinguidos uns dos outros;
Total Length (16 bits ): nmero de identicao de cada datagrama enviado, uti-
lizado na remontagem dos fragmentos do datagrama;
Identication (16 bits ): identica um datagrama;

Flags (3 bits ): identicam a transmisso de sinais de controle;
Fragment Oset (13 bits ): um valor numrico sucessivo atribudo a cada frag-
mento do datagrama. O IP no destino utiliza este campo para remontar os frag-
mentos do datagrama na ordem correta;
Time to Live (8 bits ): indica o nmero mximo de roteadores pelos quais um
datagrama pode passar. decrementado de 1 em cada roteador, e o datagrama
descartado quando o TTL (Time to Live ) atinge zero;
Protocol (8 bits ): indica qual protocolo de alto nvel foi usado para criar a mensa-
gem que est sendo transportada na rea de dados do datagrama;
Header Checksum (16 bits ): destina-se vericao da validade do cabealho.

recalculado em cada roteador medida que o campo TTL decrementado;
Source Address (32 bits ): informa o endereo de origem;

Destination Address (32 bits ): informa o endereo de destino;
Options (entre 0 e 320 bits ): de tamanho varivel com informaes de segurana,
roteamento, relatrios de erro, etc. Pode aparecer ou no em um datagrama.
8
Figura 2.3: Cabealho IPv4
Apesar de ser um projeto exvel, poderoso e de grande xito desde seu surgimento,
o IPv4 tem sofrido alguns problemas. Um deles referente ao crescimento exponencial
da Internet e a ameaa de exausto do espao de endereamento, onde os endereos
IPv4 se tornaram relativamente escassos, forando as organizaes a adotarem solues
paliativas como o CIDR (Classless Inter-Domain Routing ) [8], o DHCP (Dynamic Host
Conguration Protocol ) [9], o NAT (Network Address Translator ) [10] e por m, a alocao
de endereos privados com trs faixas de endereos, no vlidos na Internet, para uso em
redes corporativas [11].
Outro problema enfrentado pelo IPv4 refere-se necessidade de um suporte melhorado
para a entrega de dados em tempo real. Nessa circunstncia, o servio padro oferecido
pela rede IP conhecido como servio Best Eort (melhor esforo), fazendo sempre o
melhor possvel para encaminhar os pacotes de acordo com os recursos que ele tem dis-
ponveis naquele instante de tempo, mas sem qualquer garantia de entrega. O servio
de melhor esforo consiste em oferecer o mesmo tratamento aos pacotes, sem nenhuma
distino entre eles. Com isso, o QoS d o aporte necessrio s redes IP com um conjunto
de algoritmos capazes de fornecer vrios nveis de tratamentos para diferentes tipos de
trfego na rede. O propsito dessa tecnologia otimizar o uso da banda passante provendo
um trfego m-a-m ecaz e econmico.
Com objetivo de resolver estes e os demais problemas enfrentados pelo protocolo IPv4,
no comeo da dcada de 1990, a IETF (Internet Engineering Task Force ) iniciou um
9
esforo para desenvolver o sucessor do protocolo IPv4 [7]. Esta nova verso do protocolo
IP, hoje conhecida como IPv6 tenta causar o mnimo impacto nos protocolos das camadas
acima e abaixo, eliminando a adio aleatria de novas caractersticas.
2.3 Protocolo IPv6

Considerando as limitaes do protocolo IP na verso 4, justicou-se a evoluo deste
protocolo para uma verso mais avanada. No incio foi utilizada a designao IPng
(Internet Protocol next generation ) como referncia gerao seguinte do protocolo IP,
entretanto substituda pela designao IPv6 atualmente adotada [12].
Os aspectos essenciais do IPv4 que esto na base do sucesso do protocolo foram manti-
dos no IPv6. O cerne da evoluo se concentrou em reformular as decincias do protocolo
IPv4, as funcionalidades que no tm um bom desempenho ou que no so usadas com
frequncia foram tornadas opcionais ou simplesmente excludas. Algumas novas carac-
tersticas que se consideram necessrias foram adicionadas. No IPv6 foram introduzidas
novas funcionalidades tais como suporte a mobilidade, segurana de forma nativa, suporte
melhorado para cabealhos de extenso alm de promover a simplicao do cabealho
base, dentre outras mudanas.
2.3.1 Endereamento IPv6
A principal razo para a reestruturao do formato de endereamento da nova verso
do protocolo IP foi de atender a carncia de alocaes pblicas, passando de enderea-
mentos de 32 bits do IPv4 para 128 bits do IPv6 [13]. Estes endereos de 128 bits so
tipicamente representados em notao hexadecimal divididos em 8 grupos de 16 bits se-
parados por dois pontos (:), representando cada grupo com um hexadecimal (base 16)
nmero de 0 a FFFF, podendo usar letras maisculas ou minsculas para dgitos hexa-
decimais, e denominado como Hexadecateto. Exemplo de um endereo IPv6 mostrado
a Figura 2.4.
Assim, o IPv6 aumenta substancialmente o nmero de endereos em relao ao IPv4,
admitindo alocar em torno de 340 undecilhes de endereos possveis.
Com propsito de melhor representar a compreenso do formato do endereo, ado-
tada uma simplicao de notao em que quando houver grupos de zeros, apenas um
deles necessrio ser escrito e, os zeros esquerda de grupos com outros valores, no
necessitam ser representados. Assim, o endereo apresentado na Figura 2.4 pode ser
representado por FEAB:0:0:0:8:800:400B:335C. De forma ainda mais simplicada, pode
ser utilizado um par de dois pontos (::) para representar grupos de zeros consecutivos,
10
Figura 2.4: Endereamento IPv6 representado em bits
conforme pode ser observado na notao FEAB::8:800:400B:335C. Cabe enfatizar que so-
mente uma supresso de zeros por um par de dois pontos (::) admitida. Caso ocorram
duas sequncias de zeros, apenas uma dever receber esta representao [14].
Com referncia representao dos endereos IPv6 em URLs (Uniform Resource Lo-
cators ), estes agora passam a ser includos entre colchetes. Assim, evitado que possveis
ambiguidades ocorram caso seja necessrio indicar o nmero de uma porta juntamente
com a URL. Segue abaixo exemplo de URLs com endereos IPv6 que seguem essa con-
veno:
http://[FEAB::8:800:400B:335C]/index.html
http://[FEAB::8:800:400B:335C]:8080
O IPv6 no utiliza mscaras de rede, mas emprega a notao de prexo que co-
mum tambm no roteamento IPv4 ao usar a notao CIDR. Assim, um range de endere-
os IPv6 de 2001:DB8:31:1:: a 2001:DB8:31:1:FFFF:FFFF:FFFF:FFFF pode ser escrito
como 2001:DB8:31:1::/64, onde o tamanho do prexo um valor decimal que especica a
quantidade de bits contguos esquerda do endereo que compreendem o prexo. Assim,
o prexo /64 apresentado indica que dos 128 bits do endereo, 64 bits mais esquerda
so utilizados para identicar a subrede e os 64 bits restantes para identicar a inter-
face. A parte de endereo em um prexo deve ser um endereo IPv6 vlido com todos
os bits que no fazem parte do prexo denido para zero (0). Ento, 2001:DB8:31:1::/64
e 2001:DB8:31:1::/127 so prexos vlidos, mas 2001:DB8:31:1/64 e 2001:DB8:31:1::/48
no so. No primeiro caso, a parte do endereo no um endereo IPv6 vlido de 128
11
bits, e no segundo caso, a parte :1:: ca fora dos 48 bits de prexo, por isso deve ser zero,
escrito como 2001:DB8:31::/48 [15].
Diferente do IPv4, no IPv6 no existe endereo broadcast, este responsvel por direcio-
nar um pacote para todos os ns de um mesmo domnio. Entretanto, os endereos do tipo
Unicast, Multicast e Anycast so adotados, e na sequncia seguem algumas caractersticas
destes tipos de endereos.
O tipo de endereo Unicast permite que um datagrama seja entregue exclusivamente
para a interface que possui o endereo especicado. Estes endereos Unicast ainda podem
ser segmentados nas categorias descritas a seguir:
Globals : semelhantes aos endereos pblicos do IPv4, sendo roteveis globalmente

na parte IPv6 da Internet;
Link-Local : por meio deste tipo de endereamento executa-se a comunicao entre

ns pertencentes mesma rede local. O escopo deste endereo o enlace local,
de modo que os roteadores nunca encaminham para outro enlace pacotes com este
endereo. Ele usado tambm pelos processos do Neighbor Discovery e sempre
automaticamente congurado, mesmo na ausncia de todos os outros tipos de ende-
reos Unicast. Os dez primeiros bits deste endereo sempre comeam com FE80::/10;
Site-Local : so equivalentes aos endereos IPv4 privados, ou seja, est restrito a
um domnio sem ligao com a Internet. Eles podem ser usados em conjunto com os
endereos Global Unicast. Estes endereos no so automaticamente congurados e
precisam ser designados com congurao stateless ou stateful. Os 10 primeiros bits

deste endereo so xos em FEC0::/10;
Unspecied : usado para identicar a ausncia de um endereo e representado
por 0:0:0:0:0:0:0:0 ou ainda por ::;
Loopback : usado quando um n envia um datagrama para ele mesmo. repre-
sentado por 0:0:0:0:0:0:0:1 ou ainda por ::1;
IPv4 Compatible : utilizado quando se necessita encaminhar um datagrama de
uma rede IPv6 para outra utilizando tunelamento em redes IPv4. So representados
como um endereo IPv6 com os ltimos 32 bits correspondendo a um endereo IPv4
e os 96 bits iniciais acrescentados de zeros.
Um datagrama que destinado a um endereo Multicast entregue a todas as in-
terfaces que constam daquele grupo de endereos. Como no IPv6 o endereo broadcast
encontra-se indisponvel, servios conseguem utilizar caracterstica semelhante ao broad-
cast por meio de endereos do tipo Multicast [16].
12
No ambiente de redes IPv4 o Multicast tambm existe, sendo executado pelo pro-
tocolo IGMP (Internet Group Management Protocol ) [17]. No entanto, o Multicast no
IPv4, embora til, ele opcional. Em contrapartida, em IPv6, Multicast obrigatrio,
na verdade, fundamental para operao do IPv6. O protocolo IGMP foi incorporado
pelo ICMPv6, conforme RFC 2710 [18], e o Multicast usado para implementar o ARP
(Address Resolution Protocol ) equivalente do IPv6.

Todos os endereos Multicast derivam do bloco FF00::/8, onde o prexo FF identica
um endereo Multicast, e este prexo antecede quatro bits, que representam quatro ags,
seguido por outros quatro bits que dene o escopo do grupo de endereos Multicast. O
restante dos 112 bits cam cargo da identicao de grupo Multicast. As informaes
apresentadas na Tabela 01, demonstram alguns endereos Multicast permanentes.
Endereo Escopo Descrio

Tabela 2.1: Alguns Endereos Multicast Permanentes
FF01::1 Node-Local Todos os ns

FF01::2 Node-Local Todos os roteadores
FF02::1 Link-Local Todos os ns
FF02::2 Link-Local Todos os roteadores
FF02::5 Link-Local Roteadores OSPF
FF02::6 Link-Local Roteadores OSPF designados
FF02::9 Link-Local Roteadores RIP
FF02::D Link-Local Roteadores PIM
FF02::1:2 Link-Local Agentes DHCP
FF05::2 Site-Local Todos os roteadores
FF05::1:3 Site-Local Servidores DHCP em um Site
FF05::1:4 Site-Local Agentes DHCP em um Site
Uma lista completa de endereos permanentes do Multicast pode ser encontrada no

endereo web da IANA (Internet Assigned Numbers Authority - http://www.iana.org), a
qual relativamente extensa. Entretanto, dois endereos Multicast so muito importantes,
recomendvel conhec-los, trata-se dos endereos FF02::1 e FF02::2. O primeiro o Link-
Local (interface) dos endereos de todos os ns, algo prximo da equivalncia com endereo
de broadcast 255.255.255.255 do protocolo IPv4. O segundo o Link-Local (interface) de
todos os endereos de roteadores, sendo estes dois de fundamental importncia para o
processo de autocongurao no IPv6 [19].
Um endereo Anycast designado para comunicao com mltiplas interfaces. Pacotes
endereados a um endereo Anycast so encaminhados pela infraestrutura de roteamento
para a interface mais prxima do endereo Anycast designado. Recordando, endereos
Unicast so atribudos a uma mquina e cada pacote entregue a essa mquina. Ende-
reos Multicast so atribudos a vrias mquinas e cada pacote entregue a todas essas
13
mquinas. J os endereos Anycast so atribudos a muitas mquinas, mas cada pacote
entregue a apenas uma dessas mquinas. Complementando a compreenso, um endereo
Unicast atribudo a mais de uma interface transforma-se em um endereo Anycast, com
a devida explicitao do uso de endereo Anycast nas conguraes dos ns.
Os endereos Anycast so projetados para fornecer redundncia e balanceamento de
carga em situaes onde mltiplos hosts ou roteadores proveem o mesmo servio, e eles
utilizam o mesmo range de endereos Globals Unicast e so indistinguveis a partir deles.
No entanto, um n que atribudo a um endereo Anycast deve ser congurado para
estar ciente deste fato. Endereos Multicast e Anycast podem ser usados como endereos
de destino em pacotes, mas somente endereo Unicast pode ser usado como endereo de
origem. Alm disso, somente os roteadores podem ser congurados com um endereo
Anycast no IPv6 [2].
Para descomplicar a entrega, a infraestrutura de roteamento deve estar vigilante s
interfaces designadas como Anycast e a suas distncias em termos de mtricas de rotea-
mento. Exemplos de utilizao mais bsicos esto relacionados a servios UDP, principal-
mente DNS, quando se tem muitos servidores publicados em diferentes localidades com o
mesmo nmero IP [20].
Plano de Alocao de Endereos IPv6

O endereamento IPv6 possui estrutura exvel para atribuio de endereo, conferindo
redes baseadas em diferentes critrios, tais como tamanho da rede e taxa de crescimento
estimado. Em casos frequentes, uma atribuio inicial pode no ser to escalvel se uma
rede pequena torna-se maior do que o esperado e, portanto, precisa de mais endereos.
A soluo mais fcil, mas menos exvel adotar a atribuio de endereo de bloco
IPv6 em ordem desde o incio do bloco alocado para a organizao. Mas esta ao no
leva em considerao as necessidades futuras e no pondera a respeito do agrupamento de
redes por rea que possibilite a sumarizao de roteamento. Alm disso, este mtodo torna
muito difcil ou quase impraticvel fazer uma atribuio para aumentar a rede existente
e manter seu espao de endereo contguo.
Para que a rede lgica esteja mais organizada possvel, o espao de endereamento
dever ser distribudo de forma hierrquica, de acordo com a topologia e a infraestrutura
fsica da rede. Existem vrios fatores que devero ser considerados na atribuio de ende-
reamento a cada unidade, dos quais se destacam a dimenso, a localizao, a importncia
ou o contexto dentro da instituio.
Contudo, muito importante que o planejamento da atribuio de endereo de bloco
IPv6 ocorra, e a RFC 3531 [21], denominada como A Flexible Method for Managing the
14
Assignment of Bits of an IPv6 Address Block, sugere alternativa que auxilia no melhor
uso do bloco de endereos.
2.3.2 Estrutura do Cabealho IPv6
O cabealho IPv6 uma verso simplicada do cabealho IPv4, tendo sido projetado
com sensveis mudanas em relao ao seu antecessor. No IPv6, cinco campos do cabealho
IPv4 foram removidos conforme pode ser visto abaixo:
Header Length ;
Identication ;
Flags ;
Fragment Oset ;
Header Checksum.
O campo Header Length foi removido por ter se tornado desnecessrio, uma vez que
seu valor foi xado. Os campos Identication, Flags e Fragment Oset passaram a ter suas
informaes indicadas em cabealhos de extenso apropriados. Por m, o campo Header

Checksum foi eliminado com o objetivo de aumentar a velocidade de processamento j
que outras validaes so realizadas pelos protocolos das camadas superiores da rede [2].
Outros campos do IPv4 passaram por alteraes no IPv6, sendo renomeados respec-
tivamente, como o campo Type of Service que foi alterado para Trac Class, o campo
Total Length para Payload Length, o campo Time to Live para Hop Limit e o campo
Protocol para Next Header.

A estrutura do cabealho IPv6 como bem descrito na RFC 2460 [22] que especica o
protocolo IPv6 norteando toda a comunidade da Internet bem como suscitando discusses
e sugestes para sua melhoria, apresentada na ilustrao adaptada na Figura 2.5 [22].
O cabealho tem comprimento xo de 40 bytes. Considerando que os dois campos de
endereos de origem e destino usam 16 bytes cada, ca restando s 8 bytes para informao
geral do cabealho.
Uma breve descrio de cada campo no cabealho IPv6 segue abaixo:
Version (4 bits ): indica a verso do protocolo, no caso, a verso 6 do protocolo IP;

Trac Class (8 bits ): indica a classe ou prioridade do pacote IPv6, funcionalidade
semelhante ao campo ToS (Type of Service ) do cabealho IPv4. Os 6 primeiros
bits do campo Trac Class representam o campo DSCP (DiServ Code Point )
conforme especica a RFC 2474 [23], e os ltimos 2 bits so usados para ECN
(Explicit Congestion Notication ) conforme dene a RFC 3168 [24];
15
Figura 2.5: Estrutura de um pacote IPv6
Flow Label (20 bits ): o identicador de uxo. Este campo consiste num valor
arbitrrio que pode ser utilizado pelo emissor para identicar pacotes, para os quais
tenha requerido uma determinada qualidade de servio. Um uxo uma sequncia
de pacotes enviados por um determinado emissor para um destino especco para o
qual, o emissor deseja um tratamento especial e anlogo por parte dos roteadores
intermedirios no encaminhamento dos pacotes;
Payload Length (16 bits ): indica o comprimento da carga til de dados do pacote
IPv6, combinando os cabealhos de extenso e a PDU da camada superior. Estes
Payloads normalmente possuem comprimento de at 65535 bytes, mas podem exigir

cargas maiores, sendo assim designados como jumbograms ;
Next Header (8 bits ): indica o tipo do cabealho que se encontra imediatamente
aps o cabealho base IPv6. Ele usa os mesmos valores do campo Protocol do IPv4,
como denido na RFC 1700 [25]. Se este valor contm o cdigo para o TCP, ento
o cabealho TCP e o Payload iniciam imediatamente depois do pacote cabealho
IPv6. De outro modo, um ou mais cabealhos de extenso do IPv6 podem ser
encontrados antes do incio do cabealho TCP e dePayload. Assim, desde que cada
cabealho de extenso possua outro campo Next Header e um campo Header Length,
isto constitui em uma lista de cabealho antes do nal do cabealho de extenso,
seguido pelo Payload ;
Hop Limit (8 bits ): semelhante ao campo TTL do IPv4, exceto pelo fato de
no ter relao histrica com a quantidade de tempo (em segundos) que o pacote
aguarda na la do roteador. Ele indica o nmero mximo de saltos que o pacote
IPv6 pode dar antes de ser descartado;
Source Address (128 bits ): identica o endereo IPv6 do n de origem;

Destination Address (128 bits ): identica o endereo IPv6 do n de destino.
Este campo denido para o endereo de destino nal, no entanto, se um cabealho
16
de extenso de roteamento est presente, o campo Destination Address pode ser
congurado para o endereo do prximo destino intermedirio.
Cabealhos de Extenso
Os cabealhos de extenso podem ser ou no encontrados no pacote IPv6. Se cabe-
alhos de extenso esto presentes nos pacotes IPv6, o campo Next Header no cabealho
IPv6 indica o primeiro cabealho de extenso. Dentro de cada cabealho de extenso
tem outro campo Next Header, indicando o prximo cabealho de extenso. O ltimo
cabealho de extenso aponta para o cabealho dos protocolos da camada superior como
o TCP, UDP ou o ICMPv6 (Internet Control Message Protocol version 6 ), contidos na
PDU da camada superior. O novo formato de cabealho de extenso permite que o IPv6
suporte novas funcionalidades e necessidades futuras.
Os cabealhos de extenso tm tamanhos variveis, no tm tamanho mximo e podem
expandir-se para acomodar todos os dados de extenso necessrios para a comunicao
IPv6. A PDU da camada superior compreende normalmente do cabealho do protocolo
da camada superior e seu Payload - carga til de dados [14].
Os tipos bsicos de Cabealhos de Extenso so denidos pela RFC 2460 [22], e so
os seguintes:
Hop-by-Hop Options Extension Header : utilizado para transportar informa-
es opcionais que devem ser examinadas por todos os ns ao longo do caminho de
entrega do pacote. Identicado pelo valor 0 (zero) no campo Next Header ;
Routing Extension Header : utilizado pelo n de origem para listar um ou mais

ns intermedirios que devem ser visitados at que o pacote chegue ao destino.
Identicado pelo valor 43 no campo Next Header ;
Fragment Extension Header : utilizado quando o pacote IPv6 a ser enviado
maior que o Path MTU (Maximum Transmission Unit ) para o seu destino. No
IPv6, a fragmentao de pacotes feita somente no n de origem, devendo usar
uma descoberta de MTU para delimitar o tamanho mximo dos pacotes ao longo
do caminho at o destino. Identicado pelo valor 44 no campo Next Header ;
Destination Options Extension Header : utilizado para transportar informa-
es opcionais que precisam ser examinadas apenas pelo n de destino do pacote.
Identicado pelo valor 60 no campo Next Header.
17
2.3.3 Funcionalidades Bsicas do IPv6
Esta sesso tem o objetivo de apresentar aspectos tericos sobre as funcionalidades
bsicas do IPv6. No decorrer da exposio so feitas comparaes em relao ao IPv4,
com intuito de enfatizar as principais diferenas e seus motivos.
ICMPv6
A especicao do IPv6 redene o ICMP (Internet Control Message Protocol ) do IPv4
com algumas mudanas, resultando na denominao de protocolo ICMPv6 [26]. No IPv4,
uma prtica comum de alguns administradores, o bloqueio total de mensagens ICMP
na operao normal da rede. No mbito de redes IPv6, em situao normal de operao,
a prtica de bloqueio total de mensagens ICMPv6 no recomendada, uma vez que estas
mensagens so de uso fundamental para as funcionalidades bsicas do protocolo IPv6 [14].
O protocolo ICMPv6 muito mais poderoso do que ICMPv4 e contm novas funcio-
nalidades. Esta nova verso tem a capacidade de informar erros se os pacotes no podem
ser processados corretamente e enviar mensagens informativas sobre o status da rede. A
funo IGMP que gerencia as adeses do grupo multicast com IPv4 foi incorporada ao
ICMPv6. O mesmo ocorreu para os protocolos ARP/RARP (Address Resolution Proto-

col/Reverse Address Resolution Protocol ), funes usadas em IPv4 para mapear endereos
da camada 2 para endereos IP e vice-versa. Foi incorporado tambm o ND (Neighbor Dis-
covery ), utilizando mensagens ICMPv6 para determinar endereos de camada de enlace

para vizinhos ligados ao mesmo escopo de subrede, para encontrar roteadores, acompanhar
quais vizinhos so alcanveis e detectar os endereos de camada de enlace alterados. No-
vos tipos de mensagens foram denidas para tornar mais simples a renumerao de redes
e atualizao de informaes de endereo entre hosts e roteadores [2].
Todas as mensagens ICMPv6 possuem a mesma estrutura geral de cabealho como se
v na ilustrao adaptada Figura 2.6 [2]:
Campo Type (1 byte ) Especica o tipo de mensagem, o qual determina o formato
do restante da mensagem;
Campo Code (1 byte ) Identica o subtipo de mensagem dentro de cada valor do
tipo da mensagem ICMP;
Campo Checksum (2 bytes ) Usado para detectar dados corrompidos no cabea-
lho ICMPv6 e em parte do cabealho IPv6. Para calcular o checksum, um n deve
determinar os endereos de origem e destino no cabealho IPv6. Um campo pseudo-
cabealho do cabealho IPv6 anexado para o clculo da soma de vericao;
18
Figura 2.6: Estrutura geral de cabealho de mensagem ICMPv6
Campo Message Body (tamanho varivel) Depende dos valores em Type e
Code, o corpo da mensagem conter dados diversos. No caso de uma mensagem de
erro, para ajudar na soluo, ela vai conter, quanto possvel do pacote solicitado
na mensagem. O tamanho total do pacote ICMPv6 no deve exceder o mnimo do
MTU IPv6, que 1280 bytes [2].
NDP (Neighbor Discovery Protocol )

O NDP (Neighbor Discovery Protocol ) um novo protocolo dentro do IPv6 para a des-
coberta de vizinhana, concebido com o objetivo de sanar os problemas de relacionamento
entre os ns vizinhos de uma rede. O seu uso possibilita que ns de uma rede consigam
vericar a presena uns dos outros, apontar os endereos de seus vizinhos, descobrir ro-
teadores e manter informaes atualizadas sobre rotas a serem utilizadas na transmisso
de pacotes [14].
Para a comunicao entre ns em uma rede, os ns precisam de algumas informaes
alm do endereo de destino. Para obter essas informaes alguns procedimentos so
utilizados:
Router Discovery : atua na descoberta de roteadores pertencentes ao enlace;

Prex Discovery : atua na descoberta de prexos de redes do enlace, com objetivo
de decidir para onde os pacotes sero mandados numa comunicao, se para um
roteador especco ou direto para um n do enlace;
Parameter Discovery : hosts podem descobrir os parmetros IPv6 corretos para
qualquer enlace em que ele esteja inserido, como o MTU e o Hop Limit ;
Stateless Address Autoconguration : procedimento de autocongurao de
endereo Stateless na camada de enlace;
Address Resolution : atua na descoberta de endereo fsico de interfaces de rede
por meio de seu endereo lgico IPv6;
19
Next-Hop Determination : algoritmo utilizado para mapear endereos IP de
ns vizinhos para os quais pacotes devem ser enviados mediante seus endereos
de destino;
Neighbor Unreachability Detection : recurso utilizado para detectar se um n
vizinho ou continua sendo acessvel;
Duplicate Address Detection : atua na tarefa de descobrir se o endereo que se
deseja congurar j est sendo utilizado por um outro n na rede;
Redirect : permite que o roteador oriente um n na rede a respeito de uma melhor

rota a ser utilizada no encaminhamento de pacotes a um destino especco.
Dessa forma, o NDP age sobre dois aspectos principais da comunicao IPv6, a au-
tocongurao de ns na rede e a transmisso de pacotes entre os ns na rede. Assim,
as funcionalidades Parameter Discovery, Address Autoconguration e Duplicate Address

Detection inuenciam na autocongurao de ns na rede, enquanto as funcionalidades
Router Discovery, Prex Discovery, Address Resolution, Neighbor Unreachability Detec-
tion, Next-Hop Determination e Redirect inuenciam na transmisso de pacotes entre os
ns na rede.
Por meio de 5 mensagens do ICMPv6 o NDP consegue executar estas funcionalidades
citadas. Existem duas classes de mensagens ICMPv6, uma conhecida como mensagem
de erro ICMP que utiliza identicao dentro do range de 0 a 127, e a outra mensagem
informativa ICMP, identicada pelo range de 128 a 255 [15]:
Router Solicitation (Type 133) : enviada por um dispositivo para requisitar
que roteadores da rede imediatamente se apresentem atravs da resposta Router

Advertisement ;
Router Advertisement (Type 134) : enviada pelo roteador para anunciar sua
presena no enlace e suas conguraes, isto periodicamente ou como resposta a
uma mensagem Router Solicitation ;
Neighbor Solicitation (Type 135 ): enviada por um dispositivo para requisitar
que um vizinho se apresente imediatamente atravs da resposta Neighbor Advertise-

men t, atuando na descoberta de um endereo fsico atravs de um endereo lgico
como o papel do ARP no IPv4, no teste de acessibilidade de ns vizinhos do enlace,
alm da deteco de endereos IPv6 duplicados na vizinhana;
Neighbor Advertisement (Type 136) : enviada tanto em resposta a uma men-
sagem Neighbor Solicitation quanto para anunciar de forma voluntria, a alterao
20
de alguma caracterstica de um dispositivo na rede. Assim como no Neighbor Soli-
citation, tambm atua na resoluo de endereos fsicos, no teste de acessibilidade
de ns vizinhos e na deteco de endereos duplicados;
Redirect (Type 137) : enviada por roteadores para avisar a um n da rede sobre
uma melhor rota para alcanar um destino especco.
Autocongurao
A capacidade de autocongurao do IPv6 disponibiliza um substancial auxlio aos
administradores de rede. Por meio desta importante caracterstica, os diversos dispositivos
podem adquirir informaes da rede, do enlace e de endereamento. Isto leva a um grande
dinamismo Internet, visto que permite dispositivos se interconectarem sem a necessidade
de conguraes manuais.
Existem dois modos de divulgao de informaes para a autocongurao dos dispo-
sitivos:
Stateless : conhecido tambm pela sigla SLAAC (Stateless Address Autocongura-

tion ), o equipamento que fornece informaes de congurao no mantm o registro do
estado e das caractersticas do n destinatrio, ou seja, o n de destino se responsabiliza
por se autocongurar enquanto o n origem apenas informa as caractersticas da rede.
Por padro, endereo autocongurado por este modo criar um endereo Unicast Link-
Local formado pela juno do prexo (FE80::/64) com o identicador da interface fsica
da mquina. H vrias implementaes para a gerao desse identicador, a mais comum
baseada no endereo MAC. Se houver um daemon Router Advertisement congurado e
executando em um enlace, indica que um procedimento utilizado por roteadores para
transmitir informaes aos dispositivos, o que engloba desde propriedades do enlace, da
rede, de DNS, MTU, de prexos, dentre outras, as quais sero processadas e adicionadas
s conguraes dos dispositivos.
O n ao enviar uma requisio com mensagem Router Solicitation aos roteadores deste
enlace, tambm criar automaticamente um endereo Unicast do tipo Globals, utilizando
o prexo de subrede de 64 bits, caractersticas informadas pela mensagem Router Ad-
vertisement. A gerao do identicador de interface, os 64 bits restantes, pode tambm

ser obtida do endereo MAC do n, podendo ainda usar uma gerao aleatria desses 64
bits [14]. Ainda se tratando de mensagens Router Advertisement, outra alternativa por
iniciativa dos prprios roteadores que periodicamente enviam estas mensagens para anun-
ciar sua presena na rede e orientar os ns para autocongurao. Com o recebimento
da mensagem Router Advertisement, em qualquer dos modos, iniciado o processo de
autocongurao, caso este processo no tenha ocorrido anteriormente. Aps a concluso
do processo de gerao do endereo, este necessita ser conrmado como nico no enlace
21
Figura 2.7: Exemplo de Autocongurao de host
antes de ser adicionado interface. Assim, o mtodo de deteco de endereos duplicados
entra em ao, para s a partir desta conrmao, permitir que o n se comunique no
enlace [19].
Como pode ser notado por meio de ilustrao adaptada na Figura 2.7 [27], oshosts en-
viam uma mensagem Router Solicitation para todos os roteadores usando o endereo mul-
ticast (FF02::2) que indica todos os roteadores, e uma mensagem Router Advertisement
devolvida com informaes sobre a rede em questo, para posterior autocongurao do
dispositivo.
Stateful : os dispositivos obtm endereos ou conguraes de um servidor que man-

tm uma base de dados com todos os endereos que foram distribudos na rede. Esse tipo
de autocongurao permite que dispositivos clientes obtenham endereos, bem como ou-
tras conguraes, de um servidor centralizado, como ocorre no protocolo IPv4 com a
utilizao de um servidor DHCP, e no protocolo IPv6 com o DHCPv6 (Dynamic Host

Conguration Protocol for IPv6 ). Conguraes Stateful. so frequentemente emprega-
das quando h uma necessidade de maior rigor no controle com referncia aos endereos
alocados nos dispositivos, tendo a preocupao principal de manter os endereos ni-
cos. Dependendo das polticas da administrao de redes, pode ser necessrio que alguns
endereos sejam alocados para dispositivos especcos de modo permanente [27].
A autocongurao de endereos em modos Stateless e Stateful podem ser combinados.
Por exemplo, um host pode utilizar autocongurao de endereo Stateless para gerar um
endereo IPv6, mas, em seguida, usar o DHCPv6 para os parmetros adicionais [2].
DHCPv6
O DHCPv6 denido na RFC 3315 [28] a verso DHCP para o protocolo IPv6. De-
vido a recursos de autocongurao de endereos Stateless no IPv6, o DHCPv6 apresenta
22
algumas importantes diferenas se comparado ao seu predecessor, o DHCPv4 (Dynamic
Host Conguration Protocol for IPv4 ). As duas verses fornecem autocongurao Sta-
teful e registro automtico de host DNS. O DHCPv6 usa as portas 546 e 547 UDP, j o
DHCPv4 utiliza as portas 67 e 68 UDP [2].
Em cada rede deve haver ao menos um servidor DHCPv6 capaz de enviar dados para os
clientes se congurarem. Normalmente, os dispositivos comunicam em seuLink-Local com

o servidor DHCPv6 ou por meio de relay agents (All_DHCP_Relay_Agents_and_Servers ),
usando o endereo FF02::1:2 de Link-Local, mas, outros endereos podem ser utilizados
dependendo do servidor. O relay agent supracitado corresponde a um endereo Multicast
com escopo Node-Local usado para que clientes enviem mensagens aos roteadores, e aos
servidores de destino que se localizam na vizinhana. Em algumas redes simples, no h
Figura 2.8: Formato do pacote DHCPv6
necessidade do uso do DHCPv6 por causa do recurso de autocongurao de endereos
Stateless. No entanto, DHCPv6 uma soluo que possibilita que ns IPv6 aprendam
automaticamente os endereos IPv6 e os servidores DNS. Para as redes que trabalham
simultaneamente com as duas verses do protocolo IP, no h conito entre DHCPv4 e
DHCPv6, e ambos podem existir mesmo em um nico n. Neste caso, o lado IPv4 de
um n teria sua congurao IPv4 do servidor DHCPv4, e do lado IPv6 do n teria sua
congurao IPv6 do servidor DHCPv6.
Com o DHCPv6, o administrador de rede consegue melhorar signicativamente o
controle sobre a distribuio de identicadores de interface, muito mais eciente que
com a autocongurao de endereos Stateless. E nem todas as comunicaes DHCPv6
precisam ocorrer dentro do mesmo enlace, precisando para tal, utilizar roteadores para
retransmitir tanto as mensagens do cliente quanto as do servidor.
Tal como acontece com DHCPv4, relay agents so usados para permitir que os dis-
positivos se comuniquem com servidores DHCPv6 remotos. Isso ainda feito via UDP,
mas usando um endereo Multicast Site-Local

de escopo (FF05::1:3), que usado apenas
por relay agents denominados por All_DHCP_Servers, utilizados pelos roteadores para
se comunicarem com os servidores DHCPv6 ao retransmitirem as mensagens recebidas
dos clientes.
H 13 tipos de mensagens no protocolo DHCPv6 que podem ser utilizadas para troca
de informao entre clientes e servidores, com ou sem roteadores no meio do caminho:
23
SOLICIT (1): enviada por um cliente para localizar um servidor DHCPv6;
ADVERTISE (2): enviada pelo servidor DHCPv6 como resposta mensagem
SOLICIT de cliente;
REQUEST (3): enviada por um cliente a um servidor DHCPv6 para solicitar
dados de congurao;
CONFIRM (4): enviada por um cliente a um servidor DHCPv6 para vericar se
endereo e parmetros de congurao permanecem vlidos para uso no enlace;
RENEW (5): enviada por um cliente a um servidor DHCPv6 para estender o
tempo de vida do seu endereo e atualizar outros parmetros de congurao;
REBIND (6): enviada por um cliente a qualquer servidor DHCPv6 para estender
o tempo de vida do seu endereo e atualizar outros parmetros de congurao, isto
quando sua alocao estiver prximo de expirar e no ter recebido uma resposta da
mensagem RENEW ;
REPLY SOLI-
(7): enviada pelo servidor DHCPv6 como resposta s mensagens
CIT, REQUEST, RENEW e REBIND de cliente com um Rapid Commit Option.

Um REPLY a uma mensagem INFORMATION-REQUEST contm somente par-
metros de conguraes, mas nenhum endereo IP. Um REPLY a uma mensagem
CONFIRM contm uma conrmao ou negao de que o endereo IP do cliente

ainda vlido para o enlace. Por m, um servidor DHCPv6 envia uma mensagem
REPLY para informar que recebeu as mensagens RELEASE e DECLINE ;
RELEASE (8): enviada por um cliente a um servidor DHCPv6 que lhe concedeu
endereo IP, para indicar que deixar de usar o endereo alocado;
DECLINE (9): enviada por um cliente a um servidor DHCPv6 para informar que
um ou mais endereos que foram transmitidos para autocongurao j est(o)
sendo utilizado(s) no enlace;
RECONFIGURE (10): enviada pelo servidor DHCPv6 a cliente j congurado
para informar que o servidor possui novas informaes de congurao ou sofreu
atualizao. Assim, o cliente inicia atualizao por meio de transaes RENEW/-

REPLY ou INFORMATION-REQUEST/REPLY ;
INFORMATION-REQUEST (11): enviada por um cliente a um servidor DHCPv6

solicitando parmetros adicionais de conguraes, sem informaes de endereo IP;
RELAY-FORW (12): enviada por um roteador por meio de relay agent para
encaminhar mensagens para os servidores DHCPv6, seja diretamente ou atravs de
24
outro relay agent. A mensagem recebida, uma mensagem de um cliente ou uma
mensagem RELAY-FORW de outro relay agent, encapsulada em uma opo na
mensagem de RELAY-FORW ;
RELAY-REPL (13): enviada pelo servidor DHCPv6 aos clientes por meio de relay.
Esta mensagem pode ser retransmitida entre roteadores at alcanar o cliente, uma
vez que, a mensagem do cliente apresenta-se encapsulada nas opes da mensagem
RELAY-REPL. O ltimo roteador deve extra-la e envi-la ao cliente.
O pacote DHCPv6 muito simples, todas as mensagens trocadas entre clientes e
servidores que se encontrem no mesmo enlace utilizam um formato geral, um cabealho
xo com uma parte varivel para opes, como pode ser notado na ilustrao adaptada
pela Figura 2.8 [2].
O campo Message Type composto de 8 bits e dene o tipo de mensagem dentro
do protocolo, delimitando assim as opes da mensagem no campo Options. Para cada
REQUEST o cliente gera um novo cdigo de identicao da transao e registra no
campo Transaction ID, campo composto de 24 bits, possibilitando que em um uxo de
mensagens seja possvel saber se a mensagem uma resposta a uma solicitao especca.
Quanto ao campo Options, formado por um tamanho varivel, sendo usado para fornecer
informaes de parmetros de congurao.
Entretanto, quando na comunicao entre clientes e servidores h roteadores utilizando
relay agents, os pacotes precisam passar por uma transformao antes de serem envia-
dos pelo servidor. Os pacotes alterados possuem o formato demonstrado na ilustrao
adaptada pela Figura 2.9 [2].
A composio do campo Message Type continua sendo de 8 bits, determinando o tipo
de mensagem dentro do protocolo, o que permite delimitar as opes da mensagem no
campoOptions. Neste campo, quando especicado o valor 12, indica o uso de mensagem
RELAY-FORW, e quando especicado o valor 13, a mensagem a ser usada passa a ser
RELAY-REPL.
Figura 2.9: Formato do pacote DHCPv6 em Relay Agents e mensagens de servidores
25
O campo Hop Count composto de 8 bits responsvel por contabilizar a quantidade
de roteadores atravessados antes que a solicitao alcance o servidor DHCPv6. Baseado
no campo Link Address (128 bits ), em uma mensagem RELAY-FORW, o servidor pode
identicar o enlace de localizao do cliente que executou uma solicitao. Neste campo
contm o endereo Global ou Site-Local para localizao do cliente. J no campo Peer

Address bits ), contm o endereo do cliente ou do roteador que enviou a mensagem.
(128
Por m, o campo Options que tambm tem tamanho varivel, utilizado para encaminhar
informaes extras que auxiliam no mecanismo de autocongurao [14].
2.3.4 Roteamento no IPv6
O roteamento o processo utilizado na Internet para encaminhamento de pacotes entre
redes. Os protocolos de roteamento IP se dividem entre IGP (Interior Gateway Protocol )

que foi projetado para uso dentro de um AS (Autonomous System ), ou seja, entre os rote-
adores que so controlados pela mesma empresa ou organizao, e que incluem protocolos
como RIP (Routing Information Protocol ), IS-IS (Intermediate System to Intermediate

System ) e OSPF (Open Shortest Path First ). O outro tipo o EGP (Exterior Gateway
Protocol ), que foi projetado para troca de rotas entre ASs, como entre operadoras de rede,
onde encontra-se inserido o protocolo BGP (Border Gateway Protocol ) [29].
Para suportar o IPv6, estes protocolos de roteamento supracitados precisaram passar
por adequaes, principalmente a respeito da acomodao do tamanho dos endereos IP.
Esta seo cobrir sucintamente os protocolos de roteamento OSPF e BGP, uma vez que
so os que mais contribuiro para o desenvolvimento do estudo em questo.
OSPF
Projetado para ambientes de rede TCP/IP, o OSPF um protocolo do tipo link-state
que envia avisos sobre o estado da conexo a todos os outros roteadores em uma mesma
rea hierrquica [7]. O OSPF usa o algoritmo SPF (Shortest Path First ), baseado no al-
goritmo de Dijkstra para a escolha do melhor caminho e permite agrupar os roteadores em
reas, trabalhando de forma hierrquica, dividindo os roteadores de uma rede em diversas
reas, como se v na Figura 2.10. A cada uma dessas reas atribudo um identicador
nico (Area-ID ) de 32 bits e todos os roteadores de uma mesma rea mantm um banco
de dados de estado separado, de modo que a topologia de uma rea seja desconhecida
fora dela. Isso reduz o volume de trfego de roteamento entre diferentes partes da rede.
A rea identicada pelo ID 0 (ou 0.0.0.0) rea de backbone a responsvel por difundir as
informaes de roteamento. Em rede onde no existem tais divises, a rea de backbone

a nica a ser congurada.
26
Figura 2.10: Exemplo de topologia de rede sob protocolo OSPF
O OSPF verso 3 denido na RFC 5340 [30] um protocolo utilizado unicamente
em redes IPv6 e foi baseado na verso do OSPF verso 2 , utilizada em redes IPv4.
Deste modo, em uma rede com Pilha Dupla, necessrio utilizar tanto OSPFv2, para o
roteamento IPv4, quanto o OSPFv3, para o roteamento IPv6. A maioria dos algoritmos do
OSPFv2 foram preservados no OSPFv3. No entanto, algumas mudanas foram necessrias
referentes semntica do protocolo entre IPv4 e IPv6 ou simplesmente quanto ao aumento
do tamanho do endereo IPv6 [30]. O protocolo OSPFv3 processado por link, e no por
Figura 2.11: Exemplo de mltiplas instncias do OSPF em execuo em um Link
subrede como no OSPFv2. O termo link usado para indicar um meio sobre o qual
os ns podem se comunicar na camada de enlace [12]. Mltiplas instncias do OSPFv3
podem ser executadas em um link, como pode ser visto na Figura 2.11 e exemplicado na
sequncia.
Conectados mesma rede os routers A, B, C e D compartilham o mesmo link e
podem estabelecer relaes de vizinhana entre eles. Na primeira instncia do OSPFv3
so conguradas as interfaces Eth1/0, Eth1/1 e Eth1/2 respectivamente nos routers A,
B e C. J na segunda instncia do OSPFv3 conguradas as interfaces Eth1/0, Eth1/1
e Eth1/3 respectivamente nos routers A, B e D. As relaes de vizinhana da primeira
27
instncia so estabelecidas entre os routers A, B e C, enquanto que na segunda instncia
so estabelecidas entre os routers A, B e D.
Figura 2.12: Formatos de cabealhos dos protocolos OSPFv3 e OSPFv2
O OSPFv3, assim como o OSPFv2, processa pacotes que so enviados somente ao
longo da vizinhana, com exceo do pacote Hello, que usado para descobrir vizinhos.
As funes e tipos de pacotes so os mesmos em ambos IPv4 e IPv6, codicada pelo campo
Link state Type do cabealho padro do pacote OSPF, este apresentado por meio de ilus-
trao adaptada pela Figura 2.12 [14], na qual nota-se que o campo Options do OSPFv2
foi removido do OSPFv3. Na sequncia seguem relacionados os campos do cabealho
OSPFv3 [30]:
Link state age : aponta o tempo em segundos desde que o LSA foi originado;
Link state type : aponta a funo desempenhada pelo LSA;
Link state ID : identicador de origem do roteador para o LSA. A combinao de
Link state ID, Link state type e Advertising Router identicam unicamente o LSA
na base de dados de estado de link ;
Advertising Router : indica o Router ID do roteador que originou o LSA;

Link state sequence number : instncias sucessivas de um LSA so dadas por
sucessivos nmeros de sequncias de estado de link. O nmero de seqncia pode
ser usado para detectar casos de LSA antigos ou duplicados;
Link state checksum : aponta a vericao pelo algoritmo Fletcher checksum do
contedo completo do LSA;
Length : aponta o tamanho em bytes do LSA.
Assim como no OSPFv2, o OSPFv3 opera com 5 tipos de pacotes [30]:
Hello packets : pacote periodicamente enviado para estabelecer e manter o relaci-

onamento com os vizinhos;
Database Description : estes pacotes so trocados depois que uma vizinhana
iniciada e descreve o contedo da base de dados do estado de link ;
28
Link State Request : aps a troca de pacotes Database Description com um rote-
ador vizinho, um roteador pode encontrar alguns LSAs faltantes. Para obter esses
LSAs, o roteador envia pacotes Link State Request que carregam o resumo desses
LSAs para o vizinho;
Link State Update : cada pacote transporta uma coleo de LSAs;

Link State Acknowledgment : so enviados para reconhecer os LSAs recebidos.
BGP
O BGP como referido anteriormente, o acrnimo de Border Gateway Protocol, usado
para roteamento entre Sistemas Autnomos. Ele trabalha transmitindo informaes sobre
quem pode alcanar qual prexo CIDR, em essncia quais endereos, e por qual rede [13].
Na ilustrao adaptada Figura 2.13 [7], mostra a interao entre protocolos IGP e EGP, no
qual o BGP utilizado entre 02 (dois) ASs e o OSPF para comunicao entre roteadores
internos nas redes. No h atualmente uma verso especca de protocolo BGP para
Figura 2.13: Interao entre protocolos de roteamento BGP e OSPF
operao em IPv6. A verso 4 do BGP (BGP-4) denido na RFC 4271 [31], suporta
somente o IPv4, mas h denies de extenses de multiprotocolos do BGP-4 (BGP-4+)
designados na RFC 4760 [32] que permitem o suporte ao IPv6 e outros protocolos [2].
2.3.5 Segurana com IPv6
Para o propsito do estudo em questo, e por ser um tema que exige uma abordagem
pontual e aprofundada, a segurana no trfego IPv6 ser tratada de forma sucinta e
baseada em alguns focos de grande relevncia, como Endereos Temporrios, os Endereos
Criptogracamente Gerados, e o IPSec.
29
Endereos Temporrios
Os endereos temporrios podem auxiliar na segurana da arquitetura de rede, pos-
suem curta durao e so alterados de tempos em tempos. Em geral, no possvel
distingui-los dos endereos pblicos. Por meio da Figura 2.14, imagem gerada no ambi-
ente de laboratrio, com o prexo de rede 2001:DB8:CAFE::/64 v-se a autocongurao
de dois endereos IPv6 com suxos diferentes, sendo um originalmente gerado atravs do
endereo MAC (vermelho) e outro temporrio gerado aleatoriamente (amarelo).
A RFC 4941, Privacy Extensions for Stateless Address Autoconguration in IPv6, de-
ne formas de gerar e alterar esses endereos temporrios atravs de extenses de privaci-
dade. As condies importantes so que a sequncia de endereos temporrios escolhidos
para uma interface deve ser totalmente imprevisvel, sem um esquema especco, e ter
baixa probabilidade de colidir com as escolhas feitas por outras interfaces [29].
Em alguns sistemas operacionais estas extenses de privacidade so adotadas por
entender que usar o endereo MAC das interfaces de rede no prprio endereo IPv6
um risco de segurana que atinge a privacidade dos usurios, uma vez que ca mais fcil
rastrear a mquina do usurio independente da rede em que ele esteja [15]. O uso de
Figura 2.14: Exemplo de gerao de endereo temporrio em sistema operacional Linux
atribuies de endereos temporrios pode ser de muita utilidade para a privacidade. Em
muitos casos em que as empresas administram suas prprias redes, atribuies de endereo
por meio do DHCPv6 pode ser prefervel.
Endereos Criptogracamente Gerados

Os Endereos Criptogracamente Gerados, referenciados constantemente pelo acr-
nimo CGA (Cryptographically Generated Addresses ), tambm conhecidos como endereos

baseados em hash, fornece um mtodo de garantir que o originador de uma mensagem de
30
Neighbor Discovery o dono do endereo contido na mensagem. Como se v na ilustra-
o adaptada pela Figura 2.15 [29], a idia escolher um par de chave pblica e privada
adequado para criar uma assinatura digital com uma chave privada e ento as vericar
com a chave pblica. A chave pblica, junto a outros parmetros, so usados para gerar
uma identicao de interface, a chave pblica inserida dentro da mensagem, e a men-
sagem marcada com a chave privada. A chave pblica pode ser usada para vericao
de endereos e assinatura. Um atacante sem a chave privada no pode forjar a assinatura
da mensagem.
Figura 2.15: Gerao de endereo criptogrco com par de chave pblico-privada
O CGA pode ser usado para aumentar a segurana em uma rede IPv6, mas em muitos
casos este mtodo no tem sido percebido como vantajoso, alm de gerar mais overhead
do que o IPSec ou protocolos de segurana de camadas mais altas. O CGA tem sido
padronizado como a principal segurana na criao de blocos para o Secure Neighbor

Discovery do IPv6.
IPSec
O modelo de segurana com IPSec, j familiar para muitos por ela ser a base de
muitos sistemas VPN (Virtual Private Network ) que j encontram-se implantados. A
arquitetura do IPSec de considervel complexidade, e descrita na RFC 2401 [33].
No IPv6, o IPSec implementado com o uso de cabealho de extenso, e utilizado para
encriptar e autenticar pacotes IP. Ele projetado para proteger qualquer trfego da apli-
cao por estar estabelecido na camada de Internet (rede). H trs principais protocolos
que o IPSec usa para realizar suas funes [34]:
Security Association (SA): este gera as chaves de encriptao e autenticao
que sero usadas pelo IPSec. Uma vez executado papel do SA, a segurana dos
servios garantida pela utilizao dos protocolos de segurana (AH, ESP, ou ainda
de ambos);
31
Authentication Header (AH): este fornece autenticao, integridade e proteo
anti-repetio para o pacote inteiro (o cabealho IP e o payload ). Ele no fornece
condencialidade, o que signica que ele no criptografa os dados. Os dados so
legveis, mas protegidos contra modicao. O cabealho AH usa algoritmos de hash

com chave para assinar o pacote para ns de integridade;
Encapsulating Security Payload (ESP): este prov a garantia de privacidade dos

dados, utilizando criptograa para que apenas o destino seja capaz de decodicar
as informaes. Tambm fornece um mecanismo opcional prprio de autenticao,
para o caso de o AH no estar sendo utilizado. formado por trs campos, sendo eles
um cabealho ESP, uma cauda ESP e um campo referente a autenticao opcional.
Dependendo das necessidades da rede, o AH e o ESP podem ser usados em conjunto
para fornecer tanto autenticao quanto privacidade, no entanto, eles podem operar sepa-
radamente, sendo apenas um deles suciente para atender a maioria dos casos. Alm disso,
o IPSec pode ser implementado seguindo dois modos diferentes de operao, denominados
modo de transporte e modo de tunelamento.
No IPv6, no modo de transporte, os cabealhos de segurana so adicionados depois
do cabealho IP, encriptando apenas do cabealho de transporte em diante. Dessa forma,
a origem e destino do pacote cam visveis na rede pblica. J no modo de tunelamento
os cabealhos de segurana so adicionados na frente de todo o pacote original, que
totalmente encriptado, e ento adicionado na frente dos cabealhos de segurana um
novo cabealho IP. Portanto, um tnel IPSec estabelecido entre a origem e destino deste
novo cabealho IP, por onde iro trafegar os pacotes IP encriptados. As extremidades do
tnel IPSec podem ser roteadores encarregados de lidar com os protocolos do IPSec e
posteriormente encaminhar os pacotes desencriptados aos seus sistemas nais, que no
precisam estar a par da utilizao do IPSec [14].

Neste captulo foram abordadas as principais caractersticas a respeito do protocolo
IP em suas verses 4 e 6, com exposio terica sucinta sobre suas caractersticas e
as fundamentais evolues da verso 4 para a 6. Em conformidade com o estudo em
questo, o protocolo IPv6 foi alvo de uma dedicao e exposio de maior abrangncia,
com ateno especial ao conjunto de protocolos que amparam desde suas funcionalidades
bsicas a particularidades concernentes ao IPv6.
32
Captulo 3
Transio entre os protocolos IPv4 e

IPv6
Neste captulo sero abordadas as principais tcnicas disponveis e amplamente utiliza-
das na transio entre os protocolos IPv4 e IPv6. Uma palavra chave na fase de transio
a interoperabilidade entre estes protocolos, as duas verses devem coexistir na rede si-
multaneamente se comunicando. Nesse intuito, nos idos anos de 2005 a IETF por meio
da RFC 4038 [35] intitulado por Aspectos de Aplicao da Transio IPv6 apresentou o
desenvolvimento de mecanismos que intentam na colaborao para a transio de forma
gradativa e suave [35]. O objetivo no promover uma transio de forma abrupta de
todo o ambiente de rede IPv4 para IPv6, isso levaria a um transtorno incomensurvel, e
com pouca probabilidade de sucesso.
Nesse documento, so denidos mecanismos em 3 grupos principais, o conhecido como
Tunelamento ou Tunneling que permite o transporte de trfego IPv6 sobre a infraestru-
tura de IPv4 existente o Traduo ou Translation que permite ns somente com IPv6 se
comunicarem com ns somente IPv4 e por m o Pilha Dupla ou Dual Stack que permite
que IPv4 e IPv6 coexistam nos mesmos dispositivos e redes.
3.1 Tunelamento ou Tunneling

O mecanismo de Tunelamento pode ser usado para implantar uma infraestrutura de
encaminhamento IPv6 enquanto a infraestrutura global de IPv4 ainda a base [2]. Esta
tcnica pode ser usada para transportar o trfego IPv6 atravs do encapsulamento em
pacotes IPv4 de forma a viabilizar a transmisso sobre a infraestrutura IPv4. Por exem-
plo, se um provedor de acesso Internet tem uma infraestrutura somente com IPv4, o
Tunelamento permite que se tenha uma rede IPv6 e tnel atravs dessa rede de provedor
IPv4 para chegar a outros ns ou redes IPv6.
33
O Tunelamento um mecanismo pelo qual um protocolo encapsulado em outro pro-
tocolo para ser transportado atravs de uma rede onde o protocolo original normalmente
no suportado ou que seja processado de alguma forma indesejada. O tunelamento do
IPv6 no IPv4 (6in4 ) normalmente feito simplesmente adicionando um cabealho IPv4
antes do pacote IPv6. O resultado do pacote ento encaminhado para o endereo de
destino informado no cabealho IPv4, e nesse destino, o cabealho externo retirado, e o
pacote processado como se tivesse sido recebido atravs de um ambiente IPv6 habilitado
[15]. Uma ilustrao adaptada desse processo pode ser visto na Figura 3.1. Tambm
possvel, de forma anloga, encapsular pacotes IPv4 em pacotes IPv6, tcnica conhecida
como IPv4 em IPv6 (4in6 ).
Figura 3.1: Tunelamento de pacotes IPv6 atravs de rede IPv4
Denies em RFCs descrevem dois tipos de Tunelamento. Um o Tunelamento
Congurado e o outro Automtico, respectivamente de natureza esttica e dinmica. O
primeiro necessita de administradores dos sistemas para congurar os pontos nais do
tnel. Com o segundo, os ns so autocongurveis. Geralmente, em ambientes corpo-
rativos usado o Tunelamento Congurado para infraestruturas de tneis, enquanto a
forma de Tunelamento Automtico so aplicados em hosts para tunelar o retorno das ilhas
IPv4 ou IPv6. Atualmente, existem diferentes mecanismos de Tunelamento Automtico,
abaixo seguem alguns:
6over4 : para uso de host para roteador ou de roteador para host ;

6to4 e 6rd : para uso de roteador para roteador;
ISATAP : para uso de Tunelamento intra-sites ;
Teredo : para encapsulamento UDP destinados para tunelamento atravs de NAT
IPv4.
No aspecto segurana do Tunelamento, necessrio fazer algumas consideraes, o
primeiro quanto s extremidades do tnel, estas so sempre um ponto de foco para a
34
segurana, so alvos frequentes de ataques. Potencialmente, o trfego de qualquer lugar
pode chegar a pontos de extremidade do tnel. O segundo a respeito de inspeo do
trfego encapsulado, pois no se deve encar-los como conveis sem uma devida inspeo,
isto requer examinar o trfego IPv6 dentro de pacotes IPv4 e submet-lo ao controle de
segurana local. Aplicando as polticas de segurana em ambas as entradas e sadas do
tnel, ir proteger o tnel de provveis ataques.
Por ltimo, as ACLs (Access Control Lists ) nos roteadores IPv4 podem ser incapazes
de bloquear o acesso rede de endereos IPv6 especcos ou de blocos inteiros de endereos
IPv6, eles podem no ter habilidade de reconhecer os nmeros dos campos next header
do IPv6, o tipo de mensagem ICMPv6, ou nmero de porta para TCP ou UDP sobre
IPv6. O motivo que o cabealho IPv6 e endereos no so visveis para o roteador,
eles so parte do pacote de payload, que a inteno funcional de qualquer processo de
encapsulamento [29].
3.2 Traduo ou Translation

No domnio das redes IPv4, a Traduo, conhecida h muitos anos pela tcnica NAT
foi denida para mapeamento entre endereos privados dentro de uma rede e um endereo
pblico em direo ao mundo exterior, am de sanar a crescente escassez de endereos
IPv4 pblicos.
Assim, com objetivo de fornecer conectividade para muitos dispositivos, o NAT no
mapeia apenas os endereos dos dispositivos, mas tambm utiliza portas para cada en-
dereo para mapear mltiplos endereos privados para um endereo pblico. Esta uma
tcnica tipo stateful, pois o gateway precisa manter o estado para rotear corretamente
pacotes de retorno. Atualmente, em uma orbe onde os protocolos IPv4 e IPv6 necessitam
de interao, este tipo de NAT referenciado como NAT44 (Network Address Translator
from IPv4 to IPv4 ).
O fato que a tcnica de Traduo apresenta-se como uma importante tecnologia para
auxiliar na transio do IPv4 para o IPv6, como suporte administrao do acelerado
crescimento da Internet. Mesmo que novos usurios da Internet s obtenham endereos
IPv6, eles no so capazes de acessar contedos sobre as predominantes redes IPv4, exceto,
se existir um elemento com papel de Traduo. Com isso, a IETF decidiu denir mtodos
padres de Traduo para impedir a proliferao de mtodos independentes e sem padres
globais. O mecanismo de Traduo consiste em transformar pacotes IPv4 em IPv6 e vice-
versa, para que possam ser roteados ou transmitidos em uma rede [2].
35
A tcnica de Traduo pode ocorrer em diferentes camadas da pilha de protocolo,
dentre elas, Internet, Transporte e Aplicao, e nesta seo, diferentes mtodos para
implementaes da Traduo sero abordadas [27].
O mtodo SIIT (Stateless IP/ICMP Translation ) que encontra-se na camada Internet

e denido na RFC 2765 [36], permite a substituio de cabealhos IPv4 para IPv6 de
modo recproco. A Traduo no nvel IP relativamente simples, o campo Time to Live

copiado para o Hop Limit, os bits do campo Type of Service copiados para Trac Class,
o comprimento do payload recalculado e campos fragmentados podem ser copiados
para um cabealho fragmentado se necessrio. Este mtodo tambm traduz mensagens
ICMP e adiciona um pseudo-cabealho ICMP com intuito de vericao da integridade,
se necessrio, ele fragmenta e reagrupa as mensagens.
O NAT-PT (Network Address Translation-Protocol Translation ), usa o mtodo SIIT
e possibilita a comunicao entre sistemas e servios de ambos protocolos IPv6 e IPv4, e
assim amplia o conjunto de possibilidade de interoperao entre estes protocolos. Como
dene a RFC 4966, o NAT-PT tem aplicao limitada, proporcionando mais benefcios
na transio por tornar possvel a conectividade de aplicaes legadas que podem nunca
terem suporte a IPv6.
Outro mtodo que atua na camada Internet o BIS (Bump in the Stack ), denido na
RFC 2767 [37], muito similar ao NAT-PT combinado com o SIIT, mas a motivao
ligeiramente diferente. Usado em casos onde h a necessidade de migrao para o IPv6
de algum sistema, mas no se consegue uma verso do sistema compatvel com o IPv6.
O BIS, no entanto, apresenta algumas limitaes, a comunicao restrita a um nico
sentido, partindo de um host IPv4 outro IPv6, alm de que, em comunicao entre hosts
IPv4, h a necessidade de uso de Traduo em algum ponto das aplicaes envolvidas.
Outro fator de limitao, que no funciona em comunicaes multicast.

A operao do mtodo BIS desempenhada de forma que, o software ao realizar uma
consulta DNS sobre um host IPv6, recebe do BIS um endereo IPv4 privado para repre-
sentar tal host, e o software pode utilizar o endereo designado normalmente. Os pacotes
destinados a este endereo IPv4 so interceptados pelo BIS, que utiliza o mecanismo de
SIIT para traduzi-los e envi-los seu destino IPv6. A ao de retorno do pacote acontece
de forma semelhante, com o BIS traduzindo os pacotes para IPv4.
O TRT (Transport Relay Translator ) proposto na RFC 3142 [38], atua na camada de
Transporte, e permite que hosts IPv6 troquem trfego (TCP ou UDP) com hosts IPv4,
tendo como vantagem o fato de poder ser implementado sem modicaes extras tanto
nos hosts IPv6 quanto em hosts IPv4. Para tal, apenas necessita de um elemento que
trabalhe com ambos protocolos IPv4 e IPv6 inserido em um ponto intermedirio da rede.
Apesar de ser um mtodo simples, este suporta a maioria das aplicaes amplamente
36
utilizadas, alm de possuir alta escalabilidade.
No mtodo TRT, quando um host IPv6 precisa se comunicar com um host IPv4, o
host IPv6 deve inserir um prexo falso ao endereo IPv4 que deseja alcanar. O pa-
cote contendo tal prexo interceptado quando passa pelo TRT, para ser traduzido e
encaminhado ao destino [27].
Por m, o mtodo BIA (Bump in the API ) denido pela RFC 3338 [39], opera de forma
similar ao BIS, exceto pelo fato de que a Traduo ocorre em uma camada mais alta, a
de Aplicao. Seu objetivo principal o mesmo do BIS, isto , permitir que aplicaes
em IPv4 se comuniquem com hosts IPv6 sem qualquer modicao da aplicao IPv4.
Entretanto, enquanto o BIS opera em sistemas apenas em IPv4, o BIA requer que o
sistema possua as duas verses do protocolo IP.
O mtodo BIA atua incluindo uma API (Application Programming Interface ) de Tra-
duo entre o socket API e os mdulos TCP/IP da pilha dupla de um host, com a inteno
de traduzir as funes do socket IPv4 em funes do socket IPv6, e vice-versa, promovendo
a comunicao entre aplicaes IPv4 e IPv6 [27].
Em se tratando de mtodos de Traduo, relevante citar tambm o IVI, criado
inicialmente para possibilitar que servidores somente em IPv6 pudessem comunicar-se com
a Internet em IPv4. Para tal, um endereo IPv4 atribudo virtualmente ao dispositivo,
utilizando-se um mecanismo de Traduo de pacotes em modo stateless [14].
A compreenso do conceito IVI ca mais claro ao se pressupor que ele cria um host
IPv6 espelho para o IPv4 e um host IPv4 espelho para o IPv6, considerando que um host
espelho um endereo que simula a presena do dispositivo na rede, mas que na verdade
encaminha os pacotes enviados a ele para o host real por meio da Traduo stateless.
O servidor ou usurio IPv6 nativo na rede onde o IVI encontra-se implementado,
embora no possua um endereo IPv4 atribudo a si, alcanado por um host IPv4 na
Internet atravs de seu endereo espelho e, de forma semelhante, alcana um host IPv4
qualquer na Internet atravs de seu endereo IPv6 espelho.
Algumas consideraes so necessrias a respeito da Traduo, ela no recomendada
como estratgia para conduzir uma transio do IPv4 para o IPv6 por vrias razes.
Traduzir endereos IPv6 para IPv4, efetivamente rejeita muitos dos motivos convincentes
para migrao para o IPv6. A Traduo no soluciona, por exemplo, o problema da
exausto do espao de endereamento IPv4. No entanto, um sistema implementado apenas
sobre o IPv6 no pode comunicar com outro sistema em operao apenas sobre o IPv4,
a menos que a Traduo ocorra em algum lugar, por isso, a Traduo necessria para
manter aplicaes legadas em IPv4 isoladas executando de forma diferente no universo do
IPv6 [29].
37
importante salientar que a Traduo pode resultar em perda de caractersticas rele-
vantes quando no h um mapeamento claro entre os recursos fornecidos pelo mecanismo.
Por exemplo, a Traduo de um cabealho IPv6 em um cabealho IPv4 pode levar perda
da etiqueta de uxo IPv6 que acompanha a funcionalidade.
Embora apresente como uma tecnologia ecaz, a tcnica de Traduo no suporta
algumas caractersticas avanadas do IPv6, tal como os servios de segurana, controle
de acesso, condencialidade e integridade de dados, alm de impor algumas limitaes
estrutura topolgica da rede, pois qualquer mensagem enviada pelo elemento tradutor
dever retornar pelo mesmo elemento.
3.3 Pilha Dupla ou Dual Stack

Um host em Pilha Dupla tem suporte para os protocolos IPv4 e IPv6, sendo tambm
referido como um host IPv6/IPv4 e tem, pelo menos, um endereo para cada verso de
protocolo. Em comunicao com outro host IPv6, tal host se comporta como um host
somente IPv6, e em comunicao com um host IPv4, ele se comporta como um host
somente IPv4. Um host em Pilha Dupla utiliza mecanismos IPv4 para congurar um
endereo IPv4 (congurao esttica ou DHCP) e utiliza mecanismos IPv6 para congurar
um endereo IPv6 (congurao esttica, SLAAC ou DHCPv6).
Implementaes ainda podem permitir habilitar ou desabilitar um dos protocolos de
um host em Pilha Dupla. Por meio da ilustrao adaptada na Figura 3.2 [40] apresentado
de forma sucinta um cenrio de rede em Pilha Dupla.
Figura 3.2: Cenrio de rede em Pilha Dupla
O DNS utilizado em ambas verses do protocolo para resolver nomes e endereos IP.
Nos hosts em Pilha Dupla necessrio que o DNS seja capaz de resolver diferentes tipos
de registros de endereos IPv4 e IPv6.
38
Dependendo de como um servio alcanado, sobre IPv4, ou IPv6 ou ainda por ambos,
o DNS pode retornar somente em IPv4, ou somente em IPv6 ou ambos. Mecanismos de
seleo de endereos padro e pers podem garantir que as conexes sejam estabelecidas
de forma eciente em qualquer caso, tendo como exemplo, o Happy Eyeballs, que ser
abordado a frente [2].
Um host em Pilha Dupla deve incluir o cdigo na camada Internet da pilha de protocolo
TCP/IP para processar ambos pacotes IPv4 e IPv6. Normalmente, h um nico enlace
disponvel para enviar e receber pacotes IPv4 ou IPv6, e neste enlace, ainda encontra-se
os protocolos ARP do IPv4 e o ND do IPv6.
Na camada de Transporte h pequenas diferenas na forma como os pacotes IPv4 e
IPv6 so tratados, principalmente relacionado forma de clculo checksum dos protoco-
los TCP e UDP, que abrange os endereos de origem e destino do cabealho IP, o que
obviamente diferente nas duas verses do protocolo IP.
J na camada de Aplicao, o cdigo pode fazer chamadas para rotinas no socket

API do IPv4, nos sockets API bsicos e avanados do IPv6. Funes de sockets IPv4 iro
acessar o lado IPv4, enquanto as funes de socket IPv6 acessaro o lado IPv6. Na Figura
3.3 [27], apresentada uma ilustrao adaptada do modelo de Pilha Dupla [14].
Figura 3.3: Modelo de Pilha Dupla
Uma vantagem signicativa desta tecnologia que ela executa os protocolos IPv4 e
IPv6 de modo nativo. Uma vez a infraestrutura habilitada para execuo de Pilha Dupla,
vivel dar incio migrao das aplicaes do IPv4 para o IPv6 gradualmente, o que
possibilita atualizao por pequenas partes.
O propsito do mtodo de Pilha Dupla reduzir quanto possvel o nmero de tneis
usados no processo de transio [29]. Uma implementao sem o uso de Tunelamento e
nem Traduo, o melhor cenrio para o desempenho, escalabilidade e ecincia, alm de
no haver necessidade de projetar, testar e executar mecanismos temporrios de transio
que precisam ser removidos mais tarde. Uma vez toda a rede ter sido atualizada para o
protocolo IPv6, basta desabilitar o protocolo antecessor.
Esta tecnologia exige uma atualizao de rede completa para possibilitar a execuo
das duas pilhas de protocolos IP. As tabelas de roteamento so mantidas simultaneamente
com roteamento IPv4 e IPv6. No aspecto segurana preciso tambm existir dois con-
39
ceitos, um para o IPv4 e outro para o IPv6, pois, so duas incurses na rede, e estas
precisam ser tratadas no requisito poltica de segurana.
Quanto ao gerenciamento da rede, apresenta ser mais complicado executar troublesho-

oting, e em alguns sistemas operacionais, dependendo do protocolo utilizado, os comandos
podem ser separados, e preciso mais memria e poder de processamento para execuo
de Pilha Dupla [2].
Utilizar pilha dupla pode no ser possvel em todas as ocasies. Por exemplo, quando
no h mais IPv4 disponveis e o provedor precisa atender a usurios novos com IPv6 e
IPv4. Para redes corporativas que j utilizam NAT isso no um impendimento, o IPv6
nativo pode ser utilizado em conjunto com o IPv4 compartilhado. Outra situao que
diculta a implantao do IPv6 usando pilha dupla a existncia de equipamentos que
no o suportam e que no podem ser facilmente substitudos.
Entretanto, vantagens da tcnica de Pilha Dupla como novos elementos de rede j
poderem ser endereados em IPv6 e os elementos j existentes poderem ser migrados em
fases sem grandes impactos, o gerenciamento da tcnica ser mais fcil, alm da infra-
estrutura interna oferecer condies favorveis implementao da tcnica, estes j so
aspectos de grande relevncia para uma escolha segura.
3.4 Consideraes sobre as Tecnologias de Transio

Com o teor j exposto, notvel que o principal objetivo na abordagem de Transio
entre os protocolos IPv4 e IPv6 de permitir que as duas verses se comuniquem sem
afetar o funcionamento da Internet, porm este fato no algo to simplista, pois no se
pode mudar a estrutura atual com o IPv4 para a nova estrutura com o IPv6 de uma s vez.
As organizaes ou operam redes em Pilha Dupla ou precisaro acomodar tanto o IPv4
e o IPv6 em rede atravs de outros meios. No entanto, o objetivo central da Transio
de alcanar uma nica rede IPv6, ou pelo menos com o IPv6 como o protocolo principal.
Dentre as tecnologias de Transio apresentadas, nenhuma cobre todas as necessidades
ou ideal para todos os cenrios de redes, mas possibilitam muitas combinaes e maneiras
de se garantir conectividade entre as verses do protocolo IP. Designar uma ou vrias
delas est diretamente relacionado ao seu domnio de aplicabilidade, suas propriedades,
a infraestrutura existente e as metas estabelecidas para transio, devendo ser capaz
de prover a interoperabilidade entre os protocolos e satisfazer s necessidades da rede
relacionadas disponibilidade, desempenho, escalabilidade e a segurana [2].
40
3.5 IPv6 em Hardwares e Sistemas Operacionais
Um planejamento antecipado de migrao para o IPv6 com ciclos de atualizaes, estes
geralmente realizados por meio de atualizaes com o trmino do ciclo de vida regular do
produto, pode levar a um custo nal menor nos investimentos em hardware e softwares.
Em muitos casos, o IPv6 no parte do hardware e pode ser instalado como parte do
sistema operacional ou como uma atualizao de software. Se as funes do protocolo
IP so implementadas puramente em hardware ou se o software do sistema no pode ser
atualizado, o hardware deve ser substitudo para suportar o IPv6.
Atualmente, os sistemas operacionais so em sua maioria fornecidos com IPv6 e sem
custo extra. Nos sistemas operacionais modernos, o IPv6 j vem habilitado por padro,
por exemplo, uma verso atualizada de Windows, Linux, MacOS, AIX ou BSD, o IPv6
j vem ativado.
No mbito dos hardwares, mais especicamente dos relacionados infraestrutura de
rede, os roteadores e switches devem fornecer um nvel equivalente de suporte ao IPv6,
no sacricando os recursos avanados do IPv6 nem comprometendo o throughput da rede.
3.6 Migrao de Aplicaes para o protocolo IPv6

A implementao do protocolo IPv6 na rede perfeitamente factvel, e muitas apli-
caes de uso abrangente e regular j executam sobre este novo protocolo, tais como,
web, correio eletrnico, FTP, SSH, dentre outros. Entretanto, muitas aplicaes no exe-
cutam sobre esta nova realidade do protocolo IP, sejam elas desenvolvidas pela prpria
organizao ou por terceiros.
Aplicaes desenvolvidas por terceiros se tiverem suporte a IPv6, normalmente as
utiliza em redes IPv4 com o IPv6 desabilitado, em caso de no suportar o IPv6, preciso
que conste em roadmap a previso de disponibilidade nas verses de atualizao.
Os cenrios elencados abaixo so frequentemente encontrados nas organizaes que
passam pelo processo de migrao:
Aplicaes IPv4 sobre ns em Pilha Dupla;
Aplicaes IPv6 sobre ns em Pilha Dupla;
Aplicaes que suportam IPv4 e IPv6 sobre ns em Pilha Dupla;
Aplicaes que suportam IPv4 e IPv6 sobre ns somente IPv4;
Aplicaes que suportam IPv4 e IPv6 sobre ns somente IPv6.
41
O desao para os desenvolvedores a criao de aplicativos que funcionam bem em
todas as situaes. Nomes DNS devem ser usados sempre que um servio tem que ser
chamado, ento, preciso entrar com nomes de servios no DNS, com os corresponden-
tes tipos de registros de recursos para ambiente de rede IPv4 e IPv6 no DNS. Um n
resolvendo um nome DNS e obtendo vrios endereos na resposta deve julg-los e ter
um mecanismo para escolher a conexo com o melhor desempenho, a exemplo do Happy

Eyeballs [2].
Assim, ter habilitado o IPv6 na rede mas no ter aplicaes para uso sobre esta nova
rede IPv6, intil. Ento, preciso iniciar o trabalho com aplicaes no incio do processo
de habilitao do IPv6 na rede. Se a idia central de que a migrao para o IPv6 precisa
ocorrer em larga escala, as aplicaes executadas em sistemas de desktops, laptops e em
muitos aparelhos mveis, precisam trabalhar to bem com o IPv6 quanto com o IPv4 [40].
3.7 Resoluo de Nomes no IPv6

Para o protocolo IPv6, mais importante do que nunca que os nomes, em vez de
endereos, sejam usados para fazer referncia a recursos de rede. O endereo IPv4 j
sucientemente difcil de ser lembrado com uma srie de quatro nmeros decimais, como
um endereo IPv6 pode ter at 32 dgitos hexadecimais, se tornou uma tarefa ainda mais
difcil. Alis, com uma mistura de ambos endereos IPv4 e IPv6, ao especicar um nome
a um recurso, permite que o sistema operacional escolha o melhor conjunto de endereos
com os quais se comunicar. Logo, o suporte a resoluo de nomes para endereos IPv6
com o DNS uma parte de extrema importncia de uma implantao IPv6.
AAAA quad-A
A RFC 3596 [41] dene extenses DNS para suporte ao IPv6, adicionando o registro
AAAA
, tambm conhecido como para a resoluo de um nome de domnio
A
totalmente qualicado para um endereo IPv6. Os registros so comparveis
hosts
AAAA
com endereos de que designam registros de recursos usados pela resoluo de
nomes do IPv4. O tipo de registro de recurso nomeado porque os endereos
bits bits.
AAAA
IPv6 de 128 so quatro vezes maior que o tamanho do endereo IPv4 de 32
Um registro de recurso em um arquivo base de um DNS tpico tem uma
AAAA
estrutura composta de um nome de domnio totalmente qualicado e um endereo IPv6
host.alpha.com IN AAAA 2001:DB8::1:DD48:AB34:D07C:3914

associado ao nome [42]. Abaixo segue um exemplo de um registro de recurso :
RegistrosA AAAA e podem tranquilamente coexistir lado a lado, assim, possibilita a
implantao generalizada de ambos registros para o mesmo nome de host, e esta a direo
em que os registros DNS caminham. Desta forma, se um host opera em pilha dupla, po-
42
A AAAA
host.alpha.com IN A 64.4.10.56 IN AAAA 2001:DB8::1:DD48:AB34:D07C:3914
dem ser anexados os registros e ao seu nome de domnio, como mostrado abaixo:
AAAA
No entanto, preciso de cuidado com essa congurao, alguns resolvedores de nomes
atuais sempre iro procurar registros A host

antes de registros , mesmo se o
que est executando o resolvedor no tenha a capacidade de se comunicar com todos os
endereos IPv6, por exemplo, um host que tem somente um endereo IPv6 Link-Local, ou
A AAAA
usa alguma tecnologia de transio que lhe d conectividade IPv6 limitada.
host.alpha.com
Contudo, prudente anexar os registros e para nomes de domnios diferen-
hosts
IN A 64.4.10.56host-v6.alpha.com IN AAAA 2001:DB8::1:DD48:AB34:D07C:3914
tes, pelo menos aos que proveem servios, como mostrado abaixo:
Happy Eyeballs
Uma soluo potencial para os problemas de priorizao e proposto pela IETF o
referido na RFC 6555 [43] e conhecido como , e que uma forma de
A AAAA
tentar corrigir o problema de deciso sobre qual conexo preferir, em casos que h a
presena de ambos registros e . Se o endereo IPv6 est disponvel e capaz de
responder rapidamente, a comunicao acontecer sobre IPv6. Se uma conexo IPv6 no
estiver disponvel, a comunicao ocorrer sobre IPv4. Similarmente, se a comunicao
IPv6 for mais lenta, talvez por causa de estar tunelada sobre IPv4, a aplicao usa a
conexo IPv4 mais rpida [40].
Quanto ao troubleshooting relacionado ao DNS, no ambiente IPv6 no muito diferente
nslookup dig
do ambiente IPv4, as ferramentas principais no auxlio a esta tarefa continuam sendo o
e o [44].

Neste captulo as principais tcnicas de transio entre protocolos IPv4 e IPv6 foram
abordadas. So apresentadas consideraes sobre o domnio de aplicabilidade de uma ou
mais tcnicas nos ambientes de rede, expostas consideraes a respeito do protocolo IPv6
em hardwares, sistemas operacionais, em aplicaes e como a resoluo de nomes pode
auxiliar na referncia a recursos de rede.
43
Captulo 4
Estado da Arte
Existem muitas publicaes de estudos que colocam em pauta a discusso do pro-
cesso de transio entre os protocolos IPv4 e IPv6, muitas abordando questes prticas
de monitoramento de protocolo IPv6, de tunelamento e traduo, problemas de segu-
rana e desaos fundamentais, dentre outros. Entretanto, poucos trabalhos podem ser
encontrados referentes a modelos de implementao em ambientes de redes heterogneas,
sobretudo, no mbito da esfera de rgos pblicos. Entretanto, trs artigos foram sele-
cionados e apresentam correlao clara com a linha de estudo da proposta em questo,
sendo apresentados nos pargrafos subsequentes.
Em [1] so apresentados fundamentos da tecnologia de Traduo IVI seguido de exposi-
o de um modelo para implementao do mtodo de transio entre os protocolos IPv4 e
IPv6 em servidores de um ISP (Internet Service Provider ). No artigo [45], foram expostos
os principais mecanismos de transio, propondo uma soluo para suavizar a transio
para IPv6 baseado em tneis e tecnologia de traduo. J em [46], foram abordados
mecanismos principais de transio IPv6 que tm sido propostos introduzindo fundamen-
tos de tcnicas de tunelamento e traduo, e analisando o objetivo principal dos tneis
e mecanismos de traduo, mapeando por m, os mecanismos adequados em cenrios
heterogneos, discutindo ainda como escolher e implantar os mecanismos de transio.
Na continuao sero descritos os trs modelos que foram usados como base para o
Modelo 1
estudo e produo do modelo objetivo deste trabalho:
Em [1] foi proposta uma transio do protocolo IPv4 para o IPv6 dos servidores de
ISP por meio de um mtodo denominado por Traduo IVI, que sugere uma transio
consistente e suave entre as geraes do protocolo IP. Na implantao deste mtodo IVI,
o ISP exigido a ter um ambiente de rede em Pilha Dupla, operando com os protocolos
IPv4 e IPv6. Com base na regra de mapeamento de endereo IVI, o encaminhamento
ocorre de forma simples, como mostrado na ilustrao adaptada na Figura 4.1 [1].
44
Figura 4.1: Implantao do IVI em ambiente descrito pelo primeiro modelo [1]
Um endereo especco como ipv6.beijing2008.cn um servidor web IPv6 nativo es-

tabelecido no CERNET2 (China Education and Research Network 2 ) com um endereo
IPv6 IVI (IVI6) 2001:da8:3a:c8fe:1e00::. O endereo virtual IPv4 IVI (endereo IVI4)
correspondente 58.200.254.30 pela regra de mapeamento de endereo. O Tradutor IVI
um roteador em Pilha Dupla com suporte a protocolos de roteamentos esttico e din-
mico com duas interfaces, uma da rede IPv4 e a outra para a rede IPv6, sendo possvel
tambm, ter uma nica interface congurada para ambos.
O Roteador R1 tem uma rota esttica IPv4 para endereo IVI4 do servidor web com
o prximo salto para o IP 202.112.61.181. O Roteador R2 tem uma rota default IPv6
::/0 com o prximo salto para o IP 2001:da8:a0:1002::1. Enquanto isso, o Tradutor IVI
tem uma rota IPv6 para endereo IVI6 do servidor web com o prximo salto para o IP
2001:db8:a0:1002::2 e outra rota IPv4 para endereo IVI4 0.0.0.0/0 com o prximo salto
para o IP 202.112.61.182.
Na soluo, um DNS IVI em Pilha Dupla tambm foi congurado entre os cenrios
AAAA
IPv4 e IPv6 no auxlio resoluo de nomes. Quando um cliente IPv6 faz uma consulta
A
a um registro no servidor DNS, este retornar 2001:da8:3a:c8fe:1e00::. Quando
A A
um cliente IPv4 faz consulta a um registro do servidor, o DNS IVI tentar retornar
AAAA A
primeiro o registro do endereo IVI4. Se o registro no existe, o DNS IVI ir consultar
o registro e mape-lo para um endereo IVI4 e retornar um registro para o
web
cliente IPv4. Assim, permitindo que os usurios dos ambientes IPv4 e IPv6 acessem o
servidor ipv6.beijing2008.cn sem qualquer problema.
O estudo levou os autores a algumas concluses, a citar:
Pode ser implantado gradativamente para se alcanar a transio completa entre os
protocolos IPv4 e IPv6 dos numerosos servidores de ISPs;
A dependncia de uso de DNS foi compreendida como uma decincia;
Ainda assim, concluram que o mtodo de Traduo IVI uma boa opo para
transio dos servidores de ISPs.
45
Modelo 2
Em [45] foi exposto que diferentes tecnologias de transio devem ser usadas durante
diferentes fases de transio. Foi proposta uma soluo de transio para o IPv6 com base
nas tecnologias de Tunelamento, Traduo e Pilha Dupla, com processo de evoluo em
3 fases:
Fase 1 : Alguns servios IPv6 comearam a ser implantados continuamente na rede
IPv6, mas no h usurios somente IPv6. Na rede IPv4, hosts em Pilha Dupla
podem acessar esses novos servios IPv6, estabelecendo tnel IPv6 sobre IPv4. IPv4-
only e hosts em Pilha Dupla podem acessar os servios IPv4 em IPv4 nativo;
Fase 2 : Nesta fase houve um avano no nmero de servios IPv6 implantados na
rede IPv6. Alguns usurios IPv4 comearam a migrar da rede IPv4 para a rede IPv6
como usurios IPv6 IVI com endereos IVI6 especcos. Na rede IPv4, hosts em
Pilha Dupla podem acessar esses novos servios IPv6, estabelecendo o tnel IPv6
sobre IPv4. IPv4-only e hosts em Pilha Dupla acessam os servios IPv4 em IPv4
nativo. Na rede IPv6, usurios IVI6 podem acessar os servios IPv4 atravs da
soluo de IVI, podendo tambm acessar servios IPv6 em IPv6 nativo.
Fase 3 : Na fase nal alguns antigos servios IPv4 foram migrados da rede IPv4 para
IPv6 como servios de rede IPv6 IVI, com endereos IVI6 especcos para estes ser-
vios IPv6. Aumentou o nmero de usurios IVI6 na rede IPv6, correspondente
ao nmero de endereos IPv4 IVI, atingindo o objetivo de migrao da rede IPv4
para IPv6. Na rede IPv4, os hosts em Pilha Dupla podem acessar esses servios
IPv6 congurando o tnel IPv6 sobre IPv4. Se os servios IPv6 esto implantados
em IVI6, os usurios IPv4 podem acessar esses servios IVI6 por meio do Tradutor
IVI. O IPv4-only e os hosts em Pilha Dupla podem acessar os servios IPv4 por
IPv4 nativo. Na rede IPv6, usurios IVI6 podem acessar os servios IPv4 atravs
do Tradutor IVI, comumente usurios IPv6 acessam servios IPv4 pelo tnel IPv4
sobre IPv6. Todos os usurios IPv6 podem acessar servios IPv6 em IPv6 nativo.
Gradualmente todo o espao de endereos IPv4 foi convertido em espao de ende-
reos IPv4 IVI. Nesse caso, usurios e servios IPv4 foram todos migrados para a
rede IPv6, completando o processo de transio.
O servidor de tnel um gateway de rede virtual para cada cliente do tnel, sendo
ele responsvel pelo roteamento no tnel dos pacotes do cliente e tendo a funo de push,
empurrar informaes especcas de congurao de rede. Este servidor ainda precisa
congurar um pool de endereos IPv6, pois, quando um cliente do tnel se conecta ao
servidor de tnel, em primeiro lugar, o servidor precisa vericar a legitimidade do cliente
de acordo com o nome de usurio e a senha ou com base em certicado, e ento empurra
46
um endereo IPv6 ou o prexo IPv6 do pool de endereos IPv6 para o cliente de acordo
com as informaes do usurio.
Foram projetados e realizados dois modos diferentes de trabalho em tnel, os modos
Host e Gateway. O modo Host aquele quando usado processo de autenticao do cliente
do tnel, ele ter um endereo IPv6 do servidor tnel, simultaneamente, o servidor do
tnel adicionar um registro de rota para este endereo IPv6 atravs do tnel. No modo
Gateway um cliente do tnel no necessita de processo de autenticao, ele ter um prexo
IPv6 do servidor de tnel, simultaneamente, o servidor de tnel adiciona um registro de
rota para esse prexo IPv6 atravs do tnel. Como um gateway, clientes do tnel podem
distribuir endereos IPv6 com o prexo IPv6 para os hosts em suas subredes IPv4 por
meio, por exemplo, de servio DHCPv6 (Dynamic Host Conguration Protocol for IPv6 ).
Na subrede IPv4, quando um host tem um endereo IPv6 do servidor de tnel por
meio do DHCPv6, ele pode acessar os servios IPv6. Os pacotes so roteados atravs
do adaptador de rede virtual, o processo de tnel ter esses pacotes IPv6 a partir do
adaptador de rede virtual, usando o protocolo SSL (Secure Socket Layer ) para montar
esses pacotes IPv6 em dados da camada de aplicao, e os pacotes sero enviados como
pacotes IPv4 atravs do adaptador de rede fsico. Finalmente um canal de comunicao
estabelecido entre o servidor de tnel e o cliente do tnel e transparente para os usurios.
Sob a anlise dos autores no mbito do sucesso da transio, um sistema completo
de Traduo IVI deve incluir um Tradutor IVI e um DNS IVI [45]. Sendo assim, foi
desenvolvido um guia descrevendo as principais conguraes de Tradutor IVI e DNS IVI
implementadas nos testes, alm de sucintamente descrever as aes para congurao de
Tunelamento.
Alguns entendimentos nais os autores alcanaram, os quais seguem abaixo:
O conjunto de solues propostas e executadas deixou a viso de que a transio
ocorreu de forma suave e gradual;
Num mbito mais tcnico, a Traduo IVI no pode traduzir o endereo IP na
camada de aplicao.
Modelo 3
Em [46] os autores centralizaram esforos iniciais numa descrio objetiva mas bem
esclarecedora das caractersticas do protocolo IPv6 sempre fazendo referncias ao seu
antecessor IPv4 com abordagem dos problemas de conectividade em redes heterogneas,
bem como exps tambm, uma viso geral dos mecanismos principais de transio IPv6
que tm sido propostas. De forma sinttica, mapearam os mecanismos adequados em
todos os cenrios de interconexo heterognea e travessia heterognea. Diferenciando-se da
maioria das referncias encontradas, este estudo abordou mecanismo de uso e estratgias
47
de implementao de transio para IPv6 na esfera de redes ISPs, redes de backbones e
redes de borda.
Ento para demandas de acesso IPv4, o ISP pode implantar Dual Stack Lite, IPv4
sobre IPv6 ou MAP-E (Mapping of Address and Port-Encapsulation ). O ISP deve es-
colher entre os trs mecanismos candidatos com base na sua situao de endereos IPv4
excedentes e condies da rede. Se a alta taxa de compartilhamento de endereos a
principal exigncia, ou a questo NAT em larga escala no uma grande preocupao,
ento Dual Stack Lite seria uma soluo adequada. Por outro lado, IPv4 sobre IPv6 e
MAP-E so as opes quando o ISP tem endereos IPv4 suciente para o conjunto de
provisionamento de porta. Se o acesso IPv4 um requisito comum de assinantes e o ISP
capaz de renumerar a rede IPv6, ento MAP-E seria uma escolha melhor, com a grande
vantagem de ser stateless. Se o ISP quer manter IPv6 e IPv4 desacoplados e trazer ne-
nhuma mudana para a rede IPv6, ou fornecer o acesso IPv4 em um estilo sob demanda,
ento IPv4 sobre IPv6 se torna a soluo mais apropriada.
Ainda em [46], se considera que as redes de backbones so responsveis por encaminha-
mento IP de alta velocidade, enquanto os servios de redes especcas so de responsabili-
dade das redes de borda. Isso reete tambm na implantao de transio, o backbone se
concentra em fornecer transporte IPv4 e IPv6 para redes de borda, levando atualizao
do backbone para Pilha Dupla, ou a construo de um backbone IPv6 independente ao
lado do IPv4. A desvantagem tambm bvia, o custo tanto de upgrade de hardware e
operao e gerenciamento so muito altos.
Outra alternativa sugerida para migrao em backbones consiste em implantar Softwire

Mesh Single Stack do
e fornecer transporte Pilha Dupla na parte superior do backbone.
Para o backbone IPv4 existente, pode-se implantar rede IPv6 sobre IPv4 Mesh. Para isso,
deve-se atualizar os roteadores de borda do backbone com funcionamento para os proto-
colos IPv4 e IPv6 para suportar Pilha Dupla, bem como IPv6 sobre IPv4 Mesh. Trfegos
IPv6 podem ser encaminhados no backbone por tnel IPv6 sobre IPv4 entre roteadores
que suportem as duas verses de protocolos IP. Os roteadores dentro do backbone podem
permanecer com IPv4-only e evitar a atualizao. Quanto ao backbone IPv6 pode-se im-
plantar IPv4 sobre IPv6 Mesh para preservar o transporte IPv4. Apenas um backbone
fsico usado enquanto o transporte IPv4 e IPv6 so alcanados simultaneamente.
Para redes de borda, por problemas de complexidade e escalabilidade, mecanismos de
traduo devem ser implantados em seu interior, em vez de no backbone. Na sequncia,
diferentes estratgias de transio so apresentadas de acordo com diferentes requisitos
de comunicao e tipos de rede de borda:
A rede de borda IPv4 oferece um acesso IPv4 nativo para os usurios nais, e se
estes desejam acesso rede IPv6, o 6RD (IPv6 Rapid Deployment ) pode ser usado
48
com o objetivo de permitir ao usurio nal ter conexo com as redes IPv6 apesar da
rede que prov acesso continue funcionando em IPv4. Ns nais devem trabalhar
em Pilha Dupla e suportar funes 6RD em cliente de borda. No lado do ISP, um
ou mais 6RD BRs (Borders Relay ) devem ser implantados como concentradores de
tneis;
Usurios em redes de borda IPv4 tambm podem querer acessar servios em re-
des IPv6 usando IPv4. Entre os mecanismos de transio, o NAT-PT (Network
Address Port Translation-Protocol Translation ) pode satisfazer a demanda, sendo
mais utilizado em um ambiente de pequena escala e controlvel;
Usurios em redes de borda IPv6 tambm podem acessar a rede IPv4 com IPv6,
o que exige uma traduo IPv6 para IPv4, o que pode ser realizada pelas tcnicas
IVI ou NAT64 com funo adicional DNS64 (Domain Name System IPv6-IPv4 ) ao
sistema DNS. Ao escolher entre IVI e NAT64, os critrios tambm encontram-se em
situao de excesso de endereos IPv4. O IVI fornece comunicao bidirecional com
o custo do consumo de endereo por host, enquanto NAT64 somente garante comu-
nicao iniciada a partir do lado IPv6, mas alcana compartilhamento de endereos
IPv4 dinmicos.
Demandas dos servidores tambm devem ser consideradas, estes precisam prestar ser-
vios para clientes IPv4 e IPv6. Se o servidor suporta tanto IPv4 quanto IPv6 na camada
de aplicao, ento no necessrio qualquer outro mecanismo, caso contrrio, deve ser
fornecido suporte a transio a nvel da aplicao. Se o servidor opera em IPv4, pode-se
implantar um tradutor NAT64 para traduzir conexes de clientes IPv6 para IPv4, caso
contrrio, o servidor executa em IPv6, e pode ser implantado um Tradutor IVI para
traduzir conexes de clientes IPv4 para IPv6.
Contudo, algumas concluses foram alcanadas:
Para as tcnicas de traduo uma questo crtica a ausncia de mecanismo de
traduo stateful de IPv4 para IPv6;
Os mecanismos de traduo existentes apresentam problemas de escalabilidade, en-
dereamento heterogneo e traduo da camada de aplicao;
Antes de as tcnicas de transio poderem ser aplicadas numa implantao em larga
escala, anlises de desempenhos quantitativos e sistemticos devem ser efetuadas
antes de qualquer ao;
Em meio a vrios mecanismos de transio para o IPv6, provoca de incio no admi-
nistrador da rede uma certa confuso na escolha da melhor alternativa.
49
4.1 Concluses sobre as tcnicas utilizadas nos artigos
Mediante anlise de trabalhos executados na transio para o IPv6, foi possvel notar
que os grupos principais de tcnicas de transio, a citar Pilha Dupla, o Tunelamento e
a Traduo, continuam sendo fortes referncias para o alcance de uma transio segura.
Dada a constatao, estas tcnicas podem ser utilizadas ou combinadas para que em
ambiente de rede heterognea, se possa atingir a meta de experimentos bem sucedidos
seguido de um plano de transio gradual e suave tanto para os clientes quanto para os
servidores de aplicaes.
A proposta elaborada e executada no artigo [1], baseada nas tcnicas de Traduo IVI
sobre infraestrutura em Pilha Dupla, apresenta-se como uma boa alternativa de transio
para o protocolo IPv6 em servidores, principalmente por oferecer implantao stateless,

altamente incremental e independente de AS. Mesmo sob uma perspectiva de implemen-
tao direcionada a ISPs, a linha de trabalho adotada facilmente adaptvel a outros
cenrios, inclusive ao ambiente acadmico vivenciado na UnB no mbito dos servidores
que disponibilizam servios acadmicos e administrativos.
O plano de implementao demonstrado no artigo [45], concentrou-se numa soluo
com uso das tcnicas de Pilha Dupla, de Tunelamento e Traduo IVI. Mediante constata-
o de seus executores, mostrou-se vivel. Entretanto, preciso levar em considerao que
a implementao de tunelamento apresenta carga adicional colocada no roteador, j que
cada ponto de entrada e de sada precisa de tempo e poder de processamento para encap-
sular e desencapsular pacotes, alm de tornar mais complexo processo de troubleshooting

de rede [2].
O artigo [46] focou em sugerir estratgias de implementao de transio para IPv6
nos cenrios de redes ISPs, redes de backbones e redes de borda. Dentre estes cenrios,
as tcnicas sugeridas para as redes de backbones e borda permitem melhor adequao ao
ambiente de rede heterognea no qual se enquadra a REDUnB, em especial, o uso da
tcnica de Pilha Dupla em todo os cenrios de rede.

Neste captulo so relatados e analisados trs modelos de migrao do protocolo IPv4
para o IPv6. Os trs modelos em questo referem-se a registros em artigos, seguidos de
concluses sobre as metodologias utilizadas.
50
Captulo 5
Proposta de Modelo para Migrao

Gradual
Este captulo descreve de forma detalhada a metodologia de migrao do protocolo
IPv4 para o IPv6 na REDUnB, temtica que a proposta principal deste trabalho.
essencial a compreenso do atual cenrio no qual este estudo se baseia, pois, as redes tm
a tendncia para se tornar mais complexas, devido ao seu crescimento e heterogeneidade
de tecnologias utilizadas.
5.1 Ambiente de Aplicao

A REDUnB integrada ao projeto REDECOMEP (Redes Comunitrias de Educao
e Pesquisas) estruturada atualmente sobre uma ampla capilaridade de bra ptica que
alcana regies signicativamente afastadas do campus Darcy Ribeiro, como pode ser
notado na Figura 5.1. Como demonstrado, seus campi geogracamente deslocados, como
a Faculdade de Ceilndia, Faculdade do Gama, Faculdade de Planaltina, o Ncleo de
Prticas Jurdicas em Taguatinga, o Hospital Veterinrio na Granja do Torto, a Fazenda
guas Limpas, os Edifcios Anpolis e OK (ambos no Setor Comercial Sul), a Estao
Experimental de Biologia, o Centro de Ensino Distncia, estes dois ltimos localizados
na Asa Norte.
A REDUnB atende a toda a comunidade acadmica, e atua como um grande provedor
de acesso rede pblica e de acesso aos sistemas acadmicos e administrativos. Por
meio da infraestrutura de rede, mantm conectividade permanente com a Internet com
endereamento pblico.
Esta infraestrutura atende a aproximadamente 17000 (dezessete mil) pontos de acesso
cabeados. Como se v na Figura 5.2, esta rede alicerada em seu backbone por 4 (quatro)
robustos switches core (de ncleo) com capacidade de backplane de 9.5Tbps, 2.56Tbps em
51
Figura 5.1: Alcance da REDUnB
capacidade de switching e suporta throughput de 1920 Mpps. Estes so interligados em
topologia full mesh com enlaces de 10Gbps provendo redundncia e tolerncia a falhas,
caracterstica referenciada nas literaturas com frequncia como resilincia. O backbone
composto pelos ns identicados por ICC (Instituto Central de Cincias), FT (Faculdade
de Tecnologia), FINATEC (Fundao de Empreendimentos Cientcos e Tecnolgicos) e
o CPD (Centro de Informtica).
Dos 4 (quatro) switches core so distribudos enlaces de 1Gbps para 93 (noventa
e trs) unidades de switches layer 3 de agregao que possuem alta performance em
portas Gigabit Ethernet com capacidade de comutao de 264Gbps. Estes switches cam
localizados em salas de distribuio de acesso, de onde partem todo cabeamento de rede
para os pontos de acesso. O switch core do ICC prov acesso REDUnB a 37 (trinta
e sete) locais, o da FT a 22 (vinte e dois), o da FINATEC a 20 (vinte) e o do CPD a
14 (quatorze) locais. Os switches do backbone e de agregao so todos equipamentos
do mesmo fabricante operando com roteamento estabelecido em OSPF verso 2. Os
switches de acesso possuem enlaces de 1Gbps com os switches layer 3 de agregao.
Vale destacar que desde o ano de 2008 as direes do Centro de Informtica da UnB
tm seguido as orientaes do e-PING, onde todos os investimentos em equipamentos
do parque de redes de dados precisam j disponibilizar em seu datasheet a comprovao
de suporte coexistncia dos protocolos IPv4 e IPv6 e a produtos que suportem ambos
os protocolos. Contudo, todos os equipamentos envolvidos no cenrio supradescrito j
possuem caractersticas que atendam orientao do documento de referncia do governo
federal.
Ainda no contexto da infraestrutura descrita, esta constituda sobre uma rede IPv4
52
Figura 5.2: Topologia da REDUnB
com endereos pblicos classe B (164.41.0.0/16), a qual disponibiliza a alocao de 65.534
(sessenta e cinco mil e quinhentos e trinta e quatro) hosts na rede. Este bloco de endereos
IPv4 atualmente segmentado em outros 4 (quatro) blocos uniformes (164.41.0.0/18,
164.41.64.0/18, 164.41.128.0/18 e 164.41.192.0/18), cada um reservado respectivamente
para distribuio de redes pelos ns ICC, FT, FINATEC e CPD. Deste bloco de endereos
IPv4 /16 sob controle da UnB, em torno de 67% do total encontra-se reservado e em uso
dentro da REDUnB, as tendo ainda uma reserva tcnica importante de endereos livres
para uso.
Quanto ao contexto de endereamento IPv6, o Registro.br que um departamento do
NIC.br (Ncleo de Informao e Coordenao do Ponto BR) responsvel pela distribuio
de endereos IPv4 e IPv6 no Brasil, no ms de julho do ano corrente (2014), pedido do
CPD da UnB, atribuiu um bloco IPv6 com prexo /48 identicado como 2801:80:b90::/48.
O bloco de endereos IPv6 em questo disponibiliza 65.536 (sessenta e cinco mil e qui-
nhentos e trinta e seis) redes /64, redes que correspondem a uma quantidade de hosts na
ordem de 18.446.744.073.709.551.616, um nmero naturalmente complicado de grafar.
Na sada da REDUnB, h 2 (dois) enlaces de 1Gbps entre o switch core do CPD e 2
(dois) rewalls operando em cluster, cando estes ltimos encarregados pela poltica de
segurana na borda da rede. Concluindo a topologia em questo, os rewalls cluster so
53
interligados a um roteador de borda por 2 (dois) enlaces de 1Gbps, enquanto que a conexo
entre o roteador de borda e o ambiente externo (Internet) por meio da REDECOMEP,
em um link de 1Gbps, enlace designado como um AS, ou seja, Sistema Autnomo, que
utiliza o protocolo de roteamento BGP para a Internet.
O Centro de Informtica da UnB, mais especicamente o ncleo de Suporte Rede
e Servios, responsvel pelo gerenciamento da REDUnB e tem sob sua gerncia no
que compete a esta rede de dados precisamente 1277 (um mil e duzentos e setenta e
sete) equipamentos em operao e gerenciados por uma equipe de 6 (seis) analistas de
sistemas. Neste nmero de equipamentos esto includos, 748 (setecentos e quarenta e
oito) switches, rewalls, 3 (trs) roteadores, 10 (dez)

6 (seis) controladoras wireless e 510
(quinhentos e dez) access points wireless.
Ao se tratar da server farm da UnB, ou seja, o grupo de equipamentos servidores
mantidos pelo Centro de Informtica, atualmente sob plataformas que alm de possurem
poder de processamento de bom nvel, j encontram-se com sistemas operacionais para
servidores que suportam o protocolo IPv6. Esta server farm mantida em sala cofre, dispo-
nibiliza o acesso a diversos servios (correio eletrnico, HTTP, FTP, DNS, dentre outros),
alm dos sistemas administrativos e acadmicos que encontram-se em fase de plena atu-
alizao de plataforma. Outro fator importante a ser exposto que uma pequena parte
de sistemas legados encontra-se sobre equipamentos servidores com sistemas operacionais
bastante antigos, e consequentemente no suportando o protocolo IPv6.
Ainda com referncia aos sistemas operacionais, aqui concernentes aos hosts dos usu-
rios, a grande maioria das empresas que os fabricam ou distribuem j oferecem suporte
para que seus produtos trabalhem com o protocolo IPv6. Dentro da REDUnB, mediante
registro do Helpdesk que o ncleo do Centro de Informtica da UnB que d suporte
tcnico mais prximo aos usurios da rede cabeada, atualmente a predominncia de
sistemas operacionais Windows, e no inferiores ao Windows XP Service Pack 1 que j
suporta a nova verso do protocolo IP. Em outros sistemas operacionais tambm frequen-
temente encontrados na rede, como MacOs, Linux e FreeBSD, estes tambm j oferecem
suporte ao IPv6.
Como j citado anteriormente, as tcnicas de transio mencionadas no estudo podem
ser implementadas em infraestrutura de rede isoladamente ou em conjunto, dependendo
da dimenso e do grau de complexidade do ambiente de rede e sistemas de informtica da
instituio em questo. Assim, indispensvel analisar o cenrio da REDUnB para uma
migrao suave, segura e que seja exequvel.
54
5.2 Proposta de Implementao
Conforme exposto, destacam-se dois aspectos relevantes para a proposta de modelo,
um que todos os equipamentos (switches ) que compem o ncleo da REDUnB j podem
operar sobre o protocolo IPv6. O outro quanto a alta disponibilidade de endereos IPv4
na REDUnB.
Alm dos dois aspectos supracitados, outros fatores bases para a escolha do modelo
refere-se alta recomendao dos rgos gestores da Internet quanto ao uso de Pilha
Dupla e a facilidade de gerenciamento do ambiente que caracterstica da tcnica.
Assim, o modelo de migrao do protocolo IPv4 para IPv6 dentro da REDUnB con-
sistir de uma implementao voltada coexistncia das duas verses de protocolos IP
nos mesmos equipamentos, de forma nativa, simultaneamente. Inicialmente a inteno
concentra-se na implementao da tcnica de transio de Pilha Dupla no backbone da
REDUnB e nos switches layer 3 de agregao que roteiam redes para os pontos de acesso.
5.2.1 Fase 1: Endereamento e Roteamento
Esta fase, comea basicamente com os planejamentos da topologia lgica e fsica do
ambiente de rede, dos endereamentos IPv4 e IPv6 envolvidos no ncleo da rede, dos
blocos de endereos IPv4 (164.41.0.0/16) e IPv6 (2801:80:b90::/48) que estaro disponveis
na borda da rede e do esquema de roteamento das redes deste ncleo em OSPF nas
verses 2 e 3, ilustrados pela Figura 5.3. Como se v, a idia manter os ativos de rede
Figura 5.3: Atribuio de blocos de endereos IPv4 e IPv6 na REDUnB
55
(switches, roteadores, rewalls, dentre outros) com enlaces de rede utilizando endereos
IPv4 privados e no escopo IPv6 usar endereos Unicast Site-Local.

No que compete ao roteamento interno da rede, este continua utilizando o protocolo
OSPF verso 2 mas com o acrscimo da verso 3 para suporte ao trfego IPv6, pois,
como j exposto, trabalharo de forma independente. Na Figura 5.4 apresentado como
as reas de roteamento OSPF sero organizadas.
Figura 5.4: Atribuio de reas de roteamento OSPF verses 2 e 3 na REDUnB
No ncleo da rede (backbone ) os ns se comunicaro por meio de roteamento OSPF
nas reas 0 e 1, respectivamente para as verses 2 e 3 do protocolo OSPF. Os ns 1, 2, 3
e 4 do backbone recebero tambm respectivamente os pares de reas 11 e 21, 12 e 22, 13
e 23 e ainda 14 e 24, para propagaes de rotas dos switches de agregao. Nas reas de
agregaes, onde atuam os switches da categoria de agregao, sero mantidas as reas
21, 22, 23 e 24 para o protocolo OSPFv2, respectivamente para os ns 1, 2, 3 e 4 do
backbone. Para o protocolo OSPFv3, as reas 11, 12, 13 e 14 nessa ordem para os ns 1,
2, 3 e 4 do backbone.
O esquema de diviso do bloco de endereos IPv4 pblico conforme j praticado dentro
da REDUnB, em 4 (quatro) grandes blocos de endereos IPv4 /18 continuar o mesmo.
Quanto ao bloco de endereos IPv6 disponvel (2801:80:b90::/48), ser utilizado mtodo
leftmost orientado na RFC 3531 [21] e segmentado em 8 (oito) partes como pode ser visto
na Figura 5.5.
Este mtodo permite por meio de atribuies esparsas que blocos de endereos reservas
permaneam entre as atribuies, facilitando o futuro crescimento das redes.
Com a diviso em questo, 8 (oito) novos blocos so disponibilizados para uso, e res-
peitando a orientao do mtodo, como a REDUnB possui 4 (quatro) grandes reas de
56
Figura 5.5: Alocao de prexos IPv6 e reas de concentradores de redes
concentrao de redes (ICC, FT, FINATEC e CPD), os 4 (quatro) primeiros prexos /51
sero utilizados inicialmente por estas reas. Cada prexo /51 possibilita a criao de
8.192 (oito mil e cento e noventa e duas) redes com prexo /64, este ltimo, um tamanho
mnimo de prexo para redes orientada pelo CGI.br e por literaturas correlatas. Assim,
cada um dos ns do backbone, distribuir tambm acesso a redes IPv6 para os Institu-
tos, Faculdades, Departamentos mediante a atribuio de endereos IPv6 submetidas ao
mtodo leftmost.
5.2.2 Fase 2: Organizao do Ambiente de Rede
Com o planejamento concludo, iniciada a etapa de implementao das conguraes
nos switches, com atribuies dos endereos de ambos os protocolos s interfaces VLANs
(Virtual Local Area Networks ) e as conguraes de roteamento necessrias que cada
protocolo necessita para operar de forma desejada, conforme consta no captulo sobre a
descrio do laboratrio.
A habilitao de um servio de resoluo de nomes (servidor DNS e DNS reverso)
com suporte a resoluo de nomes para os protocolos IPv4 e IPv6 muito importante
A AAAA
para o xito desse novo universo que se apresenta. Para casos em que um nico nome de
domnio possua endereos do tipo e , o DNS pode ser congurado de modo a
responder utilizando uma ordem j prenunciada. Esta habilidade fora a ocorrncia de
maior trfego do protocolo escolhido como a opo prevalecente. Em nvel de aplicao,
alguns ajustes podem ser realizados a m de priorizar o trfego de uma verso.
Com a adoo do DNS na soluo de migrao para o IPv6 puramente em Pilha
AAAA
Dupla, ca muito mais simples para as aplicaes decidirem como estabelecer a conexo.
socket
A
Se ela recebe um registro , ento a conectividade estabelecida pelo v6, e
se recebe apenas um registro , ela usa o socket v4.
57
Um aspecto imprescindvel para o sucesso da migrao para o IPv6 e que precisa estar
na linha de ao, a disponibilizao de contedos aos clientes da rede de forma a divulgar
a disponibilidade de acesso IPv6. Este processo precisa ocorrer de forma gradual e segura.
Ainda ao referenciar o cenrio descrito sobre o parque tecnolgico da UnB, a server farm
j apresenta caractersticas bastante favorveis para a implementao do protocolo IPv6
por meio de Pilha Dupla, uma vez que os servios e sistemas disponveis so alcanados
mediante endereos IPv4 pblicos, e a REDUnB atualmente no vivencia o to incmodo
esgotamento do seu bloco IPv4.
No processo de migrao de contedos, os servios bsicos (correio eletrnico, HTTP,
FTP, dentre outros) j disponveis em IPv4, podem receber uma ateno especial e serem
ofertados tambm em IPv6 to logo este esteja acessvel na server farm. Os sistemas
administrativos e acadmicos como passam por fase de profundas mudanas estruturais,
desaconselhvel qualquer interveno momentnea em termos de alteraes de linhas
de cdigo, permanecendo acessvel pela rede IPv4 at que se tenha denies mais asser-
tivas respeito do futuro. Quanto aos sistemas legados e antigos que representam uma
frao nma do montante dos sistemas, esto na iminncia do desuso por ocasio de
descontinuidade da soluo e substituio por ambiente web.

Como a tcnica de Pilha Dupla suportada de forma nativa pelos atuais sistemas
operacionais, inclusive os em uso dentro da REDUnB, do lado do cliente a implementao
do seu ingresso na rede consiste em atribuir os endereos de ambos os protocolos s
interfaces de rede com os seus correspondentes servidores de resoluo de nomes (DNS).
Uma vantagem do uso de Pilha Dupla tambm nos clientes que novos membros na rede
j podem ser endereados com IPv4 e IPv6, enquanto os membros j existentes podem
ser includos em fases, em pequenas sees de redes, sem grandes impactos.
Assim, o cliente dentro da REDUnB que esteja com equipamento congurado apenas
com o protocolo IPv4, quando for comunicar com clientes em Pilha Dupla estabelecer a
comunicao por meio do protocolo IPv4, o mesmo ocorrendo no sentido inverso. De outro
modo, quando o cliente estiver operando em Pilha Dupla e o protocolo IPv6 congurado
na rede como prioritrio, o equipamento o utiliza para comunicar com clientes que estejam
tambm em Pilha Dupla, mantendo a compatibilidade e comunicao durante o perodo
de coexistncia, em servidores e em clientes.
Como endereos dos protocolos IPv4 e IPv6 sero atribudos a cada cliente, tal tarefa
pode ser executada de forma manual ou automtica (DHCPv4, DHCPv6, mecanismo de
autocongurao). inegvel a necessidade de administrar a atribuio de endereos IPv4
e IPv6 na REDUnB por meio de mecanismos automticos, principalmente em extensos
ambientes de rede, e certamente o uso dos protocolos DHCPv4 e DHCPv6 podem sustentar
uma soluo mais escalvel e segura. Entretanto, o fato em questo exige um estudo amplo
58
dos heterogneos ambientes e clientes que a REDUnB atende, o que cabe a um esforo
futuro.
presumvel que neste contexto da migrao para o IPv6 que algumas atualizaes
de softwares ou substituies de equipamentos sejam necessrias. Ainda assim, h outras
importantes medidas a serem tomadas pelo Centro de Informtica da UnB, que garantiro
resultados satisfatrios nesse processo de migrao:
1. Habilitar a tcnica de Pilha Dupla em roteadores e devida adequao de congura-
es em rewalls ;
2. Mediar junto REDECOMEP, mais especicamente ao PoP-DF, o suporte para
BGP em IPv6 e garantir redundncia deste servio;
3. Desenvolver avaliaes de segurana e implantar polticas de segurana nos diferentes
nveis da rede sobre o protocolo IPv6.
Com a tcnica de Pilha Dupla implementada, o impacto nas redes atuais menor,
o gerenciamento da rede se torna mais fcil e permite uma implantao gradual, com a
congurao de pequenas sees do ambiente de rede de cada vez. Alm de ser uma tc-
nica altamente recomendada pelo CGI.br (Comit Gestor de Internet no Brasil), quando
possvel.
Na atual fase de implantao do IPv6, no aconselhvel ter clientes com suporte so-
mente verso 6 do protocolo IP, visto que muitos servios e dispositivos na Internet ainda
trabalham somente com IPv4. Assim, manter o IPv4 j existente funcionando de forma
estvel e implantar o IPv6 nativamente, para que coexistam nos mesmos equipamentos,
a forma bsica escolhida para a transio na Internet.
A tcnica de transio de Pilha Dupla pode facilitar ainda o gerenciamento entre
as verses dos protocolos IP, por possuir pilhas distintas e funcionais cada uma em seu
mtodo de comunicao. Por outro lado, assim que a pilha do protocolo IPv4 e suas
redes forem se tornando obsoletas, a tcnica de Pilha Dupla simplica a descontinuao
do protocolo IPv4 na rede, necessitando somente desabilit-lo.

Este captulo abordou detalhadamente a descrio do ambiente de aplicao do estudo
em questo com objetivo de subsidiar a deciso na escolha da tcnica de migrao do
protocolo IPv4 para o IPv6. Na sequncia, com o j conhecido ambiente, foi apresentada
a proposta de implementao do IPv6 na REDUnB, com a incluso do planejamento do
endereamento IPv4 e IPv6, o esquema de roteamento e a ordenao da implementao
no ambiente de rede.
59
Captulo 6
Cenrio de Avaliao
Esta seo possui o objetivo de avaliar a proposta descrita. A escolha da avaliao em
laboratrio real se deve principalmente por j permitir uma viso realstica da implementa-
o das verses do protocolo IP na linha de equipamentos (fabricante Enterasys/Extreme)
com a qual a REDUnB j opera em nvel de ambientes de rede em backbone, agregao e
acesso.
6.1 Caracterizao do Laboratrio

O laboratrio em questo foi estruturado com topologias fsica e lgica de rede, de
forma a simular o cenrio descrito da REDUnB, o qual corresponde a como ela se encontra
neste momento, como pode ser notado na Figura 6.1. Como se v, so 04 (quatro) switches
que compem o backbone, e simplicadamente 1 (um) switch de agregao originado por
cada n do backbone. Os ns do backbone do laboratrio foram interligados sicamente por
topologia de rede full mesh. Entre os ns do backbone do laboratrio foram estabelecidos
enlaces de 1Gbps, assim como entre estes ns e os switches de agregao.
Os switches utilizados no laboratrio prtico so todos do mesmo fabricante (Ente-
rasys/Extreme), correspondendo ao modelo C5G124-24P2. Este modelo de equipamento
normalmente destinado dentro da REDUnB a perl de switch de agregao, por possurem
alta performance em portas Gigabit Ethernet, alm de oferecer suporte a roteamento IPv4
e IPv6. Para o melhor funcionamento dos switches em questo bem como para alcanar
o comportamento adequado dos protocolos utilizados no laboratrio, os seus rmwares

foram atualizados para uma verso mais atual e estvel (c5-series-06.81.02.0007).
Os switches do laboratrio foram congurados inicialmente com a implementao do

backbone em IPv4 e posteriormente agregando a interoperao deste com o protocolo IPv6
com o escopo de tcnica de Pilha Dupla. Esta fase de implementao das conguraes
60
Figura 6.1: Topologia do Laboratrio - Pilha Dupla
foi baseada em planejamento prvio a respeito do ambiente de laboratrio, planejamento
este que tambm semelhante ao do cenrio REDUnB.
Ainda com foco no que apresenta a Figura 6.1, os hosts que integram o laboratrio
recebem registros de nomes de domnio com objetivo de facilitar o acesso a servios e de
ALFA
demonstrar o uso de resoluo de nomes em ambiente de rede em Pilha Dupla. Assim, os
hosts
BETA GAMA
receberam registros no formato que segue: com registro alfa.lab.unb.br,
ZETA TETA
com registro beta.lab.unb.br, com registros gamav4.lab.unb.br e ga-
CAPA
mav6.lab.unb.br, com registros zetav4.lab.unb.br e zetav6.lab.unb.br, com
registro teta.lab.unb.br e por m com registro capa.lab.unb.br.
6.2 Conguraes de Equipamentos no Laboratrio

No mbito da preparao dos equipamentos no laboratrio, as tarefas foram divididas
em duas fases, a primeira para a congurao dos equipamentos do backbone e a segunda
para a congurao dos switches de agregao. No Apndice A, as conguraes des-
tes equipamentos so apresentadas de forma detalhada. Os passos de congurao dos
switches de backbone so denidos abaixo:
1. Atualizao dos rmwares para verso (c5-series-06.81.02.0007);
2. Criao de identicaes de VLANs;
3. Atribuies destas identicaes de VLANs a interfaces virtuais, denominadas de
interfaces VLAN;
61
4. Habilitao do protocolo IPv6;
5. Conguraes nas interfaces VLANs dos endereos IPv4 e IPv6 dos enlaces entre os
ns do backbone, habilitao dos protocolos de roteamento OSPF nas duas verses
(2 e 3) separadamente, atribuio da identicao de rea para o OSPF e habilitao
da interface VLAN para operar;
6. Conguraes nas interfaces VLANs dos endereos IPv4 e IPv6 dos enlaces entre os
ns do backbone e os switches de agregao, habilitao dos protocolos de roteamento
OSPF nas duas verses (2 e 3) separadamente, atribuio da identicao de rea
para o OSPF e habilitao da interface VLAN para operar;
7. Atribuda ao switch caracterstica de operao com protocolo IPv6 em endereo tipo
Unicast ;
8. Criao de identicaes de roteamento OSPF para as duas verses (2 e 3) nas reas
que interligam os ns do backbone aos switches de agregao;
9. Atribuio de identicaes de VLANs a interfaces fsicas nos switches ;
10. Execuo de conguraes do protocolo Spanning Tree para evitar os loops em
caminhos redundantes na rede.
Quanto aos switches de agregao, os passos de congurao so tambm apresentados
na sequncia:
1. Atualizao dos rmwares para verso (c5-series-06.81.02.0007);
2. Criao de identicaes de VLANs;
3. Atribuies destas identicaes de VLANs a interfaces virtuais, denominadas de
interfaces VLAN;
4. Habilitao do protocolo IPv6;
5. Conguraes nas interfaces VLANs dos endereos IPv4 e IPv6 dos enlaces entre
switches de agregao e ns do backbone, habilitao dos protocolos de roteamento
OSPF nas duas verses (2 e 3) separadamente, atribuio da identicao de rea
para o OSPF e habilitao da interface VLAN para operar;
6. Conguraes nas interfaces VLANs dos endereos IPv4 e IPv6 dos segmentos de
redes distribudos aos clientes, habilitao dos protocolos de roteamento OSPF nas
duas verses (2 e 3) separadamente, atribuio da identicao de rea para o OSPF
e habilitao da interface VLAN para operar;
62
7. Atribuda ao switch caracterstica de operao com protocolo IPv6 em endereo tipo
Unicast ;
8. Criao de identicaes de roteamento OSPF para as duas verses (2 e 3) nas reas
que interligam os ns do backbone aos switches de agregao;
9. Redistribuio de redes conectadas;
10. Atribuio de identicaes de VLANs a interfaces fsicas nos switches ;
11. Execuo de conguraes do protocolo Spanning Tree para evitar os loops em
caminhos redundantes na rede;
12. Congurao de espelhamento de interface para coleta de trfego.
hosts
Agregao R1
Ainda na composio do laboratrio, na borda da rede encontram-se conforme
switches
Agregao R4
disposio apresentada na Figura 6.1. Os de agregaes e
ALFA ZETA
exibem cenrios idnticos, roteando redes somente em Pilha Dupla,
com os respectivos hosts e podendo se comunicar tanto em IPv4 quanto
host ALFA
com IPv6. Os endereos IPv4 e IPv6 congurados so respectivamente 192.168.11.2 e
host
ZETA
2801:80:B90:0000::2 para o e 192.168.41.2 e 2801:80:B90:c000::2 para o
Agregao R2
.
switch
BETA
O de agregao possui 2 (duas) identicaes de interfaces
host
host TETA host BETA
VLANs conguradas, uma conferida rede em IPv4 mais IPv6 com e a outra
host TETA
somente IPv4 com . Os endereos IPv4 e IPv6 designados ao
so respectivamente 192.168.21.2 e 2801:80:B90:4000::2, enquanto que o por
BETA host TETA

operar apenas em IPv4 teve designado o endereo 192.168.22.2. importante ponderar
que o host no se encontra na mesma subrede IPv4 do , o que permite
concluir que um switch que opere em Pilha Dupla pode perfeitamente prover acesso a redes
Agregao R3
somente em IPv4, estas produtos de redes legadas.
switch
GAMA
Quanto ao de agregao , congurada apenas uma identicao
hosts
CAPA
de interface VLAN preparada para prover rede IPv4 e IPv6 com operando
host
GAMA
em Pilha Dupla e apenas em IPv4. Os endereos IPv4 e IPv6 designados ao
host
CAPA
so respectivamente 192.168.31.2 e 2801:80:B90:8000::2, enquanto que o
CAPA
por operar apenas em IPv4 teve designado o endereo 192.168.31.2. Neste ponto
host
host GAMA
relevante atentar ao fato de que o se encontra na mesma subrede IPv4 do
, o que tambm permite concluir que um switch que opere em Pilha Dupla
pode perfeitamente permitir que hosts somente em IPv4 compartilhem o mesmo domnio
de broadcast com os hosts em Pilha Dupla.

Os hosts no escopo do laboratrio apresentam caractersticas de hardwares e sistemas
operacionais frequentemente encontradas em equipamentos de clientes na REDUnB. To-
63
davia, a estes hosts foram adicionados softwares auxiliares para composio do ambiente
de avaliao. Na Tabela 02 seguem descritas as particularidades de cada host :
Tabela 6.1: Particularidades de hosts no Laboratrio
Host Hardware Software

01-ALFA CPU Core 2 Sistema operacional de 64 bits (Windows Se-
Duo, 2.53GHz, ven), XAMPP verso 1.8.3, iperf v-2.0.2-2,
4GB RAM, jperf v-1.0, Java 7 Update 25, Windows Me-
297GB HD, in- dia Player v-11.0, Windows Media Encoder 9
terface Ethernet Series, VLC v-2.0.7, Linphone
100Mbps
02-BETA CPU Celeron, Sistema operacional de 64 bits (Windows Se-
1.60GHz, 2GB ven), XAMPP verso 1.8.3, iperf v-2.0.2-2,
RAM, 73.4GB jperf v-1.0, Java 7 Update 25, Windows Me-
HD, inter- dia Player v-11.0, Windows Media Encoder 9
face Ethernet Series, VLC v-2.0.7
100Mbps
03-GAMA CPU Core i3, Sistema Operacional de 64 bits (Ubuntu),
3.07GHz x4, XAMPP verso 1.8.3, iperf, VLC, Asterisk
3.7GB RAM,
488.1GB HD, in-
terface Ethernet
100Mbps
04-ZETA CPU Core 2 Sistema Operacional de 64 bits (Ubuntu),
Duo, 2.53GHz XAMPP verso 1.8.3, iperf, VLC, BIND 9.9.5,
x2, 3.9GB RAM, HTTPING, Linphone
310.7GB HD, in-
terface Ethernet
100Mbps
05-TETA CPU Celeron, Sistema Operacional de 64 bits (Windows Se-
1.30GHz, 2GB ven)
RAM, 80.4GB
HD, inter-
face Ethernet
100Mbps
continua na prxima pgina
64
Tabela 6.1: Particularidades de hosts no Laboratrio
(continuao)
Host Hardware Software

06-CAPA CPU Celeron, Sistema Operacional de 64 bits (Windows Se-
1.60GHz, 2GB ven)
RAM, 100.4GB
HD, inter-
face Ethernet
100Mbps
De forma auxiliar, no laboratrio foi congurado no host ZETA um servidor de resolu-
o de nomes (DNS) ao se considerar a premissa de que nomes e endereos tm nalidades
distintas, com nomes para identicar recursos, enquanto endereos para localizar recursos.
Com a proposta de implementao da coexistncia de endereos IPv4 e IPv6 na rede, a
infraestrutura torna-se relativamente complexa para a traduo de nomes em endereos, e
vice-versa. Essa infraestrutura de rede com o trabalho de servidores DNS fundamental
para o funcionamento correto da maioria dos servios. No Apndice B seguem detalhes
das conguraes aplicadas no laboratrio.
Figura 6.2: Laboratrio prtico
hosts
ALFA BETA
Importante observar na topologia do laboratrio que todos os envolvidos nos
testes j possuem entradas de registros no servidor DNS. Os hosts e
65
GAMA ZETA
encontram-se com 01 (um) nome de domnio para cada com 02 (dois) endereos, 01 (um)
em IPv4 e o outro em IPv6. Para os hosts e existem 02 (dois) nomes
hosts TETA CAPA

de domnios para cada, 01 (um) nome de domnio para o endereo IPv4 e o outro para o
endereo IPv6. Quanto aos e , por operarem apenas com o protocolo
IPv4, foi adicionado apenas 01 (um) nome de domnio e 01 (um) endereo IPv4 para cada.
ALFA BETA
Ao adicionar registros de nomes de domnios com um endereo IPv4 e outro IPv6 como no
caso dos hosts e , se apresenta com o objetivo de comprovao da prioridade
da comunicao pelo IPv6 em detrimento do IPv4.
O ambiente do laboratrio prtico descrito acima foi montado nas dependncias do
Centro de Informtica da UnB. A Figura 6.2 demonstra o ambiente em questo composto
de 1 (um) rack com os switches e os 6 (seis) hosts usados nos testes.
De forma complementar, a este cenrio foi acrescentado um equipamento denominado
por Fluke Optiview XG apontado na Figura 6.2 com identicao 07 que um tablet
completo para a anlise de desempenho em redes. O equipamento possui caracterstica que
permite extrair relatrios detalhados do comportamento do trfego de rede, com subsdio
anlise e diagnstico de redes cabeadas e sem o [47]. Esta ferramenta foi utilizada no
laboratrio para a tarefa de capturas de pacotes e anlise destas capturas por meio do
software de anlise embarcado na soluo, o ClearSight Analyzer .
6.3 Certicaes do Ambiente

Preliminar fase de avaliaes foram executadas certicaes de ambiente com obje-
ALFA BETA GAMA ZETA TETA

tivo de vericar a correta congurao dos equipamentos do laboratrio. Inicialmente foi
hosts
CAPA
raticada a conectividade entre todos os ( , , , ,
e ) e a conrmao do pleno funcionamento da resoluo de nomes de domnio.
Comprovar a coexistncia harmnica dos protocolos IPv4 e IPv6 foi uma tarefa elementar
hosts
ALFA
e ainda a vericao da prioridade de comunicao pelo protocolo IPv6 entre em
hosts
BETA
Pilha Dupla sendo experimentado por meio da execuo de ICMP entre os e
TETA
utilizando o nome de domnio beta.lab.unb.br. Outro aspecto constatado refere-se
possibilidade de host somente em IPv4, no caso o host , executar consulta de
registro DNS ao nome de domnio alfa.lab.unb.br com retorno de detalhes de endereos
IPv4 e IPv6. Foi conrmada tambm a comunicao entre host somente em IPv4 com
host em Pilha Dupla.
BETA CAPA
O esquema de roteamento OSPF foi validado, apresentada tabela de roteamento de
um dos switches routers do backbone e traada rota entre dois hosts e ,
nos extremos da rede. Por m, com o trfego de fundo em execuo, foi averiguado o
66
nvel de utilizao de CPU nos switches do laboratrio. Os detalhes relacionados aos
experimentos esto contidos no Apndice D.
6.4 Avaliao de Desempenho no Ambiente de Experi-

mentos
Os procedimentos sistemticos de experimentos possuem o objetivo de coletar e ava-
liar informaes que municiem o amplo processo de transio, sendo executados com os
protocolos IPv4 e IPv6 em hosts em Pilha Dupla do laboratrio. Nesta nalidade, so
descritos dois planos de avaliaes de desempenho:
Avaliao 1: Comunicao de servio HTTP;
Avaliao 2: Servio VoIP.
Como exposto, na avaliao 1 o alvo prover acesso a um servio amplamente uti-
lizado na REDUnB e na Internet, o servio HTTP implementado no laboratrio, com
intuito de obter a latncia entre dois pontos da rede. Na avaliao 2 foi implementado
servio VoIP (Voice over Internet Protocol ) na comunicao entre dois hosts, com anlise
de desempenho com metas que apontam taxas de pacotes fora da sequncia, perdas de
pacotes, jitter, latncia, ndice MOS (Mean Opinion Score ) e indicador R-Value.
A latncia o termo usado para descrever a quantidade de tempo que leva para os
dados serem processados ou movidos de um ponto a outro. A latncia em enlaces de redes
a combinao da propagao de delay e o processamento de delay [13]. Os requisitos para
a navegao na web convencional (HTTP) so inuenciados principalmente pelo tempo
de resposta, que limitada a no mais que 5 segundos, em matria de acesso otimizado
no mais que 4 segundos [48].
Em redes locais cabeadas e bem estruturadas essencial que a comunicao ocorra
com timo desempenho ao considerar a proximidade entre os dispositivos e a qualidade
da infraestrutura de cabeamento. Em teste de Ping em redes locais desejvel que a
latncia no ultrapasse 10ms, ou tolervel e no recomendado at 30ms. Quanto mais
dispositivos intermedirios existirem entre dois hosts, naturalmente aumenta a latncia
porque cada dispositivo intermedirio tem algum mecanismo de tratamento dos quadros
[48].
Em termos de voz sobre IP, latncia o tempo que a fala leva pra sair do locutor e
chegar ao receptor. Latncia no tem nada a ver com o rendimento, largura de banda,
ou a velocidade de um enlace. Latncia inuenciada pela distncia, a velocidade de
propagao do sinal e a quantidade de tempo que o hardware leva para processar os
67
dados. No servio VoIP a latncia deve possuir um valor abaixo do patamar de 150ms
[48].
Pacotes fora de sequncia correspondem a entrega de pacotes de dados em uma ordem
diferente da que foi enviada. Este indicador de desordenao pode ser causado pelo fato
de os pacotes seguirem vrios caminhos atravs de uma rede, ou atravs de caminhos
de processamento paralelo dentro de equipamentos de rede que no so projetados para
garantir que a ordenao de pacotes seja preservada [13].
A perda de pacote, tambm frequentemente referenciada como packet loss ocorre
quando um ou mais pacotes que navegam sobre uma rede de computadores falha em
alcanar o destinatrio, sendo um dos erros previstos na transmisso de dados [7]. Con-
tudo, uma taxa de perda de pacotes aceitvel enquadra-se em algo menor que um porcento
(<1%) da quantidade de pacotes trafegados [49].
O jitter, que fundamenta-se na variao do atraso de transmisso, um dos princi-
pais fatores que causa degradao da qualidade em uma comunicao de voz sobre IP
(VoIP). As aplicaes VoIP geram pacotes em intervalos regulares, mas aps passarem
pelos roteadores da rede intermediria, os intervalos de tempo entre os pacotes se tornam
totalmente irregulares. Entre as causas do jitter esto a interferncia eletromagntica e a
interferncia com outros sinais [50]. Uma taxa menor que 400 milissegundos (<400ms)
sugerida para um dilogo de VoIP com qualidade.
Para a avaliao de desempenho da qualidade de voz trafegada por uma rede IP existem
alguns mtodos, dentre estes o MOS. Este mtodo representa uma das mais conhecidas
medidas da qualidade de voz, embora seja de modo subjetivo. No cenrio de teste do
laboratrio prtico onde apresentado o indicador MOS, o ndice calculado sob a reco-
mendao P.800 do ITU-T (International Telecommunication Union ) aliado a avaliaes

objetivas de mtodos usando modelos de percepo PAMS (Perceptual Analysis Measu-
rement System ), PESQ (Perceptual Evaluation of Speech Quality ) e ainda recomendaes

ITU-T G.107 com R-Value, os quais permitem a medio da qualidade m a m de uma
comunicao de voz em condies de rede reais. A escala de valores MOS vai de 1 a 5,
sendo que uma pontuao 4 ou maior indica o som de voz adequado ao servio de telefonia
e VoIP [51].
O indicador R-Value um nmero ou pontuao que usado para expressar quantita-
tivamente a qualidade subjetiva do discurso em sistemas de comunicaes, especialmente
redes digitais que trafegam VoIP, ou para as quais o servio de VoIP est sob avaliao.
A pontuao R-Value, que utilizada em conjuno com processos de teste de voz, pode
variar do indicador 1 (pior) a 100 (o melhor), tendo a margem entre 80 e 90 indicada como
uma taxa satisfatria e de 90 a 100 indicada com uma taxa muito satisfatria. A relao
de 1 (um) ponto MOS equivalente a cerca de 20 (vinte) pontos de R-Value, embora a
68
relao no seja perfeitamente linear.
O mtodo de pontuao R-Value o preferido em relao a outros mtodos de pon-
tuao pelas empresas de telecomunicaes, por ser considerado mtodo que retrata com
preciso, e assim, pode ser utilizado para prever os efeitos de perda de pacotes e atrasos
em redes digitais que transportam os sinais de voz [51].
Uma vez estabelecidas as mtricas de avaliaes de desempenho para caracterizar um
ambiente prximo do real, foi denida a utilizao de trfegos de fundo no ambiente de
experimentos. Foram injetados trfegos de fundo, ou seja, trfegos que no fazem parte do
foco na anlise de desempenho, mas podem ser utilizados para simular o congestionamento
de uma rede operacional. Dessa forma, foram utilizados software Windows Media
Encoder para transmisso de vdeo sob demanda e Broadcasting Live Event e software
iPerf .
BETA
host .avi
hosts ALFA GAMA ZETA
Na transmisso de vdeo sob demanda o prov acesso a arquivo de
host
GAMA ALFA
207MB em IPv4 e IPv6 para os , e . Enquanto que o
.avi hosts
BETA ZETA
prov acesso ao mesmo arquivo em IPv4 e IPv6 para os ,
e . As transmisses citadas so conguradas na aplicao com Bit Rate de
2137Kbps e com 29.97 frames por segundo, executados em loop e acessadas nos clientes
software VLC .
BETA
pelo
Broadcasting Live Event o host

ALFA GAMA ZETA GAMA
Na transmisso de prov acesso aplicao em
IPv4 e IPv6 para os hosts . Enquanto que o host
ALFA BETA ZETA

, e prov
acesso em IPv4 e IPv6 para os hosts
BETA GAMA
, e . Os contedos encaminha-
dos em broadcasting so captados por cmeras acopladas aos hosts e
e enviados com Bit Rate de 2137Kbps e com 29.97 frames por segundo, acessadas nos
clientes pelo software VLC .
Por meio do software iPerf foi aplicado na direo de ALFA ZETA

ZETA ALFA
para trfego em
host ALFA
IPv6, e no sentido inverso, de para trfego em IPv4, trfegos estes com as
iperf -c 2801:80:b90:c000::2 -V -len

host ZETA
mesmas caractersticas. O com comando
1450 -t 1000000000 envia trfego para o

host ZETA
que habilita o servio com o comando
iperf -s -V. No sentido inverso, o iperf -c 192.168.11.2 -l 1450

host ALFA
com comando
-t 1000000000 envia trfego para o que habilita o servio com o comando
iperf -s.
Ainda utilizando o software iPerf foi BETA GAMA
GAMA BETA
aplicado na direo de para
host BETA
trfego em IPv6, e no sentido inverso, de para trfego em IPv4, trfegos
iperf -c
GAMA
estes mais uma vez com as mesmas caractersticas. O com comando
2801:80:b90:8000::2 -V -len 1450 -t 1000000000 envia trfego para o host

GAMA
que
habilita o servio com o comando iperf -s -V. No sentido inverso, o host
BETA
com
comando iperf -c 192.168.21.2 -l 1450 -t 1000000000 envia trfego para o host
69
que habilita o servio com o comando iperf -s.
Os argumentos dos comandos do software iPerf usados no cenrio incluem -c apon-
tando que o host trabalhar como cliente, o -V designa a nova verso do protocolo IP, o
-len 1450 e -l 1450 indicam o tamanho de buer a ser trafegado, o -t 1000000000 informa
o tempo em segundos da comunicao e o -s informa que o host trabalhar como servidor.
6.4.1 Resultados
Nesta seo so apresentados os resultados dos dois planos de avaliaes de desempe-
Resultados da Avaliao 1
nho:
ZETA ALFA
A mensurao do desempenho no acesso a servio HTTP atravs da latncia nos
protocolos IPv4 e IPv6 foi realizada do host para o host . Neste cenrio
foram empregados os utilitrios Ping e HTTPing para subsidiar na coleta de resultados

e anlises.
Figura 6.3: Desempenho da latncia de rede na comunicao entre hosts ZETA e ALFA
Ping foi usado para testar a conectividade entre os hosts ZETA

ALFA
O pequeno utilitrio
e , extraindo a latncia e jitter desta comunicao no mbito da camada de rede
com nalidade de comprovar o nvel de conformidade do meio de comunicao. Com o
uso dos comandos ping -c 5 alfa.lab.unb.br e ping6 -c 5 alfa.lab.unb.br, tendo em ambos
-c 5
ZETA
o argumento para determinar a quantidade de pacotes enviados na comunicao.
A partir do host foram executados trs grupos de dez capturas de estatsticas
sumarizadas em diferentes momentos, totalizando trinta capturas. Os trs grupos de
capturas foram executados em dias diferentes e com intervalo de pelo menos 5 minutos
entre cada captura individual.
70
Figura 6.4: Desempenho do Jitter de rede na comunicao entre hosts ZETA e ALFA
O retorno das informaes sobre o tempo de ida e volta dos pacotes de dados ocorreram
sem perdas, gerando estatsticas nais de perda de pacotes, latncia e jitter como se
encontra no Anexo A e sumarizado nas Figuras 6.3 e 6.4 os ndices das mdias de latncias
e jitters.
Os ndices que compem o grco da Figura 6.3 apontam na comunicao IPv4 mdia
de latncia alcanando a mxima de 0,327ms no instante 16 e mnima de 0,17ms no
instante 19 enquanto que na comunicao em IPv6 mdia de latncia alcanando a mxima
de 0,359ms no instante 5 e mnima de 0,201ms no instante 23. Ao considerar que na prtica
um excelente desempenho da latncia em redes locais no recomendvel ultrapassar 10ms
e que tolervel at 30ms, os ndices apresentados evidenciam um timo nvel de latncia
se considerado o ambiente interno da rede do laboratrio.
A partir dos resultados obtidos quanto s mdias de latncias de rede, ao considerar
cada um dos trs grupos de capturas, somadas as taxas mdias de latncia e divididas
por dez que um nmero de capturas de cada grupo, foi possvel alcanar os seguintes
indicadores:
No primeiro grupo o desempenho do protocolo IPv6 apresentou uma taxa de 2,96%
acima da taxa mdia da latncia alcanada pelo IPv4;
No segundo grupo o desempenho do protocolo IPv4 apresentou uma taxa de 0,34%
E no terceiro grupo o desempenho do protocolo IPv6 apresentou uma taxa de 0,807%
acima da taxa mdia da latncia alcanada pelo IPv4.
Se considerado todo o conjunto de trinta capturas, somadas as mdias de latncias e
extradas taxas mdias gerais referentes a cada protocolo IP, com isso, o desempenho do
71
Figura 6.5: Desempenho da latncia de rede na comunicao do servio HTTP entre hosts
ZETA e ALFA
protocolo IPv6 apresentou uma taxa de 1,56% acima da taxa mdia latncia alcanada
pelo IPv4.
No quesito jitter de rede apresentado na Figura 6.4, os ndices que compem o grco
apontam na comunicao IPv4 taxa mxima de 0,06ms no instante 16 e mnima de 0,006ms
no instante 29 enquanto que na comunicao em IPv6 taxa mxima de 0,091ms no instante
5 e mnima de 0,013ms no instante 27. A partir dos resultados obtidos quanto ao jitter
de rede, ao considerar cada um dos trs grupos de capturas, somadas as taxas de jitter e
divididos por dez que um nmero de capturas de cada grupo, foi possvel alcanar os
seguintes indicadores:
acima da taxa de jitter alcanada pelo IPv4;
No segundo grupo o desempenho do protocolo IPv6 apresentou uma taxa de 13%
acima da taxa de jitter alcanada pelo IPv4;
acima da taxa de jitter alcanada pelo IPv4.
Se considerado todo o conjunto de trinta capturas, somadas as taxas de jitter e dividido
por trinta que a quantidade total de capturas, extraindo assim taxas mdias gerais de
jitter referentes a cada protocolo IP, possvel inferir que o IPv6 obteve um resultado
inferior ao do seu antecessor, com um ndice de 17,38% maior que o jitter na rede IPv4.
Quanto ao HTTPing , este semelhante ao Ping , mas para requisies HTTP. Ao

fornecer uma URL, este vai mostrar quanto tempo leva para conectar, enviar um pedido
e obter a resposta, com apenas os cabealhos. Com este utilitrio, importante ter em
mente que este no est apenas testando o tempo para o servidor web responder, mas
72
tambm o tempo que leva para enviar o pedido atravs da rede e o servidor web retornar
com os cabealhos de volta. Basicamente, ele mede a latncia do servidor web somado
ZETA
com a latncia da rede e opera at a camada de aplicao.
A partir do host foram executados trs grupos de dez capturas de estatsticas
sumarizadas em diferentes momentos, totalizando trinta capturas. Os trs grupos de
capturas foram executados em dias diferentes e com intervalo de pelo menos 5 minutos
entre cada captura individual. Foram utilizados os comandos httping -c 5 alfa.lab.unb.br

e httping -6 -c 5 alfa.lab.unb.br, tendo em ambos o argumento -c 5 para determinar a
quantidade de pacotes enviados na comunicao e no segundo comando o argumento -6
para especicar o uso de IPv6.
O retorno das informaes sobre o tempo de ida e volta dos pacotes de dados ocor-
reram sem perdas, gerando estatsticas nais de falhas na comunicao e latncia como
se encontra no Anexo B e sumarizado na Figura 6.5 os ndices de mdias de latncias.
Os ndices que compem o grco em foco apontam na comunicao IPv4 mdia de la-
tncia alcanando a mxima de 3,5ms no instante 16 e mnima de 2ms nos instantes 13
e 24 enquanto que na comunicao em IPv6 mdia de latncia alcanando a mxima de
4,1ms no instante 9 e mnima de 2ms no instante 16. Mais uma vez os resultados levam a
compreender que as taxas apresentadas por ambos protocolos IP esto dentro da margem
considerada aceitvel (entre 4 e 5 segundos [5]).
A partir dos resultados obtidos quanto s mdias de latncias de rede, ao considerar
cada um dos trs grupos de capturas, somadas as taxas mdias de latncia e divididas
por dez que um nmero de capturas de cada grupo, foi possvel alcanar os seguintes
indicadores:
No segundo grupo o desempenho do protocolo IPv6 apresentou uma taxa de 0,735%
acima da taxa mdia da latncia alcanada pelo IPv4.
Se considerado todo o conjunto de trinta capturas, somadas as mdias de latncias
do servio HTTP na rede e extradas taxas mdias gerais referentes a cada protocolo IP,
com isso, o desempenho do protocolo IPv6 apresentou uma taxa de 3,12% acima da taxa
mdia de latncia do servio HTTP alcanada pelo IPv4, ainda assim em nvel satisfatrio
para o tipo de servio HTTP.
Entretanto, conforme anlises apresentadas sobre os desempenhos dos protocolos IPv4
e IPv6 quanto latncia de rede, o jitter de rede e a latncia do servio HTTP, quando
73
analisados os trs grupos separadamente, possvel inferir que o protocolo IPv4 possui
uma performance superior se comparado ao protocolo IPv6, mesmo que moderado. Se
considerado o desempenho dos protocolos IPv4 e IPv6 nas mesmas circunstncias citadas,
e com um maior nmero de amostras, ou seja, um nmero trs vezes superior ao da
anlise individual, possvel identicar uma atenuao da diferena de desempenho entre
os protocolos IPv4 e IPv6, o que permite compreender uma tendncia atenuao entre
Resultados da Avaliao 2
a diferena entre os protocolos IPv4 e IPv6 ao longo do tempo.
O objetivo na segunda avaliao demonstrar sobre as redes IPv4 e IPv6 a utilizao
de servio VoIP entre 02 (dois) hosts no laboratrio e a execuo de anlise de desempenho
GAMA
da qualidade de voz sobre a comunicao em questo em ambas verses do protocolo IP.
Neste cenrio o host desempenha um papel fundamental ao prover o servio de
software Asterisk
hosts ALFA ZETA
VoIP na rede por meio do , atribuindo os nmeros 1001 e 1002 para os
hosts ALFA ZETA

respectivos e , conguraes que constam no Apndice C.
Nesta circunstncia os e tm os seus softwares clientes VoIP
Linphone congurados para atrelar o servio VoIP sobre protocolo SIP (Session Initia-
tion Protocol ) ao servidor Asterisk . Assim, os hosts so registrados respectivamente com
os nmeros 1001 e 1002. A comunicao VoIP iniciada atravs do software Linphone do
host ALFA para o host ZETA em uma ligao ininterrupta durante todo o procedimento
GAMA ALFA
de experimento.
hosts
ZETA
Uma vez concluda a ativao do servio VoIP nos (servidor),
e (clientes), o momento de posicionar o equipamento Fluke Optiview XG no
ge.1.15
cenrio para coleta de trfego. O equipamento em questo foi inserido no contexto do
Agregao R4 ge.1.14
laboratrio por meio de conexo fsica em cabo de par tranado na interface
switch
Agregao R4 ge.1.15
do de . Como bem consta no Apndice I, a interface do
switch ingress egress

ge.1.14
espelha para a interface todo o trfego ou
que trafega pela interface .
Desta forma, o equipamento Fluke Optiview XG ajustado com parmetros cor-
respondentes ao protocolo UDP porta 5060 com opo SIP habilitada na seo Combined
Flows.
ALFA ZETA
J com ltros direcionados para coleta de todo trnsito de pacote a respeito do
VoIP entre os elementos de interesse e , a coleta realizada e armaze-
.pcap para posterior anlise com o software ClearSight

Fluke
nada em arquivos com extenso
Analyzer do fabricante . Vale ressaltar que foram realizadas 05 (cinco) capturas
individuais em diferentes momentos para os trfegos em protocolo IPv4 e em IPv6.
Antes de expor os resultados obtidos das capturas, importante destacar aspectos
relevantes respeito do servio VoIP. Os 02 (dois) principais parmetros de qualidade de
servio de voz mais afetados pelo desempenho da rede IP e processamento de VoIP so a
74
Figura 6.6: ndices de desempenhos de trfego VoIP nos protocolos IPv4 e IPv6
clareza ou qualidade e atraso de voz. A melhoria da voz depende de muitos fatores, alm
de perda de pacotes e jitter, e os vrios fatores inuenciam um no outro.
Por ser sensvel ao tempo, a voz tem uma baixa tolerncia a atrasos (<100 milissegun-
dos) [52]. Uma tolerncia para varincia do atraso ou jitter (<400 milissegundos). Alm
disso, as aplicaes de voz geralmente tm uma baixa tolerncia para a perda de pacotes
(<1%). Por frequentemente utilizarem protocolo UDP, um pacote perdido signica perda
de dados, no h retransmisses [49].
Figura 6.7: Relatrio de perda de pacotes no trfego VoIP nos protocolos IPv4 e IPv6
software ClearSight Analyzer sobre captura

Fluke Optiview de trfego VoIP entre os hosts ALFA
Conforme sumarizao executada pelo
ZETA
obtida por meio do equipamento
e sobre os protocolos IPv4 e IPv6, a Figura 6.6 extrada e adaptada de relatrio
do software ClearSight Analyzer j expe de forma sucinta alguns indicadores rele-
vantes anlise. identicado que no houve perda de pacotes na comunicao VoIP
hosts,
ZETA
sobre o protocolo IPv4 em nenhum dos enquanto que na comunicao sobre o pro-
tocolo IPv6 foi registrada uma perda de 0,24% no lado do host , taxa ainda assim
considerada muito boa mediante referncia supracitada. A varincia de atraso ou jitter

no trfego VoIP se manteve em patamares sensivelmente abaixo do limite recomendvel,
ALFA ZETA
tanto na comunicao pelo protocolo IPv4 como com o IPv6. Isso permitiu o alcance
dos uxos de pacotes de voz do host para o destino host , reciprocamente,
numa harmonia constante, e em um ritmo de recebimento de pacotes proximamente com
que foram gerados.
Ainda com referncia Figura 6.6, nos trfegos em protocolos IPv4 e IPv6, os pacotes
no sofreram atrasos signicativos a ponto de culminar em desordem, como se v no
75
campo Out of Sequence com taxas percentuais de 0,00%, o que aponta que mesmo com
o trfego de fundo (concorrente) na rede, o ambiente de rede apresenta-se adequado ao
trfego de aplicaes sensveis como VoIP. O campo Out of Sequence pode ainda apontar
que o enlace sofre de perdas, duplicao ou reordenao. O valor da latncia est na
mdia em um patamar bastante aceitvel para aplicaes de VoIP, tanto no protocolo
IPv4 quanto IPv6, dado que, como pode ser observado na Figura 6.6 a latncia encontra-se
sensivelmente abaixo do limite recomendado para servio VoIP, que de 150 milissegundos
[48]. Entretanto, esta taxa de latncia apresentada pelo protocolo IPv6 foi 32,38% maior
que a taxa do protocolo IPv4.
Um relatrio de pacotes perdidos foi gerado no intuito de demonstrar gracamente os
dados j conhecidos respeito de perda de pacote, dados estes demonstrados na Figura
6.7 extrada e adaptada de relatrio do software ClearSight Analyzer . De forma com-
ALFA ZETA
plementar, a este relatrio foi adicionada para cada protocolo IPv4 e IPv6 a quantidade
de pacotes envolvida na comunicao VoIP entre os hosts e e a taxa per-
centual de pacotes perdidos. Nota-se que no houve perda de pacotes para a comunicao
realizada em IPv4, com a taxa percentual de perda de pacotes de 0,00%, um excelente in-
dicativo. Enquanto que na comunicao realizada em IPv6, embora tenha ocorrido perda
de pacotes da ordem de 0,24%, ainda assim representa uma tima qualidade do dilogo.
Figura 6.8: Indicadores de mtodos de avaliao de desempenho do trfego VoIP nos

protocolos IPv4 e IPv6
Ao se tratar de mtodos de avaliao de desempenho, por meio da Figura 6.8 extrada
e adaptada de relatrio do software ClearSight Analyzer , ca comprovado que o trfego

de voz tomado como experimento no laboratrio prtico ocorreu em alta qualidade nos
protocolos IPv4 e IPv6, e isto se baseia nos indicadores expostos. Os R-Values alcanados
em ambas verses foram identicados acima de 90 pontos e o ndices MOS acima de
4.34 pontos, o que representam pontuaes de um nvel de satisfao do cliente VoIP
denominada de Very satised ou Muito Satisfatrio [53].
76
6.4.2 Anlise dos Resultados
Os resultados apresentados nas avaliaes 1 e 2 levam compreenso de que os proto-
colos IPv4 e IPv6 demonstram uma pequena diferena de desempenho, consubstanciando
na equivalncia entre as verses do protocolo. Na avaliao 1 o protocolo IPv4 apresentou
resultados melhores se comparados aos resultados do IPv6, enquanto que na avaliao 2
os resultados das duas verses do protocolo IP no apresentaram signicativas diferenas
de desempenho, mas ambas avaliaes com resultados satisfatrios para as aplicaes em
anlise. Em meio a estas avaliaes, relevante que em um processo contnuo de imple-
mentao do novo protocolo nos ambientes de rede em produo, que sejam executadas
mais avaliaes sobre os servios de amplo uso na REDUnB.
Em complemento anlise dos resultados, vale julgar o ambiente de laboratrio para
execuo dos experimentos no estudo em questo, considero extremamente proveitoso o
uso de ambiente real com equipamentos de alto desempenho. Com esta escolha tornou
possvel notar o comportamento na prtica da coexistncia dos protocolos IPv4 e IPv6
sem ter a considervel limitao de hardware quando se usa ambientes virtuais. O labo-
ratrio foi montado com topologias de rede lgica e fsica correspondentes ao ambiente da
REDUnB, com exceo da bandwidth de cada enlace do backbone em topologia full mesh,
que no laboratrio foram estabelecidos em 1Gbps ao contrrio do ambiente real que de
10Gbps. Contudo, a dissemelhana entre os referidos enlaces do ambiente de backbone da
REDUnB com o do laboratrio no inuenciou nos resultados obtidos nos experimentos.
Ainda na composio do laboratrio, foram utilizados computadores com congura-
es frequentemente encontradas com os clientes na REDUnB. Estes computadores com
interfaces de rede com bandwidth de 100Mbps, limitou sensivelmente a possibilidade de
exausto do ambiente de rede. Os switches designados para o laboratrio por serem de alto
desempenho conforme especicado neste documento, necessitariam de uma infraestrutura
com caractersticas superiores para esgotamento de sua capacidade. Contudo, o ambi-
ente conforme implementado apresentou condies bastante favorveis aos experimentos
escolhidos bem como a possibilidade de muitos outros experimentos de aplicabilidades
distintas.
importante considerar sobre os resultados apresentados, que se observado o am-
biente de laboratrio, possvel atribuir seguramente validade aos experimentos e aos
resultados, principalmente por se tratar de tarefas executadas em ambiente real e com in-
sero de trfego de fundo para simular congestionamentos de rede em operao. Mesmo
ao julgar vlidos e seguros os resultados obtidos, no so dispensados experimentos com
maior nmero de servios e em diferentes formatos de coletas de informaes, diferentes
metodologias, mtricas de avaliaes, e em ambiente de produo. O fato que o tempo
exguo com o equipamento Fluke Optiview XG no processo de produo deste projeto
77
no permitiu a execuo de experimentos com um maior nmero de servios.

Este captulo apresentou o cenrio de avaliao executado em laboratrio real. Na
sequncia foram expostas as caractersticas do laboratrio e as conguraes utilizadas
para implementao do modelo descrito neste estudo. Por m, foram descritas as m-
tricas perseguidas no ambiente de testes, a certicao de ambiente e os testes com seus
resultados.
78
Captulo 7
Concluses
Por meio da anlise dos resultados obtidos foi possvel concluir que o protocolo IPv4
possui um melhor desempenho do que o protocolo IPv6, mesmo que mdico. Mesmo com
desempenho inferior, a transio se faz necessria e j vem sendo executada de forma
gradual, mas no h como precisar uma data para migrao total. O IPv4 ainda deve
funcionar por muitos anos.
O processo de migrao de verso do protocolo IP nas redes atuais, incluindo a RE-
DUnB, precisa ocorrer, um processo imperioso para o futuro da Internet. A crescente
escassez do IPv4 possivelmente submeter as empresas e os prossionais de tecnologias de
redes a esta ao. Conforme abordado, o IPv6 no somente tem a vantagem de disponibi-
lizar endereos vlidos para toda a necessidade atual, mas tambm com a previso futura
do uso crescente com a Internet das Coisas. Embora a REDUnB atualmente no vivencie
a referida escassez, no inteligente ignorar o movimento registrado em todo o mundo
quanto migrao para o IPv6, seno esta migrao poder ocorrer de forma repentina
no momento em que a escassez atingir pontos crticos.
Em alguns ambientes de rede a utilizao do protocolo IPv6 pode parecer algo ainda
distante de acontecer, por existir barreira a ser vencida quanto a atualizao de hardwares
e softwares, o que representa custos elevados. De forma propcia, o ambiente da REDUnB
tambm j possui sua infraestrutura completa sobre hardwares e softwares (sistemas ope-
racionais) que j suportam o novo protocolo, o que representa um signicativo subsdio
para investimento no estudo da migrao para o protocolo IPv6.
Nesta circunstncia, o modelo escolhido para migrao do ambiente IPv4 para IPv6 foi
o de ampla utilizao da tcnica de Pilha Dupla. Neste modelo so conguradas as duas
verses de protocolos nos equipamentos de rede, permitindo aos usurios o acesso a redes
em IPv4 utilizando seu endereo IPv4 e redes IPv6 utilizando seu endereo IPv6, o que
proporciona a transio um processo suave e sem grandes transtornos. Para simulao
da implementao do cenrio de rede em Pilha Dupla foi utilizado um laboratrio em
79
ambiente real, no qual os testes apresentaram resultados equivalentes entre os protocolos
IPv4 e IPv6 quanto s mtricas escolhidas. Outro aspecto relevante nas avaliaes que
os switches routers envolvidos no laboratrio no apresentaram aumento considervel de
processamento da CPU, mesmo com os testes ocorrendo em meio ao trfego de fundo.
A viabilidade para realizao desta migrao na REDUnB no requer grandes modi-
caes da estrutura das redes instaladas. Mas como implantar IPv6 afeta vrias reas,
importante ter o apoio de instncias superiores da instituio, no basta s a equipe de
prossionais de redes, os prossionais que trabalham na rea de sistemas e os provedores
de servios tambm precisam estabelecer plano de adaptao de sistemas para suporte ao
IPv6. Ademais, a maioria dos grandes provedores de Internet ainda no oferecem suporte
nativo nem servio IPv6 para os clientes, exigindo assim, o condicionamento do servio
prestado demanda pela entrega de trfego IPv6. De forma complementar, preciso que
os prossionais de redes e sistemas, alm de equipes de apoio tcnico em redes, sejam
treinados, pois, no possuem conhecimento suciente de IPv6 para suporte tcnico.
Contudo, a administrao da atribuio de endereos IPv4 e IPv6 na REDUnB precisa
ocorrer preferencialmente por meio de mecanismos automticos, em especial por se tratar
de ambiente de rede com grande nmero de clientes. Nesta tarefa seguramente o uso
dos protocolos DHCPv4 e DHCPv6 oferecem uma soluo mais escalvel e segura, e que
cabe como sugesto para estudo futuro, alm de esforo aplicado sobre a segurana no
protocolo IPv6.
Ademais, este trabalho pode ser melhorado com a disponibilizao no ambiente de
laboratrio de computadores mais robustos para os experimentos, com a elaborao de
avaliaes de outros servios de amplo uso na REDUnB alm de implementao de trfego
IPv6 no mbito da sada para a Internet.
O atual panorama de implantao permite concluir que grande parte das redes ainda
no est apta a receber o novo protocolo IPv6. Ainda por um tempo indenido, as duas
verses continuaro existindo, de forma que os mecanismos de transio garantiro a
interoperabilidade entre elas.
Porm, espera-se que este trabalho possa servir de incentivo a discusses sobre a adoo
do IPv6, sendo tambm til quem deseja obter informaes a respeito da transio, mas
que cada ambiente de rede possui suas peculiaridades e exigem solues igualmente com
suas particularidades.
80
Referncias
[1] L. ZIMU; P. WEI e L. YUJUN. An innovative ipv4-ipv6 transition way for internet
service provider. http://ieeexplore.ieee.org/stamp/stamp.jsp-arnumber-6219279, nov
2012. xiii, 44, 45, 50
[2] Silvia HAGEN. IPv6 Essentials Integrating IPv6 into Your IPv4 Network. O'Reilly
Media Inc., 3rd edition, 2014. 1, 2, 14, 15, 18, 19, 22, 23, 25, 29, 33, 35, 39, 40, 42,
50
[3] Secretaria de Logstica e Tecnologia da Informao Ministrio do Planejamento Or-

amento e Gesto. Padres de interoperabilidade de governo eletrnico e-ping, verso
2015. http://eping.governoeletronico.gov.br, jun 2015. 3
[4] Bruce HARTPENCE. Packet Guide to Core Network Protocols. O'Reilly Media Inc.,
1st edition, 2011. 5
[5] Andrew S. TANENBAUM. Computer Networks. Editora Campus, 4th edition, 2003.
6, 7, 8, 73
[6] Douglas E. COMER. Interligao em Rede com TCP/IP: Princpios, protocolos e

arquitetura. Editora Elsevier, 3rd edition, 1998. 6
[7] James F. KUROSE e Keith W. ROSS. Redes de computadores e a Internet: uma

abordagem top-down. Pearson Education, 6th edition, 2013. 8, 10, 26, 29, 68
[8] V. FULLER e T. LI. Request for comments 4632. classless inter-domain

routing (cidr): The internet address assignment and aggregation plan.
https://tools.ietf.org/html/rfc4632, aug 2006. 9
[9] R. DROMS. Request for comments 2131. dynamic host conguration protocol.
https://tools.ietf.org/html/rfc2131, mar 1997. 9
[10] K. EGEVANG e P. FRANCIS. Request for comments 1631. the ip network address
translator (nat). https://tools.ietf.org/html/rfc1631, may 1994. 9
[11] Y. REKHTER; B. MOSKOWITZ; G. J. de GROOT; D. KARRENBERG e

E. LEAR. Request for comments 1918. address allocation for private internets.
https://tools.ietf.org/html/rfc1918, feb 1996. 9
[12] Pete LOSHIN. IPv6: Theory, Protocol, and Practice. Morgan Kaufmann Publishers,
2nd edition, 2004. 10, 27
81
[13] Gary A. DONAHUE. Network Warrior. O'Reilly Media, 2nd edition, 2011. 10, 29,
67, 68
[14] Lawrence E. HUGHES. The Second Internet - Reinventing Computer Networking

with IPv6. InfoWeapons, 1st edition, 2010. 11, 17, 18, 19, 21, 26, 28, 32, 37, 39
[15] Iljitsch van BEIJNUM. Running IPv6. Apress, 1st edition, 2006. 12, 20, 30, 34
[16] Qing LI; Tatuya JINMEI e Keiichi SHIMA. IPv6 Core Protocols Implementation.
Morgan Kaufmann Publishers, 1st edition, 2007. 12
[17] B. CAIN; S. DEERING; I. KOUVELAS; B. FENNER e A. THYAGARAJAN.

Request for comments 3376. internet group management protocol, version 3.
https://tools.ietf.org/html/rfc3376, oct 2002. 13
[18] S. DEERING; W. FENNER e B. HABERMAN. Request for comments 2710. multi-

cast listener discovery (mld) for ipv6. https://tools.ietf.org/html/rfc2710, oct 1999.
13
[19] Niall Richard MURPHY e David MALONE. IPv6 Network Administration. O'Reilly
Media, 1st edition, 2005. 13, 22
[20] Adilson Aparecido FLORENTINO. IPv6 na Prtica. New Media do Brasil Editora
Ltda, 1st edition, 2012. 14
[21] M. BLANCHET. Request for comments 3531. a exible method for managing the
assignment of bits of an ipv6 address block. https://tools.ietf.org/html/rfc3531, apr
2003. 14, 56
[22] S. DEERING e R. HINDEN. Request for comments 2460. internet protocol, version
6 (ipv6) specication. https://tools.ietf.org/html/rfc2460, dec 1998. 15, 17
[23] K. NICHOLS; S. BLAKE; F. BAKER e D. BLACK. Request for comments 2474.

denition of the dierentiated services eld (ds eld) in the ipv4 and ipv6 headers.
https://tools.ietf.org/html/rfc2474, dec 1998. 15
[24] K. RAMAKRISHNAN; S. FLOYD e D. BLACK. Request for com-

ments 3168. the addition of explicit congestion notication (ecn) to ip.
https://tools.ietf.org/html/rfc3168, sep 2001. 15
[25] J. REYNOLDS e J. POSTEL. Request for comments 1700. assigned numbers.

[26] A. CONTA; S. DEERING e M. GUPTA. Request for comments 4443. internet control
message protocol (icmpv6) for the internet protocol version 6 (ipv6) specication.
[27] Daniel MINOLI e John J. AMOSS. Handbook of IPv4 to IPv6 Transition, Metho-
dologies for Institutional and Corporate Networks. Auerbach Publications Taylor e
Francis Group, 1st edition, 2008. 22, 36, 37, 39
82
[28] R. DROMS; J. BOUND; B. VOLZ; T. LEMON; C. PERKINS e M. CARNEY.
Request for comments 3315. dynamic host conguration protocol for ipv6 (dhcpv6).
https://tools.ietf.org/html/rfc3315, jul 2003. 22
[29] Sheila FRANKEL; Richard GRAVEMAN; John PEARCE e Mark ROOKS. Guideli-
nes for the Secure Deployment of IPv6 - Recommendations of the National Institute
of Standards and Technology. NIST, 1st edition, 2010. 26, 30, 31, 35, 37, 39
[30] R. COLTUN; D. FERGUSON; J. MOY e A. LINDEM. Request for comments 5340.

ospf for ipv6. https://tools.ietf.org/html/rfc5340, jul 2008. 27, 28
[31] S. Y. REKHTER; LI, T. e HARES. Request for comments 4271. a border gateway
protocol 4 (bgp-4). https://tools.ietf.org/html/rfc4271, jan 2006. 29
[32] T. BATES; R. CHANDRA; D. KATZ e Y. REKHTER. Request for comments 4760.

multiprotocol extensions for bgp-4. https://tools.ietf.org/html/rfc4760, jan 2007. 29
[33] S. KENT e R. ATKINSON. Request for comments 2401. security architecture for
the internet protocol. https://tools.ietf.org/html/rfc2401, nov 1998. 31
[34] John e Sons WILEY. Networking Fundamentals. Wiley, 1st edition, 2011. 31
[35] M-K. SHIN; Y-G. HONG; J-I I. HAGINO; P. SAVOLA e E. M. CAS-

TRO. Request for comments 4038. application aspects of ipv6 transition.
[36] E. NORDMARK. Request for comments 2765. stateless ip/icmp translation algo-
rithm (siit). https://tools.ietf.org/html/rfc2765, feb 2000. 36
[37] C. AOUN e E. DAVIES. Request for comments 4966. reasons to move the
network address translator protocol translator (nat-pt) to historic status.
https://tools.ietf.org/html/rfc4966, jul 2007. 36
[38] J. HAGINO e K. YAMAMOTO. Request for comments 3142. an ipv6-to-ipv4 trans-

port relay translator. https://tools.ietf.org/html/rfc3142, jun 2001. 36
[39] S. LEE; M-K. SHIN; Y-J. KIM; E. NORDMARK e A. DURAND. Re-

quest for comments 3338. dual stack hosts using bump-in-the-api (bia).
[40] Dan YORK. Migrating Applications to IPv6. O'Reilly Media, 1st edition, 2011. 38,
42, 43
[41] S. THOMSON; C. HUITEMA; V. KSINANT e M. SOUISSI. Request for comments

3596. dns extensions to support ip version 6. https://tools.ietf.org/html/rfc3596, oct
2003. 42
[42] Joseph DAVIES. Understanding IPv6. O'Reilly Media, 3rd edition, 2012. 42
[43] D. WING e A. YOURTCHENKO. Request for comments 6555. happy eyeballs:

Success with dual-stack hosts. https://tools.ietf.org/html/rfc6555, apr 2012. 43
83
[44] Cricket LIU. DNS and BIND on IPv6. O'Reilly Media, 1st edition, 2011. 43
[45] H. HOU; Q. ZHAO e Y. MA. Design and implementation of a solution to smo-

oth ipv6 transition. http://ieeexplore.ieee.org/xpls/absall.jsp-arnumber-5696883tag-
1, jul 2010. 44, 46, 47, 50
[46] P. WU; Y. CUI; J. WU; J. LIU e C. METZ. Transition from ipv4 to ipv6, a state-of-
the-art survey. http://ieeexplore.ieee.org/stamp/stamp.jsp-arnumber-6380492, jun
2013. 44, 47, 48, 50
[47] Fluke Corporation. Datasheet: Optiview xg network analysis tablet - trac and
packet analysis. http://pt.ukenetworks.com/content/optiview-xg-network-analysis-
tablet, oct 2014. 66
[48] Yan CHEN; Toni FARLEY e Nong YE. Qos requirements of network applications on
the internet. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.475.9277,
sep 2004. 67, 68, 76
[49] F. FLUCKIGER. Understanding Networked Multimedia. Prentice Hall, 1st edition,

1995. 68, 75
[50] N. YE. Qos-centric stateful resource management in information systems. information

systems frontiers. http://dl.acm.org/citation.cfm?id=595230, oct 2002. 68
[51] Sivannarayana NAGIREDDI. VoIP Voice and Fax Signal Processing. Wiley, 1st
edition, 2008. 68, 69
[52] B. O. SZUPROWICZ. Multimedia Networking. McGraw-Hill, 1st edition, 1995. 75
[53] J. A. BERGSTRA e C. A. MIDDELBURG. Itu-t recommendation g.107.

the e-model, a computational model for use in transmission planning.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.103.3547, nov 2003. 76
84
Parte I
Apndices
85
Apndice A
switch R1 backbone
R1
Conguraes de no do laboratrio prtico:
begin
set vlan create 10
set vlan create 701
set vlan create 4001
set vlan name 10 "ENLACE-R1-AGREGACAO"
set vlan name 701 "GER"
set vlan name 4001 "ENLACE-R1-R2"
clear vlan egress 1 ge.1.1-2;ge.1.22-24
set vlan egress 10 ge.1.2 untagged
set host vlan 701
router
enable
congure
ipv6 unicast-routing
interface vlan 10
ip address 10.11.11.1 255.255.255.0
ip ospf areaid 0.0.0.1
ip ospf enable
86
ipv6 address fec0:11:11:11::1/64
ipv6 ospf areaid 0.0.0.5
ipv6 ospf enable
no shutdown
exit
interface vlan 4001
ip address 10.1.1.1 255.255.255.0
ip ospf enable
ipv6 ospf enable
no shutdown
exit
interface vlan 4002
ip address 10.2.2.1 255.255.255.0
ip ospf enable
ipv6 ospf enable
no shutdown
exit
interface vlan 4003
ip address 10.3.3.1 255.255.255.0
ip ospf enable
ipv6 ospf enable
no shutdown
exit
router id 10.10.10.10
router ospf 1
area 0.0.0.1 nssa
exit
ipv6 router id 110.110.110.110
ipv6 router ospf
area 0.0.0.5 nssa
exit
87
exit
exit
exit
set ipv6 enable
set port vlan ge.1.1 701
set spantree version rstp
set spantree portadmin ge.1.2 disable
set spantree priority 0 0
R2
end
switch backbone
R2
begin
set vlan create 20
set vlan create 701
set vlan egress 701 ge.1.1 tagged
set host vlan 701
router
88
enable
congure
interface vlan 20
ip address 10.22.22.1 255.255.255.0
ip ospf enable
ipv6 ospf enable
no shutdown
exit
interface vlan 4001
ip address 10.1.1.2 255.255.255.0
ip ospf enable
ipv6 ospf enable
no shutdown
exit
interface vlan 4004
ip address 10.4.4.1 255.255.255.0
ip ospf enable
ipv6 ospf enable
no shutdown
exit
interface vlan 4005
ip address 10.5.5.1 255.255.255.0
ip ospf enable
ipv6 ospf enable
no shutdown
exit
router id 20.20.20.20
89
router ospf 1
area 0.0.0.2 nssa
exit
ipv6 router id 120.120.120.120
ipv6 router ospf
area 0.0.0.6 nssa
exit
exit
exit
exit
set ipv6 enable
R3
end
switch backbone
R3
begin
set vlan create 30
set vlan create 701
90
set host vlan 701
router
enable
congure
interface vlan 30
ip address 10.33.33.1 255.255.255.0
ip ospf enable
ipv6 ospf enable
no shutdown
exit
interface vlan 4002
ip address 10.2.2.2 255.255.255.0
ip ospf enable
ipv6 ospf enable
no shutdown
exit
interface vlan 4004
ip address 10.4.4.2 255.255.255.0
ip ospf enable
ipv6 ospf enable
no shutdown
exit
interface vlan 4006
ip address 10.6.6.1 255.255.255.0
91
ip ospf enable
ipv6 ospf enable
no shutdown
exit
router id 30.30.30.30
router ospf 1
area 0.0.0.3 nssa
exit
ipv6 router id 130.130.130.130
ipv6 router ospf
area 0.0.0.7 nssa
exit
exit
exit
exit
set ipv6 enable
set spantree disable
R4
end
switch backbone
R4
begin
set vlan create 40
set vlan create 701
92
set host vlan 701
router
enable
congure
interface vlan 40
ip address 10.44.44.1 255.255.255.0
ip ospf enable
ipv6 ospf enable
no shutdown
exit
interface vlan 4003
ip address 10.3.3.2 255.255.255.0
ip ospf enable
ipv6 ospf enable
no shutdown
exit
interface vlan 4005
ip address 10.5.5.2 255.255.255.0
93
ip ospf enable
ipv6 ospf enable
no shutdown
exit
interface vlan 4006
ip address 10.6.6.2 255.255.255.0
ip ospf enable
ipv6 ospf enable
no shutdown
exit
router id 40.40.40.40
router ospf 1
area 0.0.0.4 nssa
exit
ipv6 router id 140.140.140.140
ipv6 router ospf
area 0.0.0.8 nssa
exit
exit
exit
exit
set ipv6 enable
94
Agregao R1
end
switch
Agregao R1
Conguraes de de agregao do laboratrio prtico:
begin
set vlan create 10
set vlan create 701
set vlan name 10 "ENLACE-AGREGACAO-R1"
set vlan name 100 "REDE-1"
set vlan egress 100 ge.1.1-12 untagged
set host vlan 701
router
enable
congure
interface vlan 10
ip address 10.11.11.2 255.255.255.0
ip ospf enable
ipv6 ospf enable
no shutdown
exit
interface vlan 100
ip address 192.168.11.1 255.255.255.0
ip ospf enable
ipv6 address 2801:80:b90::1/64
ipv6 ospf enable
no shutdown
exit
interface loopback 1
ip address 10.1.1.1 255.255.255.255
95
ip ospf enable
no shutdown
exit
router id 10.1.1.1
router ospf 1
area 0.0.0.1 nssa
redistribute connected subnets
exit
ipv6 router id 110.101.101.101
ipv6 router ospf
area 0.0.0.5 nssa
redistribute connected
exit
exit
exit
exit
set ipv6 enable
96
set port mirroring create ge.1.14 ge.1.15
set port mirroring enable ge.1.14 ge.1.15
Agregao R2
end
switch
Agregao R2
begin
set vlan create 20
set vlan create 200
set vlan create 201
set vlan create 701
set vlan name 201 "REDE-2-IPv4Only"
set host vlan 701
router
enable
congure
interface vlan 20
ip address 10.22.22.2 255.255.255.0
ip ospf enable
ipv6 ospf enable
no shutdown
exit
interface vlan 200
ip address 192.168.21.1 255.255.255.0
ip ospf enable
97
ipv6 address 2801:80:b90:4000::1/64
ipv6 ospf enable
no shutdown
exit
interface vlan 201
ip address 192.168.22.1 255.255.255.0
ip ospf enable
no shutdown
exit
ip address 10.2.2.1 255.255.255.255
ip ospf enable
no shutdown
exit
router id 10.2.2.1
router ospf 1
area 0.0.0.2 nssa
exit
ipv6 router id 110.102.102.101
ipv6 router ospf
area 0.0.0.6 nssa
exit
exit
exit
exit
set ipv6 enable
98
Agregao R3
end
switch
Agregao R3
begin
set vlan create 30
set vlan create 300
set vlan create 301
set vlan create 701
set vlan name 301 "REDE-3-IPv6Only"
set host vlan 701
router
enable
congure
interface vlan 30
ip address 10.33.33.2 255.255.255.0
99
ip ospf enable
ipv6 ospf enable
no shutdown
exit
interface vlan 300
ip address 192.168.31.1 255.255.255.0
ip ospf enable
ipv6 address 2801:80:b90:8000::1/64
ipv6 ospf enable
no shutdown
exit
interface vlan 301
ipv6 address 2801:80:b90:8001::1/64
ipv6 ospf enable
no shutdown
exit
ip address 10.3.3.1 255.255.255.255
ip ospf enable
no shutdown
exit
router id 10.3.3.1
router ospf 1
area 0.0.0.3 nssa
exit
ipv6 router id 110.103.103.101
ipv6 router ospf
area 0.0.0.7 nssa
exit
100
exit
exit
exit
set ipv6 enable
Agregao R4
end
switch
Agregao R4
begin
set vlan create 40
set vlan create 400
set vlan create 701
set host vlan 701
101
router
enable
congure
interface vlan 40
ip address 10.44.44.2 255.255.255.0
ip ospf enable
ipv6 ospf enable
no shutdown
exit
interface vlan 400
ip address 192.168.41.1 255.255.255.0
ip ospf enable
ipv6 address 2801:80:b90:c000::1/64
ipv6 ospf enable
no shutdown
exit
ip address 10.4.4.1 255.255.255.255
ip ospf enable
no shutdown
exit
router id 10.4.4.1
router ospf 1
area 0.0.0.4 nssa
exit
ipv6 router id 110.104.104.101
ipv6 router ospf
area 0.0.0.8 nssa
102
exit
exit
exit
exit
set ipv6 enable
end
103
Apndice B
named.conf
Conguraes do servidor de resoluo de nomes (DNS) no laboratrio prtico:
Arquivo
options {
directory "/etc/named/";
listen-on { any; };
listen-on-v6 { any; };
allow-query { any; };
recursion no;
};
zone "."{
type hint;
le "named.root";
};
zone "localhost"{
type master;
le "/etc/bind/db.local";
};
zone "lab.unb.br"{
type master;
le "lab.unb.br.zone";
};
zone "168.192.in-addr.arpa"{
type master;
le "192-168.db";
lab.unb.br.zone
};
Arquivo
$TTL 1s
lab.unb.br. IN SOA ns.lab.unb.br. root.lab.unb.br. (
104
19 ; serial
28800 ; refresh
7200 ; retry
604800 ; expire
1s ; ttl
;; Servidor que responde pelo dominio
IN NS ns.lab.unb.br.
ns IN A 192.168.41.2
ns IN AAAA 2801:80:b90:c000::2
;; Hosts do LAB
alfa.lab.unb.br. IN A 192.168.11.2
alfa.lab.unb.br. IN AAAA 2801:80:b90:0000::2
beta.lab.unb.br. IN A 192.168.21.2
beta.lab.unb.br. IN AAAA 2801:80:b90:4000::2
gamav4.lab.unb.br. IN A 192.168.31.2
gamav6.lab.unb.br. IN AAAA 2801:80:b90:8000::2
zetav4.lab.unb.br. IN A 192.168.41.2
zetav6.lab.unb.br. IN AAAA 2801:80:b90:c000::2
teta.lab.unb.br. IN A 192.168.22.2
capa.lab.unb.br. IN A 192.168.31.3
Comando para iniciar servio do servidor de resoluo de nomes (DNS)
sudo named -c /etc/named.conf
105
Apndice C
softwareAsterisk
Asterisk
Conguraes do servio de voz sobre IP em :
Comandos para iniciar e parar servio do software :
Para iniciar: 'sudo /etc/init.d/asterisk start';
sip.conf
Para parar: 'sudo /etc/init.d/asterisk stop';
Arquivo
;contexto geral, conguracoes gerais dos canais sip
[general]
;iudpbindaddr=0.0.0.0
;disallow=all
;allow=ulaw
;session-timers=refuse
;session-expires=3600
;session-minse=90
;session-refresher=uac
bindaddr=::
;useragent=unbvoip
srvlookup=yes
maxexpirey=120
dafaultexpirey=80
language=pt_BR
nat=force_rport,comedia instead
;qualify=yes
rtcachefriends=yes
canreinvite=no
realm=asterisk
call-limit = 1000
;textsupport=yes
;accept_outofcall_message=yes
106
;outofcall_message_context=astsms
;TESTES
disallow=all
allow=ulaw
allow=alaw
allow=gsm
;TEMPLATE DE CANAIS SIP SEM TLS
[sip](!)
context=internal
type=friend
host=dynamic
callgroup=10
pickupgroup=10
encryption=no
;;;;;;;;;;;;;;;;;
;CANAIS SIP
[1001](sip)
defaultuser=1001
secret=1001
callerid = Cliente1
[1002](sip)
defaultuser=1002
secret=1002
sip.conf
callerid = Cliente2
Arquivo
;SECAO QUE DEFINE VALORES PADROES PARA OUTRAS SESSOES
[general]
static=yes
writeprotect=no
autofallthrough=yes
priorityjumping=yes
language=pt_BR
[default]
include => internal
;EXTENSAO GENERICA QUE FAZ LIGACOES PARA TODOS OS RAMAIS
[internal]
exten => _X.,1,Macro(discar,SIP,$EXTEN)
107
exten => _X.,n,Hangup()
;MACRO QUE REALIZA LIGACOES PARA RAMAIS DO ASTERISK
[macro-discar]
exten => s,1,Dial($ARG1$ARG2,20,tTwW)
exten => s,n,Goto(s-$DIALSTATUS,1)
exten => s-BUSY,1,VoiceMail($ARG2@caixa_msg,b) ;ocupado
exten => s-NOANSWER,1,VoiceMail($ARG2@caixa_msg,u) ;ele nao atende
exten => s-CHANUNAVAIL,1,ExecIf($[MAILBOX_EXISTS($ARG2@caixa_msg)]?VoiceMail
($ARG2@caixa_msg,u):Playback(erro))
108
Apndice D
Com o objetivo de vericar a correta congurao dos equipamentos do laboratrio,
host
ALFA
esta seo expe os detalhes das certicaes de ambiente aplicadas. A partir do
foi comprovado o alcance deste aos demais hosts do laboratrio prtico tanto no
protocolo IPv4 quanto com o IPv6 como pode ser visto na Figura D.1. O teste de alcance
foi executado por meio do comando 'Ping' (ping <endereo IPv4 ou IPv6> -t) que para
sistemas operacionais Windows pode ser usado para ambas verses do protocolo IP.
Figura D.1: Alcance do host ALFA para os demais hosts do ambiente de teste por meio
do comando 'Ping'
host GAMA host ALFA

ALFA
Como se v na Figura D.2 o alcana o . Importante con-
ferir que o host possui registrado no servidor de resoluo de nomes 01 (um)
nome de domnio (alfa.lab.unb.br) e 02 (dois) registros de endereos IP (192.168.11.2 e
2801:80:b90:0000::2). Constata-se por meio da gura apresentada que embora o protocolo
ALFA
IPv6 possua prioridade de comunicao sobre o protocolo IPv4, na resoluo de nome para
o host foi traduzido para um endereo IPv4. Isto se deve pelo fato de que nos
sistemas operacionais, algumas aplicaes utilizam o mesmo comando para as 02 (duas)
verses do protocolo IP, enquanto em outras no. Como se v ainda na imagem em ques-
109
to, o comando 'Ping6' utilizado no sistema operacional Ubuntu para alcanar endereos
IPv6 e o comando 'Ping' para alcanar endereos IPv4.
Figura D.2: Alcance do host GAMA para o host ALFA por meio do comando 'Ping' e
'Ping6'
ALFA
Ainda no propsito de demonstrar a prioridade da comunicao pelo protocolo IPv6
hosts host
BETA
entre em Pilha Dupla, na Figura D.3 v-se um exemplo. O ao tentar
alcanar ohost por meio do comando 'Ping' e utilizando neste comando o nome
de domnio do host a alcanar (ping beta.lab.unb.br), ao consultar o servidor de resoluo
de nomes, a prioridade dada ao protocolo IPv6, assim, o endereo 2801:80:b90:4000::2
tem prioridade sobre o endereo 192.168.21.2. Pode ser notado tambm que no sistema
operacional Windows o comando 'Ping' pode ser utilizado para ambas verses do protocolo
IP.
Figura D.3: Host ALFA alcana o host BETA por meio do comando 'Ping'
Como j citado neste documento, compete aos servidores de resoluo de nomes (DNS)
um papel elementar para o sucesso das redes, sejam elas concernentes ao universo IPv4
110
ou IPv6. Com a coexistncia das 02 (duas) verses do protocolo IP, sua funo se torna
TETA
ainda mais valorosa, facilitando a localizao de recursos na rede.
host
ZETA
Na Figura D.4 apresentada uma consulta do ao servidor DNS do la-
boratrio (host ) por informaes sobre domnio ou host. A consulta ocorre atra-
vs do comando 'Nslookup' com o objetivo de obter detalhes sobre o nome de domnio
alfa.lab.unb.br, retornando alm do endereo do servidor DNS (192.168.41.2) consultado,
os endereos IPv4 e IPv6 (2801:80:b90:0000::2 e 192.168.11.2) correspondentes ao nome
hosts
TETA
de domnio de interesse. Outra constatao a ser extrada que apenas com IPv4
podem receber detalhes de informaes de endereos IPv6, como o caso do host

que apenas possui endereo IPv4.
Figura D.4: Resoluo de nome do host TETA para o host ALFA

Um aspecto muito importante do uso da tcnica de Pilha Dupla nos hosts se deve
ao fato de que a comunicao precisa ocorrer destes com hosts que operam apenas no
BETA CAPA
universo de redes IPv4, a comunicao precisa ser estabelecida de forma estvel para o
usurio. V-se pela Figura D.5 que o host em Pilha Dupla alcana o host
somente em IPv4, obviamente, por meio deste ltimo protocolo IP, circunstncia que se
replica normalmente nas demais comunicaes entre hosts em Pilha Dupla e somente em
IPv4, seja no ambiente de rede local ou deste com a Internet.
Figura D.5: Host BETA traa rota para o host CAPA por meio do comando 'Tracert'
host
BETA CAPA
Ainda com referncia Figura D.5, relevante explicitar que a comunicao do
para o host foi executada por meio do comando 'Tracert', o qual expe
os endereos IPs dos switches (roteadores) intermedirios entre a origem e o destino, isto
, traa a rota entre ambos.
Na perspectiva do roteamento das redes do laboratrio prtico, como j informado,
foram congurados os protocolos OSPF verses 2 e 3. A Figura D.6 demonstra a tabela de
111
roteamento OSPF do switch router R1 , consulta executada por meio do comando show ip
route. Embora o comando citado apresente as tabelas das 02 (duas) verses do protocolo
OSPF, estas operam de forma independente.
Figura D.6: Tabela de rotas consultada no switch router R1

No decorrer dos testes com o trfego de fundo em execuo, relevante ter uma viso
do nvel de utilizao da CPU (Central Processing Unit ) dos switches do laboratrio
prtico com o advento do uso dos protocolos IPv4 e IPv6 em Pilha Dupla. A Figura
D.7 exibe as respostas ao comando show system utilization utilizado em todos os switches
envolvidos no cenrio de testes enquanto o trfego de fundo executado. Como se v,
os nveis de utilizao de CPU em todos os switches apresentam-se baixos, o que aponta
comportamento adequado para a operao onde lhe conferida a habilidade de trabalhar
com protocolos adicionais, como o IPv6 e OSPF verso 3.
Figura D.7: Nvel de utilizao de CPU nos switches do laboratrio
host ALFA web

ZETA ALFA
Na complementao de certicaes de ambiente, o acessa a pgina
do host e este a pgina web do host como se v na Figura D.8. Este
experimento possui objetivo de primeiramente demonstrar o comportamento da resoluo
112
de nomes entre hosts em Pilha Dupla que possuem diferentes entradas de registros no
servidor DNS.
Figura D.8: Acesso mtuo a servio HTML entre hosts ALFA ZETA
e
host ALFA
A AAAA
Importante observar que no servidor de resoluo de nomes (DNS) o
ZETA A
possui apenas 1 (um) nome de domnio para registros e outro , enquanto que
host
AAAA
o possui 2 (dois) nomes de domnios, 1 (um) para cada tipo de registro e
, como consta na Figura D.9.
Figura D.9: Conguraes de resoluo de nome para a zona lab.unb.br e habilitao

de IPv6 no DNS
Observa-se ainda na Figura D.9 as conguraes do arquivo named.conf onde
habilitada a resoluo de nomes para endereos IPv4 listen-on { any; }; e IPv6 listen-on-
v6 { any; };.
113
Parte II
Anexos
114
Anexo A
Figura A.1: Grupo de coleta 01 - IPv4
115
116
117
118
119
120
Anexo B
Figura B.1: Grupo de coleta 07 - IPv4
121
122
123
124
125
126
Anexo C
Figura C.1: Relatrio VoIP - IPv4 pag 01 de 02
127
Figura C.2: Relatrio VoIP - IPv4 pag 02 de 02
128
Anexo D
Figura D.1: Relatrio VoIP - IPv6 pag 01 de 02
129
Figura D.2: Relatrio VoIP - IPv6 pag 02 de 02
130

2015 JuvenaldosSantosBarreto

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

2015 JuvenaldosSantosBarreto

Загружено:

Авторское право:

Доступные форматы

Universidade de Braslia

Instituto de Cincias Exatas

Um Modelo de Migrao de Ambiente IPv4 para IPv6

Juvenal dos Santos Barreto

Dissertao apresentada como requisito parcial

para concluso do Mestrado Prossional em Computao Aplicada

Dissertao (Mestrado Mestrado Profissional em

1. Interconexo de redes. 2. Migrao de IPv4 para Ipv6. 3.

me realizasse prossionalmente e pessoalmente.

na vida, enfrentando minhas fraquezas e inseguranas.

A todos os professores do Mestrado Prossionalizante em Computao Aplicada, em

sdio no desenvolvimento do estudo em questo e por ter acreditado na minha vontade de

realizar este trabalho e na conana demonstrada durante toda a pesquisa.

A todos os colegas do curso, em especial ao Andrei, Arthur, Antonio, Eduardo, Jack-

son, Jobe, Karam e Riane, pelo constante companheirismo.

Hiroaki, Samuel Oliveira e Vincius Cesrio, pela compreenso em momentos de presses

intensas e contribuies pelo zelo s funes conadas.

e outros aqui no mencionados, e a prima Eliene Santos, pelas constantes palavras de

motivao e compartilhamento de bons momentos.

Enm, a todos que contriburam diretamente ou indiretamente neste trabalho com

simples apoios e incentivos.

A crescente demanda por informaes e, particularmente, o aumento exponencial de

infraestruturas frequentemente. A sensvel limitao do endereamento disponvel desta

tocolo da Internet, o IPv6. A Universidade de Braslia, como grande provedor de acesso

e de informaes, e procurando manter-se conectada ao maior nmero de usurios pos-

svel e em alta disponibilidade, v a necessidade de introduo de novas solues em seu

segura, gradual e suave.

Neste trabalho de pesquisa apresentada uma metodologia para criar um ambiente de

experimentos dentro da REDUnB (Rede de Dados da UnB) para implementao do IPv6,

analisando aspectos relacionados s tcnicas de transio com anlises de desempenho

migrao do ambiente de IPv4 para IPv6 em um ambiente de rede acadmica heterognea,

com perspectivas concretas de implementao no ambiente REDUnB.

Keywords: IPv6, transition techniques

6RD IPv6 Rapid Deployment

API Application Programming Interface

ARP Address Resolution Protocol

ASN Autonomous System Number

BIS Bump in the Stack

BGP Border Gateway Protocol

BRs Borders Relay

CERNET2 China Education and Research Network 2

CIDR Classless Inter-Domain Routing

CLNS Connectionless-mode Network Service

CPU Central Processing Unit

DDoS Distributed Denial of Service

DHCP Dynamic Host Conguration Protocol

DHCPv4 Dynamic Host Conguration Protocol for IPv4

DHCPv6 Dynamic Host Conguration Protocol for IPv6

DNS Domain Name System

DNS64 Domain Name System IPv6-IPv4

DSCP DiServ Code Point

ECN Explicit Congestion Notication

EGP Exterior Gateway Protocol

FTP File Transfer Protocol

ICMP Internet Control Message Protocol

ICMPv6 Internet Control Message Protocol version 6

IETF Internet Engineering Task Force

IGMP Internet Group Management Protocol

IGPs Interior Gateway Protocols

IPSec Internet Protocol Security

IPv4 Internet Protocol version 4

IPng Internet Protocol next generation

IPv6 Internet Protocol version 6

para concluso do Mestrado Prossional em Computao Aplicada

me realizasse prossionalmente e pessoalmente.

A todos os professores do Mestrado Prossionalizante em Computao Aplicada, em

realizar este trabalho e na conana demonstrada durante toda a pesquisa.

intensas e contribuies pelo zelo s funes conadas.

Enm, a todos que contriburam diretamente ou indiretamente neste trabalho com

DHCP Dynamic Host Conguration Protocol

DHCPv4 Dynamic Host Conguration Protocol for IPv4

DHCPv6 Dynamic Host Conguration Protocol for IPv6

DSCP DiServ Code Point

ECN Explicit Congestion Notication

N Network Layer Protocol IDentier

SLAAC Stateless Address Autoconguration

6.2 Conguraes de Equipamentos no Laboratrio . . . . . . . . . . . . . . . 61

6.3 Certicaes do Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . 66