Você está na página 1de 146

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

2.4 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

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

3.8 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4 Estado da Arte 44
4.1 Concluses sobre as tcnicas utilizadas nos artigos . . . . . . . . . . . . . . 50

4.2 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

5.3 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

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

6.5 Resumo do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

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

A.2 Grupo de coleta 02 - IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

A.3 Grupo de coleta 03 - IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

A.4 Grupo de coleta 04 - IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

A.5 Grupo de coleta 05 - IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

A.6 Grupo de coleta 06 - IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

B.1 Grupo de coleta 07 - IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

B.2 Grupo de coleta 08 - IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

B.3 Grupo de coleta 09 - IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

B.4 Grupo de coleta 10 - IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

B.5 Grupo de coleta 11 - IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

B.6 Grupo de coleta 12 - IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

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].

2.4 Resumo do Captulo


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].

3.8 Resumo do Captulo


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.

4.2 Resumo do Captulo


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.

5.3 Resumo do Captulo


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%

acima da taxa mdia da latncia alcanada pelo IPv6;

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:

No primeiro grupo o desempenho do protocolo IPv6 apresentou uma taxa de 35,66%

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;

E no terceiro grupo o desempenho do protocolo IPv6 apresentou uma taxa de 5,32%

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 primeiro grupo o desempenho do protocolo IPv6 apresentou uma taxa de 7,36%

acima da taxa mdia da latncia alcanada pelo IPv4;

No segundo grupo o desempenho do protocolo IPv6 apresentou uma taxa de 0,735%

acima da taxa mdia da latncia alcanada pelo IPv4;

E no terceiro grupo o desempenho do protocolo IPv6 apresentou uma taxa de 1,476%

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.

6.5 Resumo do Captulo


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.


https://tools.ietf.org/html/rfc1700, oct 1994. 16

