Monografia - Versão Final

Faculdade de Tecnologia de Americana - FATEC
Lincon Moreira Peretto

RA: 031221
Transi cao IPv4/IPv6 atraves dos Mecanismos
Dual-Stack, Translation e Tunneling
Orientador: Prof. Jose Mario Balan
Co-Orientador: Prof. Marcos A. de A. Cora
Maio de 2005
Americana/SP - Brasil
Faculdade de Tecnologia de Americana - FATEC
Transi cao IPv4/IPv6 atraves dos Mecanismos
Dual-Stack, Translation e Tunneling
Autor: Lincon Moreira Peretto
Orientador: Prof. Jose Mario Balan
Co-Orientador: Prof. Marcos A. de A. Cora
Dissertacao de Conclusao de Graduacao ap-
resentada à Faculdade de Tecnologia de Ameri-
cana como parte dos requisitos para obten cao do
ttulo de Tecnologo em Processamento de Dados.
Area de concentra cao: Teleprocessamento e

Redes.
Maio de 2005
Americana/SP - Brasil
Dedicatoria
Dedico este trabalho a todos aqueles que, a cada
dia, procuram aprender um pouco mais na inces-
sante luta da vida, especialmente aos estudantes
que vencem as suas diculdades e conseguem con-
ciliar o estudo com o trabalho, com a famlia e com
os mais diversos problemas que surgem durante o
curso.
iii
Agradecimentos
Agrade co em primeiro lugar a Deus. Aos meus pais, por terem me dado a vida, por terem me
educado e por serem os responsaveis pelo meu carater. Aos verdadeiros amigos da Faculdade
de Tecnologia de Americana, pelo companheirismo. Enm, aos professores Jose M. Balan e
Marcos Ant. de A. Cora pela orienta cao e paciencia, e a todas as pessoas que me ajudaram
direta ou indiretamente para a concretiza cao desta monograa.
iv
Resumo
PERETTO, Lincon M. Transi cao IPv4/IPv6 atraves dos Mecanismos Dual-Stack, Transla-
tion e Tunneling. Americana, 2005. x p. Monograa (Trabalho Final de Gradua c ao) Faculdade
de Tecnologia de Americana, Americana.
Este documento descreve os principais aspectos do principal protocolo da camada de rede,
o IP, mostrando as diferen cas entre o IPv4 e sua nova versao, o IPv6. Sao discutidos os mecan-
ismos de transi cao, sendo eles: Dual-Stack, Translation e Tunneling, utilizados na migra cao do
protocolo IPv4 para IPv6.
Palavras-chave: IP; IPv4; IPv6; Telecomunica coes; Redes de Computadores; Protocolos.
v
Abstract
PERETTO, Lincon M. IPv4/IPv6 Transition through the Mechanisms Dual-Stack, Trans-
lation and Tunneling. Americana, 2005. x p. Monograph (Final Work of Graduation) Faculty
of Technology of Americana, Americana.
This document describes the aspects of the main protocol of the network layer, the IP, showing
the dierences between the IPv4 and its new version, the IPv6. The transition mechanisms
are argued, being they: Dual-Stack, Translation and Tunneling, used in migration from IPv4
protocol to IPv6.
Keywords: IP; IPv4; IPv6; Telecommunications; Computer Networks; Protocols.
vi
Lista de Siglas e Acronimos
ADSL (Asymmetric Digital Subscriber Lines), page 22
AH (Authentication Header), page 30
ALM (At Large Membership), page 9
APNIC (Asia Pacic Network Information Centre), page 10
ARIN (American Registry for Internet Numbers), page 10
ARPANET (Advanced Research Projects Agency Network), page 3
ASN (Autonomous System Numbers), page 10
ASO (Address Supporting Organization), page 10
BGP (Border Gateway Protocol ), page 27
BIA (Bump-In-the-API ), page 59
BIS (Bump-In-the-Stack), page 59
CIDR (Classless InterDomain Routing), page 18
CLNP (Connectionless Network Protocol ), page 27
DARPA (Defense Advanced Research Projects Agency), page 3
DES (Data Encryption Standard), page 33
DHCP (Dynamic Host Conguration Protocol ), page 17
DNS (Domain Name Server), page 9
DNSO (Domain Name Supporting Organization), page 10
DoS (Denial of Service), page 46
DSTM (Dual Stack Transition Mechanism), page 63
vii
Abstract Peretto, L.M.
ESP (Encapsulating Security Payload), page 30
FAPESP (Funda cao de Amparo à Pesquisa do Estado de S ao Paulo), page 11
FTP (File Transfer Protocol ), page 22
gTLDs (Global Top Level Domains), page 9
HTTP (HyperText Transfer Protocol ), page 9
IANA (Internet Assigned Numbers Authority), page 9
ICANN (Internet Corporation for Assigned Names and Numbers), page 9
ICMP (Internet Control Message Protocol ), page 31
IEEE (Institute of Eletrical and Eletronics Engineers), page 27
IETF (Internet Engineering Task Force), page 26
IGMP (Internet Group Management Protocol ), page 27
IHL (Internet Header Length), page 4
IKE (Internet Key Exchange), page 46
IMP (Interface Message Processor), page 3
IP (Internet Protocol ), page 3
IPng (Internet Protocol Next Generation), page 27
IPX (Internal Packet Exchange), page 37
ISATAP (Intra-Site Automatic Tunnel Addressing Protocol ), page 62
ISP (Internet Service Provider), page 21
LACNIC (Latin American and Caribbean Internet Addresses Registry), page 10
LAN (Local Area Network), page 13
MIP (Mobile IP), page 48
MSS (Maximum Segment Size), page 25
MTP (Multicast Translator based on IGMP/MLD Proxying), page 60
MTU (Maximum Transfer Unit), page 23
viii
Abstract Peretto, L.M.
NAPT (Network Address and Port Translation), page 21
NAT (Network Address Translation), page 20
NAT-PT (Network Address Translation - Protocol Translation), page 60
NSAP (Network Service Access Point), page 37
OSI (Open System Interconnection), page 27
OSPF (Open Shortest Path First), page 27
PSO (Protocol Supporting Organization), page 10
QoS (Quality of Service), page 5
RFC (Request for Comments), page 3
RIPE/NCC (Reseaux IP Europeens/Network Coordination Centre), page 10
RSVP (Resource Reservation Protocol ), page 29
SIIT (Stateless IP/ICMP Translation), page 59
SIPP (Simple Internet Protocol Plus), page 27
SMTP (Simple Mail Transfer Protocol ), page 9
TCP (Transport Control Protocol ), page 20
ToS (Type of Service), page 5
TRT (Transport Relay Translator), page 61
TTL (Time to Live), page 6
UDP (User Datagram Protocol ), page 20
VPN (Virtual Private Network), page 6
ix
Sumario
Dedicatoria iii
Agradecimentos iv
Resumo v
Abstract vi
Siglas e Acronimos vii
1 Introducao 1
1.1 Organiza cao do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 IPv4 3
2.1 Cabe calho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Endere camento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Mascaras e Sub-Redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Faixa de Endere cos IP nao-roteaveis . . . . . . . . . . . . . . . . . . . . 16
2.2.4 CIDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.5 NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Fragmenta cao e Remontagem do IPv4 . . . . . . . . . . . . . . . . . . . . . . . 23
3 IPv6 26
3.0.1 Cabe calho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.0.1.1 Extension Header . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.0.2 Endere camento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.0.2.1 Endere cos Unicast . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.0.2.2 Endere cos Multicast . . . . . . . . . . . . . . . . . . . . . . . . 37
3.0.2.3 Endere cos Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.0.2.4 Hierarquia de Endere camento . . . . . . . . . . . . . . . . . . . 39
3.0.3 Fragmenta cao e Remontagem do IPv6 . . . . . . . . . . . . . . . . . . . 41
3.0.4 Diferen cas entre o IPv6 e IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 44
x
SUM
ARIO Peretto, L.M.