[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.
https://tools.ietf.org/html/rfc4443, mar 2006. 18

[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.
https://tools.ietf.org/html/rfc4038, mar 2005. 33

[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).
https://tools.ietf.org/html/rfc3338, oct 2002. 37

[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 create 4002

set vlan create 4003

set vlan name 10 "ENLACE-R1-AGREGACAO"

set vlan name 701 "GER"

set vlan name 4001 "ENLACE-R1-R2"

set vlan name 4002 "ENLACE-R1-R3"

set vlan name 4003 "ENLACE-R1-R4"

clear vlan egress 1 ge.1.1-2;ge.1.22-24

set vlan egress 10 ge.1.2 untagged

set vlan egress 701 ge.1.1 untagged

set vlan egress 4001 ge.1.24 untagged

set vlan egress 4002 ge.1.23 untagged

set vlan egress 4003 ge.1.22 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 address fec0:1:1:1::1/64

ipv6 ospf areaid 0.0.0.0

ipv6 ospf enable

no shutdown

exit

interface vlan 4002

ip address 10.2.2.1 255.255.255.0

ip ospf enable

ipv6 address fec0:2:2:2::1/64

ipv6 ospf areaid 0.0.0.0

ipv6 ospf enable

no shutdown

exit

interface vlan 4003

ip address 10.3.3.1 255.255.255.0

ip ospf enable

ipv6 address fec0:3:3:3::1/64

ipv6 ospf areaid 0.0.0.0

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 port vlan ge.1.2 10

set port vlan ge.1.22 4003

set port vlan ge.1.23 4002

set port vlan ge.1.24 4001

set spantree version rstp

set spantree portadmin ge.1.2 disable

set spantree portadmin ge.1.22 disable

set spantree portadmin ge.1.23 disable

set spantree portadmin ge.1.24 disable

set spantree priority 0 0

R2
end

switch backbone
R2
Conguraes de no do laboratrio prtico:

begin

set vlan create 20

set vlan create 701

set vlan create 4001

set vlan create 4004

set vlan create 4005

set vlan name 20 "ENLACE-R2-AGREGACAO"

set vlan name 701 "GER"

set vlan name 4001 "ENLACE-R2-R1"

set vlan name 4004 "ENLACE-R2-R3"

set vlan name 4005 "ENLACE-R2-R4"

clear vlan egress 1 ge.1.1-2;ge.1.22-24

set vlan egress 20 ge.1.2 untagged

set vlan egress 701 ge.1.1 tagged

set vlan egress 4001 ge.1.24 untagged

set vlan egress 4004 ge.1.23 untagged

set vlan egress 4005 ge.1.22 untagged

set host vlan 701

router

88
enable

congure

ipv6 unicast-routing

interface vlan 20

ip address 10.22.22.1 255.255.255.0

ip ospf areaid 0.0.0.2

ip ospf enable

ipv6 address fec0:22:22:22::1/64

ipv6 ospf areaid 0.0.0.6

ipv6 ospf enable

no shutdown

exit

interface vlan 4001

ip address 10.1.1.2 255.255.255.0

ip ospf enable

ipv6 address fec0:1:1:1::2/64

ipv6 ospf areaid 0.0.0.0

ipv6 ospf enable

no shutdown

exit

interface vlan 4004

ip address 10.4.4.1 255.255.255.0

ip ospf enable

ipv6 address fec0:4:4:4::1/64

ipv6 ospf areaid 0.0.0.0

ipv6 ospf enable

no shutdown

exit

interface vlan 4005

ip address 10.5.5.1 255.255.255.0

ip ospf enable

ipv6 address fec0:5:5:5::1/64

ipv6 ospf areaid 0.0.0.0

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

set port vlan ge.1.1 701

set port vlan ge.1.2 20

set port vlan ge.1.22 4005

set port vlan ge.1.23 4004

set port vlan ge.1.24 4001

set spantree version rstp

set spantree portadmin ge.1.2 disable

set spantree portadmin ge.1.22 disable

set spantree portadmin ge.1.23 disable

set spantree portadmin ge.1.24 disable

set spantree priority 0 0

R3
end

switch backbone
R3
Conguraes de no do laboratrio prtico:

begin

set vlan create 30

set vlan create 701

set vlan create 4002

set vlan create 4004

set vlan create 4006

set vlan name 30 "ENLACE-R3-AGREGACAO"

set vlan name 701 "GER"

set vlan name 4002 "ENLACE-R3-R1"

set vlan name 4004 "ENLACE-R3-R2"

set vlan name 4006 "ENLACE-R3-R4"

clear vlan egress 1 ge.1.1-2;ge.1.22-24

90
set vlan egress 30 ge.1.2 untagged

set vlan egress 701 ge.1.1 tagged

set vlan egress 4002 ge.1.24 untagged

set vlan egress 4004 ge.1.23 untagged

set vlan egress 4006 ge.1.22 untagged

set host vlan 701

router

enable

congure

ipv6 unicast-routing

interface vlan 30

ip address 10.33.33.1 255.255.255.0

ip ospf areaid 0.0.0.3

ip ospf enable

ipv6 address fec0:33:33:33::1/64

ipv6 ospf areaid 0.0.0.7

ipv6 ospf enable

no shutdown

exit

interface vlan 4002

ip address 10.2.2.2 255.255.255.0

ip ospf enable

ipv6 address fec0:2:2:2::2/64

ipv6 ospf areaid 0.0.0.0

ipv6 ospf enable

no shutdown

exit

interface vlan 4004

ip address 10.4.4.2 255.255.255.0

ip ospf enable

ipv6 address fec0:4:4:4::2/64

ipv6 ospf areaid 0.0.0.0

ipv6 ospf enable

no shutdown

exit

interface vlan 4006

ip address 10.6.6.1 255.255.255.0

91
ip ospf enable

ipv6 address fec0:6:6:6::1/64

ipv6 ospf areaid 0.0.0.0

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 port vlan ge.1.1 701

set port vlan ge.1.2 30

set port vlan ge.1.22 4006

set port vlan ge.1.23 4004

set port vlan ge.1.24 4002

set spantree disable

set spantree version rstp

set spantree portadmin ge.1.2 disable

set spantree portadmin ge.1.22 disable

set spantree portadmin ge.1.23 disable

set spantree portadmin ge.1.24 disable

set spantree priority 0 0

R4
end

switch backbone
R4
Conguraes de no do laboratrio prtico:

begin

set vlan create 40

set vlan create 701

set vlan create 4003

92
set vlan create 4005

set vlan create 4006

set vlan name 40 "ENLACE-R4-AGREGACAO"

set vlan name 701 "GER"

set vlan name 4003 "ENLACE-R4-R1"

set vlan name 4005 "ENLACE-R4-R2"

set vlan name 4006 "ENLACE-R4-R3"

clear vlan egress 1 ge.1.1-2;ge.1.22-24

set vlan egress 40 ge.1.2 untagged

set vlan egress 701 ge.1.1 tagged

set vlan egress 4003 ge.1.24 untagged

set vlan egress 4005 ge.1.23 untagged

set vlan egress 4006 ge.1.22 untagged

set host vlan 701

router

enable

congure

ipv6 unicast-routing

interface vlan 40

ip address 10.44.44.1 255.255.255.0

ip ospf areaid 0.0.0.4

ip ospf enable

ipv6 address fec0:44:44:44::1/64

ipv6 ospf areaid 0.0.0.8

ipv6 ospf enable

no shutdown

exit

interface vlan 4003

ip address 10.3.3.2 255.255.255.0

ip ospf enable

ipv6 address fec0:3:3:3::2/64

ipv6 ospf areaid 0.0.0.0

ipv6 ospf enable

no shutdown

exit

interface vlan 4005

ip address 10.5.5.2 255.255.255.0

93
ip ospf enable

ipv6 address fec0:5:5:5::2/64

ipv6 ospf areaid 0.0.0.0

ipv6 ospf enable

no shutdown

exit

interface vlan 4006

ip address 10.6.6.2 255.255.255.0

ip ospf enable

ipv6 address fec0:6:6:6::2/64

ipv6 ospf areaid 0.0.0.0

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

set port vlan ge.1.1 701

set port vlan ge.1.2 40

set port vlan ge.1.22 4006

set port vlan ge.1.23 4005

set port vlan ge.1.24 4003

set spantree version rstp

set spantree portadmin ge.1.2 disable

set spantree portadmin ge.1.22 disable

set spantree portadmin ge.1.23 disable

set spantree portadmin ge.1.24 disable

set spantree priority 0 0

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 name 701 "GER"

set vlan egress 10 ge.1.14 untagged

set vlan egress 100 ge.1.1-12 untagged

set vlan egress 701 ge.1.13 tagged

set host vlan 701

router

enable

congure

ipv6 unicast-routing

interface vlan 10

ip address 10.11.11.2 255.255.255.0

ip ospf areaid 0.0.0.1

ip ospf enable

ipv6 address fec0:11:11:11::2/64

ipv6 ospf areaid 0.0.0.5

ipv6 ospf enable

no shutdown

exit

interface vlan 100

ip address 192.168.11.1 255.255.255.0

ip ospf areaid 0.0.0.1

ip ospf enable

ipv6 address 2801:80:b90::1/64

ipv6 ospf areaid 0.0.0.5

ipv6 ospf enable

no shutdown

exit

interface loopback 1

ip address 10.1.1.1 255.255.255.255

95
ip ospf areaid 0.0.0.1

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

set port vlan ge.1.1 100

set port vlan ge.1.2 100

set port vlan ge.1.3 100

set port vlan ge.1.4 100

set port vlan ge.1.5 100

set port vlan ge.1.6 100

set port vlan ge.1.7 100

set port vlan ge.1.8 100

set port vlan ge.1.9 100

set port vlan ge.1.10 100

set port vlan ge.1.11 100

set port vlan ge.1.12 100

set port vlan ge.1.13 701

set port vlan ge.1.14 10

set port vlan ge.1.15 10

set port vlan ge.1.18 10

set port vlan ge.1.21 10

set port vlan ge.1.22 10

set port vlan ge.1.23 10

96
set port vlan ge.1.24 10

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
Conguraes de de agregao do laboratrio prtico:

begin

set vlan create 20

set vlan create 200

set vlan create 201

set vlan create 701

set vlan name 20 "ENLACE-AGREGACAO-R2"

set vlan name 200 "REDE-2"

set vlan name 201 "REDE-2-IPv4Only"

set vlan name 701 "GER"

set vlan egress 20 ge.1.14 untagged

set vlan egress 200 ge.1.1-12 untagged

set vlan egress 201 ge.1.22-24 untagged

set vlan egress 701 ge.1.13 tagged

set host vlan 701

router

enable

congure

ipv6 unicast-routing

interface vlan 20

ip address 10.22.22.2 255.255.255.0

ip ospf areaid 0.0.0.2

ip ospf enable

ipv6 address fec0:22:22:22::2/64

ipv6 ospf areaid 0.0.0.6

ipv6 ospf enable

no shutdown

exit

interface vlan 200

ip address 192.168.21.1 255.255.255.0

ip ospf areaid 0.0.0.2

ip ospf enable

97
ipv6 address 2801:80:b90:4000::1/64

ipv6 ospf areaid 0.0.0.6

ipv6 ospf enable

no shutdown

exit

interface vlan 201

ip address 192.168.22.1 255.255.255.0

ip ospf areaid 0.0.0.2

ip ospf enable

no shutdown

exit

interface loopback 1

ip address 10.2.2.1 255.255.255.255

ip ospf areaid 0.0.0.2

ip ospf enable

no shutdown

exit

router id 10.2.2.1

router ospf 1

area 0.0.0.2 nssa

redistribute connected subnets

exit

ipv6 router id 110.102.102.101

ipv6 router ospf

area 0.0.0.6 nssa

redistribute connected

exit

exit

exit

exit

set ipv6 enable

set port vlan ge.1.1 200

set port vlan ge.1.2 200

set port vlan ge.1.3 200

set port vlan ge.1.4 200

set port vlan ge.1.5 200

set port vlan ge.1.6 200

98
set port vlan ge.1.7 200

set port vlan ge.1.8 200

set port vlan ge.1.9 200

set port vlan ge.1.10 200

set port vlan ge.1.11 200

set port vlan ge.1.12 200

set port vlan ge.1.13 701

set port vlan ge.1.14 20

set port vlan ge.1.22 201

set port vlan ge.1.23 201

set port vlan ge.1.24 201

set port mirroring create ge.1.14 ge.1.15

set port mirroring enable ge.1.14 ge.1.15

Agregao R3
end

switch
Agregao R3
Conguraes de de agregao do laboratrio prtico:

begin

set vlan create 30

set vlan create 300

set vlan create 301

set vlan create 701

set vlan name 30 "ENLACE-AGREGACAO-R3"

set vlan name 300 "REDE-3"

set vlan name 301 "REDE-3-IPv6Only"

set vlan name 701 "GER"

set vlan egress 30 ge.1.14 untagged

set vlan egress 300 ge.1.1-12 untagged

set vlan egress 301 ge.1.22-24 untagged

set vlan egress 701 ge.1.13 tagged

set host vlan 701

router

enable

congure

ipv6 unicast-routing

interface vlan 30

ip address 10.33.33.2 255.255.255.0

ip ospf areaid 0.0.0.3

99
ip ospf enable

ipv6 address fec0:33:33:33::2/64

ipv6 ospf areaid 0.0.0.7

ipv6 ospf enable

no shutdown

exit

interface vlan 300

ip address 192.168.31.1 255.255.255.0

ip ospf areaid 0.0.0.3

ip ospf enable

ipv6 address 2801:80:b90:8000::1/64

ipv6 ospf areaid 0.0.0.7

ipv6 ospf enable

no shutdown

exit

interface vlan 301

ipv6 address 2801:80:b90:8001::1/64

ipv6 ospf areaid 0.0.0.7

ipv6 ospf enable

no shutdown

exit

interface loopback 1

ip address 10.3.3.1 255.255.255.255

ip ospf areaid 0.0.0.3

ip ospf enable

no shutdown

exit

router id 10.3.3.1

router ospf 1

area 0.0.0.3 nssa

redistribute connected subnets

exit

ipv6 router id 110.103.103.101

ipv6 router ospf

area 0.0.0.7 nssa

redistribute connected

exit

100
exit

exit

exit

set ipv6 enable

set port vlan ge.1.1 300

set port vlan ge.1.2 300

set port vlan ge.1.3 300

set port vlan ge.1.4 300

set port vlan ge.1.5 300

set port vlan ge.1.6 300

set port vlan ge.1.7 300

set port vlan ge.1.8 300

set port vlan ge.1.9 300

set port vlan ge.1.10 300

set port vlan ge.1.11 300

set port vlan ge.1.12 300

set port vlan ge.1.13 701

set port vlan ge.1.14 30

set port vlan ge.1.22 301

set port vlan ge.1.23 301

set port vlan ge.1.24 301

set port mirroring create ge.1.14 ge.1.15

set port mirroring enable ge.1.14 ge.1.15

Agregao R4
end

switch
Agregao R4
Conguraes de de agregao do laboratrio prtico:

begin

set vlan create 40

set vlan create 400

set vlan create 701

set vlan name 40 "ENLACE-AGREGACAO-R4"

set vlan name 400 "REDE-4"

set vlan name 701 "GER"

set vlan egress 40 ge.1.14 untagged

set vlan egress 400 ge.1.1-12 untagged

set vlan egress 701 ge.1.13 tagged

set host vlan 701

101
router

enable

congure

ipv6 unicast-routing

interface vlan 40

ip address 10.44.44.2 255.255.255.0

ip ospf areaid 0.0.0.4

ip ospf enable

ipv6 address fec0:44:44:44::2/64

ipv6 ospf areaid 0.0.0.8

ipv6 ospf enable

no shutdown

exit

interface vlan 400

ip address 192.168.41.1 255.255.255.0

ip ospf areaid 0.0.0.4

ip ospf enable

ipv6 address 2801:80:b90:c000::1/64

ipv6 ospf areaid 0.0.0.8

ipv6 ospf enable

no shutdown

exit

interface loopback 1

ip address 10.4.4.1 255.255.255.255

ip ospf areaid 0.0.0.4

ip ospf enable

no shutdown

exit

router id 10.4.4.1

router ospf 1

area 0.0.0.4 nssa

redistribute connected subnets

exit

ipv6 router id 110.104.104.101

ipv6 router ospf

area 0.0.0.8 nssa

redistribute connected

102
exit

exit

exit

exit

set ipv6 enable

set port vlan ge.1.1 400

set port vlan ge.1.2 400

set port vlan ge.1.3 400

set port vlan ge.1.4 400

set port vlan ge.1.5 400

set port vlan ge.1.6 400

set port vlan ge.1.7 400

set port vlan ge.1.8 400

set port vlan ge.1.9 400

set port vlan ge.1.10 400

set port vlan ge.1.11 400

set port vlan ge.1.12 400

set port vlan ge.1.13 701

set port vlan ge.1.14 40

set port vlan ge.1.24 40

set port mirroring create ge.1.14 ge.1.15

set port mirroring enable ge.1.14 ge.1.15

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
Figura A.2: Grupo de coleta 02 - IPv4

116
Figura A.3: Grupo de coleta 03 - IPv4

117
Figura A.4: Grupo de coleta 04 - IPv6

118
Figura A.5: Grupo de coleta 05 - IPv6

119
Figura A.6: Grupo de coleta 06 - IPv6

120
Anexo B

Figura B.1: Grupo de coleta 07 - IPv4

121
Figura B.2: Grupo de coleta 08 - IPv4

122
Figura B.3: Grupo de coleta 09 - IPv4

123
Figura B.4: Grupo de coleta 10 - IPv6

124
Figura B.5: Grupo de coleta 11 - IPv6

125
Figura B.6: Grupo de coleta 12 - IPv6

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