3.1 IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2 MIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3 Protocolos para IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.1 SMTPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.2 DNSv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.3 HTTPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.3.4 ICMPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.3.5 FTPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.3.6 TELNETv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4 Mecanismos de Transicao IPv4/IPv6 55
4.1 Mecanismos de Transi cao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.1.1 Dual-Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.1.2 Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.1.2.1 SIIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1.2.2 BIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1.2.3 BIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1.2.4 NAT-PT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.1.2.5 MTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.1.2.6 TRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.1.2.7 SOCKS64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.1.3 Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.1.3.1 6over4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.1.3.2 ISATAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.1.3.3 DSTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.1.3.4 Congured IP-in-IP Tunneling . . . . . . . . . . . . . . . . . . 63
4.1.3.5 6to4 Automatic Tunneling . . . . . . . . . . . . . . . . . . . . . 63
5 Conclusao 65
5.1 Propostas para trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Referencias Bibliogracas 69
xi
Lista de Figuras
2.1 Formato do datagrama IPv4 [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Signicado do campo ToS [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Subdivisao do campo Flags [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Estrutura hierarquica do ICANN. . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Classes de endere camento IP [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 Uma rede de uma empresa consistindo em LANs para varios departamentos . . 13
2.7 Uma rede de classe B dividida em 64 sub-redes [1] . . . . . . . . . . . . . . . . . 14
2.8 Posicionamento e opera cao de um servidor NAT [1] . . . . . . . . . . . . . . . . 20
2.9 Cabe calho do Protocolo TCP [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.10 Cabe calho do Protocolos UDP [1] . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.11 Exemplo de fragmenta cao no IP [4] . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1 Formato do datagrama IPv6 [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 O cabe calho de extensao Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 O cabe calho de extensao Fragmentation . . . . . . . . . . . . . . . . . . . . . . 33
3.4 O cabe calho de extensao Authentication . . . . . . . . . . . . . . . . . . . . . . 34
3.5 Formato do endere co Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6 Formato do endere co Unicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.7 A divisao de um datagrama a ser fragmentado . . . . . . . . . . . . . . . . . . . 42
3.8 Pacote original dividido para fragmenta cao . . . . . . . . . . . . . . . . . . . . . 42
3.9 Pacotes ja fragmentados para envio . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.10 Arquitetura Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.11 Visao Geral do MIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1 Possveis cenarios IPv4/IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2 Funcionamento de um Dual-Stack Router . . . . . . . . . . . . . . . . . . . . . . 58
4.3 Cenarios em que utiliza-se o Mecanismo Translation . . . . . . . . . . . . . . . . 58
4.4 Cenarios em que utiliza-se o Mecanismo Tunneling . . . . . . . . . . . . . . . . 62
xii
Lista de Tabelas
2.1 Classes de Endere camento IP [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Endere cos IP de Classe C divididos por regiao geograca [4] . . . . . . . . . . . 12
2.3 Rela cao Sub-Redes vs Hosts de acordo com a mascara adotada [4] . . . . . . . . 16
3.1 Cabe calhos de extensao do IPv6 [1] . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Representa cao de endere cos IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 Aloca cao do espa co de endere camento . . . . . . . . . . . . . . . . . . . . . . . . 36
xiii
Captulo 1
Introducao
Com a evolu cao da Internet, houve uma rapida diminui cao no espa co de endere camento
IP, motivando a evolu cao do protocolo ja existente, pra uma nova versao, o IPv6. Alem da
propaga cao dos dados na forma de texto, surgiram as informa coes multimdia, como voz e
vdeo, que exigiram melhorias no antigo protocolo IPv4 para que eles pudessem atender as
novas exigencias, garantindo uma boa presta cao de servi cos aos usuarios.
A inconveniencia ou impossibilidade de desprezar toda a antiga infra-estrutura, fez com
que pesquisadores e fabricantes de produtos de alta tecnologia desenvolvessem solu coes para
a integra cao dos recursos computacionais existentes com os novos equipamentos de conectivi-
dade, utilizando-se de mecanismos de transi cao que pudessem integrar todo este cenario hbrido
existente hoje.
A motiva cao para a cria cao deste documento
1
foi justamente analisar as tecnologias exis-
tentes atualmente neste cenario diversicado, exigindo, portanto, a existencia de tecnologias
que combinem velocidade, qualidade e credibilidade.
O crescimento da Internet e a grande necessidade por integrar as diferentes versoes do pro-
tocolo IP foram fatores decisivos para que houvesse o desenvolvimento de mecanismos como
Dual-Stack, Translation e Tunneling. IPv6 e um protocolo que veio para solucionar tanto o
problema de espa co de endere camento, quanto questoes como seguran ca, mobilidade e Quali-
dade de Servi co (QoS).
A transi cao tem ocorrido de forma gradual, devendo-se ao fato de algumas solu coes como
CIDR e NAT, serem criadas para solucionar de forma rapida o problema do esgotamento de
endere cos. Aos poucos o IPv6 vai se tornando realidade, pois muitas mudan cas sao necessarias
am de prover melhoria nos servi cos oferecidos.
Este documento descreve os principais aspectos da tecnologia e a sua implementa cao, no
entanto, nao visa esgotar todas as possibilidades na busca de solu coes para promover esta
migra cao, ja que trata-se de uma tecnologia em constante evolu cao.
1
Este documento foi editado atraves do sistema de editora c ao de textos L
A
T
E
X.
1
1.1 Organizacao do Trabalho Peretto, L.M.
1.1 Organizacao do Trabalho
Este trabalho esta organizado em 3 partes.
O captulo 2 apresenta uma introdu cao ao protocolo IP, abordando os todos os recursos
oferecidos pela antiga versao, IPv4, porem atual. Traz os conceitos de classes de endere co,
mascaras, sub-redes, CIDR e NAT, bem como os detalhes do formato do cabe calho.
O captulo 3 apresenta as caractersticas do protocolo IPv6, abordando os recursos oferecidos
por essa versao. Apresenta todos os detalhes do formato do cabe calho, bem como os novos
recursos que este protocolo oferece, corrigindo problemas existentes na antiga versao. Dentre
estas solu coes, estao: IPSecurity e MobileIP. Tambem sao apresentas as principais diferen cas
existentes entre o protocolos IPv4 e IPv6.
No captulo 4 sao apresentados os diferentes cenarios encontrados na Internet, mostrando
os atuais mecanismos existentes, Dual-Stack, Translation e Tunneling, que visam realizar esta
integra cao entre os protocolos IPv4/IPv6, ate que toda a rede mundial tenha migrado para o
novo protocolo.
Por m, o captulo 5 traz uma conclusao sobre a evolu cao do protocolo IP, mostrando os
problemas enfrentados durante a cria cao do protocolo IPv6, a situa cao atual e uma previsao
de como sera este cenario futuramente. Apresenta tambem algumas propostas para trabalhos
futuros, que sao de grande importancia no cenario atual e podem ser abordadas de forma mais
profunda.
2
Captulo 2
IPv4
Embora o IP (Internet Protocol ) seja o protocolo de rede mais conhecido, deve ser men-
cionado que a ideia de se transmitir mensagens por um canal de comunica cao persegue o homem
a milhares de anos. Atendo-se aos fatos historicos, por volta de 700 aC, ja eram utilizados pom-
bos para se transmitir mensagens na Grecia antiga. As comunica coes evoluram muito desde
entao... Em 1957, os russos colocaram em orbita o Sputnik, o primeiro satelite articial,
ganhando uma corrida espacial contra os americanos. Como resposta, em 7 de Fevereiro de
1958 o Departamento de Defesa dos Estados Unidos, atraves da diretiva 5105.15, decidiu criar a
DARPA (Defense Advanced Research Projects Agency). A DARPA tinha como missao garantir
que os Estados Unidos estivessem sempre na dianteira tecnologica militar e antecipar quais
seriam os avan cos tecnologicos dos adversarios.
Com o passar dos anos, a DARPA teve a necessidade de criar um protocolo de comunica cao
por comuta cao de pacotes capaz de interconectar computadores heterogeneos. Entao, a DARPA
lan cou uma licita cao para o projeto de um hardware que eles chamaram de IMP (Interface
Message Processor), que deveria ser o no de comuta cao de pacotes. Empresas como IBM e
AT&T achavam que nao era possvel realizar tal tarefa. Entao, uma pequena empresa, formada
por dois professores de Cambridge e um ex-aluno de um deles, chamados Bolt, Beranek e
Newman, respectivamente, venceram a concorrencia para desenvolver tal tecnologia. A empresa
e a renomada Bolt, Beranek & Newman, tambem conhecida como BBN. Em 7 de Abril de
1969, Steve Crocker criou a primeira RFC (Request for Comments) (RFC 1 - Host Software),
identicando como deveria ser o software de um host em uma rede, no caso, o software do IMP.
A BBN trabalhando em conjunto com o Information Processing Techniques Oce da DARPA
desenvolveu a primeira IMP da ARPANET (Advanced Research Projects Agency Network),
entregue em 1971, implementado em um minicomputador da Honeywell.
Em Maio de 1974, Vint Cerf e Bob Kahn publicaram um artigo chamado A Protocol for
Packet Network Internetworking, que estabelecia o TCP (Transmission Control Protocol ). Foi
a primeira vez que o termo Internet foi utilizado. Em 1978, quando Vint Cerf, Steve Crocker e
Danny Cohen decidiram passar as fun coes de roteamento do TCP para um protocolo separado,
surgiu o IP. O TCP continuaria com as fun coes de corre cao de erro e fun coes de datagrama. A
3
2.1 Cabecalho Peretto, L.M.
especica cao do IPv4 foi publicada em Setembro de 1981, sob a RFC 791 [14], com o auxlio
do Information Sciences Institute University of Southern California. Em 1982 o TCP e o IP
foram adotados como os protocolos ociais da ARPANET. A populariza cao do IP veio quando
ele passou a ser distribudo pelo Berkeley Software Distribution UNIX (BSD UNIX), versao
4.2c, em 1983. Desde entao, o IP e o protocolo da camada de rede que mantem a Internet
unida.
2.1 Cabecalho
Um datagrama IPv4 consiste em uma parte de cabe calho e uma parte de texto. O cabe calho
tem uma parte xa de 20 bytes e uma parte opcional de tamanho variavel. O formato do
cabe calho e mostrado na gura 2.1. Ele e transmitido em uma ordem big endian: da esquerda
para a direita, com o bit de mais alta ordem do campo Version aparecendo primeiro. Os campos
do datagrama IPv4 sao os seguintes:
Figura 2.1: Formato do datagrama IPv4 [1]
Version. 4 bits. Signica a versao do protocolo IP do datagrama. Examinando o n umero
da versao, o roteador pode determinar como interpretar o restante do datagrama IP.
Diferentes versoes de IP usam diferentes formatos de datagramas.
IHL (Internet Header Length). 4 bits. Dene o comprimento do cabe calho. Como o
datagrama IPv4 pode conter um n umero variavel de op coes (includas no cabe calho do
datagrama IPv4), esses quatro bits sao necessarios para determinar onde, no datagrama
IP, os dados realmente come cam. A maior parte dos datagramas IP nao contem op coes;
portanto o datagrama IP tpico tem um cabe calho de 20 bytes. O tamanho mnimo do
cabe calho e de 5 palavras de 32, e o tamanho maximo (o campo Option + Padding tem
tamanho variavel) e de 15 palavras de 32 bits.
ToS (Type of Service). 8 bits.

E utilizado para indicar o QoS (Quality of Service) desejado.
Os bits de tipo de servi co foram includos no cabe calho do IPv4 para poder distinguir as
4
diferentes classes de servi co, podendo assim manipular os datagramas de forma diferente
quando houver sobrecarga. Em se tratando de voz digitalizada, a entrega rapida vence
a entrega segura. Para a transferencia de arquivos, uma transmissao sem erros e mais
importante do que uma transmissao rapida. O campo ToS e ilustrado na gura 2.2.
Figura 2.2: Signicado do campo ToS [3]
O campo de 8 bits contem (da esquerda para a direita) um campo Precedence (Precedencia)
de 3 bits e 3 ags, D, T e R, alem de 2 bits reservados que sao obrigatoriamente 00. O
campo Precedence tem uma prioridade que varia de 0 (normal) a 7 (pacote de controle de
rede). Os 3 bits de ags permitem que o host especique o que e mais importante no con-
junto Retardo, Throughput (Vazao), Conabilidade. Teoricamente, esse campo permite
que os roteadores optem, por exemplo, entre um enlace de satelite com alto throughput,
mas com grande retardo ou uma linha dedicada com baixo throughput e baixo retardo, ou
em certas situa coes de grande congestionamento, por exemplo, aceitar somente pacotes
com um certo nvel mnimo de precedencia. Na pratica, os roteadores atuais ignoram
completamente o campo Type of Service, porem, mais recentemente, um importante
fabricante de equipamentos de rede (Cisco) passou a interpretar os tres primeiros bits de
TOS como a deni cao dos nveis diferenciais de servi co que podem ser oferecidos pelo
roteador. O nvel especco de servi co a ser fornecido e uma questao de poltica determi-
nada pelo administrador do roteador.
Total Lenght. 16 bits.

E o comprimento total do datagrama IP (cabe calho mais dados)
medido em bytes. Uma vez que esse campo tem 16 bits de comprimento, o tamanho
maximo do datagrama IP e 65.535 bytes. Contudo, os datagramas raramente sao maiores
do que 1.500 bytes e frequentemente cam limitados a 576 bytes. Recomenda-se que os
hosts so enviem datagramas maiores que 576 bytes se houver a certeza que o endere co
destino aceita receber a quantidade de dados enviados.
Identication. 16 bits. Este campo e necessario para permitir que o host de destino
determine a qual datagrama pertence um fragmento recem-chegado. Todos os fragmentos
5
de um datagrama contem o mesmo valor de Identication.
Flags. 3 bits. Identicam a transmissao de sinais de controle. Dentre eles, apenas os
dois ultimos sao utilizados. O campo Flags e ilustrado na gura 2.3. O primeiro bit
utilizado signica DF (Dont Fragment). Trata-se de uma ordem para os roteadores
nao fragmentarem o datagrama, porque a maquina de destino e incapaz de juntar os
fragmentos novamente. O bit MF (More Fragments) e colocado em todos os fragmentos,
exceto o ultimo, tem esse conjunto de bits, necessario para se saber quando chegaram
todos os fragmentos de um datagrama.
Figura 2.3: Subdivisao do campo Flags [3]
Fragment Oset. 13 bits. O campo Fragment oset informa a que ponto do datagrama
atual o fragmento pertence. Todos os fragmentos de um datagrama, com exce cao do
ultimo, devem ser m ultiplos de 8 bytes, a unidade elementar de fragmento. Como sao
fornecidos 13 bits, existem no maximo 8.192 fragmentos por datagrama, resultando em
um tamanho maximo de datagrama igual a 65.536 bytes, um a mais que o campo Total
Length. O primeiro fragmento tem valor 0 nesse campo.
TTL (Time to Live). 8 bits.

E um contador usado para limitar a vida util dos data-
gramas. Esse campo conta o tempo em segundos, porem, na pratica, ele simplesmente
conta os hops. Esse contador deve ser decrementado a cada hop e sup oe-se que ele seja
decrementado diversas vezes quando estiver enleirado durante um longo tempo em um
roteador. Quando o contador chega a zero, o pacote e descartado e um pacote de ad-
vertencia e enviado ao host de origem. Esse recurso evita que os datagramas quem
vagando indenidamente, algo que aconteceria se as tabelas de roteamento fossem dani-
cadas.
Protocol. 8 bits. Quando tiver montado um datagrama completo, a camada de rede
precisara saber o que fazer com ele. O campo Protocol indica a camada de rede superior
que esta utilizando os servi cos da camada IP. Estes valores sao denidos na RFC 790
de 1981, que foi substituda pela RFC 1700 [16], sendo que hoje estao contidos em um
banco de dados on-line localizado em www.iana.org. O n umero do TCP, por exemplo,
e 6. Quando o IP estiver encapsulado em uma outra camada IP, como em uma VPN
(Virtual Private Network), por exemplo, o valor desse campo e 4.
6
2.2 Enderecamento Peretto, L.M.
Header Checksum. 16 bits. A soma de verica cao do cabe calho auxilia um roteador
na detec cao de erros de bits em um datagrama IP recebido. Ela e calculada utilizando
a tecnica de soma de complemento de 1. Um roteador calculara o valor da soma de
verica cao para cada datagrama IP recebido e detectara uma condi cao de erro se o valor
de verica cao carregado pelo datagrama nao for igual à soma de verica cao calculada.
Os roteadores normalmente descartam datagramas quando um erro e detectado. A soma
de verica cao deve ser recalculada e restabelecida em cada roteador, pois o campo TTL
e, possivelmente, os campos de op coes podem mudar.
Source Address. 32 bits. Informa o endere co IP de origem do datagrama.
Destination Address. 32 bits. Informa o endere co IP de destino do datagrama.
Options. Tamanho variavel, entre 0 e 320 bits. Este campo permite que um cabe calho
IP seja ampliado. Ele foi projetado para permitir que versoes posteriores do protocolo
incluam informa coes inexistentes no projeto original, possibilitando a experimenta cao
de novas ideias e evitando a aloca cao de bits de cabe calho para informa coes raramente
necessarias. Contudo, a mera existencia do campo de op coes complica as coisas, ja que os
cabe calhos de datagrama podem ter comprimentos variaveis, nao podendo determinar a
priori onde come ca o campo de dados. Alem disso, uma vez que alguns datagramas podem
requerer processamento de op coes e outros nao, a quantidade de tempo necessaria para
processar um datagrama IP em um roteador pode variar bastante. Essas considera coes se
tornam particularmente importantes para o processamento do IP em roteadores e hosts
de alto desempenho.
2.2 Enderecamento
A composi cao do endere camento de um protocolo consiste de uma sintaxe e uma semantica.
A sintaxe de um protocolo dene os conjuntos de bits (series de uns e zeros) divididos em
campos, ou seja, a forma como os bits estao dispostos. Ja a semantica de um protocolo dene
o signicado exato dos bits dentro de cada campo. Por exemplo, um endere co de 48 bits iguais,
signica que e um endere co de broadcast, ou seja, representa algo que pode ser lido por todos
os computadores da rede.
Antes de discutirmos o endere camento IP, contudo, temos de mencionar como hosts e
roteadores estao interconectados na rede. Um host, caracteristicamente, tem apenas um unico
enlace com a rede. Quando o IP no host quer enviar um datagrama, ele o faz por meio desse
enlace. A fronteira entre o host e o enlace fsico e chamado de interface. Um roteador, por
outro lado, e fundamentalmente diferente de um host. Como a tarefa de um roteador e receber
um datagrama em um enlace de entrada e repassa-lo a algum enlace de sada, ele necessaria-
mente estara ligado a dois ou mais enlaces. A fronteira entre o roteador e qualquer um desses
7
enlaces tambem e chamada de interface. Assim, um roteador tem m ultiplas interfaces, uma
para cada um de seus enlaces. Como todos os hosts e roteadores podem enviar e receber data-
gramas IP, o IP exige que cada interface tenha um endere co IP. Desse modo, um endere co IP
esta tecnicamente associado a uma interface, e nao a um host ou um roteador que contem a
interface.
Cada endere co IP tem comprimento de 32 bits (equivalente a 4 bytes). Portanto, ha um
total de 2
32
endere cos IP possveis. Esses endere cos sao escritos na chamada nota cao decimal
separada por pontos, na qual cada byte do endere co e escrito em sua forma decimal e separado
dos outros bytes do endere co por um ponto. Por exemplo, considere o endere co IP 192.41.6.20.
O 192 e o n umero decimal equivalente aos primeiros 8 bits do endere co; o 41 e o decimal
equivalente ao segundo conjunto de 8 bits do endere co, e assim por diante. Por conseguinte, o
endere co 192.41.6.20, em nota cao binaria, e :
11000000 001010001 00000110 00010100
Cada interface em cada host e roteador da Internet global tem de ter um endere co IP
globalmente exclusivo. Contudo, esses endere cos nao podem ser escolhidos de qualquer maneira.
Ate certo ponto, um endere co de interface IP sera determinado pela rede a que esta conectado.
Nesse contexto, o termo rede nao se refere à infra-estrutura geral dos hosts, roteadores e enlaces
que formam uma rede. Em vez disso, ele tem um signicado muito preciso, que esta intimamente
ligado ao endere camento IP. No jargao do IP, as interfaces desses hospedeiros e a interface
do roteador constituem uma rede IP. Por exemplo: os 24 bits de endere camento da extrema
esquerda, que compartilham em comum os hosts de uma mesma rede, constituem a parcela de
rede de seus endere cos IP; os 8 bits restantes sao a parcela do endere co IP do host.
Desde 1996, o governo dos EUA vem tentando reorganizar o sistema de gestao da infra-
estrutura Internet. A Internet e descentralizada, razoavelmente horizontal e, para quem pode
pagar, supostamente livre de barreiras à entrada, mas grande parte de sua infra-estrutura de
rede, administrada por um consorcio de entidades altamente centralizado, esta na pratica sob
comando do governo americano. A infra-estrutura Internet sempre teve um governo central
sem o qual seria impossvel faze-la funcionar e expandir. A imensa maioria de n umeros IP foi
distribuda entre empresas, universidades e centros de pesquisa dos EUA, Inglaterra, Canada
e Japao. No entanto, dos 4,3 bilhoes de n umeros possveis, grande parte ainda nao esta em
uso, apesar da explosao da Internet ocorrida entre 1998 e 2000. A perspectiva da crescente
expansao de dispositivos pessoais e domesticos conectaveis à Internet fez surgir a preocupa cao
com uma possvel escassez de n umeros IP. Assim, desde 1992 vem sendo desenvolvida uma nova
versao de endere camento IP (IPv6), com comprimento de endere co de 128 bits, cujo padrao foi
formalmente estabelecido em 1998. Veja o captulo 3.
Todo este processo fez com que surgisse a necessidade de criar um org ao para regulamentar
esta distribui cao de endere cos e o seu gerenciamento. O IANA (Internet Assigned Numbers
8
Authority) foi o organismo contratado pelo governo dos EUA para administrar a aloca cao de
n umeros IP a nvel mundial. O IANA atuou por 30 anos mediando as disputas e fazendo as
fun coes tecnicas de todas as partes do sistema de domnios. Em Setembro de 1998 surgiu o
ICANN (Internet Corporation for Assigned Names and Numbers), que veio para assumir esta
responsabilidade.
Com a explosao da Internet desencadeada pela generaliza cao da infra-estrutura nos pases
desenvolvidos e a expansao dos servi cos baseados no protocolo HTTP (HyperText Transfer
Protocol ), serios problemas no DNS (Domain Name Server) come caram a car evidentes. Sur-
giram disputas tanto em torno de nomes de domnio e marcas registradas, como em rela cao
a quem realmente deveria operar e coordenar todo o sistema, ja que a Internet passava a ser
de fato mundial. Em 1997, uma equipe de tecnicos de alto nvel propos a formaliza cao de um
conjunto de mais de 100 gTLDs (Global Top Level Domains) como domnios internacionais. Na
verdade, o grupo de domnios comercializado pela Network Solutions ja era internacional sendo
que qualquer institui cao ou indivduo de um pas capaz de pagar em dolares americanos podia
registrar domnios .com / .net /.org, mas a ideia era criar muitos outros. O fato gerou mais
discussao sobre a jurisdi cao de todo o processo de cria cao e distribui cao de nomes e n umeros
IP, levando nalmente o governo dos EUA a conceber uma organiza cao de escopo internacional
para administrar o sistema. O entao presidente Bill Clinton encarregou o Departamento do
Comercio dessa tarefa, come cando assim a desvincular o Departamento de Defesa do controle
da infra-estrutura Internet. Apos um processo limitado de consultas p ublicas, foi criada em
Setembro de 1998 a entidade civil sem ns lucrativos ICANN (Internet Corporation for Assigned
Names and Numbers), sediada em Marina del Rey, California. Alem de passar a administrar a
deni cao e manuten cao da tabela de n umeros de portas logicas dos diversos servi cos-padrao da
Internet (FTP (File Transfer Protocol ), HTTP, SMTP (Simple Mail Transfer Protocol ) etc.),
coube à ICANN a gestao de n umeros IP, dos nomes de domnio de primeiro nvel (gTLDs) e a
gerencia dos servidores-raiz. Na primeira reuniao do Conselho Interino da ICANN, dois meses
apos sua cria cao, constavam da pauta as seguintes questoes: elaborar o organograma opera-
cional da institui cao, denindo a estrutura das divisoes especcas para gerir suas atividades;
propor metodos de funcionamento para garantir a transparencia operacional da entidade; e
instituir uma divisao formada pelos usuarios da Internet a ALM (At Large Membership).
Hoje a ICANN e uma organiza cao sem ns lucrativos criada para assumir a responsabilidade
pela aloca cao do espa co de endere camento IP, designa cao de parametros de protocolos, gestao
do sistema de nomes de domnio e administra cao do sistema dos 18 servidores-raiz, fun coes antes
realizadas sob contrato com o governo dos EUA pela IANA e outras entidades. O Conselho da
ICANN e atualmente composto por 19 diretores: nove representantes da comunidade ampla de
usuarios; nove escolhidos pelas tres organiza coes de suporte da ICANN; e o presidente.
A ICANN funciona basicamente com tres divisoes: DNSO (Domain Name Supporting Orga-
nization), PSO (Protocol Supporting Organization) e ASO (Address Supporting Organization),
sendo esta ultima responsavel pelo controle da distribui cao de endere cos IP. A ASO funciona
9
em estreita coopera cao com alguns organismos regionais de administra cao de infra-estrutura,
como a ARIN, APNIC, LACNIC e RIPE/NCC. Veja gura 2.4.
IANA / ICANN
( Internet Assigned Numbers
Authority / Internet Corporation for
Assigned Numbers and Names )
ASO
( Address Supporting
Organization )
PSO
( Protocol Supporting
Organization )
DNSO
( Domain Name
Supporting
Organization )
ccTLD Registries

APNIC
( Asia Pacific
Network Information
Centre )
gTLD Registries

ITU - T
( International
Telecommunication
Union )
RIPE / NCC
( Rseaux IP
Europens / Network
Coordination Centre)
ARIN
( American Registry
for Internet Numbers)
IETF
( Internet Engineering
Task Force )
LACNIC
( Latin American and
Caribbean Internet
Address Registry)
FAPESP
( Fundao de
Amparo Pesquisa
do Estado de So
Paulo )
Figura 2.4: Estrutura hierarquica do ICANN.
ARIN (American Registry for Internet Numbers) O ARIN foi criado em 1997 com o
objetivo de administrar o registro de n umeros IP em separado da administra cao de nomes
de domnio a cargo da empresa privada Network Solutions. Hoje o ARIN, que administra
os n umeros IP por delega cao da ICANN para as Americas, e um corpo tecnico constitudo
basicamente por empresas americanas e canadenses de servi cos e produtos Internet.
APNIC (Asia Pacic Network Information Centre) Com fun coes semelhantes à ARIN,
o APNIC e praticamente um consorcio de empresas de produtos e servi cos Internet dis-
tribudas por 62 pases da regiao com fun cao de administrar os n umeros IP dessa regiao.
RIPE/NCC (Reseaux IP Europeens/Network Coordination Centre) - e uma comunidade
colaborativa aberta de organiza coes e indivduos que operam as redes IP europeias, com
alcance em alguns outros pases. O objetivo e garantir a coordena cao tecnica e adminis-
trativa necessarias para permitir a opera cao de uma rede IP pan-europeia.
LACNIC (Latin American and Caribbean Internet Addresses Registry) Desempenha papel
similar ao do APNIC, ARIN e RIPE na respectiva regiao: administra cao do espa co de
endere cos IP alocado para os pases da regiao e do ASN (Autonomous System Numbers),
opera cao da resolu cao reversa de domnios e outros recursos.

E constitudo basicamente
por empresas de servi cos e produtos Internet.
FAPESP (Funda cao de Amparo à Pesquisa do Estado de Sao Paulo) Maior orgao p ublico
brasileiro de fomento à pesquisa, supera em volume de recursos o proprio CNPq (Conselho
Nacional de Pesquisas). A FAPESP tem participado com pesquisadores, apoio nanceiro
10
e de infra-estrutura da implanta cao das redes de computadores orientadas à educa cao
e pesquisa desde os anos 80. Por decisao do Comite Gestor da Internet no Brasil, a
Funda cao foi escolhida como administradora tecnica do registro de nomes de domnio e
distribui cao de n umeros IP para o domnio .br.
2.2.1 Classes
Por varias decadas, os endere cos IP foram divididos nas cinco categorias (classes A,B,C,D e
E) listadas na gura 2.5. Essa aloca cao chegou a ser chamada endere camento de classe completo.
Todavia, as classes D e E sao destinadas para multicast e uso futuro respectivamente. Portanto,
iremos abordar com detalhes, somente as classes A,B e C. Embora nao seja mais usada, ainda
sao comuns referencias a essa aloca cao na literatura.
Figura 2.5: Classes de endere camento IP [1]
A deni cao de classes de endere cos deve-se ao fato do tamanho das redes que compoem
a internet variar muito, indo desde redes locais de computadores de pequeno porte ate redes
p ublicas interligando milhares de hosts.
A primeira classe de endere cos, classe A, o bit mais signicativo e 0, os outros 7 bits do
primeiro octeto identicam a rede e os 24 bits restantes denem o endere co local. Essa classe de
endere cos e usada para redes de grande porte, onde e possvel representar 126 redes e 16.777.214
hosts.
A classe B, usa dois octetos para o n umero da rede e dois para endere cos de hosts. Os
endere cos da rede de classe B variam na faixa de 128.1 ate 191.255 (os n umeros 0 e 255 do
segundo octeto, e 127 do primeiro, sao usados para fun coes especiais). Nessa classe e possvel
representar 16.382 redes e 65.534 hosts para cada uma das redes.
Finalmente os endere cos de classe C, utilizam tres octetos para identicar a rede e um para
o host. Os endere cos de rede situam-se na faixa de 192.1.1 ate 223.254.254. Os endere cos
11
acima de 223 no primeiro octeto, foram reservados para uso futuro. Nesta classe, e possvel
representar 2.097.150 redes com 254 hosts cada.
Redes Enderecos
Classe A 126 16.777.214
Classe B 16.382 65.534
Classe C 2.097.150 254
Tabela 2.1: Classes de Endere camento IP [4]
Para simplicar o roteamento, foram alocadas faixas de endere cos IP classe C por regiao
geograca, como mostra a tabela 2.2.
Faixa de Enderecos Regiao
192.0.0.0 a 192.255.255.255 Diversas
193.0.0.0 a 195.255.255.255 Europa
212.0.0.0 a 213.255.255.255
196.0.0.0 a 197.255.255.255

Africa
198.0.0.0 a 199.255.255.255
204.0.0.0 a 209.255.255.255 America do Norte
200.0.0.0 a 201.255.255.255 America do Sul e Central
202.0.0.0 a 203.255.255.255
210.0.0.0 a 211.255.255.255

Asia e Oceania
Tabela 2.2: Endere cos IP de Classe C divididos por regiao geograca [4]
A partir de 1993, nao foram mais concebidos redes tipo B, dado seu precario aproveita-
mento e a iminente escassez de n umeros para todos. Isso ocorreu da seguinte forma: muitas
institui coes optaram por endere cos de classe B (65.535 endere cos), sendo que elas precisavam
de algumas centenas apenas. Isto tornou-se um problema, ja que muitos endere cos passaram a
ser desperdi cados, culminando com a escassez de endere cos. Para isso foram propostas algumas
solu coes como CIDR (Se cao 2.2.4) e NAT (Se cao 2.2.5). Come cou entao a distribui cao intensa
de redes classe C, onde apenas o ultimo octeto pode ser variado pelo cliente. Sao redes que
comportam teoricamente 255 endere cos.
A crescente utiliza cao do espa co de endere cos em pequenas redes C levou a um outro, e nao
menos grave, problema: o crescimento descontrolado das tabelas de roteamento. Anal, cada
rede corresponde a uma rota especca, alocando para cada nova rede mais uma entrada nas
tabelas dos roteadores, o que causaria tabelas com comprimentos maiores, consequentemente,
exigindo grande capacidade de armazenamento nos roteadores. A exigencia de cada vez mais
memoria nos roteadores centrais da rede amea cou a Internet com um bloqueio geral. A forma
de contornar essa amea ca foi, lan car mao de blocos de endere cos de classe C, chamados blocos
CIDR. Desta forma cada bloco de endere cos de classe C e referenciado na tabela de roteamento
por uma unica entrada, e assim economiza-se memoria nos roteadores. Da provem o seguinte
problema: a coordena cao que um bloco CIDR precisa ter para ser efetivo. Ao se atribuir
12
um bloco a uma rota, uma linha internacional que vai dos EUA ao Brasil por exemplo, e
necessario que todos os endere cos desse bloco sejam, de fato, atingveis por essa rota. Assim, e
quase obrigatorio delegar a redistribui cao do bloco para quem cuida da rota, de forma que ele
distribua os endere cos contidos no bloco aos usuarios de sua rota.
2.2.2 Mascaras e Sub-Redes
Todos os hosts de uma rede devem ter o mesmo n umero de rede. Essa propriedade do
endere camento IP podera causar problemas à medida que as redes crescem. Seria difcil obter
um segundo endere co de rede, pois os endere cos de rede sao cada vez mais escassos. O problema
e a regra segundo a qual um unico endere co da classe A, B ou C se refere a uma rede, e nao a
um conjunto de LANs.
`
A medida que mais e mais organiza coes se encontravam nesta situa cao,
pequenas mudan cas eram realizadas no sistema de endere camento para lidar com ela.
A solu cao para esses problemas e permitir que uma rede seja dividida em diversas partes para
uso interno, mas externamente continue a funcionar como uma unica rede. Hoje, uma rede de
uma empresa tpica seria semelhante à da gura 2.6, contendo um roteador principal conectado
a um ISP ou a uma rede regional e numerosas redes Ethernet espalhadas pela empresa em
diferentes departamentos. Cada uma das redes Ethernet tem seu proprio roteador conectado
ao roteador principal.
Figura 2.6: Uma rede de uma empresa consistindo em LANs para varios departamentos
Na literatura sobre Internet, as partes da rede sao chamadas sub-redes. Essa acep cao apre-
senta roteadores e linhas de comunica cao de uma rede.
Quando um pacote entre no roteador principal, uma alternativa seria uma tabela com 65.536
entradas no roteador principal, informando que roteador usar para cada host na empresa.
13
Porem isso iria exigir uma tabela muito grande no roteador principal e um grande volume
de manuten cao manual, à medida que os hosts fossem acrescentados, movidos ou retirados de
servi co.
Em vez disso, foi criado um esquema diferente. Basicamente, em vez de ter um unico
endere co da classe B com 14 bits para indicar o n umero da rede e 16 bits para indicar o n umero
do host, alguns bits sao retirados do n umero do host para criar um n umero de sub-rede. Por
exemplo, se a empresa tivesse 35 departamentos, ela poderia usar um n umero de sub-rede de
6 bits e um n umero de host de 10 bits, permitindo ate 64 redes Ethernet, cada uma com o
maximo de 1022 hosts. Essa divisao poderia ser alterada mais tarde, caso houvesse necessidade.
Para implementar a divisao em sub-redes, o roteador principal precisa de uma mascara de
sub-rede que indique a divisao entre o n umero de rede + sub-rede e o host, como mostra a
gura 2.7. As mascaras de sub-redes tambem sao escritas em nota cao decimal com pontos,
com a inclusao de uma barra vertical seguida pelo n umero de bits na parte da rede + sub-rede.
No exemplo da gura 2.7, a mascara de sub-rede pode ser escrita como 255.255.252.0. Uma
nota cao alternativa e /22 para indicar que a mascara de sub-rede tem 22 bits.
Figura 2.7: Uma rede de classe B dividida em 64 sub-redes [1]
Fora da rede, a divisao em sub-redes nao e visvel; assim, a aloca cao de uma nova sub-rede
nao exige a interven cao da ICANN ou a mudan ca de quaisquer bancos de dados externos. Nesse
exemplo, a primeira sub-rede pode usar os endere cos IP, a partir de 130.50.4.1, a segunda sub-
rede pode se iniciar em 130.50.8.1, a terceira sub-rede pode come car em 130.50.12.1 e assim
por diante. Para ver por que as sub-redes estao sendo contadas de quatro em quatro, observe
que os endere cos binarios correspondentes sao:
Sub-rede 1: 10000010 00110010 000001|00 00000001
Sub-rede 2: 10000010 00110010 000010|00 00000001
Sub-rede 3: 10000010 00110010 000011|00 00000001
Aqui a barra vertical (|) mostra o limite entre o n umero da sub-rede e o n umero do host.
`
A sua esquerda esta o n umero de sub-rede de 6 bits; à sua direita esta o n umero de host de 10
bits.
Para ver como as sub-redes funcionam, e necessario explicar como os pacotes IP sao pro-
cessados em um roteador. Cada roteador tem uma tabela que lista algum n umero de endere cos
14
IP (rede, 0) e uma serie de endere cos IP (esta rede ou host). O primeiro tipo informa como
chegar a redes distantes. O segundo, como chegar a hosts locais. Associadas a essa tabela estao
a interface de rede usada para alcan car o destino e algumas outras informa coes.
Quando um pacote IP e recebido, seu endere co de destino e procurado na tabela de rotea-
mento. Se o destino for uma rede distante, o pacote sera encaminhado para o proximo roteador
da interface fornecida na tabela. Caso o destino seja um host local, o pacote sera enviado
diretamente para la. Se a rede nao estiver presente, o pacote sera enviado para um roteador
predenido que tenha tabelas maiores. Esse algoritmo signica que cada roteador so precisa
controlar as outras redes e hosts locais, deixando de lado os pares (rede, host), o que reduz
muito o tamanho da tabela de roteamento.
Quando a divisao em sub-redes e introduzida, as tabelas de roteamento sao alteradas
acrescentando-se entradas da forma (rede, sub-rede, 0) e (esta rede, esta sub-rede, host). Sendo
assim, um roteador da sub-rede k sabe como alcan car todas as outras sub-redes, e tambem como
chegar a todos os hosts da sub-rede k. Ele nao precisa saber detalhes sobre os hosts de outras
sub-redes. Na realidade, a unica modica cao e fazer com que cada roteador seja submetido a
um AND booleano com a mascara de sub-rede, a m de eliminar o n umero de host e pesquisar
o endere co resultante em suas tabelas depois de determinar qual e a classe da rede.
Por exemplo, um pacote endere cado a 130.50.15.6 recebido no roteador principal passa pela
opera cao AND booleana com a mascara de sub-rede 255.255.252.0/22 para gerar o endere co
130.50.12.0. Esse endere co e usado para acessar as tabelas de roteamento com a nalidade de
descobrir que linha de entrada usar para chegar ao roteador correspondente à sub-rede 3. Desse
modo, a divisao em sub-redes reduz o espa co na tabela do roteador, criando uma hierarquia de
tres nveis que consiste em rede, sub-rede e host.
O calculo para descobrir tanto o n umero de possveis sub-redes como o n umero de hosts
possveis por sub-rede, e dado pela equa cao generica: 2
n
2, onde n e igual ao n umero de bits
da sub-rede ou do host.
A maneira como as sub-redes operam, e emprestar um ou mais dos host, bits disponveis e
deixa-los fazer interfaces localmente interpretando estes bits emprestados como parte dos bits
de rede.
A tabela 2.3 mostra algumas das op coes de sub-rede que voce tem, para um endere co de
rede Classe C.
15
N
o
de Sub-Redes N
o
de Hosts Mascara
2 126 255.255.255.128
(11111111.11111111.11111111.10000000)
4 62 255.255.255.192
(11111111.11111111.11111111.11000000)
8 30 255.255.255.224
(11111111.11111111.11111111.11100000)
16 14 255.255.255.240
(11111111.11111111.11111111.11110000)
32 6 255.255.255.248
(11111111.11111111.11111111.11111000)
64 2 255.255.255.252
(11111111.11111111.11111111.11111100)
Tabela 2.3: Rela cao Sub-Redes vs Hosts de acordo com a mascara adotada [4]
2.2.3 Faixa de Endere cos IP nao-roteaveis
O IANA (Internet Assigned Numbers Authority) reserva os seguintes tres blocos de en-
dere cos IP para redes privadas.
10.0.0.0 - 10.255.255.255 (10/8 prex)
172.16.0.0 - 172.31.255.255 (172.16/12prex)
192.168.0.0 - 192.168.255.255 (192.168/16 prex)
O primeiro bloco nao e nada mais que um bloco de endere cos de classe A, enquanto que o
segundo e de classe B, e o terceiro, um bloco de endere cos de classe C.
Uma empresa que decida usar endere cos IP fora do espa co de endere co denidos na RFC
1918 [17] pode fazer sem nenhuma coordena cao com o IANA ou com um Internet Registry.
Dessa forma, estes endere cos podem ser usados por muitas empresas. Os endere cos dentro
deste intervalo serao validos somente dentro da empresa, ou para um conjunto de empresas que
escolherem se comunicar usando uma rede privada.
Toda a empresa que necessitar de um endere co IP valido na Internet, devera requerer tais
endere cos de um Internet Registry. Uma empresa que pe ca endere cos IP validos, nunca recebera
endere cos dos blocos denidos acima.
Para utilizar uma faixa de endere cos IP nao-roteaveis, uma empresa necessita determinar
quais os hosts que nao necessitam ter conectividade fora da empresa. Tais hosts usarao en-
dere cos nao-roteaveis denidos acima. Eles podem comunicar-se com todos os outros hosts
dentro da empresa. Entretanto, nao podem ter conectividade a nenhum host fora da empresa.
Enquanto que eles conseguem ter acesso a servi cos externos atraves de um gateway.
Todos os hosts restantes serao p ublicos e usarao um endere co valido atribudo por um
Internet Registry. Os hosts p ublicos podem comunicar-se com outros hosts dentro da empresa
16
e podem ter conectividade com hosts p ublicos fora da empresa. Os hosts p ublicos nao tem
conectividade com hosts privados de outras empresas.
Mover um host de privado para p ublico ou vice-versa envolve uma mudan ca do endere co
IP, do DNS, e das linhas de congura cao em outros hosts que fazem referencia ao host pelo
endere co IP.
Como os endere cos IP nao-roteaveis nao tem nenhum signicado global, a informa cao de
roteamento sobre redes privadas nao sera propagada e os pacotes com fonte ou endere cos de
destino privados nao devem ser enviados atraves de tais liga coes. Os roteadores nas redes que
nao usam o espa co de endere co privado, em especial aqueles do ISP, esperam ser congurados
para rejeitar a informa cao de roteamento sobre redes privadas. Se um roteador receber tal
informa cao, a rejei cao nao sera tratada como um erro do protocolo de roteamento.
As referencias indiretas a tais endere cos devem ser contidas dentro da empresa. Os exemplos
proeminentes de tais referencias sao registros do recurso do DNS e outras informa coes que
consultam os endere cos internos nao-roteaveis.
A vantagem em usar o endere co IP nao-roteavel se deve grande parte ao fato de conservar
os endere cos validos, nao usando onde nao sao requeridos. As empresas tambem apreciam os
benefcios que seu uso traz, pois ganham muito em exibilidade no projeto de rede, tendo mais
endere cos do que poderiam obter do pool global valido.
Por in umeras razoes, a Internet tem encontrado situa coes onde uma empresa conectada a
Internet tinha usado endere cos IP para seus hosts sem que eles tenham sido atribudos pelo
IANA. Em alguns casos, estes endere cos tinham sido atribudos ja a outras empresas. Se tal
empresa conectar mais tarde à Internet, este poderia criar problemas muito serios, porque o
roteamento IP nao poderia fornecer opera coes corretas na presen ca de endere cos ambguos.
Embora no princpio os ISP devessem evitar tais erros com o uso de ltros de rota, este nao
acontece na pratica. Usar endere cos IP nao-roteaveis fornece uma escolha segura para tais
empresas, evitando problemas, uma vez que a conectividade com o mundo exterior e precisa.
Um inconveniente causado pelo uso do endere co IP nao-roteavel e que pode realmente
reduzir a exibilidade de uma empresa em alcan car a Internet. Uma vez que uma empresa
comece a usar um endere co nao-roteavel, ela precisara renumerar parte dela ou toda a empresa,
se decidir fornecer conectividade externa a esta parte ou ao todo com a Internet. Geralmente
o custo de renumerar pode ser medido contando o n umero de hosts que esta transi cao tera.
Um outro inconveniente ao uso de endere cos nao-roteaveis e que ele pode requerer uma
renumera cao ao fundir diversas redes privadas em apenas uma unica rede privada. O custo de
renumerar pode muito bem ser reduzido pelo desenvolvimento e distribui cao de ferramentas
que facilitam este servi co (Por exemplo: DHCP (Dynamic Host Conguration Protocol )).
Com o esquema descrito, muitas empresas grandes necessitarao somente de um bloco rela-
tivamente pequeno de endere cos IP validos. As empresas beneciam-se da exibilidade aumen-
tada fornecida por um range de endere cos IP nao-roteaveis relativamente grande. Entretanto,
o uso destes endere cos requer que uma organiza cao renumere uma parte ou toda a sua rede,
17
porque suas exigencias de conectividade mudam o tempo todo.
2.2.4 CIDR
O IP vem sendo utilizado ha mais de uma decada e tem funcionado muito bem, sendo
demonstrado pelo seu grande crescimento. Porem, devido a sua popularidade, esta cando cada
vez mais escasso o n umero de endere cos. Esse problema causou muita discussao e controversias
na comunidade da Internet sobre o que fazer em rela cao a ele.
Em 1987, alguns visionarios previram que algum dia a Internet chegaria a 100.000 redes.
Muitos especialistas disseram que isto so aconteceria apos muitas decadas. Em 1996, a Internet
ja atingia este n umero de redes. O problema, e que a Internet esta esgotando com rapidez os
endere cos IP disponveis. Em princpio, existem mais de quatro bilhoes de endere cos, porem a
pratica de organizar o espa co de endere cos por classes faz com que milhoes sejam desperdi cados.
Veja se cao 2.2.1. O verdadeiro problema desta organiza cao, esta nos endere cos de classe B. Os
endere cos de classe A, com 16 milhoes de endere cos, e muito grande, e uma rede de classe C,
com 256 endere cos, e muito pequena. Uma rede de classe B, com 65.536 endere cos, e a melhor
solu cao, entretanto, por ser um n umero grande demais para a maioria das organiza coes, isto
faz com que haja um grande desperdcio de endere cos IP.
Estudos demonstraram que mais da metade de todas as redes da classe B tem menos de 50
hosts. Uma rede da classe C funcionaria muito bem nesse caso, mas nao ha d uvida de que todas
as empresas que solicitaram um endere co da classe B pensaram que um dia ultrapassariam
o campo dos hosts de 8 bits. Teria sido muito melhor fazer com que as redes da classe C
utilizassem 10 bits, em vez de oito para o n umero de host, permitindo 1.022 hosts por rede. Se
isso tivesse acontecido, a maioria das empresas provavelmente teria optado por uma rede da
classe C, e haveria meio milhao dessas redes contra somente 16.384 redes da classe B.
Entretanto, outro problema teria surgido com maior rapidez: a explosao da tabela de rotea-
mento. Do ponto de vista dos roteadores, o espa co do endere co IP, tem dois nveis hierarquicos,
com n umero de redes e n umero de hosts. Os roteadores nao precisam conhecer todas os hosts,
mas sim todas as redes. Se meio milhao de redes classe C estivesse em uso, cada roteador da
Internet precisaria de uma tabela com meio milhao de entradas, uma por rede, indicando qual
rota deveria ser utilizada para se chegar a um determinado destino, alem de uma serie de outras
informa coes.
O armazenamento fsico de tabelas com meio milhao de entradas provavelmente e viavel.
O problema mais serio esta na complexidade dos diversos algoritmos que gerenciam as tabelas
de roteamento crescendo cada vez mais rapidamente. Alem disso, grande parte do software
projetado para roteadores foi criado em uma epoca em que haviam pouco mais de 1.000 redes
conectadas.
Como se nao bastassem todos estes problemas, diversos algoritmos de roteamento exigem
que cada roteador transmita suas tabelas periodicamente, ou seja, quanto maiores as tabelas,
18
maior sera a probabilidade de que algumas partes se percam pelo caminho, resultando em dados
incompletos na outra extremidade.
O problema da tabela de roteamento poderia ter sido solucionado pelo estabelecimento de
uma hierarquia mais profunda. Por exemplo, fazer com que cada endere co IP contenha um
campo de pas, estado/provncia, cidade, rede e host poderia funcionar. Porem, essa solu cao
exigiria muito mais de 32 bits para endere cos IP.
Em suma, algumas solu coes resolvem um problema, porem criam outros. Assim sendo, a
solu cao implementada que deu à Internet um tempo extra para respirar foi o CIDR (Classless
InterDomain Routing). A ideia basica por tras do CIDR, descrito na RFC 1519 [15], e alocar
os endere cos IP restantes em blocos de tamanho variavel, sem levar em considera cao as classes.
Se uma empresa precisar de 4.000 endere cos, ele recebera um bloco de 4.096 endere cos em um
limite de 4.096 bytes. Em outras palavras, a ideia e usar um intervalo de endere cos de classe C
em vez de um unico endere co de classe B.
O CIDR roteia de acordo com os bits de ordem mais alta do endere co IP, chamados de
prexo IP e nao pela classe do n umero da rede (por isso o termo Classless, sem classe).
Cada entrada de tabela de roteamento CIDR contem um endere co IP de 32 bits e uma mascara
de rede de 32 bits, que juntos fornecem o comprimento e o valor do prexo IP. Isto pode ser
representado como (endere co-IP mascara-Rede). Por exemplo, para uma organiza cao que pre-
cisa de 2.000 endere cos, e necessario endere car um bloco de oito endere cos de classe C, isto
porque cada endere co de classe C pode ter 256 endere cos, portanto oito endere cos de classe
C seria o equivalente a 2.048 endere cos, isto tudo com uma unica entrada na tabela de rotea-
mento. Assim sendo, a representa cao seria a seguinte: (192.32.136.0 255.255.248.0) ou ainda
(192.32.136.0/21), ou seja:
192.32.136.0 = 11000000.00100000.10001000.00000000
255.255.248.0= 11111111.11111111.11111000.00000000
que tambem pode ser representado da seguinte forma:
192.32.136.0/21
Isto porque , conforme a equa cao 2
n
, onde n neste caso e igual ao n umero de bits referente
aos hosts, teramos entao 211 que e igual a 2.048 endere cos. Embora alternativas como CIDR
e NAT tenham ajudado no problema de escassez de endere cos IPv4, todo mundo percebe que
o IP em sua forma atual esta com os dias contados, da a necessidade de uma nova versao do
protocolo, o IPv6. Veja captulo 3.
2.2.5 NAT
Com o problema do esgotamento de endere cos IP, a solu cao a longo prazo e a migra cao
para o IPv6, porem enquanto isto nao ocorre, ja que e um processo lento, fez-se necessario uma
19
solu cao a curto prazo, que veio sob a forma do servi co NAT (Network Address Translation),
descrita na RFC 3022 [27].
A ideia basica e atribuir um unico endere co IP para cada empresa ou no maximo um
n umero pequeno deles para trafego na Internet. Dentro da empresa, todo computador obtem
um endere co IP exclusivo, situado dentro de um intervalo de IP nao-roteaveis, usado somente
para roteamento do trafego interno. Veja se cao 2.2.3. A unica regra e que nenhum pacote
contendo esses endere cos pode aparecer na Internet.
A opera cao do servi co NAT e mostrado na gura 2.8. Dentro das instala coes da empresa,
toda maquina tem um endere co IP exclusivo e nao roteavel, sendo que ao passar pelo servidor
NAT, ele e convertido no endere co IP verdadeiro da empresa. Geralmente o servidor NAT esta
combinado no mesmo dispositivo que o Firewall, ja que os dois atuam na porta de entrada da
rede. Tambem e possvel integrar o servidor NAT ao roteador da empresa.
Pacote antes
da converso
LAN da
empresa
Roteador
da
empresa
Servidor
Limite das instalaes da empresa
Servidor
NAT / Firewall
Pacote aps
a converso
Roteador
do ISP
Linha
dedicada
Figura 2.8: Posicionamento e opera cao de um servidor NAT [1]
O grande problema do servi co NAT esta na resposta às requisi coes feitas pelos dispositivos
situados internos ao gateway. Para resolver este problema seria necessario termos um campo
para controlar qual e o transmissor real, mas resta somente um bit no cabe calho IP que ainda
nao e utilizado. Como op cao, poderia ser criado um campo para conter este endere co de
origem verdadeiro, porem isso exigiria que todas as maquinas na Internet tivessem seu codigo
IP mudado para que pudessem manipular a nova op cao.
Para resolver este problema, os projetistas perceberam que a maioria dos pacotes IP trans-
porta uma carga util TCP ou UDP. Ambos os protocolos, possuem em seu cabe calho uma
porta de origem e outra porta de destino. As portas sao inteiros de 16 bits que indicam onde
a conexao come ca e termina. Elas fornecem o campo necessario para o servi co NAT funcionar.
Os cabe calhos sao mostrados na guras 2.9 e 2.10.
20
Figura 2.9: Cabe calho do Protocolo TCP [1]
Figura 2.10: Cabe calho do Protocolos UDP [1]
Usando o campo Source Port, presentes nos dois protocolos, podemos resolver o problema
de mapeamento. Sempre que um pacote de sada entra no servidor NAT, o endere co de origem
e substitudo pelo endere co IP verdadeiro da empresa. Alem disso, o campo Source Port do
TCP e substitudo por um ndice para a tabela de conversao de 65.536 entradas do servidor
NAT. Essa entrada de tabela contem a porta de origem e o endere co IP original. Por m, tanto
o total de verica cao do cabe calho IP quanto do cabe calho TCP sao recalculados e inseridos
no pacote.
Quando um pacote chega ao servidor NAT vindo do ISP (Internet Service Provider), o
campo Source Port do cabe calho de TCP e extrado e usado como ndice para a tabela de
mapeamento do servidor NAT. Esse metodo e denominado NAPT (Network Address and Port
Translation). A partir da entrada localizada, o endere co IP interno e o campo Source Port
do TCP original sao extrados e inseridos no pacote. Em seguida sao recalculados os totais de
verica cao do IP e do TCP e inseridos no pacote. O pacote e entao repassado ao roteador da
empresa para entrega normal.
O servi co NAT tambem pode ser utilizado para diminuir o problema da escassez de endere cos
IP aos usuarios de ADSL e cabo. Quando os pacotes das maquinas dos usuarios saem do ISP
e entram na Internet principal, eles passam por um servidor NAT que faz a conversao de seus
endere cos de origem, no endere co valido na Internet do ISP. Na volta os pacotes sofrem o
21
mapeamento inverso. Nesse aspecto, para o restante da Internet, o ISP e seus usuarios parecem
ser apenas uma grande empresa.
Embora o servi co NAT venha a resolver uma parte dos problemas, ele apresenta muitas
obje coes. Primeiro, o NAT contraria a regra em que cada endere co IP identica de forma
exclusiva uma unica maquina em todo o mundo. Toda a estrutura de software da Internet
se baseia nesse fato. Com a estrutura NAT, milhares de maquina podem e usam o endere co
10.0.0.1.
Em segundo lugar, o NAT faz a Internet mudar suas caractersticas de rede sem conexoes
para uma especie de rede orientada a conexoes. O problema e que o servidor NAT deve manter
o mapeamento para cada conexao que passa por ele. Manter o estado da conexao e uma
propriedade das redes orientadas a conexoes, e nao das redes sem conexoes. Se o servidor
NAT sofrer uma pane e sua tabela de mapeamento se perder, todas as conexoes TCP serao
destrudas. Na ausencia deste servi co, panes em roteadores nao terao nenhum efeito sobre o
TCP. O processo transmissor simplesmente entrara em timeout dentro de alguns segundos e
retransmitira todos os pacotes nao-conrmados.
Em terceiro lugar, o NAT viola a regra mais fundamental da distribui cao de protocolos em
camadas. Esse princpio basico existe para manter as camadas independentes. Se o TCP for
atualizado mais tarde, com um layout de cabe calho diferente, o NAT falhara. Toda a ideia
de protocolos em camadas tem o objetivo de assegurar que as mudan cas em uma camada nao
exigirao mudan cas em outras camadas. O NAT destroi essa independencia.
Em quarto lugar, os processos na Internet nao sao obrigados a usar o TCP ou o UDP. Se
um usuario quiser criar o seu proprio protocolo de transporte para se comunicar com outras
maquinas, o servi co NAT falhara, porque nao sera capaz de localizar corretamente o campo
Source Port do cabe calho TCP.
Em quinto lugar, algumas aplica coes inserem endere cos IP no corpo do texto. O receptor
entao extrai esses endere cos e os utiliza. Tendo em vista que o NAT nada sabe sobre esses
endere cos, ela nao pode substitu-los; assim, qualquer tentativa de usa-los no lado remoto
falhara. O FTP (File Transfer Protocol ) padrao funciona desta maneira e pode falhar na
presen ca do NAT, a menos que sejam adotadas precau coes especiais.
Em sexto lugar, como o campo Source Port do TCPe de 16 bits, no maximo 65.536 maquinas
podem ser mapeadas em um endere co IP. Na realidade, o n umero e um pouco menor, porque
as primeiras 4096 portas estao reservadas para usos especiais. Porem se varios endere cos IP
estiverem disponveis, cada um deles podera manipular ate 61.440 maquinas.
Esse e outros problemas com o NAT sao discutidos na RFC 2993 [26].Em geral, os opositores
do NAT armam que solucionar o problema de insuciencia de endere cos IP com uma corre cao
temporaria e detestavel signica reduzir a pressao para implementar a verdadeira solu cao, ou
seja, a transi cao para o IPv6.
22
2.3 Fragmentacao e Remontagem do IPv4 Peretto, L.M.
2.3 Fragmentacao e Remontagem do IPv4
Nem todos os protocolos de camada de enlace podem carregar pacotes do mesmo tamanho.
Alguns protocolos podem carregar pacotes grandes, ao passo que outros podem carregar
apenas pacotes pequenos. Por exemplo, os pacotes Ethernet nao podem carregar mais do
que 1500 bytes de dados, enquanto que os pacotes para muitos enlaces de longa distancia nao
podem carregar mais do que 576 bytes. A quantidade maxima de dados que um pacote de
camada de enlace pode carregar e chamada de MTU (Maximum Transfer Unit). Como cada
datagrama IP e encapsulado dentro do pacote de camada enlace para ser transportado de
um roteador ate o roteador seguinte, a MTU do protocolo de camada de enlace coloca um
limite severo no comprimento do datagrama IP. Ter uma limita cao severa para o tamanho do
datagrama IP nao e o grande problema. O problema maior e que cada um dos enlaces ao
longo da rota entre o remetente e o destinatario pode usar diferentes protocolos de camada
de enlace, e cada um desses protocolos pode ter diferentes MTUs. Para entender melhor o
problema, imagine que voce e um roteador que esta interligando diversos enlaces, cada um
rodando diferentes protocolos de camada de enlace com diferentes MTUs. Suponha que voce
receba um datagrama IP de enlace, verique sua tabela de roteamento para determinar o enlace
de sada e veja que esse enlace de sada tem uma MTU que e menor do que o comprimento do
datagrama IP. Neste ponto, existem poucas alternativas:
Descartar o pacote;
Comprimir esse pacote de tamanho excessivo atraves de algum algoritmo de compressao,
para que o mesmo possa caber no campo de carga util do quadro da camada de enlace;
Fragmentar os dados do datagrama IP em dois ou mais datagramas IP menores e, entao,
enviar esses datagramas menores pelo enlace de sada.
Cada um desses datagramas menores e chamado de fragmento. Os fragmentos precisam ser
remontados antes que cheguem à camada de transporte no destino. Na verdade, tanto o TCP
quanto o UDP esperam receber da camada de rede segmentos completos, e nao fragmentos.
Os projetistas do IPv4 perceberam que a remontagem (e a possvel refragmenta cao) de
datagramas nos roteadores introduziria uma complica cao signicativa no protocolo e colocaria
um freio no desempenho do roteador. Seguindo o princpio de conservar a simplicidade da
camada de rede, os projetistas do IPv4 decidiram passar a tarefa de remontagem de datagramas
aos sistemas nais, preparando os roteadores da rede.
Quando um host destinatario recebe uma serie de datagramas da mesma fonte, ele precisa
determinar se, dentre esses datagramas, algum e fragmento de um datagrama original de maior
tamanho. Se ele, de fato, determinar que alguns desses datagramas sao fragmentos, deve de-
terminar, adicionalmente, quando recebeu o ultimo fragmento e como os fragmentos recebidos
devem ser remontados para voltar à forma do datagrama original. Para permitir que o host
23
destinatario realize essas tarefas de remontagem, os projetistas do IPv4 criaram os seguintes
campos: Identication, Flags e Fragment Oset no datagrama IP, como mostra a gura 2.11.
Quando um datagrama e criado, o host remetente marca o datagrama com um n umero de iden-
tica cao, bem como o endere co da fonte e do destino. O host remetente incrementa o n umero
de identica cao para cada datagrama que envia. Quando um roteador precisa fragmentar um
datagrama, cada datagrama resultante (isto e, cada fragmento) e marcado com o endere co da
fonte, o endere co do destino e o n umero de identica cao do datagrama original. Quando o desti-
natario recebe uma serie de datagramas do mesmo host remetente, ele pode examinar o n umero
de identica cao dos datagramas para determinar quais deles sao, na verdade, fragmentos de
um mesmo datagrama de tamanho maior. Como o IP e um servi co nao conavel, e possvel que
um ou mais desses fragmentos jamais cheguem ao destino. Por essa razao, para que o host de
destino que absolutamente seguro de que recebeu o ultimo fragmento do datagrama original, o
ultimo datagrama tem um bit de ag ajustado para 0, ao passo que todos os outros fragmentos
tem um bit de ag ajustado para 1. Alem disso, para que o host destinatario possa determinar
se esta faltando algum segmento (e possa remontar os fragmentos na ordem correta), o campo
de deslocamento e usado para especicar a localiza cao exata do fragmento no datagrama IP
original.
ID
=x
offset
=0
fragflag
=0
tamanho
=4000
ID
=x
offset
=0
fragflag
=0
tamanho
=4000
ID
=x
offset
=0
fragflag
=1
tamanho
=1500
ID
=x
offset
=0
fragflag
=1
tamanho
=1500
ID
=x
offset
=1480
fragflag
=1
tamanho
=1500
ID
=x
offset
=1480
fragflag
=1
tamanho
=1500
ID
=x
offset
=2960
fragflag
=0
tamanho
=1040
Umgrande datagrama setorna
v rios datagramas menores
Figura 2.11: Exemplo de fragmenta cao no IP [4]
A Figura 2.11 apresenta um exemplo de um datagrama de 4000 bytes que chega a um
roteador e deve ser repassado a um enlace com MTU de 1500 bytes. Isso implica que os 4000
bytes de dados do datagrama original devem ser alocados em tres fragmentos separados (cada
qual e tambem datagrama IP).
A carga util do datagrama somente e passada para a camada de transporte no destino
quando a camada IP remonta o datagrama IP original. Se um ou mais fragmentos nao chegarem
ao destino, o datagrama sera descartado e nao sera passado à camada de transporte. Mas, caso
o TCP estiver sendo usado na camada de transporte, ele recuperar a essa perda fazendo com
24
que a fonte retransmita os dados do datagrama original.
A fragmenta cao e a remontagem colocam uma carga adicional sobre os roteadores da In-
ternet (o esfor co adicional de criar fragmentos a partir de um datagrama) e sobre os hosts
destinatarios (o esfor co adicional de remontar fragmentos). Por essa razao, e desejavel que
se mantenha a fragmenta cao no mnimo. Isso e feito com frequencia limitando os segmentos
TCP e UDP a tamanhos relativamente pequenos, de modo que a fragmenta cao dos datagramas
correspondentes seja pouco provavel. Como todos os protocolos de enlace suportados pelo IP
supostamente tem MTUs de, no mnimo, 576 bytes, a fragmenta cao pode ser eliminada usando-
se um MSS (Maximum Segment Size) de 536 bytes, 20 bytes para o cabe calho do segmento
TCP e 20 bytes para o cabe calho do datagrama IP.

E por isso que a maioria dos segmentos IP
para transferencia de dados tem em media 512 à 536 bytes de comprimento.
O IPv6, assim como o IPv4, implementa a fragmenta cao do Datagrama. A grande diferen ca
se da na maneira com que isto ocorre. No IPv4 cada roteador intermediario deveria fragmentar
e reorganizar datagramas de acordo com o MTU da sub-rede. No IPv6, a fragmenta cao e
feita na origem, antes de enviar um datagrama, utiliza a tecnica de enviar um Path MTU
Discovery para descobrir qual o menor dos MTUs. Quando o envio se da, a origem fragmenta
de maneira que cada fragmento devera ser menor que o MTU mnimo descoberto. Desta forma
a fragmenta cao nao ocorre nos roteadores intermediarios.
25
Captulo 3
IPv6
O IP em sua forma atual (IPv4) esta com os dias contados, embora o CIDR e o NAT
ainda tenham alguns anos pela frente. Alem desses problemas tecnicos, ha uma outra questao
em paralelo. No incio, a Internet era amplamente usada por universidades, ind ustrias de alta
tecnologia e orgaos governamentais dos Estados Unidos. Com a explosao da Internet a partir de
meados de 1990, ela come cou a ser usada por um grupo diferente de pessoas, em especial pessoas
com necessidades especcas. Por um lado, milhares de pessoas com computadores portateis
sem os a utilizam para estabelecer contato com suas bases. Por outro, com a inevitavel
convergencia das ind ustrias de informatica, comunica cao e entretenimento, talvez nao demore
para que cada telefone e cada televisor do mundo seja um no da Internet, resultando no uso de
audio e vdeo por demanda em um bilhao de maquinas. Sob essas circunstancias, cou claro
que o IP precisava evoluir para se tornar mais exvel.
Em 1990, com esses problemas no horizonte, a IETF (Internet Engineering Task Force)
come cou a trabalhar em uma nova versao do IP, capaz de impedir que os endere cos fossem
esgotados e de resolver uma serie de outros problemas, alem de ser mais exvel e mais eciente.
Aqui estao os principais objetivos:
Aceitar bilhoes de hosts, mesmo com aloca cao de espa co de endere cos ineciente.
Reduzir o tamanho das tabelas de roteamento.
Simplicar o protocolo, de modo a permitir que os roteadores processem os pacotes com
mais rapidez.
Oferecer mais seguran ca (autentica cao e privacidade) do que o IP atual.
Dar mais importancia ao tipo de servi co, particularmente no caso de dados em tempo
real.
Permitir multidifusao, possibilitando a especica cao de escopos.
Permitir que um host mude de lugar sem precisar mudar o endere co.
26
IPv6 Peretto, L.M.
Permitir que o protocolo evolua no futuro.
Permitir a coexistencia entre protocolos novos e antigos durante anos.
Para chegar a um protocolo que atendesse a todos esses requisitos, a IETF convocou os
interessados a apresentarem suas propostas na RFC 1550. Foram recebidas 21 respostas, mas
nem todas foram consideradas propostas completas. Em Dezembro de 1992, havia sete pro-
postas muito interessantes em estudo. As propostas variavam desde pequenos ajustes no IP, à
sua elimina cao pura e simples, com a cria cao de um protocolo totalmente diferente.
Uma proposta era executar o TCP sobre o CLNP (Connectionless Network Protocol ) que,
com seus endere cos de 160 bits, seria capaz de oferecer um espa co de endere cos innitos e uni-
caria os dois principais protocolos da camada de rede. No entanto, para muita gente, isso seria o
mesmo que admitir que o mundo OSI ainda tinha suas vantagens, uma arma cao politicamente
incorreta nos crculos da Internet. A padroniza cao do protocolo CLNP tinha caractersticas
muito parecidas com a do IP; portanto, nao podemos armar que os dois protocolos sejam de
fato muito diferentes. Na verdade, o protocolo que acabou sendo escolhido apresenta muito mais
diferen cas em rela cao ao IP do que o CLNP. Um dos fatores que pesaram contra o CLNP foi a
baixa qualidade em rela cao aos tipos de servi cos oferecidos, algo de fundamental importancia
para uma eciente transmissao multimdia.
As tres melhores propostas foram publicadas na IEEE Network. Depois de muita discussao,
revisao e disputa, foi selecionada uma versao combinada modicada das propostas de Deering e
Francis, agora chamada SIPP (Simple Internet Protocol Plus), à qual foi atribuda a designa cao
IPv6. A sigla IPv5 nao pode ser utilizada nesta versao posterior ao IPv4, pois foi uma pequena
modica cao experimental para trafegar voz e vdeo sobre multicast. Sua especica cao pode ser
encontrada sob a RFC 1819 (Internet Streaming Protocol Version 2).
O IPv6 atende a todos os objetivos propostos, preservando os bons recursos do IP, descar-
tando ou reduzindo a importancia das caractersticas ruins e criando outras quando necessario.
Genericamente, o IPv6 nao e compatvel com o IPv4, mas e compatvel com todos os outros
protocolos auxiliares da Internet, incluindo TCP, UDP, ICMP, IGMP, OSPF, BGP e DNS, ape-
sar de, em certos momentos serem necessarias pequenas modica coes (principalmente quando
tem de lidar com endere cos mais longos). Os principais recursos do IPv6 serao discutidos a
seguir.
Apesar de haver varios backbones com IPv6 em carater experimental, como o 6Bone, que e
o backbone IPv6 do projeto IPng (Internet Protocol Next Generation), a previsao e que ainda
demore um pouco para o incio das opera coes comerciais. Por alguns anos, os equipamentos
deverao oferecer compatibilidade entre IPv6 e IPv4. Porem, a migra cao nao sera algo simples.
Ha um grupo de trabalho do IETF, o IPng Transition exclusivamente ocupado para levantar
os problemas e solu coes para essa migra cao.
27
IPv6 Peretto, L.M.
3.0.1 Cabecalho
O formato do datagrama IPv6 e mostrado na gura 3.1. Muitas das novas caractersticas
sao fundamentais para a manuten cao da Internet nos proximos anos. Outras foram denidas
com base na identica cao de problemas futuros.
Figura 3.1: Formato do datagrama IPv6 [1]
Version. 4 bits. Este campo e sempre 6 para o IPv6. A simples coloca cao do valor 6
nesse campo, nao cria um datagrama IPv6 valido. Durante o perodo de transi cao do IPv4,
os roteadores serao capazes de examinar esse campo para identicar o tipo de pacote que
eles tem. A realiza cao deste teste desperdi ca algumas instru coes no caminho, fazendo com
que muitas implementa coes tentem evita-lo usando algum campo no cabe calho de enlace
de dados para diferenciar os pacotes IPv4 dos pacotes IPv6. Dessa forma, os pacotes
podem ser passados diretamente para o tratador da camada de rede correto. No entanto,
esta estrategia de fazer com que a camada de enlace de dados tenha conhecimento dos
tipos de pacotes de rede viola completamente o princpio do projeto, onde cada camada
nao deveria saber o signicado dos bits que estao sendo passados a ela pela camada
superior.
Trac Class. 8 bits. Esse campo ainda e experimental e pode vir a ser modicado. Na
primeira especica cao do IPv6, RFC 1883, esse campo nao existia. Em seu lugar havia
um campo de 4 bits chamado Priority. A fun cao deste campo e permitir diferencia cao
de trafego e mecanismos de prioridade, para que os roteadores possam prover tratamento
apropriado em cada caso. Algumas ideias do ToS e dos bits Precedence do Ipv4 foram
aproveitadas. Ainda ha muita discussao sobre a divisao mais util e eciente dos varios
tipos de trafego em classes. Cabe à camada superior informar a camada IPv6 qual a classe
28
IPv6 Peretto, L.M.
de trafego a ser utilizada. Um roteador pode alterar os bits do campo Trac Class da
forma que desejar. Por esse motivo, uma esta cao nao deve assumir que um determinado
tipo de trafego que ela associou a uma certa classe, sera recebido com o campo Trac
Class com o mesmo valor com o qual ela transmitiria.
Flow Label. 20 bits. Um ow e uma seq uencia de pacotes enviados a partir de uma
determinada origem, para um determinado destino (unicast ou multicast), requerendo
um tratamento especial pelos roteadores, como QoS ou reserva de banda (RSVP), por
exemplo. Ainda esta em fase de experiencia e pode sofrer modica coes, como ja ocorreu
desde a primeira especica cao do IPv6, onde ele possua 24 bits, mas sera usado para
permitir que uma origem e um destino congurem uma pseudoconex ao com propriedades
e necessidades especcas. Por exemplo, um uxo de pacotes entre um processo e um
determinado host de origem e um certo processo de um host de destino especco pode
ter severas restri coes em termos de retardo e, por essa razao, necessitar de uma largura de
banda reservada. O uxo pode ser congurado com antecedencia e ter um identicador
atribudo a ele. Quando um pacote com o campo Flow Label com valor diferente de zero
aparece, todos os roteadores podem vericar nas tabelas internas que tipo de tratamento
especial ele exige. Na pratica, os uxos sao uma tentativa de se ter a exibilidade de
uma sub-rede de datagramas juntamente com as garantias de uma sub-rede de circuitos
virtuais.
Cada uxo e designado pelo endere co de origem, endere co de destino e n umero de uxo.
Portanto, pode haver muitos uxos ativos ao mesmo tempo entre um determinado par
de endere cos IP. Por essa razao, quando dois uxos enviados por diferentes hosts e com o
mesmo n umero de uxo passarem pelo mesmo roteador, este sera capaz de distingui-los
usando os endere cos de origem e de destino. Para que os roteadores possam analisar os
n umeros de uxo com mais facilidade, eles serao escolhidos ao acaso, em vez de serem
atribudos sequencialmente a partir de 1. Roteadores e hosts que nao sao capazes de
identicar o Flow Label de um pacote devem deixar o campo com valor igual a 0, quando
origina-lo, deixa-lo inalterado, quando retransmiti-lo, ou ignora-lo, quando recebe-lo.
Payload Length. 16 bits. O nome desse campo, que no IPv4 era Total Length, foi alterado
devido à pequena mudan ca de signicado a que foi submetido: os 40 bytes do cabe calho
deixaram de ser contados como parte do tamanho, como acontecia ate entao, passando a
determinar o comprimento dos dados, em octetos, encapsulados pela camada de rede, isto
e, quantos bytes seguem o cabe calho IPv6 (os campos de extensao sao contabilizados).
Caso esse campo seja 0, indica que o comprimento do payload e superior a 65.535 octetos
e e informado em um Extension Header.
Next Header. 8 bits. Com a utiliza cao deste campo, o cabe calho pode ser simplicado,
porque existe a possibilidade de haver outros cabe calhos de extensao (opcionais). Esse
29
IPv6 Peretto, L.M.
campo informa qual o protocolo da camada superior que esta utilizando os servi cos da
camada IP. A numera cao tambem segue o RFC 1700 [16]. No IPv6, caso haja algum
campo adicional apos o cabe calho, o valor de Next Header informa qual o tipo de extensao
que vem apos o cabe calho IPv6. Se esse cabe calho for o ultimo cabe calho do IP, o campo
Next Header revelara para qual tratador de protocolo de transporte (por exemplo, TCP
ou UDP) o pacote devera ser enviado.
Hop Limit. 8 bits. Semelhante ao campo TTL do IPv4, e usado para impedir que os
pacotes tenham dura cao eterna. No IPv4 ele denotava um tempo em segundos, mas
nenhum roteador o utilizava dessa maneira. Por esse motivo, seu nome foi alterado para
reetir o modo como de fato ele e usado. Cada unidade processadora de pacotes (no)
decrementa esse valor de 1 unidade e quando esse valor chegar a 0, o pacote e descartado.
Source Address. 128 bits. Informa o endere co IP de origem do datagrama.
Destination Address. 128 bits. informa o endere co IP de destino do datagrama.
3.0.1.1 Extension Header
Ocasionalmente, alguns dos campos ausentes do IPv4 ainda serao necessarios; assim, o
IPv6 introduziu o conceito de cabe calho de extensao (opcional), baseado no conceito do
campo Options do IPv4. Esses cabe calhos podem ser criados com a nalidade de oferecer
informa coes extras, desde que elas sejam codicadas de maneira eciente. Possuem tamanho
variavel, mas sempre m ultiplo de 8 octetos (64 bits). Atualmente, ha seis tipos de cabe calhos
de extensao denidos, mostrados na tabela 3.1.Os quatro primeiros tipos de Extension Header
podem ser encontrados no RFC 2460 [21], e os dois ultimos, nos RFCs 2402 [19] e 2406 [20],
respectivamente. Todos eles sao opcionais, mas, se houver mais de um, eles terao de aparecer
logo depois do cabe calho xo e, de preferencia, na ordem listada.
Extension Header Valor Descricao
Hop-by-hop options 0 Informa coes diversas para os roteadores
Destination options 60 Informa coes adicionais para o destino
Routing 43 Lista parcial
Fragmentation 44 Gerenciamento de fragmento de datagramas
Authentication 50 Verica cao da identidade do transmissor
Encapsulating Security Payload 51 Informa coes sobre o conte udo criptografado
Tabela 3.1: Cabe calhos de extensao do IPv6 [1]
Alguns desses cabe calhos tem um formato xo; outros contem um n umero variavel de cam-
pos de comprimento variavel. Nesses casos, cada item e codicado como uma tupla (Type,
Length, Value). Type e um campo de 1 byte que identica a op cao. Os valores de Type foram
escolhidos de tal forma que os dois primeiros bits informem o que devem fazer os roteadores
30
IPv6 Peretto, L.M.
que nao sabem como processar a op cao. Estas sao as possibilidades: ignorar a op cao, descartar
o pacote, descartar o pacote e enviar de volta um pacote ICMP, e ainda a mesma op cao ante-
rior sem que, no entanto, sejam enviados pacotes ICMP para endere cos de multidifusao (para
impedir que um pacote de multidifusao defeituoso gere milhoes de relatorios ICMP).
Length tambem e um campo de 1 byte. Ele identica o tamanho do valor (0 a 255 bytes).
Value contem todas as informa coes obrigatorias, com no maximo 255 bytes.
O cabe calho Hop-by-hop e usado para transmitir as informa coes opcionais que todos os
roteadores ao longo do caminho devem examinar. Os campos do cabe calho sao especicados
abaixo:
Next Header. 8 bits. Indica o proximo cabe calho, utiliza os mesmos valores que o campo
Protocol no IPv4.
Length. 8 bits. Especica o tamanho do campo Options.
Options. 16 bits.

E subdividido em 2 outros campos:
Options Data Length. 8 bits. Especica o tamanho do campo Options Data em
bytes;
Options Type. 8 bits. Indica o tipo da op cao e divide-se em : Action (2 bits) A cao
que deve ser executada, caso o no que esta processando o pacote nao reconhe ca a
op cao; C (1 bit) Informa se a op cao pode ou nao ser alterada em algum roteador
intermediario; e Number (5 bits)- Indica o n umero correspondente a determinada
op cao (C).
O cabe calho Destination options e usado em campos que so precisam ser interpretados no
host de destino. Na versao inicial do IPv6, as unicas op coes denidas sao op coes nulas para
preencher esse cabe calho ate formar um m ultiplo de oito bytes; portanto, ele nao sera utilizado
inicialmente. Esse campo foi includo para garantir que o novo software de roteamento e de host
podera trata-lo, no caso de alguem imaginar uma op cao de destino algum dia. Muito parecido
com o campo Hop-by-hop em sua forma ja que contem os campos Next Header, Length e
Options.
O cabe calho Routing lista um ou mais roteadores que devem ser visitados no caminho ate
o destino. Ele e muito semelhante ao roteamento livre do IPv4, no fato de todos os endere cos
listados terem de ser visitados em ordem; porem, outros roteadores nao-listados tambem podem
ser visitados. O formato do cabe calho de roteamento e mostrado na gura 3.2.
31
IPv6 Peretto, L.M.
Figura 3.2: O cabe calho de extensao Routing
O cabe calho Authentication consiste nos seguintes campos:
Next Header. 8 bits. Identica o tipo de cabe calho que segue imediatamente depois.
Length. 8 bits. Comprimento do campo de autentica cao.
Routing Type. 8 bits. Fornece o formato do restante do cabe calho. Se ele nao for
compreensvel por algum equipamento roteador no caminho, o datagrama sera descartado.
Segment Left. 8 bits. Controla quantos endere cos da lista ainda nao foram visitados. Ele
e decrementado toda vez que um endere co e visitado. Quando chega a 0, o pacote ca
sem nenhuma orienta cao adicional sobra qual rota seguir. Em geral, a essa altura ele esta
tao perto do destino que a melhor rota e evidente.
Reserved. Indenido. Uso reservado, setado seu valor em 0.
O cabe calho Fragmentation lida com a fragmenta cao da mesma maneira que o IPv4. O
cabe calho contem o identicador do datagrama, o n umero do fragmento e um bit que informa
se havera novos fragmentos em seguida. No IPv6, ao contrario do IPv4, apenas o host de origem
pode fragmentar um pacote. Os roteadores ao longo do caminho nao podem faze-lo. Embora
represente uma grande ruptura losoca com o passado, esse recurso simplica o trabalho dos
roteadores e faz com que o roteamento seja mais rapido. Como ja dissemos, se um roteador
for confrontado com um pacote muito grande, ele o descartara e enviara um pacote ICMP de
volta à origem. Tais informa coes permitem que o host de origem utilize esse cabe calho para
fragmentar o pacote em peda cos menores e tentar outra vez.
32
IPv6 Peretto, L.M.
Figura 3.3: O cabe calho de extensao Fragmentation
Descri cao do cabe calho:
Next Header. 8 bits. Indica o tipo do proximo cabe calho.
Reserved. Indenido. Reservado para op coes futuras.
Fragment Oset. 13 bits. Indica a ordem do fragmento no pacote.
M (More Fragments). 1 bit. Caso esta op cao esteja setado em 1, indica que ainda restam
fragmentos e 0 indica que e o ultimo pacote do fragmento.
Identication. 32 bits. Indica a que pacote pertence o fragmento.
O cabe calho Authentication e uma extensao de cabe calho que prove autentica cao e integri-
dade (sem condencialidade) para datagramas IPv6, pelo qual o receptor de um pacote pode ter
certeza de quem o enviou. Enquanto a extensao e um algoritmo independente e suporta varias
tecnicas diferentes de autentica cao, foi proposto o uso de chaves MD5 (Message Digest 5) para
garantir a interoperabilidade na Internet. Este mecanismo pode ser usado para eliminar varios
tipos de ataques, inclusive spoof de IP. A inclusao de tal mecanismo na rede pode ser util para
os protocolos das camadas superiores no processo de autentica cao da origem. Este mecanismo
pode ser exportado pelos E.U.A. e por outros pases que possuem as mesmas restri coes de ex-
porta cao, uma vez que ele prove somente autentica cao e integridade e nao condencialidade.
Isto encoraja o desenvolvimento e divulga cao do IPv6 Authentication Header. O cabe calho
Authentication consiste nos seguintes campos:
Next Header. 8 bits. Identica o tipo de cabe calho que segue imediatamente depois.
Length. 8 bits. Comprimento do campo de autentica cao em palavras de 32 bits.
Reserved. 16 bits. Para uso futuro.
Security Parameters Index. 32 bits. Identica a associa cao de seguran ca.
Authentication Data. 32 bits. Possui valor variavel.
A segunda op cao de seguran ca disponvel e o Encapsulating Security Header. Este
mecanismo prove integridade e condencialidade para os datagramas IPv6. Ele e mais sim-
ples que alguns protocolos de seguran ca similares (Ex.: SP3D, ISO, NLSP), possui exibilidade
e independencia de algoritmo. Para prover interoperabilidade na Internet, o algoritmo padrao
utilizado e o DES (Data Encryption Standard) com chaves de 56 bits.
33
IPv6 Peretto, L.M.
Figura 3.4: O cabe calho de extensao Authentication
3.0.2 Endere camento
A amplia cao de 32 bits do endere co IPv4 para 128 bits no endere co IPv6 e uma das mais
importantes caractersticas do novo protocolo.

E um imenso espa co de endere camento, com
um n umero difcil de ser apresentado (2
128
), porque sao milhares de bilhoes de endere cos. O
IPv6 acaba ainda com as classes de endere cos e possibilita um metodo mais simples de auto-
congura cao.
O endere co IPv6 e representado atraves de tres formas diferentes. A nota cao mais usual e
x:x:x:x:x:x:x:x, onde os x sao n umeros hexadecimais, ou seja, o endere co e dividido em oito
partes de 16 bits, como no seguinte exemplo:
1080:0:0:0:8:800:200C:417A
De todo espa co de endere camento IPv6, apenas 15% esta previamente alocado para uso,
mostrado na tabela 3.3 a seguir, cando os 85% restantes reservados para o futuro. Como
apresentado a seguir, na forma abreviada, as sequencias de zeros podem ser substitudas pela
string ::. No entanto, esta substitui cao so pode ser feita uma unica vez em cada endere co. A
tabela abaixo 3.2 mostra alguns exemplos na forma completa e na forma abreviada:
Endere co Representacao Completa Representacao Abreviada
Unicast 1080:0:0:0:8:800:200C:417A 1080::8:800:200C:417A
Multicast FF01:0:0:0:0:0:0:43 FF01::43
Loopback 0:0:0:0:0:0:0:1 ::1
Unspecied 0:0:0:0:0:0:0:0 ::
Tabela 3.2: Representa cao de endere cos IPv6
A terceira forma de representa cao, mais conveniente quando em ambientes mistos com nodes
IPv4 e IPv6, e da forma x:x:x:x:x:x:d:d:d:d, onde os x sao n umeros hexadecimais (16 bits)
e os d sao valores decimais de 8 bits referentes à representa cao padrao ja bem conhecida do
IPv4. Por exemplo:
0:0:0:0:0:0:192.168.20.30
34
IPv6 Peretto, L.M.
0:0:0:0:0:FFFF:172.17.10.40
ou, na forma abreviada:
::192.168.20.30
::FFFF:172.17.10.40
Esta forma de nota cao sera bastante util durante a migra c ao do IPv4 para o IPv6 e na
coexistencia entre ambos. Ha ainda uma outra nota cao importante, a que se refere à repre-
senta cao textual dos prexos e que e similar à nota cao CIDR do IPv4: endere co/prexo, ou
seja, o prexo representa a sub-rede a qual o endere co pertence. Por exemplo, considerando
um prexo de 60 bits sendo 12AB00000000CD3 em hexadecimal, as seguintes representa coes
sao validas:
12AB:0:0:CD3:0:0:0:0/60
12AB::CD3:0:0:0:0/60
12AB:0:0:CD3::/60
Especicamente, o prexo denido pelos primeiros bits do endere co indica cada tipo de en-
dere co IPv6. O campo variavel que compreende esses bits e denominado Format Prex. A
aloca cao de todo espa co de endere camento, e apresentada pela seguinte tabela:
Foi tambem eliminada a antiga aloca cao de endere cos Unicast Geographic-based apresentada
pela RFC 1883, referente a uma faixa de endere cos que seriam distribudos geogracamente.
Os endere cos IPv6 Unspecied, Loopback, e Embedded IPv4, apresentados a seguir, sao
alocados fora do espa co de endere camento do prexo 0000 0000. Tambem todos os Format
Prex de 001 ate 111, exceto os endere cos Multicast (1111 1111), devem ter identicadores de
interface de 64 bits no formato EUI-64.
Na arquitetura de endere camento IPv6, ha 3 tipos de endere cos: Unicast, Multicast e Any-
cast. Os endere cos do tipo Broadcast foram abolidos da arquitetura, mas essa funcionalidade
e provida pelos endere cos Multicast. Endere cos de qualquer tipo podem ser assinalados a uma
interface, e uma unica interface pode compartilhar mais de um endere co que tambem podem
ser de qualquer tipo.
35
IPv6 Peretto, L.M.
Aloca c ao Prexo (binario) Fracao do Espaco
de Enderecamento
Reservado 0000 0000 1/256
Nao Alocado 0000 0001 1/256
Reservado para Aloca cao NSAP 0000 001 1/128
Reservado para Aloca cao IPX 0000 010 1/128
Nao Alocado 0000 1/128
Aggregatable Global Unicast Address 001 1/8
Nao Alocado 010 1/8
Nao Alocado 011 1/8
Nao Alocado 100 1/8
Nao Alocado 101 1/8
Nao Alocado 110 1/8
Nao Alocado 1111 0 1/32
Nao Alocado 1111 10 1/64
Nao Alocado 1111 110 1/128
Nao Alocado 1111 1110 0 1/512
Site-local Unicast Address 1111 1110 10 1/1024
Link-local Unicast Address 1111 1110 11 1/1024
Multicast Address 1111 1111 1/256
Tabela 3.3: Aloca cao do espa co de endere camento
3.0.2.1 Enderecos Unicast
Identica uma unica interface. Um pacote destinado a um endere co unicast e enviado
diretamente para a interface associada ao endere co. Foram denidos alguns tipos de endere cos
unicast, que sao:
Aggregatable Global Unicast Addresses: e o endere co unicast que sera globalmente utilizado
na Internet. Seu novo formato possui sete campos: o prexo de 3 bits (001), um identicador
TLA (Top-Level Aggregation), um campo RES reservado, um identicador NLA (Next-Level
Aggregation), um identicador SLA (Site-Level Aggregation) e o identicador da interface:
Observe que, no formato inicial, a RFC 1883 indicava um NLA de 32 bits. Agora, o NLA foi
reduzido para 24 bits, e foi criado um espa co reservado de 8 bits. A sub-se cao 3.0.2.4 apresenta
detalhes dessa hierarquia de endere cos.
Unspecied Address: denido como 0:0:0:0:0:0:0:0 ou ::, indica a ausencia de um endere co
e nunca devera ser utilizado em nenhum no. Um exemplo seria sua utiliza cao como endere co
36
IPv6 Peretto, L.M.
de origem (Source Address) de esta coes ainda nao inicializadas, ou seja, que ainda nao tenham
aprendido seus proprios endere cos. Alem disso, esse tipo de endere co nao deve ser utilizado
como Destination Address ou num cabe calho de roteamento de pacotes IPv6;
Loopback Address: representado por 0:0:0:0:0:0:0:1 ou ::1. Pode ser utilizado apenas
quando um no envia um datagrama para si mesmo. Nao pode ser associado a nenhuma interface
fsica, nem como Source Address, nem como Destination Address, mas pode ser imaginado como
sendo de uma interface virtual (loopback). Nao deve ser utilizado Source Address de pacotes
enviados. Um pacote IPv6 com Destination Address de loopback tambem nao deve deixar o no
e nunca ser repassado por um roteador IPv6;
Embedded IPv4 Addresses: trata-se de um endere co IPv6 com um IPv4 embutido, tambem
denominado IPv4-compatible IPv6 Address.

E formado anexando-se um prexo nulo (96 bits
zeros) a um endere co IPv4 como, por exemplo, ::172.16.25.32. Este tipo de endere co foi includo
como mecanismo de transi cao para hosts e roteadores.
NSAP Address: endere co de 121 bits identicado pelo prexo 0000001, denido pela RFC
1888 como mecanismo de suporte para endere camento OSI NSAP (Network Service Access
Point) em redes IPv6;
IPX Address: endere co de 121 bits identicado pelo prexo 0000010, includo para prover
mecanismo de mapeamento de endere cos IPX em endere cos IPv6. Os endere cos IPX (Internal
Packet Exchange) sao utilizados em redes Netware;
Local-Use IPv6 Address: ha dois de endere cos para uso local, Link-local e Site-local, que sao
descritos abaixo:
Link-local : endere co identicado por um prexo de 10 bits (1111111010), denido para
uso interno num unico enlace para fun coes como auto-congura cao de endere cos, neighbor
discovery ou quando nao ha roteador. Esta coes ainda nao conguradas, ou com um
endere co global unicast ou com um site-local, poderao utilizar um endere co link-local. Os
roteadores nao devem repassar pacotes com Source Address ou Destination Address deste
tipo;
Site-local : endere co identicado pelo prexo de 10 bits (1111111011), denido para uso
interno numa organiza cao que nao se conectara à Internet, e nao ha necessidade de uso
de um prexo global. Os roteadores nao devem repassar pacotes cujos Source Address ou
Destination Address sejam endere cos site-local.
3.0.2.2 Enderecos Multicast
Este endere co identica um grupo de interfaces ou um grupo de nos. No entanto, um pacote
destinado a um endere co multicast e enviado para todas as interfaces do grupo. Um no pode
pertencer a mais de um grupo multicast.
As funcionalidades de multicasting foram formalmente incorporadas ao IPv4 em 1988, com
a deni cao dos endere cos classe D e do IGMP e ganhou for ca com o advento do MBone (Multi-
37
IPv6 Peretto, L.M.
casting Backbone), mas seu uso ainda nao e universal. Desta vez, estas funcionalidades foram
automaticamente incorporadas ao IPv6. Isto signica que nao sera mais necessario implementar
t uneis MBone, pois todos os hosts e roteadores IPv6 deverao suportar multicasting nativamente.
Os endere cos multicast tem o seguinte formato:
Figura 3.5: Formato do endere co Multicast
Ou seja, todo endere co iniciado por 1111 1111 (ou FF) e um endere co multicast. O campo
gs tem o formato 000T. T=0, indica um endere co multicast permanentemente (well-know)
alocado. T=1 indica um endere co temporario. Ja o campo scop limita o escopo dos endere cos
multicast e assume alguns valores representando endere cos multicast no-local, site-local, link-
local, organization-local, global, etc. Ha varios endere cos multicast ja alocados para algumas
aplica coes, outros reservados e algumas faixas ainda nao alocadas.
3.0.2.3 Enderecos Anycast
Igualmente ao endere co multicast, identica um grupo de interfaces de nos diferentes, to-
davia um pacote destinado a um endere co anycast e enviado somente para uma das interfaces
identicadas pelo endere co do grupo. Especicamente, o pacote e enviado para a interface mais
proxima de acordo com a medida de distancia do protocolo de roteamento.
Os endere cos anycast sao alocados no mesmo espa co de endere camento unicast, utilizando
qualquer um dos formatos dos endere cos unicast. Assim, ambos os tipos de endere cos nao
sao distinguveis sintaticamente. Quando um endere co unicast e congurado em mais de uma
interface num mesmo no, ele se torna um endere co anycast e o no deve ser explicitamente
congurado para reconhecer este endere co.
Um dos possveis uso deste tipo de endere co seria identicar o grupo de roteadores perten-
centes a um provedor Internet. Ou entao, identicar um conjunto de roteadores conectados a
uma sub-rede, ou ainda identicar os roteadores provendo entrada para um domnio de rotea-
mento especco. Na pratica, a experiencia com endere cos anycast na Internet ainda e muito
incipiente e existem algumas complica coes no uso generalizado desse endere co. Por isso, ate
que se adquira mais experiencia e as solu coes resolvam tais problemas, as seguintes restri coes
sao impostas:
Um endere co anycast nao pode ser utilizado como Source Address de qualquer pacote
IPv6;
Um endere co anycast nao pode ser congurado num host IPv6, ou seja, ele so pode ser
associado a roteadores.
38
IPv6 Peretto, L.M.
Foi pre-denido um formato para os endere cos anycast, denominado subnet-router anycast
address. O prexo de sub-rede no endere co identica um link especco. Este endere co anycast
e sintaticamente o mesmo endere co unicast, so que com os bits do identicador da interface
zerados.
Pacotes enviados para um endere co subnet-router anycast serao entregues a um roteador na
sub-rede. Todos os roteadores devem suportar endere cos deste tipo para as sub-redes nas quais
possuam interfaces.
3.0.2.4 Hierarquia de Enderecamento
Os endere cos IPv6 unicast foram projetados assumindo que os sistemas de roteamento
da Internet repassam pacotes baseado num algoritmo de calculo do prexo mais longo, sem
nenhum conhecimento da estrutura interna do endere co IPv6. O tipo especco de endere co
IPv6 e indicado pelos primeiros bits do endere co. Como mostrado anteriormente, o campo
variavel que compreende estes bits e denominado Format Prex.
Dentre os tipos de endere cos unicast apresentados anteriormente, foram apresentados os
endere cos Aggregatable Global Unicast Addresses a serem globalmente utilizados na Internet e
denidos pelo formato de prexo (FP = 001) para suportar a agrega cao provider-based, denida
inicialmente pela RFC 1884, e um novo tipo de agrega cao denominada como exchange-based.
Esta combina cao permitira uma agrega cao eciente de rotas, tanto para sites conectados a
provedores, quanto para aqueles conectados aos pontos de troca de trafego (exchanges). A
estrutura destes endere cos pode ser vista na gura 3.6:
Figura 3.6: Formato do endere co Unicast
FP (Format Prex). 3 bits. Neste caso igual a 001;
TLA ID Identicador Top-Level Aggregation. 13 bits. Os identicadores TLA sao o
topo da hierarquia de roteamento. Este formato suporta 8.192 identicadores TLA, que
podem ser aumentados atraves do aumento do tamanho do campo TLA, utilizando os bits
reservados do campo RES, ou utilizando um prexo de formato adicional. Os roteadores
default-free devem ter uma entrada na tabela de roteamento para cada TLA ID ativa, e
podem ter entradas adicionais para otimizar o roteamento de suas topologias especcas.
Mas, em todos os nveis, a topologia de roteamento deve ser projetada para minimizar a
quantidade de entradas na tabela de roteamento.
RES. 8 bits. Reservado para uso futuro, deve ter todos os bits zerados;
39
IPv6 Peretto, L.M.
NLA ID. Identicador Next-Level Aggregation. 24 bits. Os identicadores NLA sao uti-
lizados pelas organiza coes que possuam um TLA ID para criar uma estrutura de en-
dere camento hierarquica e identicar sites. Cada organiza cao que recebe um TLA ID
tem um espa co de endere camento de 24 bits de espa co NLA, ou seja, 16.777.216 de en-
dere cos. O que torna possvel dizer que cada organiza cao recebe aproximadamente a
mesma quantidade de endere cos que toda atual Internet IPv4 pode suportar. Supondo,
entao, uma distribui cao plana de todo espa co NLA, teramos uma tabela de rotas com
aproximadamente 16 milhoes de entradas. Da a importancia de se hierarquizar o en-
dere camento para minimizar a tabela de rotas e otimizar o roteamento.
SLA ID Identicador Site-Level Aggregation. 16 bits. O identicador SLA e utilizado
por uma organiza cao individual, que e responsavel por denir a estrutura de endere cos
do espa co SLA. Dentro deste espa co, a organiza cao pode criar localmente sua propria
estrutura de endere camento hierarquica, num procedimento similar às divisoes em sub-
redes do IPv4, so que com um n umero muito maior de sub-redes. A exemplo do esquema
apresentado no NLA, a organiza cao possuidora do SLA pode decidir utilizar uma estrutura
plana, aumentando as tabelas de rotas, ou denir uma estrutura hierarquica.
Interface ID. 64 bits. Os Interface ID, como o proprio nome indica, sao utilizados para
identicar interfaces de um enlace especco e devem ser unicos para esse link. Tambem
devem ser unicos num escopo mais abrangente. Em muitos casos, o identicador de
interface sera o endere co de interface da camada de enlace ou obtido a partir deste. Para
os endere cos aggregatable global unicast, os identicadores de interface de 64 bits devem
ser construdos no formato IEEE EUI-64. Estes identicadores podem ter um escopo
global quando formados a partir de registros de escopo global, como e o caso dos MAC
Address de 48 bits denidos pelo IEEE; ou um escopo local quando n ao existirem tais
registros.

E o caso das conexoes seriais ponto-a-ponto. Para cada RFC que dene o
protocolo IPv6 sobre algum enlace especco, como IPv6 sobre Ethernet ou IPv6 sobre
FDDI, ha procedimentos para forma cao do Interface ID.
Em termos de topologia, essa estrutura permite uma organiza c ao em tres nveis hierarquicos:
p ublica, site e identicador de interface. A topologia p ublica (campos TLA, RES, e NLA)
reetem o conjunto de provedores de servi cos Internet, provedores de transito e pontos de troca
de trafego. A topologia site (campos SLA) tem abrangencia local, uma organiza cao especca
que nao prove servi cos de transito para outras organiza coes ou sites. Ja o identicador de
interface (campos Interface ID), como o proprio nome indica, identica a interface do no.
Muitas das compara coes entre os protocolos IPv4 e IPv6 se focam no tamanho dos endere cos
permitidos pelos dois (32 versus 128 bits). No entanto, como tem mostrado a experiencia com o
atual protocolo IPv4, nao basta simplesmente aumentar a quantidade de endere cos disponveis.
E necessario organizar o espa co de endere camento de forma hierarquica, com o objetivo de

40
IPv6 Peretto, L.M.
prover a maior eciencia possvel no roteamento. Sem tal preocupa cao, o tamanho das tabelas
de rotas da Internet se tornaria tao elevado, que nao seria possvel a expansao da rede. Com isso
em mente, os projetistas do IPv6 tiveram como uma de suas principais preocupa coes criar um
espa co de endere camento que permitisse, ecientemente, o particionamento em uma hierarquia
global de roteamento.
3.0.3 Fragmentacao e Remontagem do IPv6
O IPv6 nao permite fragmenta cao e remontagem em roteadores intermediarios, essas opera coes
podem ser realizadas somente pela fonte e pelo destino. Se um datagrama IPv6 recebido por
um roteador for muito grande para ser repassado pelo enlace de sada, o roteador simplesmente
descartara o datagrama e enviara uma mensagem ICMP de erro para o remetente. O remetente
pode entao reenviar os dados usando um datagrama IP de tamanho menor. Fragmenta cao e re-
montagem sao opera coes que tomam muito tempo; remover essas funcionalidades dos roteadores
e coloca-las nos sistemas nais acelera consideravelmente o repasse do datagrama IP dentro da
rede, diminuindo dessa forma, a latencia. Para que o no de origem possa determinar qual a
menor MTU de enlace do percurso ate ao destino, e utilizada a tecnica Path MTU Discovery
descrita na RFC 1981 [18]. Normalmente, os nos que nao implementam Path MTU Discovery
usam o MTU=1280.
O cabe calho Fragmentation e usado por um remetente IPv6 para enviar pacotes maiores do
que caberiam no path MTU ate seus destinos. O cabe calho Fragmentation e identicado pelo
valor 44 do Next Header do cabe calho imediatamente precedente. Veja gura 3.3.
A m de enviar um pacote que seja tao grande para caber na MTU do caminho ate seu
destino, um no remetente pode dividir o pacote em fragmentos e enviar cada fragmento como
um pacote separado, para ser remontado na recep cao.
Para todos pacotes que sao fragmentados, o no remetente gera um valor Identication. O
Identication deve ser diferente de qualquer outro pacote fragmentado enviado recentemente
com o mesmo Source Address e Destination Address. Isto signica dentro de um tempo maximo
de vida provavel de um pacote, incluindo o tempo de transito do remetente ao destino e o
tempo gasto na espera da remontagem com outros fragmentos do mesmo pacote. Contudo, nao
e requerido que um no remetente conhe ca o tempo de vida maximo de um pacote. Ate certo
ponto, e assumido que o requerimento pode ser encontrado mantendo-se o valor Identication
como simples, 32-bit, contador wrap-around, incrementado cada vez que um pacote deva ser
fragmentado.

E uma escolha de implementa cao manter um simples contador para cada no ou
m ultiplos contadores, por exemplo, um para cada endere co de remetente possvel do no, ou uma
para cada combina cao em atividade(endere co-remetente, endere co-destino). Se um cabe calho
Routing estiver presente, o Destination Address de interesse e aquele do destino nal.
De incio, em geral, o pacote nao fragmentado e referido como o pacote original, e consiste
de duas partes, como ilustrado na gura 3.7:
41
IPv6 Peretto, L.M.
UnfragmentablePart FragmentablePart
Figura 3.7: A divisao de um datagrama a ser fragmentado
O Unfragmentable Part consiste do cabe calho IPv6 mais qualquer cabe calho de extensao
que deva ser processado pelo no durante o roteamento ate o destino.
O Fragmentable Part consiste do resto do pacote, isto e, qualquer cabe calho de extensao que
precisa ser processado apenas pelo no(s) do destino nal, mais o cabe calho da camada superior
e dados.
O Fragmentable Part do pacote original e dividido em fragmentos, cada, exceto possivel-
mente o ultimo (mais à direita), sendo um inteiro m ultiplo de 8 octetos. Os fragmentos sao
transmitidos em pacotes de fragmento como ilustrado na guras 3.8 e 3.9:
UnfragmentablePart
First
Fragment
Second
Fragment
. . .
Last
Fragment
Figura 3.8: Pacote original dividido para fragmenta cao
Unfragmentable Part Fragment First Part
Fragment Second Fragment
.
.
.
Unfragmentable Part
Unfragmentable Part Fragment Last Part
Figura 3.9: Pacotes ja fragmentados para envio
Cada pacote de fragmento e composto pelo seguinte:
O Unfragmentable Part do pacote original, com o Payload Length do cabe calho IPv6
original trocado para conter o tamanho deste pacote de fragmento apenas(excluindo o
tamanho do proprio cabe calho IPv6), e o campo Next Header do ultimo cabe calho do
Unfragmentable Part trocado para 44.
Um cabe calho Fragment contem:
O valor Next Header que identica o primeiro cabe calho do Fragmentable Part do pacote
original.
42
IPv6 Peretto, L.M.
Um campo Fragment Oset, em unidades de 8 bytes, relativos ao incio do Fragmentable
Part do pacote original. O Fragment Oset do primeiro fragmento e 0.
Valor 0 de M se o fragmento e o ultimo, para os outros, o valor de M e 1.
O proprio fragmento.
Os tamanhos dos fragmentos devem ser escolhidos tal que os pacotes de fragmento resul-
tantes caibam na MTU do caminho ate o destino do pacote. No destino, pacotes de fragmento
sao remontados ao seu original, forma nao fragmentada. As seguintes regras governam a re-
montagem:
Um pacote original e remontado apenas dos pacotes de fragmento que tem o mesmo Source
Address, Destination Address, e Fragment Identication.
O Unfragmentable Part do pacote remontado consiste de todos os cabe calhos ate, mas
nao incluindo, o cabe calho Fragment do primeiro pacote de fragmento, isto e, o pacote cujo
Fragment Oset seja zero, com as seguintes duas diferen cas:
O campo Next Header do ultimo cabe calho do Unfragmentable Part e obtido do campo
Next Header do primeiro cabe calho Fragment do fragmento.
O Payload Length do pacote remontado e computado do tamanho do Unfragmentable
Part e do tamanho e oset do ultimo fragmento.
O Fragmentable Part do pacote remontado e construdo dos fragmentos depois do cabe calho
Fragment de cada pacote de fragmento. O tamanho de cada fragmento e computado subtraindo
o Payload Length do pacote e o tamanho dos cabe calhos entre o cabe calho IPv6 e o proprio
fragmento. Sua posi cao relativa no Fragmentable Part e computada do seu valor de Fragment
Oset. O cabe calho Fragment nao esta presente no pacote remontado.
As seguintes condi coes de erro podem surgir quando os pacotes fragmentados sao remonta-
dos:
Se insucientes fragmentos sao recebidos para a completa remontagem de um pacote den-
tro de 50 segundos da recep cao da do primeiro fragmento daquele pacote, a remontagem
do pacote deve ser abandonada e todos os fragmentos daquele pacote que foram rece-
bidos devem ser descartados. Se o primeiro fragmento, isto e, aquele cujo o Fragment
Oset e zero foi recebido, uma mensagem ICMP Time Exceeded devera ser enviada para
o remetente daquele fragmento.
Se o tamanho de um fragmento, como derivado do campo Payload Length do pacote de
fragmento, nao e um m ultiplo de 8 octetos e o campo M daquele fragmento e 1, entao
aquele fragmento deve ser descartado e uma mensagem ICMP Parameter Problem, Code
0, devera ser enviada ao remetente do fragmento, indicando o campo Payload Length do
pacote de fragmento.
43
IPv6 Peretto, L.M.
Se o tamanho e o oset de um fragmento sao tal que o Payload Length do pacote re-
montado daquele fragmento excederia os 65.535 octetos, ent ao aquele fragmento deve ser
descartado e uma mensagem ICMP Parameter Problem, Code 0, devera ser enviada ao
remetente do fragmento, indicando o campo Fragment Oset do pacote de fragmento.
As seguintes condi coes nao sao esperadas, mas nao sao consideradas erros se ocorrerem:
O n umero e conte udo dos cabe calhos precedentes ao cabe calho Fragmentation de
diferentes fragmentos do mesmo pacote original podem diferir. Qualquer cabe calho pre-
sente, precedentes ao cabe calho Fragmentation em cada pacote de fragmento, serao pro-
cessados na chegada do pacote, antes do enleiramento dos fragmentos para a remon-
tagem. Apenas aqueles cabe calhos no pacote de Fragment oset zero sao conservados no
pacote remontado.
Os valores do Next Header no cabe calho Fragmentation de diferentes fragmentos do
mesmo pacote original podem diferir. Apenas o valor do pacote de Fragment oset zero
e usado na remontagem.
3.0.4 Diferencas entre o IPv6 e IPv4
As mudan cas mais importantes introduzidas no IPv6 cam evidentes no formato do pacote.
Dentre as novas caractersticas e funcionalidades do IPv6, pode-se citar:
Endere cos de 128 bits capazes de prover uma imensa quantidade de hosts. Este espa co
de endere camento deve ser suciente por muitos anos;
Simplica cao do cabe calho, permitindo um aumento na eciencia do mecanismo de rotea-
mento e processamento dos pacotes;
Cabe calho xo de 40 bytes. Uma serie de campos IPv4 foi descartada ou cou opcional.
O cabe calho de comprimento xo de 40 bytes resultante permite processamento mais
veloz do datagrama IP, principalmente nos roteadores intermediarios (Backbone). Uma
nova codica cao de op coes permite um processamento de op coes mais exvel.
Flexibilidade para a utiliza cao de op coes atraves do uso de cabe calhos de extensao capazes
de prover um conjunto de novas caractersticas ao datagrama;
Todos os campos relacionados à fragmenta cao foram removidos, porque o IPv6 da um
tratamento diferente à fragmenta cao. Para come car, todos os hosts e roteadores com-
patveis com o IPv6 devem determinar dinamicamente o tamanho do datagrama que sera
usado. Essa regra diminui a probabilidade de ocorrer fragmenta cao. O valor mnimo
tambem foi elevado de 576 para 1.280, a m de permitir o uso de 1.024 bytes de dados
e muitos cabe calhos. Alem disso, quando um host enviar um pacote IPv6 muito grande,
44
IPv6 Peretto, L.M.
o roteador que nao puder encaminha-lo enviara de volta uma mensagem de erro em vez
de fragmenta-lo. Essa mensagem instrui o host a dividir todos os novos pacotes enviados
a esse destino. Na verdade, e muito mais eciente obrigar o host a enviar pacotes com
tamanho exato que solicitar que os roteadores os fragmentam automaticamente.
O campo Checksum foi eliminado, porque esse calculo reduz de forma signicativa o
desempenho. Com as redes conaveis usadas atualmente, alem do fato de a camada de
enlace de dados e as camadas de transporte terem seus proprios totais de verica cao, a
importancia de um novo total e insignicante, se comparada com a queda de desempenho
que ela implica.
Implementa cao de mecanismos de seguran ca nativos com o uso do IPSec, capazes de
prover condencialidade e autentica cao;
Suporte para a aloca cao de recursos e especica cao de tipos de servi co para aplica coes
de tempo-real e para aplicativos que necessitem de pre-aloca cao de recursos. A grande
questao ainda e denir o que e um uxo. O IPv6 tem uma deni c ao esquiva de uxo, a
RFC 1752 e a RFC 2460 [21] estabelecem que isso permite identica cao de pacotes que
pertencem a uxos particulares para os quais o remetente requisita tratamento especial,
tal como um servi co de qualidade nao padrao ou um servi co em tempo real. Por exemplo,
a transmissao de audio e vdeo poderia ser tratada como um uxo. Por outro lado, as
aplica coes mais tradicionais, como a transferencia de arquivos e o e-mail, poderiam nao ser
tratadas como uxos.

E possvel que o trafego carregado por um usuario de alta prioridade
(por exemplo, alguem que paga por um servi co melhor quanto ao trafego) seja tambem
tratado como uxo. O que ca claro, contudo, e que os projetistas do IPv6 preveem a
possvel necessidade de poder diferenciar os uxos, mesmo que o exato signicado de
uxo ainda nao tenha sido determinado. O cabe calho IPv6 tambem tem um campo de
8 bits para classe de trafego. Esse campo, assim como o campo ToS do IPv4, pode ser
usado para dar prioridade a certos pacotes dentro de um uxo ou a datagramas de certas
aplica coes (por exemplo, pacotes ICMP) em rela cao a datagramas de outras aplica coes
(por exemplo, notcias pela rede).
Suporte para a utiliza cao de endere cos multicast e anycast. Esta caracterstica, permite
que um pacote enviado a um endere co anycast seja entregue a qualquer host de um grupo.
(Por exemplo, para enviar uma mensagem http GET ao membro mais proximo dos sites
espelhados que contenham um dado documento.);
Implementa cao de tecnicas capazes de permitir a convivencia das duas versoes do proto-
colo IP.
Assim, o objetivo do IPv6, um protocolo a um so tempo rapido e exvel, capaz de oferecer
um grande espa co de endere cos, foi atendido por este projeto.
45
3.1 IPSec Peretto, L.M.
3.1 IPSec
O IPSec (IP Security) e uma sute de protocolos denida pelo IETF, cujo objetivo e pos-
sibilitar a utiliza cao de servi cos de autentica cao, integridade e condencialidade em pacotes.
Tais servi cos sao providos atraves de dois cabe calhos: o AH (Authentication Header), utilizado
para autenticar a origem dos dados e garantir a integridade dos mesmos ate o destino; e o
ESP (Encapsulating Security Payload), utilizado para prover condencialidade dos dados e,
opcionalmente, autentica cao e integridade. A implementa cao do IPSec no IPv6 e obrigatoria,
diferentemente do IPv4, que nao foi projetado para ser um protocolo com caractersticas de
seguran ca. Inicialmente, seu uso estava restrito a um ambiente colaborativo onde existia uma
coopera cao harmoniosa entre os usuarios. Porem, a populariza cao deste protocolo, dado seu
uso na Internet, trouxe consigo a descoberta de um conjunto de falhas de seguran ca que podem
ser exploradas por ataques que resultam desde DoS (Denial of Service) ate invasoes capazes de
comprometer um sistema inteiro.
Diversos algoritmos criptogracos podem ser utilizados pelo AH e ESP. Porem, existe um
conjunto mnimo cuja implementa cao e mandatoria. Sao eles: HMAC-MD5-96 e HMAC-SHA-
1-96 para os servi cos de autentica cao e integridade do AH e ESP; DES-CBC para a conden-
cialidade provida pelo ESP; e, algoritmos nulos de autentica cao e condencialidade utilizados
pelo ESP quando um dos seus servi cos nao e requisitado.
Para que duas entidades consigam enviar e receber pacotes utilizando os servi cos do IPSec
e necessario estabelecer uma associa cao de seguran ca (AS) que especica os algoritmos a serem
utilizados, as chaves criptogracas, os tempos de vida destas chaves, entre outros parametros.
ASs sao direcionais e so podem especicar um protocolo de seguran ca.
Existem duas maneiras para o estabelecimento de associa coes de seguran ca: estatica e
dinamica. No primeiro, os parametros sao inseridos manualmente em ambos os extremos da
comunica cao. No segundo, os parametros sao negociados por protocolos como o IKE (Internet
Key Exchange), sem qualquer interven cao do administrador.
O IPv6 foi projetado com o objetivo de solucionar os problemas e deciencias detectados
no IPv4. Em rela cao à seguran ca, a principal caracterstica do IPv6 foi a incorpora cao do
IPSec na sua especica cao. Apesar do IPSec tambem poder ser utilizado com o IPv4, ele nao
e nativo neste protocolo e, portanto, sua utiliza cao transparente torna-se inviavel, dado o alto
custo das modica coes em muitas implementa coes. Os servi cos providos pelo IPSec, atraves
dos cabe calhos AH e ESP, podem ser utilizados para resolver parte dos problemas de seguran ca
do IPv4.
Apesar do projeto do IPv6 ter sido norteado pela necessidade de corre cao das fragilidades
do IPv4, e razoavel pensar que novas fragilidades deverao ser evidenciadas.
Apesar do IPSec estar presente como parte integrante do IPv6, o seu uso nao e obrigatorio.
Desta forma, utilizar o IPv6 sem os servi cos do IPSec, torna-o vulneravel a diversos ataques ja
conhecidos do IPv4 e a ataques que podem ser desenvolvidos a partir dos novos mecanismos
46
3.1 IPSec Peretto, L.M.
utilizados pelo IPv6. Por exemplo, o Router Discovery, denido como parte do ICMPv6 possi-
bilita que roteadores sinalizem sua presen ca para os hosts presentes no mesmo trecho de rede
atraves da mensagem ICMP Router Advertisement. Tais mensagens podem conter parametros
como o Hop Limit maximo a ser utilizado pelos hosts e o tempo em que cada host deve utilizar
o roteador como default. Este processo e susceptvel a um conjunto de ataques quando nao
utiliza a autentica cao do pacote IP.
O IPSec pode ser utilizado de diversas maneiras, com o AH ou ESP, ou ambos. Alem disso,
as AS podem ter granularidade distintas. Por exemplo, da mesma forma que uma unica AS
pode ser utilizada para proteger todos os dados entre dois hosts, uma AS pode ser requisitada
para cada conexao ou ainda para cada usuario. Um caso especial do uso do IPSec e quando se
utilizam somente ESP e ASs baseadas em host. Neste caso, as chaves criptogracas dos hosts
sao xas para toda a comunica cao entre eles.
Os Extension Header possuem uma ordem especca de encadeamento, porem as imple-
menta coes devem estar preparadas para processa-los em qualquer ordena cao. Ataques volta-
dos para erros de implementa cao podem ser desenvolvidos atraves do envio de pacotes com
cabe calhos em ordens diversas contendo cabe calhos duplicados, entre outros, na tentativa
de descobrir problemas na pilha IPv6, como buer, overow ou crashes. Em rela cao à es-
pecica cao, fragilidades poderao ser exploradas quando novas op coes foram denidas para os
cabe calhos Hop-by-Hop Options e Destination Options. Em tais cabe calhos, existem op coes
cujos valores sao alterados em transito e, portanto, nao entram no checksum gerado pelo AH.
Desta forma, pode ser possvel capturar pacotes, alterar os valores de tais op coes ou, ate mesmo,
substituir por outras op coes, provocando efeitos ainda nao conhecidos.
O IPSec suporta a utiliza cao de diversos algoritmos criptogracos com o AH e ESP. Porem,
o conjunto obrigatorio nao e suciente para prover seguran ca adequada a todos os tipos de
informa cao. Estudos tem mostrado que particularidades do MD5 permitem acelerar o processo
para gerar mensagens que produzam o mesmo hash utilizando maquinas de baixo custo. Em
rela cao ao DES, o tamanho da chave utilizada, 56 bits, e, atualmente, vulneravel a ataques
de for ca-bruta tornando-o inadequado para preservar informa coes cujo sigilo e de extrema sig-
nicancia. A implementa cao de outros algoritmos pode ser util somente entre sistemas isolados.
Se algoritmos mais seguros nao estao padronizados, nem todas as implementa coes os conterao.
Alem disso, o IPSec nao possui diferencia cao entre quais algoritmos utilizar para a comunica cao
de diferentes servi cos. A escalabilidade do IPSec esta relacionada ao estabelecimento dinamico
de ASs que devem ser denidas por conexao ou, no maximo, por usu ario, para prover maior se-
guran ca. Abusar, intencionalmente, do mecanismo de estabelecimento de ASs, pode constituir
diversos ataques de DoS. Como o IPSec e fundamental para a seguran ca do IPv6, e de extrema
importancia encontrar solu coes para prevenir tais possibilidades.
O desenvolvimento do IPv6 visa adaptar este protocolo à novos requisitos da Internet con-
temporanea nao contemplados na sua versao anterior. Porem, apesar de impedir um conjunto de
vulnerabilidades exploradas no IPv4 ao longo dos anos, o IPv6 certamente nao e uma panaceia
47
3.2 MIPv6 Peretto, L.M.
para a camada de rede. O uso de algoritmos criptogracos por parte do IPSec, nativo no IPv6,
pode provocar uma falsa sensa cao de seguran ca. O transporte seguro de pacotes nao e capaz
de imunizar fragilidades em aplica coes nem tampouco proteger contra falhas decorrentes da
administra cao de um sistema. Outros esfor cos neste sentido vem sendo empenhados no intuito
de viabilizar a utiliza cao deste protocolo que, certamente, ira servir como um dos alicerces para
a manuten cao da Internet nas proximas decadas.
3.2 MIPv6
Atualmente, ja convivemos com alguma mobilidade provida por protocolos das camadas
fsicas e de enlace de dados. Um bom exemplo disto e o ja popular IEEE 802.11. Contudo, a
mobilidade, neste caso, existe apenas em ambito local, sendo impossvel que uma unidade movel
se desloque entre redes diferentes, conservando, portanto, sua congura cao de rede inalterada
durante a movimenta cao.
O MIP (Mobile IP), por outro lado, possibilita que um no movel passe de uma rede para
outra sem que as conexoes ou sessoes estabelecidas sejam interrompidas e permitindo que
outras novas sejam estabelecidas. O grande desao da mobilidade IP e evitar que conexoes,
cuja parametriza cao do socket atrela o endere co IP do movel local, sejam quebradas no evento
de uma movimenta cao.
Atualmente, sobretudo como resultado do desenvolvimento dos diferentes padroes para co-
munica cao em redes wireless, do surgimento de equipamentos portateis com mais recursos
computacionais e da utiliza cao de tecnicas de compressao e transmissao capazes de trazer um
signicativo aumento na banda disponvel na interface aerea, ha uma forte pressao de usuarios
e fornecedores de servi cos de telecomunica coes por recursos que ofere cam suporte nativo na
camada de rede à mobilidade. Alem disto, mobilidade IP esta sendo vista como a melhor forma
de interconectar as diferentes tecnologias de redes wireless, entre si e com as tradicionais redes
com o.
Usuarios moveis podem fazer uso da mobilidade IP e de redes sem o para trabalhar de
forma transparente em locais remotos, sem necessidade de conexao fsica com cabos, acessando
recursos de sua rede local. O MIP permite que pessoas possam realizar atividades como ler e
responder seus e-mails, acessar servidores internos, buscar informa coes na Internet etc.
Em rela cao à funcionalidade de encaminhamento, o protocolo IP roteia pacotes de um ponto
de origem a um ponto de destino atraves de roteadores, que recebem pacotes por interfaces de
entrada e os encaminham para interfaces de sada, de acordo com tabelas de roteamento. As
tabelas de roteamento, tipicamente, mantem a informa cao do next-hop para cada endere co IP
destino, de acordo com o n umero de rede ao qual o endere co IP esta conectado. Basicamente,
este e o funcionamento da camada de rede. Analisando, agora, uma aplica cao de rede, esta
contem em seu codigo a abertura de um socket, que e a associa cao de um endere co de origem
e porta de origem, com um endere co de destino e porta de destino. Isto garante que a camada
48
de rede envie os dados da aplica cao corretamente quando os pacotes chegarem à maquina
de destino. Imagine que um dispositivo movel inicie, por exemplo, um FTP e, no meio da
transmissao, o no movel mude de rede. Para manter a conexao FTP na camada de transporte,
e preciso manter o mesmo endere co IP. Mudando o endere co IP, a conexao e desfeita. Por outro
lado, a entrega de pacotes para o ponto de conexao corrente do no movel depende do n umero de
rede contido em seu endere co IP. Quando o no movel muda de rede, recebera um novo endere co
IP e isto signica que havera uma mudan ca no roteamento dos pacotes enviados a ele.
O Mobile IP, permite que um no movel se mova de uma rede a outra sem quebrar uma
conexao. Isto signica que o endere co original (home address) nunca se modica. O no movel
pode estar em qualquer lugar, que os pacotes serao roteados corretamente para ele atraves
de mecanismos apropriados. O movimento e, desta forma, transparente para a camada de
transporte e para aplica coes que usam o protocolo TCP/IP e Mobile IP.
O home address e constitudo de um prexo valido no link de sua rede original (home
network).

E atraves deste endere co que um no correspondente ira se comunicar com o no
movel, independente de onde este estiver. Quando o no movel muda de rede, ele mantem o
home address e recebe outro endere co, o care-of address, constitudo de um prexo valido em
uma rede estrangeira. Este endere co e conseguido de forma stateless ou stateful, (sem ou com
servidor de endere cos, respectivamente). Desta forma, o no m ovel tera um home address e um
ou mais care-of address quando esta se movendo entre redes.
Para que seja possvel saber onde o no movel se encontra, uma associa cao entre home address
e care-of address deve ser realizada (binding). Esta associa cao do care-of address e feita pelo no
movel, no home agent. Esta associa cao e realizada atraves de um binding registration, onde o no
movel envia mensagens chamadas Binding Updates para o home agent, que responde com uma
mensagem Binding Acknowledgement. Os nos correspondentes no MIP possuem inteligencia
para a otimiza cao de rota, ou seja, eles podem armazenar bindings entre home address e care-
of address de nos moveis. Sendo assim, um no movel pode fornecer informa coes sobre sua
localiza cao.
O Mobile IP pode trazer serios problemas à seguran ca, caso nao seja implementado de forma
adequada. A autentica cao do no movel e imprescindvel. Imagine quantos problemas voce teria
se alguem mal intencionado zesse, remotamente, um registro em um home agent da sua rede
local. Ele poderia sobrepujar as regras do seu rewall e explorar vulnerabilidades dentro da
rede interna. Alem disto, diversos tipos de ataques poderiam ser facilmente implementados; a
internet se tornaria um grande parque de diversoes para hackers.

E importante, portanto,
que uma solu cao seja, pelo menos, tao segura quanto o protocolo IP original, sem o recurso de
mobilidade.
49
A gura 3.10 apresenta a arquitetura Mobile IP.
Figura 3.10: Arquitetura Mobile IP
A opera cao do Mobile IP pode ser brevemente descrita pelos seguintes passos:
1. Os agentes de mobilidade (home agent e foreign agent) anunciam suas presen cas atraves
de mensagens chamadas Agent Advertisement;
2. Estas mensagens podem, opcionalmente, ser solicitadas por agentes moveis, atraves de
mensagens chamadas Agent Solicitation;
3. Um no movel recebe estes an uncios enviados pelos agentes de mobilidade e determina se
esta em sua rede ou em uma rede estrangeira;
4. Se o no movel detecta que esta em sua rede original, ele opera sem o servi co de mobilidade.
Se ele acaba de voltar à sua rede, ele retira o registro feito anteriormente com seu home
agent, atraves de uma troca de mensagens Registration Request e Registration Reply
com o agente;
5. Quando um no movel detecta que se moveu para uma rede estrangeira, ele obtem um
care-of address naquela rede. O care-of address pode ser alocado pelo foreign agent ou
por outro mecanismo, como DHCP, por exemplo;
6. Quando o no movel esta operando fora de sua rede, ele precisa registrar seu care-of address
com seu home agent. Isso e feito atraves da troca de mensagens Registration Request e
Registration Reply;
7. Datagramas enviados para o endere co de origem do no movel (home address), por um
no correspondente, sao interceptados e tunelados pelo home agent para o care-of address,
recebidos na sada do t unel e, nalmente, entregues ao no movel;
50
8. Datagramas enviados pelo no movel sao, geralmente, entregues ao destino usando
mecanismos de roteamento padrao, nao necessariamente passando pelo home agent.
Varios dos problemas existentes no MIPv4 simplesmente nao existem em MIPv6. Mo-
bilidade em IPv6 nao oferece problemas para a ingress ltering, implementada em rewalls
e roteadores. Isto acontece porque um no movel sempre usa seu care-of address, obtido por
autocongura cao stateful ou stateless. NAT, que e basicamente um mecanismo usado para
amortizar os efeitos do limitado espa co de endere camento em IPv4, nao e mais necessario em
redes IPv6. Portanto, problemas com NAT sao exclusivos da vers ao atual do protocolo IP.
Condencialidade e integridade de dados podem ser implementadas usando o protocolo IPSec,
mandatorio no IPv6. Alem disto, IPv6 basico tenta resolver outros problemas de seguran ca
existentes em IPv4, sendo mais adequado para a atual realidade encontrada na Internet. A
gura a seguir 3.11 mostra um cenario de mobilidade IPv6 com elementos basicos:
Figura 3.11: Visao Geral do MIPv6
Em MIPv6, o home agent faz uso do protocolo Neighbor Discovery (ND), baseado no proto-
colo ICMPv6, para fazer o mapeamento entre endere cos MAC e endere cos IP. IPv6, portanto,
nao necessita do protocolo ARP para esta funcionalidade. A pergunta e: ND e mais seguro
que o protocolo ARP? Ainda nao temos uma resposta exata para esta pergunta, mas ha uma
forte tendencia de que este protocolo elimine todas as amea cas existentes no protocolo ARP.
E possvel implementar, segundo sua propria especica cao, um esquema de autentica cao para
mensagens do protocolo, usando IPSec e chaves secretas manualmente conguradas. Em con-
trapartida, isto vai de encontro a uma das principais vantagens do IPv6 em rela cao ao IPv4: a
existencia de mecanismo de autocongura cao, onde nenhuma interven cao do administrador e
necessaria para congurar os nos na rede.
O IETF tem um working group chamado MOBILEIP, responsavel pela investiga cao e
padroniza cao da mobilidade usando IPv4 e IPv6. Em rela cao ao MIPv4, a RFC 3344 descreve
detalhadamente sua opera cao, onde sao mostrados os papeis de todos os elementos envolvidos.
51
3.3 Protocolos para IPv6 Peretto, L.M.
Mostra tambem que, opcionalmente, o foreign agent pode nao ser utilizado, assim como acon-
tece no MIPv6. Porem, esta solu cao demanda um n umero IP global diferente para cada no
movel, o que pode rapidamente esgotar a quantidade de endere cos IP de uma rede estrangeira.
Alem disso, nao e resolvido o problema de triangula cao, ou seja, nao e possvel otimiza cao de
rota neste caso.
Algumas solu coes para a otimiza cao de rota no MIPv4 foram propostas, mas nao deixaram
de ser drafts e foram removidas da lista de documentos em discussao. Atualmente, segundo
palavras de Jari Arkko, um dos autores da RFC 3344, nao e foco e interesse do IETF tratar
deste assunto. Possivelmente isto se deve às discussoes para a padroniza cao do MIPv6, que ja
trata da otimiza cao e propoe solu coes melhores para seguran ca.
3.3 Protocolos para IPv6
A transi cao para o IPv6 nao e inteiramente transparente às camadas mais altas do IP. Os
endere cos IPv6 sao mais longos do que os endere cos IPv4, requerendo uma mudan ca nas es-
truturas de dados das aplica coes que utilizam-se dos endere cos IP. Consequentemente, algumas
APIs (Application Programming Interfaces) devem ser criadas para suportar IPv4 e IPv6, bem
como o recurso de poder selecionar o protocolo apropriado para cada comunica cao. No geral,
as aplica coes escritas para IPv4 necessitam ser reescritas ou ser construdo uma ponte sobre
elas para suportar IPv6. Por exemplo, Para o exemplo, o FTP, que utiliza endere cos IP em seu
protocolo, requerendo assim mudan cas nas aplica coes dos cliente e do usuarios.
3.3.1 SMTPv6
O protocolo SMTP (Simple Mail Transport Protocol ) ja foi adaptado para poder trabalhar
com o IPv6. O programa que sofreu estas adapta coes foi o Sendmail. Este programa, nas suas
mais recentes versoes (8.10.x), ja pode utilizar os recursos de uma rede IPv6, caso ela exista.
Este programa ja trabalha com a ideia de dual-stack, ou seja, quando um programa tenta
utilizar uma rede IPv6 utiliza o endere co IPv6 da interface, quando deseja utilizar a rede IPv4,
utiliza o endere co IPv4 da interface.
3.3.2 DNSv6
O DNS (Domain Name Service), e um servi co importante no que diz respeito a facilidades
do uso de aplica coes para internet: ele facilita o mapeamento de nomes em endere cos IP. O DNS
trabalha com a ideia de hierarquia para ajudar a mapear os nomes. O nome dos hosts podem
vir na forma computador.organizacao.com. O host existe dentro do domnio organiza cao.com.
Existe uma serie de servidores de nvel superior que indicam qual e o servidor responsavel
pelo domnio organiza cao.com. Quando alguem requisita o endere co host.organizacao.com, o
52
servidor de nomes superior no qual chegou o pedido repassa-o para o servidor responsavel, e
esse retorna para o requerente o endere co IP deste host, na forma de um endere co de 32 bits.
Para que este recurso trabalhe com IPv6 algumas altera coes terao que ser feitas. O DNS,
como e utilizado hoje, foi projetado para trabalhar com endere cos de 32 bits, nao podendo por
isso, retornar endere cos de 128 bits. As altera coes descritas na RFC 1886 mostram o que deve
ser feito para que o DNS possa suportar o IPv6. As altera coes podem ser resumidas da seguinte
maneira:
Cria cao de um novo tipo de recurso para grava cao, chamado de AAAA, para mapear
endere cos de 128 bits (o tipo de recurso para grava cao do IPv4 e o A).
Cria cao de um novo domnio (.IP6.int), para permitir que endere cos de hosts IPv6 possam
servir de base para que chegue ao nome do domnio que responde por eles. Este recurso
e parecido com o existente no IPv4 (.in.addr.arpa). Os servidores de DNS devem ser
revisados para localizar ou processar nao apenas endere cos IPv4, mas endere cos IPv4 e
IPv6 (caso existam).
3.3.3 HTTPv6
O servidor adaptado para trabalhar com o protocolo HTTP (Hyper Text Transport Pro-
tocol ), junto com o IPv6, e o Apache. Este programa deve ter um patch aplicado para que
ele comece a reconhecer o novo protocolo. Assim como o Sendmail, o Apache pode tambem
trabalhar com dual-stack.
Para a leitura das paginas existe uma versao adaptada para trabalhar com o IPv6 do Lynx,
um navegador que trabalha em modo terminal.
3.3.4 ICMPv6
O protocolo ICMP e usado pelos nos IP para informar condi c oes de erro e fornecer in-
forma coes limitadas (por exemplo, a resposta de eco para uma mensagem ping) a um sistema
nal. Uma nova versao do ICMP foi denida para o IPv6 na RFC 2463. Alem da reorga-
niza cao das deni coes existentes de tipo e de codigo do ICMP, o ICMPv6 adicionou novos tipos
e codigos requeridos pela nova funcionalidade do IP. Neles estao includos codigos de erro para
pacotes muito grandes e para pacotes IPv6 irreconhecveis. Alem disso, o ICMPv6 inclui a fun-
cionalidade do IGMP (Internet Group Management Protocol ). O IGMP, que e utilizado para
gerenciar a adesao ou o abandono de um host aos chamados grupos multicast, era anteriormente
um protocolo separado do ICMP no IPv4.
3.3.5 FTPv6
O FTP (File Transport Protocol ) foi um dos primeiros protocolos a serem adaptados para o
IPv6. Muitas distribui coes de sistemas operacionais ja entregam em seus pacotes de atualiza cao
53
para IPv6 um cliente de FTP ja adaptado.
Como exemplo de servidores ja adaptados, pode-se citar o WU-FTP. Este programa possui
um patch que faz com que ele comece a trabalhar com o novo protocolo, incluindo tecnologias
como dual-stack.
3.3.6 TELNETv6
O Telnet foi, sem d uvida, uma das principais adapta coes, em materia de ferramentas, para
que se pudesse trabalhar com o novo protocolo, o IPv6. Cada sistema operacional se encarregou
de produzir o seu proprio Telnet, ou seja, o daemon para funcionar como servidor do cliente
Telnet, que tambem e produzido de forma exclusiva para sistema operacional.
Atualmente, ja existem adaptadas para o IPv6 uma nova safra de programas que tem a
mesma nalidade do Telnet, como por exemplo o SSH (Security Shell ).
54
Captulo 4
Mecanismos de Transicao IPv4/IPv6
4.1 Mecanismos de Transicao
Na realidade, a Internet provavelmente ira se transformar num aglomerado complexo de
protocolos diferentes, onde IPv4 existira com IPv6 e outros protocolos padronizados. A proba-
bilidade de que o IPv6 vira a ser um dia tao prevalecente como seu predecessor esta aumentando
certamente. As razoes principais para isto sao duas. Primeiramente, o n umero de mecanismos
de transi cao propostos pelo IETF esta permitindo aos administradores de rede um trajeto
mais facil à migra cao permitindo que os nos da rede, e mais especicamente aplica coes nestes
nos, comuniquem-se com outros nos, sobre um cenario totalmente heterogeneo. Em segundo,
os domnios especializados em aplica coes com interesse de mercado, particularmente o domnio
movel, estao exigindo as caractersticas do IP que nao podem ser cumpridas pelo IPv4, tal como
uma disponibilidade maior de espa co de endere cos e uma maior facilidade de congura cao.
Supondo o sucesso eminente do IPv6, o obstaculo mais provavel estara em realizar e con-
trolar o processo de transi cao. Mesmo com uma larga disposi cao de mecanismos de transi cao
disponibilizados pelo IETF, infelizmente nao signica que o movimento simplesmente acon-
tecera. Uma quantidade grande de esfor cos focalizou em tecnicas especcas para tunneling
(4.1.3), translation (4.1.2), e outras varia coes. Nao obstante, as edi coes reais concernem agora
como este processo evolucionario ira ocorrer de forma cuja transi cao seja mais transparente
possvel e de facil gerenciamento.
Este ambiente heterogeneo, nos apresenta diferentes cenarios e consequentemente diferentes
tecnicas sao necessarias para prover a coexistencia de ambas as versoes do IP. Alguns possveis
cenarios, mais comuns, podem ser vistos na gura 4.1.
55
4.1 Mecanismos de Transicao Peretto, L.M.
Figura 4.1: Possveis cenarios IPv4/IPv6
Este documento apresenta as principais tecnicas de transi c ao IPv6 propostas atualmente
pelo IETF (Internet Engineering Task Force) dividas em 3 (tres) formas: Dual Stacks,
Tunneling e Translation.
O principal metodo de transi cao e o dual-stack (4.1.1). Dual stacks, como o nome
sugere, literalmente mantem duas pilhas de protocolos que operam em paralelo e, dessa forma,
permitem que os dispositivos operem cada qual com seu protocolo. Dual stacks podem ser
implementadas nos sistemas nais e nos dispositivos de rede. Nos sistemas nais, elas habilitam
aplica coes de ambos os protocolos, IPv4 e IPv6, a operarem no mesmo no. A capacidade de
trabalhar com dual-stack nos dispositivos de rede, faz com que possam manipular tanto pacotes
IPv6, quanto IPv4.
No entanto, somente o mecanismo dual-stack, nao resolve todos os problemas de inter-
conexao de redes IPv4 e IPv6. Um segundo mecanismo e requerido para isso, como o
mecanismo translation (4.1.2) ou o mecanismo tunneling (4.1.3). Translation refere-se dire-
tamente a conversao de protocolos e pode incluir a transforma cao de ambos os protocolos de
cabe calho e payload. Translation pode ocorrer nas diversas camadas da pilha de protocolos,
incluindo rede, transporte e camada de aplica cao. A tradu cao de protocolos pode ter como
resultado, a perda de algumas fun coes, onde nao haja um mapeamento claro dentre as car-
56
actersticas providas pelos mecanismos traduzidos. Por exemplo, a tradu cao de um cabe calho
IPv6 em um cabe calho IPv4, resulta na perda do campo Flow Label do IPv6, assim como a
tradu cao de um cabe calho IPv4 em um cabe calho IPv6 resulta na perda do campo Header
Checksum.
Os mecanismos translation podem ser stateless ou stateful. Um tradutor stateless esta
habilitado para processar cada conversao individualmente sem fazer qualquer referencia previa
aos pacotes traduzidos; um tradutor stateful precisa manter alguma tabela com as tradu coes
precedentes.
Ambos os sistemas nais e os dispositivos de rede podem ser usados para executar o processo
de tradu cao. Translation e considerado transparente quando o trafego e inerentemente roteado
atraves de um tradutor na rede.
Outro mecanismo para transi cao e o tunneling (4.1.3). Tunneling e utilizado como uma
ponte que liga duas redes compatveis atraves de uma rede intermediaria incompatvel. Isto
pode ser visto tecnicamente como a transferencia do datagrama presente no sistema nal,
encapsulado no payload do datagrama do sistema intermediario. O encapsulamento e realizado
na borda de entrada do t unel e o desencapsulamento e realizado na sada do t unel. A associa cao
logica entre os sistemas de entrada e de sada de um t unel e o que o dene.
Quanto a perspectiva de transi cao do IPv4/IPv6, tunneling e em muitos casos usado para
criar uma ponte que interligue segmentos IP incompatveis: um payload IPv6 sobre um IPv4,
ou um payload IPv4 sobre um IPv6.
Sistemas nais e dispositivos de rede podem atuar como sistemas nais de um t unel, execu-
tando encapsulamento ou desencapsulamento. Em muitos casos, tunneling e descrito como uma
simples congura cao ponto-a-ponto. Entretanto, os t uneis tambem podem existir hierarquica-
mente (um t unel dentro de outro) e sequencialmente (t uneis concatenados). As congura coes
hierarquicas sao usadas frequentemente onde haja necessidade de existirem t uneis cuja
nalidade seja prover seguran ca e QoS. Como exemplo, um t unel IPSec (RFC 1825) provendo
seguran ca.
4.1.1 Dual-Stack
No mecanismo dual-stack (RFC 2893 [25]) um no de rede mantem as duas pilhas de pro-
tocolos, IPv6 e IPv4, em paralelo. Aplica coes IPv4 utilizam a pilha IPv4, e aplica coes IPv6
utilizam a pilha IPv6. As decisoes sobre cada uxo sao baseadas no conte udo do campo Version
do cabe calho IP para recebimento e no tipo de Destination Address para envio. Os tipos de
endere cos tipicamente vem do DNS; a pilha apropriada e escolhida, tendo como resposta uma
grava cao na tabela do DNS.
Muitos sistemas operacionais comerciais ja proveem o mecanismo dual-stack para protocolos
IP. Consequentemente, o mecanismo dual-stack e a solu cao mais amplamente utilizada para a
transi cao. No entanto, note que dual-stacks funcionam somente como nos para comunica cao
57
IPv4-IPv4 e IPv6-IPv6. Muito mais e requerido para uma solu cao completa que consiga realizar
a comunica cao entre IPv6-IPv4 e IPv4-IPv6, da a necessidade de mecanismos como Tunneling
e Translation.
Figura 4.2: Funcionamento de um Dual-Stack Router
4.1.2 Translation
A regra basica do mecanismo translation para realizar a transi cao de IPv4/IPv6 e a con-
versao dos pacotes IP e ICMP. Muitos algoritmos de tradu cao sao baseados no algoritmo con-
hecido como SIIT.
Figura 4.3: Cenarios em que utiliza-se o Mecanismo Translation
58
4.1.2.1 SIIT
O SIIT (Stateless IP/ICMP Translation algorithm) (RFC 2765 [22]) especica um algo-
ritmo de tradu cao bidirecional entre os cabe calhos dos pacotes IPv4 e IPv6, bem como, entre
mensagens ICMPv4 e ICMPv6. SIIT, com exce cao do Fragmentation Header, ignora todos os
outros Extension Header do cabe calho IPv6 e o campo Options do cabe calho IPv4. A tradu cao
tem sido desenvolvida, tanto que UDP e TCP, nao sao afetados pelo processo de tradu cao. SIIT
e utilizado como base para outras tecnicas de tradu cao como BIS (4.1.2.2) e NAT-PT (4.1.2.4).
Os tradutores nos sistemas nais sao relativamente faceis para implementar, mas tornam-se
muito difceis para gerenciar em larga escala. O termo bump e utilizado para denotar modulos
de processamento adicionais em uma pilha TCP/IP convencional. Os dois sistemas tradutores
nais atualmente propostos pelo IETF, sao BIS e BIA. Ambos permitem que as aplica coes IPv4
operem sobre uma rede IPv6 a m de atender as exigencias que as aplica coes requerem.
4.1.2.2 BIS
O BIS (Bump-In-the-Stack) (RFC 2767 [24]) compreende um modulo TCP/IPv4 e um
modulo tradutor, o qual consiste de tres bumps (componentes de colisao) e situa-se numa
camada acima do modulo IPv6. Os pacotes das aplica coes IPv4 uem no modulo TCP/IPv4.
Aqui, os pacotes identicados sao traduzidos em IPv6 e por sua vez enviados no modulo IPv6,
e assim por diante. Os tres componentes bump incluem resolu cao de nome, para que o DNS
lookup possa decidir se o no do par e somente IPv6; mapeador de endere cos, o qual aloca um
endere co IPv4 provisorio para o par IPv6; e nalmente, o tradutor, que traduz pacotes entre
IPv4 e IPv6. Os endere cos IPv4 provisorios sao somente visveis dentro do sistemas-nais e
sao conseq uentemente um espa co de endere co condencial. Em conseq uencia, o BIS e utilizado
somente nas aplica coes que nao trocam campos dependentes em seus protocolos de camada de
aplica cao. Por exemplo, o FTP nao opera com o BIS.
4.1.2.3 BIA
BIA (Bump-In-the-API ), como BIS, tambem permitem que aplica coes IPv4 se comuniquem
atraves de pontos sobre uma rede IPv6. A diferen ca e que a camada do bump e inserida num
nvel mais alto, como parte de uma camada socket, habilitando a intercepta cao da chamada
do Socket API. A localiza cao do modulo BIA, permite a tradu cao de pacotes IP (permitindo
seguran ca no nvel do IP) e, diferentemente do BIS, permitindo modica coes para a opera cao do
kernel do sistema. Implementa coes BIA, consistem de tres bump: um resolvedor de nome, um
mapeador de endere cos e um mapeador de fun cao. Os primeiros dois tem muita similaridade
com o BIS. Ja o mapeador de fun cao intercepta chamadas de fun cao de sockets IPv4 e as traduz
para chamadas de socket IPv6. Como BIS, BIA tambem pode usar qualquer endere co IPv4
temporariamente, sujeitando-se as limita coes providas pelo protocolo da camada de aplica cao.
59
Para evitar um alto grau de complexidade nos sistemas nais, o qual conduz a problemas de
escalabilidade em distribui coes maiores, os mecanismos de tradu cao podem ser conduzidos para
dentro da rede como forma alternativa. No entanto, o processo de tradu cao e relativamente
pesado, tornando-se praticavel somente na borda da rede. Os mecanismos propostos para a
tradu cao em dispositivos de rede operam na camada de rede ou na camada de transporte.
Diferentemente da tecnica de tradu cao BIA, as tecnicas NAT-PT e MTP 4.1.2.5 sao tradu-
tores propostos IETF para a camada de rede. O anterior traduz pacotes unicast, enquanto
que o ultimo traduz pacotes multicast. Ja as tecnicas TRT (4.1.2.6) e SOCKS64 (4.1.2.7), sao
mecanismos de tradu cao que atuam na camada de transporte.
4.1.2.4 NAT-PT
O NAT-PT (Network Address Translation - Protocol Translation) (RFC 2766 [23]) e um
tradutor IPv4/IPv6 stateful que usa o algoritmo SIIT. O dispositivo NAT-PT serve para
m ultiplos nos IPv6, alocando um endere co IPv4 temporario para cada no, agindo assim como
um proxy de uma comunica cao com os pontos IPv4. A aloca cao e gerada pelo primeiro pacote
IPv6 outbound (que usa um endere co de destino IPv4-compatible IPv6) ou pelo lookup inbound
de IPv4 DNS (do par) que chega em uma passagem co-localizada do nvel da aplica cao (ALG).
Porque NAT-PT mantem o estado da tradu cao, cada sessao deve ser distribuda atraves do
mesmo dispositivo de NAT-PT (a menos que a informa cao do estado seja xo atraves de um
conjunto de balanceamento de carga).
4.1.2.5 MTP
O MTP (Multicast Translator based on IGMP/MLD Proxying) propoe uma arquitetura para
tradu cao de datagramas multicast entre IPv4 e IPv6. O tradutor e situado no limite do local
entre o IPv4 e o IPv6, e compreende um mapeador de endere cos e um tradutor multicast. O
mapeador de endere cos realiza as tradu coes entre os endere cos multicast IPv4 e os endere cos
multicast IPv6 compatveis com IPv4 (representados pelo prexo FFxx::/96 seguido pelos 32
bits do endere co multicast IPv4).
O tradutor multicast consiste de um proxy multicast IPv4 que junte grupos multicast IPv4
em nome dos receptores IPv6, um proxy multicast IPv6 que junte grupos multicast IPv6 em
nome dos receptores IPv4, e um tradutor que obtenha os datagramas multicast dos proxies,
juntamente com o mapeamento dos endere cos, e traduza, enviando entao os pacotes multicast
sobre um IP diferente. As tecnicas automatizadas para a distribui cao do proxy continuam
indenidas e sao consideradas uma tarefa administrativa.
Os roteadores da camada de transporte, tais como aqueles encontrados em produtos para
rewall, podem tambem ser prolongados para os tradutores IPv6/IPv4. Um processo no
roteador de borda divide o trajeto da camada de transporte em dois segmentos nais, onde
cada segmento suporta versoes diferentes do IP. Os pacotes que atravessam o roteador pas-
60
sam completamente acima da camada de transporte e come cam entao a serem emitidos para
fora no segmento adjacente. A tradu cao ocorre somente na camada de transporte e acima;
consequentemente, a conversao na camada do IP e evitada. Entretanto, processar pacotes em
camadas mais elevadas conduz frequentemente a um baixo desempenho e, com as tecnicas de
tradu cao, a seguran ca end-to-end frequentemente nao pode ser alcan cada. Como com todos
os tradutores stateful, o trafego entre pontos dados devem passar atraves do mesmo roteador.
Hoje, disponvel mais extensamente e utilizado nas tecnicas de troca de mensagens, temos as
tecnicas TRT (4.1.2.6) e SOCKS64 (4.1.2.7).
4.1.2.6 TRT
O TRT (Transport Relay Translator) realiza a tradu cao entre as sessoes TCP/UDPv6 e
TCP/UDPv4. Uma comunica cao e iniciada do lado IPv6 atraves de um tipo do endere co
de destino especial (um prexo de 64 bits seguido pelo endere co IPv4 do no de destino). A
informa cao de roteamento e congurada para distribuir este prexo para o dual-stack router de
TRT, que termina a sessao IPv6 e inicia uma comunica cao IPv4 com o destino nal.
4.1.2.7 SOCKS64
SOCKS64 usa um dual-stack router SOCKS64 e aplica coes que utilizem sockets para permi-
tir uma comunica cao entre os nos IPv4 e IPv6. As aplica coes recebem um novo socket usando
uma biblioteca SOCKS64 especial que substitua o socket e as APIs do DNS. A biblioteca
SOCKS64 intercepta o incio da sessao dos lookups conhecidos do DNS na aplica cao do sistema
nal e responde com os endere cos IP da falsica cao tra cados para a sessao dada. A biblioteca
SOCKS64 emite tambem chamadas de controle da sessao (por exemplo, conexoes TCP) ao
roteador SOCKS64 local, que usa por sua vez o endere co IP real para estabelecer uma sessao
com o destino nal atraves de uma versao diferente do IP.
4.1.3 Tunneling
Lidar com a interliga cao de duas redes diferentes e extremamente difcil. Entretanto, existe
um caso especial muito comum que proporciona bons resultados. Isso acontece quando os hosts
de origem e de destino pertencem ao mesmo tipo de rede, mas ha uma rede de outro tipo entre
eles.
A solu cao para esse problema e uma tecnica chamada Tunneling, permitindo construir uma
ponte sobre redes incompatveis.
O IETF propoe tres mecanismos para este cenario: 6over4, ISATAP, e DSTM.
61
Figura 4.4: Cenarios em que utiliza-se o Mecanismo Tunneling
4.1.3.1 6over4
6over4 (RFC 2529) encaixa os endere cos IPv4 na parte identicadora da camada de enlace
no endere co IPv6, isto e, os ultimos 64 bits e dene o ND (Neighbor Discovery) sobre o IPv4
usando uma organiza cao local multicast. Este uso do multicast signica que a rede IPv4 se
comporta ecazmente como uma LAN virtual. Um remetente resolve o endere co do alvo IPv6
na LAN virtual atraves do ND. O endere co resultante carrega o endere co IPv4 do endpoint do
t unel de destino.
6over4 mantem todas as caractersticas do IPv6, incluindo a seguran ca end-to-end e a auto-
congura cao stateless, e suporta multicast devido a um mapeamento tra cado entre endere cos
IPv6 multicast e endere cos de organiza cao local multicast IPv4. Os sistemas nais tambem
podem usar o espa co de endere co IPv4 condencial.
4.1.3.2 ISATAP
O ISATAP (Intra-Site Automatic Tunnel Addressing Protocol ) e similar ao 6over4, per-
mitindo sistemas nais dual-stack alcan car os roteadores IPv6 que nao sao conectados direta-
mente, atraves de tunneling. Tunneling ao sistema nal e automatizado usando os endere cos
de compatibilidade IPv4/IPv6 (RFC 2373). Estes encaixam um endere co IPv4 na interface da
parte identicadora (isto e, prexo 0x02005EFE seguido pelo endere co IPv4). O tunelamento
ao roteador oink e conseguido estabelecendo um novo nome que seja bem conhecido do
servi co DNS para os roteadores oink, ou atribuindo aos roteadores oink um endere co bem
conhecido do anycast.
62
4.1.3.3 DSTM
O DSTM (Dual Stack Transition Mechanism) permite a aloca cao dos endere cos IPv4 pro-
visorios aos sistemas dual-stack de borda que sao conectados somente a uma rede IPv6. Este
esquema realiza um tunelamento dos pacotes IPv4 atraves da rede IPv6 ao domnio global da
Internet IPv4.
Quando as sessoes sao iniciadas pelo sistema DSTM nal, um servidor DHCPv6 e usado
para obter um endere co IPv4 provisorio e um endere co oink do roteador DSTM de borda,
para que mais tarde os pacotes sejam tunelados. Alternativamente, quando as sessoes sao
iniciadas por um no que utiliza somente IPv4, o pedido do lookup do DNS e dirigido a um
usuario do DNS no domnio de DSTM. Este usuario atribui um endere co IPv4 provisorio ao
sistema nal. Assim, os pacotes que entram sao tunelados a este endere co IPv4. As duas
principais solu coes de tunneling do IETF para a interconexao atraves das redes incompatveis
sao Congured IP-in-IP Tunneling e 6to4 Automatic Tunneling.
4.1.3.4 Congured IP-in-IP Tunneling
Os nos dentro da rede sao congurados estaticamente para executar a tecnica de tunnel-
ing. Os parametros sao controlados atraves da introdu cao de dados feitos manualmente ou
atraves de algum servi co automatizado fornecido por um tunnel broker (RFC 3053). Os tunnel
brokers aliviam o esfor co requerido para o gerenciamento. Seus servi cos sao fornecidos geral-
mente atraves das aplica coes via Web que alocam prexos de endere cos IPv6 e retornam os
certicados e os parametros apropriados da congura cao do t unel. Os tunnel brokers vericam
periodicamente o status dos clientes IPv4 tunelados. Os clientes inalcan caveis sao removidos
geralmente com base nos dados do t unel, e os respectivos recursos sao recuperados.
4.1.3.5 6to4 Automatic Tunneling
Automatic Tunneling implica que a congura cao do t unel esta sendo executada sem a ne-
cessidade de uma gerencia explcita. 6to4 e a tecnica mais utilizada para Automatic Tunneling
(RFC 3056). O mecanismo 6to4 realiza um t unel do trafego IPv6 sobre as redes IPv4 entre as
redes 6to4 isoladas. Cada rede 6to4 assume um prexo especial para encaixe do endere co IPv4
de sua passagem 6to4 (2002:V4ADDR::/48). Isto signica que os endere cos do endpoint do
t unel facilmente sao obtidos e nao necessitam da participa cao de nenhum orgao IPv6 adminis-
trativo. Todos os pacotes IPv6, à exce cao daqueles destinados aos endere cos locais, sao dirigidos
ao gateway. Trafego no sentido reverso, destinado para a rede 6to4, e enviado primeiramente
a um roteador proximo do relay (que anuncia o prexo de 2002::/16). Estes entao, realizam o
tunelamento do trafego ao gateway 6to4 apropriado usando o endere co IPv4 encapsulado. Neste
sentido, qualquer roteador pode ser usado desde que o roteamento IPv4 seja usado nalmente
para encontrar a rede 6to4.
63
Para suportar multicast, os roteadores podem tambem atuar como proxies multicast, tro-
cando informa coes com membros do grupo e encaminhando pacotes multicast sobre o t unel.
64
Captulo 5
Conclusao
Tendo como referencia o processo de projeto aberto e a paixao com que as pessoas
defenderam suas opinioes, muitas das escolhas feitas para o IPv6 geraram muita polemica.
Vamos apresentar um breve resumo dessas controversias.
Conforme mencionado antes, o resultado sobre o tamanho do endere co, foi fruto de uma
concilia cao, incorporando o uso de endere cos de comprimento xo de 128 bits.
O tamanho do campo Hop Limit tambem gerou muita discussao. De um lado, estavam os
defensores da tese de que seria um grande equvoco limitar o n umero de hops a um maximo de
255 (implcito na utiliza cao de um campo de 8 bits). Anal de contas, os caminhos de 32 hops
sao comuns agora e, daqui a 10 anos, talvez sejam comuns caminhos muito mais longos. As
pessoas argumentaram que a utiliza cao de um tamanho de endere co gigantesco era uma boa
ideia, mas usar um pequeno n umero de hops limitava as op coes. Para elas, o maior pecado que
a ciencia da computa cao poderia cometer seria oferecer t ao poucos bits.
Do outro lado, estavam os que acreditavam que a amplia cao excessiva do campo incharia
o cabe calho. Alem disso, a fun cao do campo Hop Limit e impedir que os pacotes vagueiem
por muito tempo, tese incompatvel com o tempo necessario para percorrer 65.535 hops. Por
m, com o crescimento da Internet, serao criados cada vez mais enlaces de longa distancia,
tornando possvel ir de um pas a outro, usando no maximo meia dezena de hops. Se forem
necessarios mais de 125 hops para ir da origem ate o destino atraves de seus respectivos gateways
internacionais, algo esta errado com os backbones nacionais. Os defensores dos 8 bits venceram
essa batalha.
Outro problema complicado era o tamanho maximo do pacote. A comunidade dos super-
computadores desejava pacotes com mais de 64 KB. Quando inicia a transferencia, um super-
computador esta tentando executar uma tarefa importantssima e nao deve ser interrompido a
cada 64 KB. O argumento contrario ao uso de grandes pacotes e que, se um pacote de 1 MB
alcan car uma linha de 1,5 Mbps, ele a ocupara durante cinco segundos, o que produzira um
retardo bastante perceptvel para os usuarios que estao compartilhando a linha. Chegou-se a
um acordo quanto a essa questao: os pacotes normais foram limitados a 64 KB, mas o cabe calho
de extensao Hop-by-hop pode ser usado para permitir a utiliza cao de jumbogramas.
65
Conclusao Peretto, L.M.
Outro assunto polemico foi a remo cao do total de verica cao do IPv4. Algumas pessoas
comparavam esse movimento à remo cao dos freios de um autom ovel. Dessa forma, o veculo
caria mais leve e mais veloz, mas, se ocorresse alguma situa cao inesperada, haveria serios
problemas.
O argumento contrario aos totais de verica cao levava em conta que qualquer aplica cao que
realmente se preocupasse com a integridade dos dados teria de incluir um total de verica cao na
camada de transporte e, por essa razao, seria uma redundancia ter um novo total de verica cao
no IP (alem do total de verica cao da camada de enlace de dados). Vale lembrar tambem
que a experiencia mostrava que o calculo do total de verica cao no IP representava um grande
desperdcio no IPv4. Os que eram contrarios ao total de verica cao venceram essa batalha, e o
IPv6 cou sem o total de verica cao.
Os hosts moveis tambem foram motivo de discordia. Quando um computador portatil vai de
um canto a outro do mundo, ele pode continuar a operar no destino com o mesmo endere co IPv6
ou tem de usar um esquema com agentes locais (home agents) e externos (foreign agents)? Os
hosts moveis tambem introduzem assimetrias no sistema de roteamento.

E bastante provavel
que um pequeno computador movel possa captar facilmente o potente sinal transmitido por
um grande roteador estacionario, mas talvez o roteador estacionario nao seja capaz de captar
o tenue sinal transmitido pelo host movel. Consequentemente, algumas pessoas quiseram dar
ao IPv6 uma compatibilidade explcita com hosts moveis. Esse esfor co fracassou, pois nao foi
possvel chegar a um consenso quanto a essa questao.
Provavelmente, a maior batalha se deu no campo da seguran ca. Todos concordavam que
ela era essencial. O problema era descobrir onde e como usar a seguran ca. O argumento para
inseri-la na camada de rede e que nessa camada ela se torna um servi co padrao que todas as
aplica coes podem usar sem qualquer planejamento previo. O argumento contrario e que, em
geral, tudo o que as aplica coes realmente seguras desejam e a criptograa m a m, na qual a
aplica cao de origem cuida da codica cao, e a aplica cao de destino a desfaz. Se nao for assim, o
usuario estara à merce de implementa coes potencialmente problematicas, sobre as quais ele nao
tem o menor controle na camada de rede. A resposta a esse argumento e que essas aplica coes
podem se abster de usar os recursos de seguran ca do IP, executando elas mesmas essa tarefa. A
replica a esse argumento e que as pessoas que nao conam na execu cao adequada dessa tarefa
nao estao dispostas a pagar o pre co das desajeitadas e lentas implementa coes IP que dispoem
desse recurso, ainda que ele esteja desativado.
Outro aspecto a ser levado em considera cao quanto à localiza cao da seguran ca diz respeito ao
fato de que, em muitos pases, as leis de exporta cao envolvendo a criptograa sao muito rgidas.
Alguns deles, como a Fran ca e o Iraque, tambem impoem in umeras restri coes quanto a seu uso
domestico; portanto, as pessoas nao podem guardar segredos. Consequentemente, os Estados
Unidos e muitos outros pases nao teriam mercado consumidor para qualquer implementa cao
do IP que usasse um sistema criptograco sucientemente forte para ser digno de valor. A
maioria dos fabricantes de computadores detesta produzir dois conjuntos de software, um para
66
Conclusao Peretto, L.M.
uso domestico e outro para exporta cao.
Um ponto sobre o qual nao houve controversia foi o fato de ninguem esperar que a Internet
do IPv4 passasse da noite para o dia a ser a Internet do IPv6. Em vez disso, ilhas de IPv6
isoladas serao convertidas, comunicando-se inicialmente atraves de t uneis. Quando come carem
a se desenvolver, as ilhas do IPv6 formarao ilhas maiores. Em algum momento, todas as ilhas
estarao unidas, e a Internet estara totalmente convertida. Devido ao maci co investimento feito
ha pouco tempo em roteadores IPv4, o processo de conversao deve durar pelo menos uma
decada. Por essa razao, ha um grande esfor co no sentido de garantir que essa transi cao ocorra
da maneira menos dolorosa possvel.
E agora bem aceito que a chegada de IPv6 no Internet realmente acontecera. Os proponentes
admitem que o progresso em realizar exames acima deste novo protocolo foi mais lento do que
o esperado inicialmente. Acredita-se que a razao chave para esta questao, e que o IPv6 e
evolucionario, nao revolucionario. Ate que a Internet funcione realmente fora do espa co de
endere co, ou a demanda para a seguran ca e o QoS se tornem mais signicativas, a tecnologia
IPv6 sera considerada um luxo. Nao obstante, a aceita cao de IPv6 se deve primeiramente aos
problemas que encontramos na Internet IPv4 atual e que necessitarao ser resolvidos mais cedo
ou mais tarde, sendo que, e muito mais praticavel voce solucionar estas questoes pendentes no
protocolo IPv6, do que corrigi-los no IPv4, gerando uma despesa muito menor. Alem disso,
IPv6 e a unica solu cao real que temos para estes problemas.
Muita da movimenta cao atual para implementa cao do IPv6 esta centrada em Europa e na
Asia, porem, enquanto nao houver maior uma adesao mais forte por parte principalmente da
America do Norte, este movimento talvez nao tenha a for ca necessaria. Ha duas razoes provaveis
para esta situa cao. A primeiro e que Europa e

Asia sao os que possuem maiores problemas
com a insuciencia de endere cos. Na America do Norte, estao alocados 70 porcento do espa co
de endere cos IPv4 no mundo, enquanto que as popula coes da Europa e da

Asia, sedentas
por tecnologia, foram deixadas com um n umero de endere cos de rede severamente restrito.
O segundo e com respeito à tecnologia Wireless 3G. Europa e

Asia mantem uma demanda
grande de mercado para as tecnologias moveis que resultarao provavelmente em demandas
maiores de endere co. Consequentemente, os vendedores 3G europeus e asiaticos, e grupos de
padroniza cao sao cometidos signicativamente à resolu c ao do problema da falta de endere cos,
evidenciando mais ainda a necessidade em utilizar-se o IPv6. Recentemente, o governo de Japao
exigiu a incorpora cao do IPv6 para os ISPs e ajustou o m de 2005 como prazo nal para
promo cao de seus sistemas. Alem das inuencias polticas, as grandes companhias comerciais
estao suportando agora IPv6 em seus produtos. Ja existe milhoes de sistemas operacionais com
suporte ao IPv6 conectados na Internet.
Apesar do entusiasmo aparentemente crescente pelo IPv6, a migra cao para este protocolo
novo nao ira ocorrer da noite para o dia. A migra cao deve ser realizada em fases a m de
adaptar-se à demanda pelo IPv6 e permitir uma transi cao gradual. Muitas edi coes tecnicas
propoem in umeras solu coes para este problema da migra c ao. Entretanto, os resultados do
67
5.1 Propostas para trabalhos futuros Peretto, L.M.
trabalho no IETF estao fornecendo agora, solu coes mais praticaveis para a migra cao e o uso de
IPv6 na Internet. Deste trabalho, nos acreditamos que os mecanismos essenciais na transi cao
sao o NAT-PT, 6to4 Automatic Tunneling e Congured IP-in-IP Tunneling. Estas sao as
tecnologias de transi cao mais extensamente utilizadas e que cumprem as exigencias basicas
para o interoperabilidade dentro da Internet existente. Talvez agora IPv6 pode passar de um
sonho para se tornar realidade.
5.1 Propostas para trabalhos futuros
Conforme descrito anteriormente nos captulos deste trabalho, o protocolo IPv6 traz in umeras
solu coes para problemas que hoje sao encontrados no IPv4. Porem, a sua implementa cao esta
ocorrendo de forma gradual. Com a introdu cao de mecanismos de transi cao ecientes, logo
teremos suporte para o IPv6 nas in umeras redes espalhadas ao redor do mundo, tornando-o o
principal protocolo da camada de rede. Muitos assuntos que foram abordados neste trabalho,
podem tornar-se propostas para estudo e pesquisa, dando continuidade ao tema tratado nesta
monograa:
A utiliza cao do Mobile IPv6: Atualmente, ja convivemos com alguma mobilidade provida
por protocolos das camadas fsicas e de enlace de dados. Contudo, a mobilidade, neste
caso, existe apenas em ambito local, sendo impossvel que uma unidade movel se desloque
entre redes diferentes, conservando, portanto, sua congura cao de rede inalterada durante
a movimenta cao. O MIP (Mobile IP), por outro lado, possibilita que um no movel passe
de uma rede para outra sem que as conexoes ou sessoes estabelecidas sejam interrompidas
e permitindo que outras novas sejam estabelecidas, tudo isto de forma transparente ao
usuario. Alem disso, o Mobile IPv6, vem corrigir alguns problemas que eram encontrados
na versao anterior.
A utiliza cao do IPSec: O IPSec (IP Security) e uma sute de protocolos denida pelo
IETF, cujo objetivo e possibilitar a utiliza cao de servi cos de autentica cao, integridade
e condencialidade em pacotes. A implementa cao do IPSec no IPv6 e obrigatoria,
diferentemente do IPv4, que nao foi projetado para ser um protocolo com caractersticas
de seguran ca. Inicialmente, seu uso estava restrito a um ambiente colaborativo onde
existia uma coopera cao harmoniosa entre os usuarios. Porem, a populariza cao deste
protocolo, dado seu uso na Internet, trouxe consigo a descoberta de um conjunto de falhas
de seguran ca que podem ser exploradas por ataques que resultam desde DoS (Denial of
Service) ate invasoes capazes de comprometer um sistema inteiro.
68
Referencias Bibliogracas
[1] TANENBAUM, Andrew S.Redes de Computadores. 4
a
Edi cao, Editora Campus, Rio de
Janeiro, 2003.
[2] KUROSE, James F. e ROSS, Keith W.Redes de Computadores e a Internet - Uma Nova
Abordagem. 1
a
Edi cao, Editora Addison Wesley, Sao Paulo, 2003.
[3] SMETANA, George Marcel M.A.IPv4 e IPv6. Laboratorio de Arquitetura e Redes de
Computadores, Escola Politecnica da Universidade de Sao Paulo (USP).
[4] COR
A, Marcos Ant. de Almeida. Introdu cao às Redes de Computadores. Versao 5.3.14,
Campinas, 2005.
[5] LEE, D.C.; LOUGH, D.L.; MIDKIFF, S.F.; DAVIS, N.J. e BENCHOFF, P.E. The next
generation of the Internet: aspects of the Internet protocol version 6. Network, IEEE,
Volume: 12, Janeiro - Fevereiro 1998, Paginas: 28 - 33.
[6] AFIFI, H. e TOUTAIN, L. Methods for IPv4-IPv6 transition. Computers and Communi-
cations, 1999. Proceedings. IEEE International Symposium on, 6-8 Julho 1999, Paginas:
478 - 484.
[7] CHEN, Jiann-Liang; CHANG, Yao-Chung e LIN, Chien-Hsiu. Performance investigation
of IPv4/IPv6 transition mechanisms. Advanced Communication Technology, 2004. The
6th International Conference on, Volume: 2, Paginas: 545 - 550.
[8] MACKAY, M.; EDWARDS, C.; DUNMORE, M.; CHOWN, T. e CARVALHO, G. A
scenario-based review of IPv6 transition tools. Internet Computing, IEEE, Volume: 7,
Maio-Junho 2003, Paginas: 27 - 35.
[9] TATIPAMULA, M.; GROSSETETE, P. e ESAKI, H. IPv6 integration and coexistence
strategies for next-generation networks. Communications Magazine, IEEE, Volume: 42,
Janeiro 2004, Paginas: 88 - 96.
[10] RAICU, I. e ZEADALLY, S. Evaluating IPv4 to IPv6 transition mechanisms Telecom-
munications, 2003. ICT 2003. 10th International Conference on, Volume: 2, 23 Fevereiro
- 1 Mar co 2003, Paginas: 1091 - 1098.
69
REFER
ENCIAS BIBLIOGR
AFICAS Peretto, L.M.

[11] SILVA, Adailton J. S. O que Vai Mudar na sua Vida com o IPv6. Rede Nacional de
Ensino e Pesquisa, RNP News Generation, Volume: 1, N umero: 2, 30 de Junho de 1997.
[12] SILVA, Adailton J. S. e FARIA, Marcel R. Hierarquia de Endere cos IPv6. Rede Nacional
de Ensino e Pesquisa, RNP News Generation, Volume: 5, N umero: 2, 16 de Mar co de
2001.
[13] FRANK, Ned. A Nova Gera cao de Protocolos IP. Rede Nacional de Ensino e Pesquisa,
RNP News Generation, Volume: 2, N umero: 8, 13 de Novembro de 1998.
[14] [RFC 791] POSTEL, J. Internet Protocol: DARPA Internet Program Protocol Speci-
cation, RFC 791, Setembro 1981.
[15] [RFC 1519] FULLER, V.; LI, T.; YU, J. e VARADHAN, K. Classless Inter-Domain
Routing (CIDR), RFC 1519, Setembro 1993.
[16] [RFC 1700] REYNOLDS, J. e POSTEL J. Assigned Numbers, RFC 1700, Outubro 1994.
[17] [RFC 1918] REKHTER, Y.; MOSKOWITZ, B.; KARRENBERG, D.; GROOT, J. G.
e LEAR, E. Address Allocation for Private Internets, RFC 1918, Fevereiro 1996.
[18] [RFC 1981] MCCANN, J.; DEERING, S. e MOGUL, J. Path MTU Discovery for IPv6,
RFC 1981, Agosto 1996.
[19] [RFC 2402] KENT, S. e ATKINSON, R. IP Authentication Header, RFC 2402, Novem-
bro 1998.
[20] [RFC 2406] KENT, S. e ATKINSON, R. IP Encapsulating Security Payload (ESP),
RFC 2406, Novembro 1998.
[21] [RFC 2460] DEERING S. e HINDEN, R. Internet Protocol, Version 6 (IPv6) Specica-
tion, RFC 2460, Dezembro 1998.
[22] [RFC 2765] NORDMARK, E. Stateless IP/ICMP Translation Algorithm (SIIT), RFC
2765, Fevereiro 2000.
[23] [RFC 2766] TSIRTSIS, G. e SRISURESH, P. Network Address Translation - Protocol
Translation (NAT-PT), RFC 2766, Fevereiro 2000.
[24] [RFC 2767] TSUCHIYA, K. e ATARASHI, Y. Dual Stack Hosts using the Bump-In-
the-StackTechnique (BIS), RFC 2767, Fevereiro 2000.
[25] [RFC 2893] GILLIGAN, R. e NORDMARK, E. Transition Mechanisms for IPv6 Hosts
and Routers, RFC 2893, Agosto 2000.
[26] [RFC 2993] HAIN, T. Architectural Implications of NAT, RFC 2993, Novembro 2000.
70
REFER
ENCIAS BIBLIOGR
AFICAS Peretto, L.M.

[27] [RFC 3022] SRISURESH, P. e EGEVANG, K. Traditional IP Network Address Trans-
lator (Traditional NAT), RFC 3022, Janeiro 2001.
71

Monografia - Versão Final

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Monografia - Versão Final

Hochgeladen von

Copyright:

Verfügbare Formate

Faculdade de Tecnologia de Americana - FATEC

Lincon Moreira Peretto

Area de concentra cao: Teleprocessamento e

ARIO Peretto, L.M.

E necessario organizar o espa co de endere camento de forma hierarquica, com o objetivo de

AFICAS Peretto, L.M.

AFICAS Peretto, L.M.

Das könnte Ihnen auch gefallen