IPv6

básico
Antônio Marcos Moreiras
Alexandre Yukio Harano
Eduardo Barasal Morales
Edwin Santos Cordeiro
Heitor de Souza Ganzeli
Rodrigo Matos Carnier
Rodrigo Regis dos Santos
A RNP – Rede Nacional de Ensino
e Pesquisa – é qualificada como
uma Organização Social (OS),
sendo ligada ao Ministério da
Ciência, Tecnologia e Inovação
(MCTI) e responsável pelo
Programa Interministerial RNP,
que conta com a participação dos
ministérios da Educação (MEC), da
Saúde (MS) e da Cultura (MinC).
Pioneira no acesso à Internet no
Brasil, a RNP planeja e mantém a
rede Ipê, a rede óptica nacional
acadêmica de alto desempenho.
Com Pontos de Presença nas
27 unidades da federação, a rede
tem mais de 800 instituições
conectadas. São aproximadamente
3,5 milhões de usuários usufruindo
de uma infraestrutura de redes
avançadas para comunicação,
computação e experimentação,
que contribui para a integração
entre o sistema de Ciência e
Tecnologia, Educação Superior,
Saúde e Cultura.

Ministério da
Cultura

Ministério da
Saúde

Ministério da
Educação

Ministério da
Ciência, Tecnologia
e Inovação
IPv6
Básico
Antônio Marcos Moreiras
Alexandre Yukio Harano
Eduardo Barasal Morales
Edwin Santos Cordeiro
Heitor de Souza Ganzeli
Rodrigo Matos Carnier
Rodrigo Regis dos Santos

Colaboração
Tiago Jun Nakamura
Tuany Oguro Tabos
IPv6
Básico

Antônio Marcos Moreiras

Alexandre Yukio Harano
Eduardo Barasal Morales
Edwin Santos Cordeiro
Heitor de Souza Ganzeli
Rodrigo Matos Carnier
Rodrigo Regis dos Santos

Colaboração
Tiago Jun Nakamura
Tuany Oguro Tabosa

Rio de Janeiro
Escola Superior de Redes
2014
Copyright © 2014 – Rede Nacional de Ensino e Pesquisa – RNP
Rua Lauro Müller, 116 sala 1103
22290-906 Rio de Janeiro, RJ

Diretor Geral
Nelson Simões

Diretor de Serviços e Soluções

José Luiz Ribeiro Filho

Escola Superior de Redes

Coordenação
Luiz Coelho

Edição
Pedro Sangirardi

Revisão técnica
Luiz Carlos Lobato

Equipe ESR (em ordem alfabética)

Adriana Pierro, Celia Maciel, Cristiane Oliveira, Derlinéa Miranda, Edson Kowask, Elimária
Barbosa, Evellyn Feitosa, Felipe Nascimento, Lourdes Soncin, Luciana Batista, Renato Duarte
e Yve Abel Marcial.

Capa, projeto visual e diagramação

Tecnodesign

Versão
3.0.0

Este material didático foi elaborado com fins educacionais. Solicitamos que qualquer erro encon-
trado ou dúvida com relação ao material ou seu uso seja enviado para a equipe de elaboração de
conteúdo da Escola Superior de Redes, no e-mail [email protected]. A Rede Nacional de Ensino e
Pesquisa e os autores não assumem qualquer responsabilidade por eventuais danos ou perdas, a
pessoas ou bens, originados do uso deste material.
As marcas registradas mencionadas neste material pertencem aos respectivos titulares.

Distribuição
Escola Superior de Redes
Rua Lauro Müller, 116 – sala 1103
22290-906 Rio de Janeiro, RJ
http://esr.rnp.br
[email protected]

Dados Internacionais de Catalogação na Publicação (CIP)

I64 IPV6 básico / Rodrigo Regis dos Santos ... [et. al.]; colaboração Sidney C. de Lucena. – 3. ed.
– Rio de Janeiro: RNP/ESR, 2014.
210 p.: il.; 28cm.

Primeira edição com o título de: Curso IPV6 Básico.

ISBN 978-85-63630-40-7

1. TCP/IP (protocolo de rede de computador). 2. Redes de computador – gestão. I. Santos,

Rodrigo Regis dos. II. Lucena, Sidney C. de. III. Título.

CDD 004.62
Sumário

Escola Superior de Redes

A metodologia da ESR ix

Sobre o curso  x

A quem se destina  xi

Convenções utilizadas neste livro xi

Permissões de uso xi

Sobre os autores xii

1. Histórico do IPv6
Introdução 1

A internet e o TCP/IP 2

Esgotamento dos endereços IPv4 4

Mapa de endereços IPv4 6

Soluções paliativas 6

NAT 7

Nova versão do IP 9

Soluções 10

IPv6 11

Por que utilizar IPv6 hoje? 12

Demanda crescente por endereços IPv4 14

Governança da internet 15

Evolução do estoque de blocos IP na IANA 16

Como está a implantação do IPv6? 17

iii
 A transição do IPv4 para o IPv6 19

IPv6 em uso 21

Troca de tráfego IPv6 21

Alocação de blocos IPv6 22

Como está a implantação do IPv6 no Brasil? 24

Riscos de não implantar o IPv6 24

2. Cabeçalho IPv6
Cabeçalho IPv4 27

Cabeçalho IPv6 28

Cabeçalhos de extensão 33

Hop-by-Hop Options  34

Destination Options  35

Routing  35

Fragmentation  36

Authentication Header (AH) e Encapsulating Security Payload (ESP) 36

Resumo de cabeçalho de extensão 37

3. Endereçamento IPv6
Endereçamento 39

Unicast 41

Global Unicast 41

Unique local 42

Identificador da Interface (IID) 43

EUI-64 44

Endereços e faixas especiais e endereços obsoletos 45

Anycast  46

Multicast  47

Flags e escopo 47

Endereços multicast permanentes 48

Endereço Solicited-Node 49

Endereço multicast derivado de um prefixo unicast  49

Endereços Multicast SSM 50

Abordagem one size fits all  52

Abordagem conservadora 52

O que os RIRs e ISPs têm praticado? 52

iv
Considerações  54

Exercício de fixação 1 – Planejamento de endereçamento IP 55

Exercício de fixação 2 – Tipo de endereços 56

4. ICMPv6 – Parte 1
ICMPv6 59

Descoberta de Vizinhança 64

Router Solicitation (ICMPv6 tipo 133) 65

Router Advertisement (ICMPv6 tipo 134) 66

Neighbor Solicitation (ICMPv6 tipo 135) 68

Neighbor Advertisement (ICMPv6 tipo 136) 69

Redirect (ICMPv6 tipo 137) 71

Source link-layer address 74

Target link-layer address 74

Prefix information 75

Redirected header 76

MTU 77

Recursive DNS Server Option (RDNSS) 77

5. ICMPv6 – Parte 2
Descoberta de endereços da camada de enlace 79

Descoberta de roteadores e prefixos 80

Detecção de Endereços Duplicados (DAD) 81

Detecção de vizinhos inacessíveis 83

Redirecionamento 85

Autoconfiguração de endereços stateless  87

Autoconfiguração de endereços stateful  89

Estado dos endereços  93

6. Funcionalidades do IPv6
Path MTU Discovery 95

Jumbograms 96

Quality of Service (QoS) 99

DiffServ 99

IntServ 100

v
 Suporte à mobilidade no IPv6 100

Binding Updates 101

Tunelamento bidirecional 103

Otimização de Rota 103

Mobility 104

Novas mensagens ICMPv6 105

Mudanças no protocolo Descoberta de Vizinhança 105

Mobilidade IPv4 x Mobilidade IPv6 106

7. Protocolo DNS
O protocolo DNS 107

Definições 108

Domínio 108

Zonas de autoridade 109

Registro de recursos 110

Mapeamento direto 112

Mapeamento reverso 113

Resolução direta no IPv6 113

Resolução reversa no IPv6 113

Cliente e servidor DNS 114

Suporte IPv6 do DNS 115

8. Segurança
A questão da segurança 117

Segurança no IPv6 117

Ferramentas de segurança no IPv6 124

IPSec  124

Estrutura dos endereços 127

Endereços – CGA 128

Endereços: extensões de privacidade 128

Resumindo segurança no IPv6 128

Recomendações 129

9. Coexistência e transição – Parte 1

Cenários de coexistência de IPv6 e IPv4 133

Classificação das técnicas de transição 136

Pilha Dupla: IPv6 e IPv4 em todos os dispositivos 138

vi
 Túneis 6over4 (IPv6-over-IPv4) 140

Técnicas de tunelamento 140

Túneis GRE 144

Tunnel Broker 145

Dual Stack Lite (DS-Lite) 150

IVI, dIVI e dIVI-pd 154

NAT64 e DNS64 161

464XLAT 165

10. Coexistência e transição – Parte 2

4rd 167

6PE e 6VPE 169

6rd 170

6to4 173

Teredo 177

ISATAP 184

Inicialização do ISATAP 185

Comunicação entre clientes ISATAP na mesma rede  186

Comunicação entre clientes ISATAP em redes diferentes  187

Comunicação entre clientes ISATAP e computadores IPv6 188

A+P 189

NAT444 190

Técnicas de tradução 191

SIIT  191

BIS 192

BIA 193

TRT 194

ALG e DNS-ALG 194

Segurança na transição 195

Considerações finais 195

11. Planejamento
O planejamento 199

Primeiro passo: treinamento 200

O impacto do IPv6 200

Exercício de fixação: engenheiros x gerentes 201

vii
 12. O IPv6 na RNP
IPv6 na RNP  205

Backbone IPv6 na RNP 206

Backbone IPv6 RNP – Peerings  207

Backbone IPv6 RNP – Clientes  208

Distribuição de blocos IPv6 na RNP 209

Regras para a alocação de endereços IPv6 na RNP 209

viii
Escola Superior de Redes
A Escola Superior de Redes (ESR) é a unidade da Rede Nacional de Ensino e Pesquisa (RNP)
responsável pela disseminação do conhecimento em Tecnologias da Informação e Comunica-
ção (TIC). A ESR nasce com a proposta de ser a formadora e disseminadora de competências
em TIC para o corpo técnico-administrativo das universidades federais, escolas técnicas e
unidades federais de pesquisa. Sua missão fundamental é realizar a capacitação técnica do
corpo funcional das organizações usuárias da RNP, para o exercício de competências aplicá-
veis ao uso eficaz e eficiente das TIC.

A ESR oferece dezenas de cursos distribuídos nas áreas temáticas: Administração e Projeto
de Redes, Administração de Sistemas, Segurança, Mídias de Suporte à Colaboração Digital e
Governança de TI.

A ESR também participa de diversos projetos de interesse público, como a elaboração e

execução de planos de capacitação para formação de multiplicadores para projetos edu-
cacionais como: formação no uso da conferência web para a Universidade Aberta do Brasil
(UAB), formação do suporte técnico de laboratórios do Proinfo e criação de um conjunto de
cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).

A metodologia da ESR
A filosofia pedagógica e a metodologia que orientam os cursos da ESR são baseadas na
aprendizagem como construção do conhecimento por meio da resolução de problemas típi-
cos da realidade do profissional em formação. Os resultados obtidos nos cursos de natureza
teórico-prática são otimizados, pois o instrutor, auxiliado pelo material didático, atua não
apenas como expositor de conceitos e informações, mas principalmente como orientador do
aluno na execução de atividades contextualizadas nas situações do cotidiano profissional.

A aprendizagem é entendida como a resposta do aluno ao desafio de situações-problema

semelhantes às encontradas na prática profissional, que são superadas por meio de análise,
síntese, julgamento, pensamento crítico e construção de hipóteses para a resolução do pro-
blema, em abordagem orientada ao desenvolvimento de competências.

Dessa forma, o instrutor tem participação ativa e dialógica como orientador do aluno para as
atividades em laboratório. Até mesmo a apresentação da teoria no início da sessão de apren-
dizagem não é considerada uma simples exposição de conceitos e informações. O instrutor
busca incentivar a participação dos alunos continuamente.

ix
 As sessões de aprendizagem onde se dão a apresentação dos conteúdos e a realização das
atividades práticas têm formato presencial e essencialmente prático, utilizando técnicas de
estudo dirigido individual, trabalho em equipe e práticas orientadas para o contexto de atua-
ção do futuro especialista que se pretende formar.

As sessões de aprendizagem desenvolvem-se em três etapas, com predominância de tempo

para as atividades práticas, conforme descrição a seguir:

Primeira etapa: apresentação da teoria e esclarecimento de dúvidas (de 60 a 90 minutos).

O instrutor apresenta, de maneira sintética, os conceitos teóricos correspondentes ao tema
da sessão de aprendizagem, com auxílio de slides em formato PowerPoint. O instrutor
levanta questões sobre o conteúdo dos slides em vez de apenas apresentá-los, convidando
a turma à reflexão e participação. Isso evita que as apresentações sejam monótonas e que o
aluno se coloque em posição de passividade, o que reduziria a aprendizagem.

Segunda etapa: atividades práticas de aprendizagem (de 120 a 150 minutos).

Esta etapa é a essência dos cursos da ESR. A maioria das atividades dos cursos é assíncrona e
realizada em duplas de alunos, que acompanham o ritmo do roteiro de atividades proposto
no livro de apoio. Instrutor e monitor circulam entre as duplas para solucionar dúvidas e
oferecer explicações complementares.

Terceira etapa: discussão das atividades realizadas (30 minutos).

O instrutor comenta cada atividade, apresentando uma das soluções possíveis para resolvê-la,
devendo ater-se àquelas que geram maior dificuldade e polêmica. Os alunos são convidados a
comentar as soluções encontradas e o instrutor retoma tópicos que tenham gerado dúvidas,
estimulando a participação dos alunos. O instrutor sempre estimula os alunos a encontrarem
soluções alternativas às sugeridas por ele e pelos colegas e, caso existam, a comentá-las.

Sobre o curso
O protocolo IPv6, há muito tempo lançado como o sucessor do protocolo IP versão 4 (IPv4),
vem sendo tratado com importância crescente ao longo dos últimos anos. Com a previsão
do Internet Assigned Numbers Authority (IANA) para o término das grandes faixas de IPv4
cedidas aos provedores de acesso Internet (ISPs), a alocação de faixas IPv6 pelos ISPs tem
crescido exponencialmente.

Hoje, a grande maioria dos ISPs de nível mundial possui o protocolo IPv6 nativamente configu-
rado em seus roteadores, e isso também passa a ocorrer com ISPs de nível regional. Ciente da
importância de uma política de incentivo à adoção do IPv6 pelas comunidades de TIC brasilei-
ras, o Comitê Gestor da Internet no Brasil (CGI.br) lançou o curso IPv6 Básico, voltado para os
profissionais de TIC envolvidos na migração do IPv4 para IPv6.

Este curso, de cunho teórico e prático, não se limita somente a mostrar as diferenças básicas
entre os dois protocolos e as novas funcionalidades do IPv6. Apresenta várias técnicas e
práticas de planejamento e configuração de endereçamento IPv6, proporcionando o enten-
dimento na prática de como ocorre a migração de IPv4 para IPv6. A Escola Superior de Redes
da RNP tem orgulho de ser parceira do CGI.br nesta importante iniciativa, adaptando para seu
portfólio este valioso material.

x
A quem se destina
O curso é destinado aos técnicos e administradores de redes que planejam implementar o
IPv6 em suas redes, aos engenheiros de redes das universidades federais e pontos de pre-
sença da RNP que pretendem atualizar seus conhecimentos em redes IPv6 e aos acadêmicos
com interesse de pesquisa em rede e tecnologia da Internet.

Convenções utilizadas neste livro

As seguintes convenções tipográficas são usadas neste livro:

Itálico
Indica nomes de arquivos e referências bibliográficas relacionadas ao longo do texto.

Largura constante

Indica comandos e suas opções, variáveis e atributos, conteúdo de arquivos e resultado da saída
de comandos. Comandos que serão digitados pelo usuário são grifados em negrito e possuem
o prefixo do ambiente em uso (no Linux é normalmente # ou $, enquanto no Windows é C:\).

Conteúdo de slide q
Indica o conteúdo dos slides referentes ao curso apresentados em sala de aula.

Símbolo w
Indica referência complementar disponível em site ou página na internet.

Símbolo d
Indica um documento como referência complementar.

Símbolo v
Indica um vídeo como referência complementar.

Símbolo s
Indica um arquivo de aúdio como referência complementar.

Símbolo
Indica um aviso ou precaução a ser considerada.

Símbolo p
Indica questionamentos que estimulam a reflexão ou apresenta conteúdo de apoio ao
entendimento do tema em questão.

Símbolo l
Indica notas e informações complementares como dicas, sugestões de leitura adicional ou
mesmo uma observação.

Permissões de uso
Todos os direitos reservados à RNP.
Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra.
Exemplo de citação: TORRES, Pedro et al. Administração de Sistemas Linux: Redes e Segurança.
Rio de Janeiro: Escola Superior de Redes, RNP, 2013.

xi
 Comentários e perguntas
Para enviar comentários e perguntas sobre esta publicação:
Escola Superior de Redes RNP
Endereço: Av. Lauro Müller 116 sala 1103 – Botafogo
Rio de Janeiro – RJ – 22290-906
E-mail: [email protected]

Sobre os autores
“Os autores e colaboradores trabalham no CEPTRO.br, área do Núcleo de Informação e
Coordenação do Ponto BR - NIC.br, responsável por serviços e projetos relacionados princi-
palmente à infraestrutura da Internet no Brasil e ao seu desenvolvimento. A equipe desen-
volve soluções em infraestrutura de redes, software e hardware, além de gerenciar projetos
executados por parceiros externos.

Dentre os projetos coordenados pelo CEPTRO.br, destaca-se o IPv6.br. Projeto que engloba
uma série de iniciativas do NIC.br para disseminar o uso do protocolo IPv6 no Brasil, ofe-
recendo cursos presenciais e a distância, desenvolvendo materiais didáticos, ministrando
palestras e mantendo o site web http://ipv6.br, o blog http://ipv6.br/blog, o validador de sites
web para IPv6 http://ipv6.br/validador e o curso e-learning http://ipv6.br/curso.”.

xii
 1
Histórico do IPv6
objetivos

Conhecer a história da internet e o desenvolvimento do protocolo IPv4; entender a

razão da transição do IPv4 para IPv6 e suas consequências.

A internet e o TCP/IP; Esgotamento dos endereços IPv4; Mapa de endereços IPv4;

conceitos
Soluções paliativas para o esgotamento de endereços IPv4: NAT (Network Address
Translation); Nova versão do IP: IPv6; Demanda por endereços IPv4; Transição do IPv4
para IPv6; Alocação de blocos IPv6

Introdução
Neste capítulo introdutório, além de conhecer um pouco da história da internet e do desenvolvi-
mento do protocolo IP, vamos entender os problemas causados pela forma adotada inicialmente
para distribuição dos endereços IP e pelo rápido crescimento da internet, além de conhecer as
soluções para resolver esses problemas. Seguindo esse histórico, veremos como algumas dessas
soluções evoluíram até chegarmos à definição da versão 6 do protocolo IP, o IPv6.

Neste módulo também saberemos, através de dados estatísticos, a real necessidade da

implantação do IPv6 nas redes de computadores, confrontando dados sobre o ritmo de
crescimento da internet e sobre a adoção e utilização do IPv6. Também serão discutidas as
consequências da não implantação do novo protocolo IP e da larga utilização de técnicas
tidas como paliativas, como no caso de uso de NAT para tradução de endereços.

A internet é um fenômeno muito recente, mas que alterou, e continua alterando, a forma
como nos comunicamos, trabalhamos, compramos, vendemos, nos divertimos, nos rela-
cionamos com o Estado e mesmo como nos organizamos enquanto sociedade. Seu efeito
tem sido, em geral, benéfico. Tanto que muitos argumentam que o acesso a ela deveria ser
considerado um direito fundamental de todo ser humano. A internet quebra fronteiras geo-
Capítulo 1 - Histórico do IPv6

gráficas, socializa a informação, permite a colaboração entre as pessoas numa escala antes
inimaginável e favorece o desenvolvimento, tanto dos indivíduos, como das organizações.
Sem dúvida, a internet é algo que a sociedade deve preservar, e mais: deve trabalhar para
que seja algo de que todos possam usufruir, e cujo desenvolvimento seja sempre contínuo.

Do ponto de vista tecnológico, a internet é uma rede de alcance mundial, que interliga com-
putadores, tablets, celulares e uma infinidade de outros dispositivos. Na verdade, como seu
próprio nome sugere, é formada por uma interconexão de um grande número de redes, mais
ou menos independentes umas das outras. As diversas redes que compõem a internet são

1
 administradas por diferentes instituições, que têm objetivos diversos e usam equipamentos
de vários fabricantes. Ainda assim, todas são capazes de interoperar. Como isso é possível?

A internet só é possível porque todos os seus participantes concordam em seguir um con-

junto comum de padrões tecnológicos. Esses padrões são criados de forma aberta e colabo-
rativa e aprovados por um processo de consenso aproximado pela Internet Engineering Task
Force (IETF). Há literalmente milhares de padrões que definem como cada função deve ser
realizada na rede, como cada serviço e aplicação devem funcionar. Um deles, contudo, pode
ser destacado: o Internet Protocol (IP). Um protocolo é um conjunto de regras de comuni-
cação. O IP é a base tecnológica da rede, o protocolo que empresta seu nome a ela: internet.

É importante lembrar que a internet é construída sobre a infraestrutura de telecomunica-

ções tradicional. A mesma infraestrutura que é usada para telefonia, rádio e TV. Ainda assim,
a internet é normalmente muito mais flexível e barata do que as demais tecnologias que
fazem uso dos mesmos recursos de telecomunicações. Isso é possível porque ela faz uso
muito mais eficiente dos recursos. No lugar de utilizar a comunicação por circuitos, que faz a
reserva antecipada dos recursos necessários para a comunicação entre emissor e receptor,
a internet utiliza a comutação de pacotes, dividindo a informação em pequenos blocos, que
podem ser enviados de forma independente pela rede, seguindo seu caminho até o destino.
A comunicação de pacotes permite o compartilhamento dos recursos de telecomunicações

l
de forma muito eficiente, e a construção de redes extremamente resilientes, em que pode
haver muitos caminhos diferentes entre dois pontos quaisquer.
O IPv6 é a versão mais
recente do protocolo IP.
Quem separa a internet das telecomunicações é justamente o IP. Ela tem de ser implan-
tada rapidamente na
internet, porque a
versão anterior, o IPv4,
O Protocolo Internet é o responsável por identificar cada dispositivo presente na rede, por meio
não é mais capaz de
de números que chamamos de endereços, e por encapsular todos os dados que fluem através suportar o crescimento
dela, agregando a eles informações suficientes para que cheguem a seus destinos. O IP pode da rede: não há mais
endereços livres.
fazer uso de diversos tipos de redes de telecomunicações diferentes, criando uma camada
padronizada sobre a qual todos os demais protocolos e serviços na internet funcionam.

A internet e o TCP/IP
11 1969: início da ARPANET. q
11 1981: definição do IPv4 na RFC 791.

11 1983: ARPANET adota o TCP/IP.

11 1990: primeiros estudos sobre o esgotamento dos endereços.

11 1993: internet passa a ser explorada comercialmente.

22 Intensificada a discussão sobre o possível esgotamento dos endereços livres e do

aumento da tabela de roteamento.

O Departamento de Defesa (DoD – Department of Defense) do governo norte-americano iniciou DoD

em 1966, através de sua Agência de Pesquisas e Projetos Avançados (ARPA – Advanced Research Órgão federal respon-
Projects Agency), um projeto para a interligação de computadores em centros militares e de sável pela coordenação
das agências ligadas à
pesquisa. Esse sistema de comunicação e controle distribuído com fins militares recebeu o segurança nacional e
nome de ARPANET, tendo como principal objetivo teórico formar uma arquitetura de rede sólida às forças armadas dos
IPv6 Básico

e robusta que pudesse, mesmo com a queda de alguma estação, trabalhar com os computa- Estados Unidos.

dores e ligações de comunicação restantes. Em 1969, são instalados os primeiros quatro nós da
rede: na Universidade de Los Angeles (UCLA), na Universidade da Califórnia em Santa Bárbara
(UCSB), no Instituto de Pesquisas de Stanford (SRI) e na Universidade de Utah.

2
 Figura 1.1
Rede Arpa (fonte:
Alex Mckenzie).

Figura 1.2
Mapa lógico dos
primeiros quatro
nós da ARPANET,
em dezembro
de 1969, como
esboçado por Larry
Roberts (fonte:
Computer History
Museum).

No início, a ARPANET trabalhava com diversos protocolos de comunicação, sendo o principal

NCP o Network Control Protocol (NCP). No entanto, em 1983, quando a rede já possuía 562 hosts,
Primeiro protocolo todas as máquinas da ARPANET passaram a adotar como padrão os protocolos TCP/IP, permi-
servidor a servidor da
tindo o crescimento ordenado da rede e eliminando restrições dos protocolos anteriores.
ARPANET. Criado em
1971 pelo Network
Nesse mesmo ano, a ARPANET foi dividida em duas: uma rede fechada para os militares
Working Group (NWG),
liderado por Steve chamada MILNET e uma rede aberta, com então 45 hosts, que evoluiu para a rede que hoje
Crocker, também conhecemos como a internet. Não há uma data formal na qual a ARPANET passou a ser a
criador das RFCs.
internet e, ao discutir quando a internet realmente começou, há diversos critérios diferentes
que podem ser adotados.
Capítulo 1 - Histórico do IPv6

Uma das possibilidades é considerar a data de 1º de janeiro de 1983 como o nasci-

mento da internet.

Um ponto interessante a ser notado é que, apesar de ter nascido como um projeto militar,
desde o início a ARPANET foi utilizada para conectar instituições de pesquisa, e sempre foi
baseada em padrões abertos. Talvez esse tenha sido um fator fundamental para sua evo-
lução para a internet que todos conhecem hoje, um ambiente aberto e propício à inovação,

3
 com um gerenciamento que não é centralizado, mas dividido entre diversas instituições,
com a participação de operadores e usuários, incluindo a iniciativa privada, o governo e a
sociedade civil.

Definido na RFC 791, o protocolo IP possui duas funções básicas: RFC 791
Especificação do pro-
11 Fragmentação: permite o envio de pacotes maiores que o limite de tráfego estabelecido tocolo IP do Programa
de um enlace, dividindo-os em partes menores; Internet da DARPA.

11 Endereçamento: permite identificar o destino e a origem dos pacotes a partir do ende-

reço armazenado no cabeçalho do protocolo.

A versão do protocolo IP utilizada na época e atualmente é a versão 4 (IPv4). Ela mostrou-se

muito robusta e de fácil implantação e interoperabilidade; entretanto, seu projeto original
não previu alguns aspectos, como:

11 O crescimento das redes e um possível esgotamento dos endereços IP;

11 O aumento da tabela de roteamento;

11 Problemas relacionados à segurança dos dados transmitidos;

11 Prioridade na entrega de determinados tipos de pacotes.

Esgotamento dos endereços IPv4

IPv4 = 4.294.967.296 endereços. q
Política inicial de distribuição de endereços:

11 Classe A:

22 IBM, HP, AT&T, MIT, DoD, US Army e USPS.

11 Classe B.

11 Classe C.

11 Endereços reservados.

As especificações do IPv4 reservam 32 bits para endereçamento, possibilitando gerar mais

de 4 bilhões de endereços distintos. Inicialmente, esses endereços foram divididos em três
classes de tamanhos fixos, da seguinte forma:

11 Classe A: define o bit mais significativo como 0, utiliza os 7 bits restantes do primeiro
octeto para identificar a rede, e os 24 bits restantes para identificar o host. Esses ende-
reços utilizam a faixa de 1.0.0.0 até 126.0.0.0;

11 Classe B: define os 2 bits mais significativos como 10, utiliza os 14 bits seguintes para
identificar a rede, e os 16 bits restantes para identificar o host. Esses endereços utilizam a
faixa de 128.1.0.0 até 191.254.0.0;

11 Classe C: define os 3 bits mais significativos como 110, utiliza os 21 bits seguintes para
identificar a rede, e os 8 bits restantes para identificar o host. Esses endereços utilizam a
faixa de 192.0.1.0 até 223.255.254.0.

Classe Formato Redes Hosts

A 7 bits rede, 24 bits host 128 16.777.216

IPv6 Básico

B 14 bits rede, 16 bits host 16.384 65.536 Tabela 1.1

Classes de
C 21 bits rede, 8 bits host 2.097.152 256 endereço IPv4.

4
 Embora o intuito dessa divisão tenha sido tornar a distribuição de endereços mais flexível,
abrangendo redes de tamanhos variados, esse tipo de classificação mostrou-se ineficiente.
Dessa forma, a classe A atenderia um número muito pequeno de redes, mas ocupava
metade de todos os endereços disponíveis; para endereçar 300 dispositivos em uma rede,
seria necessário obter um bloco de endereços da classe B, desperdiçando assim quase o
total dos 65 mil endereços; e os 256 endereços da classe C não supriam as necessidades da
grande maioria das redes.

Outro fator que colaborava com o desperdício de endereços era o fato de que dezenas de
faixas classe A foram atribuídas integralmente a grandes instituições como IBM, AT&T, Xerox,
HP, Apple, MIT, Ford, DoD, entre muitas outras, disponibilizando para cada uma 16.777.216
milhões de endereços. Além disso, 35 faixas de endereços classe A foram reservadas para
Multicast finalidades específicas, como multicast, loopback e uso futuro.
Técnica que permite a entrega
de cópias de um mesmo pacote Em 1990, já existiam 313.000 hosts conectados à rede, e estudos já apontavam para um
a um determinado subconjunto possível colapso causado pela falta de endereços. Os problemas do aumento da tabela de
de estações.
roteamento se agravava, conforme a internet evoluía.

Loopback Devido ao ritmo de crescimento da internet e da política de distribuição de endereços, em

Endereço IP reservado maio de 1992 já estavam alocados 38% das faixas de endereços classe A, 43% da classe B e
(127.0.0.0) que é utilizado para
2% da classe C. Nessa época, a rede já possuía 1.136.000 hosts conectados.
referenciar a interface de
loopback.
Em 1993, com a criação do protocolo HTTP e a liberação por parte do governo norte-americano
para a utilização comercial da internet, houve um salto ainda maior na taxa de crescimento
da rede, que passou de 2.056.000 hosts em 1993 para mais de 26.000.000 de hosts em 1997.

Data Hosts Domínios

1981 213 –

1982 235 –

1983 562 –

1984 1.024 –

d 1985 1.961 –
Mais informações nas
1986 5.089 –
RFCs:
1287: Towards the 1987 28.174 –
Future Internet
Architecture. 1988 56.000 1.280
1296: Internet Growth
(1981-1991). 1989 159.000 4.800
3330: Special-Use IPv4
Addresses. 1990 313.000 9.300

1991 617.000 18.000

Capítulo 1 - Histórico do IPv6

1992 1.136.000 17.000

1993 2.056.000 26.000

1994 3.212.000 46.000

1995 8.200.000 120.000

Tabela 1.2
O crescimento 1996 16.729.000 488.000
da internet
desde 1981. 1997 26.053.000 1.301.000

5
 Mapa de endereços IPv4
Visualização das informações da tabela de roteamento BGP.

Figura 1.3
Mapa de endereços
IPv4 (fonte: The
Measurement
Factory).

Essa imagem, extraída do projeto Routeviews, mostra uma visualização das informações da
tabela de roteamento BGP. Nela, o espaço de endereço IPv4 unidimensional é mapeado em
uma imagem de bidimensional, onde blocos CIDR sempre aparecem como quadrados ou
Para saber mais sobre
retângulos. o mapa de endereços
IPv4, acesse:
É possível observar, na figura, os grandes blocos classe A, no quadrante esquerdo superior, http://maps.measure-
distribuídos para instituições como HP, DEC, AT&T, Apple, MIT, GE, Level3, IBM, Merit etc. e ment-factory.com/
como, desproporcionalmente, regiões como a do LACNIC usaram pouco espaço.

Soluções paliativas
11 1992: IETF cria o grupo Routing and Addressing (ROAD). q
11 CIDR (RFC 4632)‫‏‬:

22 Fim do uso de classes = blocos de tamanho apropriado.

22 Endereço de rede = prefixo/comprimento.

22 Agregação das rotas = reduz o tamanho da tabela de rotas.

11 DHCP:

22 Alocações dinâmicas de endereços.

11 NAT + RFC 1918:

22 Permite conectar toda uma rede de computadores usando apenas um endereço

público na internet, porém com várias restrições.

Diante desse cenário, a Internet Engineering Task Force (IETF) passa a discutir estratégias IETF
IPv6 Básico

para solucionar a questão do esgotamento dos endereços IP e o problema do aumento da Grupo de pesquisa-
dores que atua como
tabela de roteamento. Para isso, em novembro de 1991, é formado o grupo de trabalho
corpo editorial e de
Routing and Addressing (ROAD), que apresenta como solução a esses problemas a utilização revisão técnica dos
do Classless Inter-domain Routing (CIDR). padrões da internet.

6
 Definido na RFC 4632, que tornou obsoleta a RFC 1519, o CIDR tem como ideia básica o fim
do uso de classes de endereços, permitindo a alocação de blocos de tamanho apropriado à
real necessidade de cada rede; e a agregação de rotas, reduzindo o tamanho da tabela de
roteamento. Com o CIDR os blocos são referenciados como prefixo de redes. Por exemplo,
no endereço a.b.c.d/x, os x bits mais significativos indicam o prefixo da rede. Outra forma de
indicar o prefixo é através de máscaras. Por exemplo, a máscara 255.0.0.0 indica um prefixo
/8, a máscara 255.255.0.0 indica um /16, e assim sucessivamente.

Outra solução, apresentada na RFC 2131, que tornou obsoleta a RFC 1541, foi o protocolo
DHCP Dynamic Host Configuration Protocol (DHCP). Através do DHCP um host é capaz de obter um
Protocolo de aplicação endereço IP automaticamente e adquirir informações adicionais, como máscara de sub-rede,
adotado no serviço de
endereço do roteador padrão e o endereço do servidor DNS local.
configuração dinâmica
de estações da arquite-
O DHCP tem sido muito utilizado por parte dos ISPs, por permitir a atribuição de endereços
tura TCP/IP, que permite
a uma estação obter IP temporários a seus clientes conectados. Dessa forma, torna-se desnecessário obter um
diversas informações de endereço para cada cliente, devendo-se apenas designar endereços dinamicamente, através
configuração, incluindo
de seu servidor DHCP. Esse servidor terá uma lista de endereços IP disponíveis, e toda vez
o endereço IP e a
máscara de rede. que um novo cliente se conectar à rede, um desses endereços será designado a ele de forma
arbitrária. Então, no momento que o cliente se desconecta, o endereço é devolvido.

IPv4
Internet

Provedor
Residência
NAT ou empresa

Figura 1.4
Network Address
Translation (NAT).
Capítulo 1 - Histórico do IPv6

NAT
11 Vantagens: q
22 Reduz a necessidade de endereços públicos.

22 Facilita a numeração interna das redes.

22 Oculta a topologia das redes.

22 Só permite a entrada de pacotes gerado em resposta a um pedido da rede.

7
 11 Desvantagens: q
22 Quebra o modelo fim-a-fim da internet.

22 Dificulta o funcionamento de uma série de aplicações.

22 Não é escalável.

22 Aumenta o processamento no dispositivo tradutor.

22 Gera falsa sensação de segurança.

22 Impossibilidade de rastrear o caminho do pacote.

22 Impossibilita a utilização de algumas técnicas de segurança como IPSec.

A Network Address Translation (NAT) foi outra técnica paliativa desenvolvida para resolver
o problema do esgotamento dos endereços IPv4. Definida na RFC 3022 (tornou obsoleta a
RFC 1631), tem como ideia básica permitir que, com um único endereço IP, ou um pequeno
número deles, vários hosts possam trafegar na internet. Dentro de uma rede, cada compu-
tador recebe um endereço IP privado único, que é utilizado para o roteamento do tráfego Endereço IP privado
interno. No entanto, quando um pacote precisa ser roteado para fora da rede, uma tradução Endereço IP reservado
de endereço é realizada, convertendo endereços IP privados em endereços IP públicos que possui unicidade
local e pode ser usado
globalmente únicos. de forma aberta por
qualquer organização,
Para tornar possível esse esquema, utilizam-se os três intervalos de endereços IP declarados sem autorização prévia.
como privados na RFC 1918, sendo que a única regra de utilização é que nenhum pacote
contendo esses endereços pode trafegar na internet pública. As três faixas reservadas são: Endereço IP público
Endereço IP que possui
11 10.0.0.0 a 10.255.255.255 /8 (16.777.216 hosts); unicidade global e
somente pode ser
11 172.16.0.0 a 172.31.255.255 /12 (1.048.576 hosts);
alocado para uma orga-
11 192.168.0.0 a 192.168.255.255 /16 (65.536 hosts). nização através de uma
instituição autorizada
A utilização da NAT mostrou-se eficiente no que diz respeito à economia de endereços IP, da internet.
além de apresentar alguns outros aspectos positivos, como facilitar a numeração interna
das redes, ocultar a topologia das redes e só permitir a entrada de pacotes gerados em
resposta a um pedido da rede. No entanto, o uso da NAT apresenta inconvenientes que não
compensam as vantagens oferecidas.

A NAT quebra o modelo fim-a-fim da internet, não permitindo conexões diretas entre dois hosts,
o que dificulta o funcionamento de uma série de aplicações, como P2P, VoIP e VPNs. Outro
problema é a baixa escalabilidade, pois o número de conexões simultâneas é limitado, além
de exigir um grande poder de processamento do dispositivo tradutor. O uso da NAT também
impossibilita rastrear o caminho do pacote, através de ferramentas como traceroute, e dificulta
a utilização de algumas técnicas de segurança, como IPSec. Além disso, seu uso passa uma falsa
sensação de segurança, pois, apesar de não permitir a entrada de pacotes não autorizados, a
NAT não realiza nenhum tipo de filtragem ou verificação nos pacotes que passam por ela.
IPv6 Básico

8
 200

150

Blocos de endereços /8
100

NAT + CIDR
50

Figura 1.5
Alocações de
endereços IPv4 ao
0
longo do tempo 1985 1990 1995 2000 2005
pela IANA (fonte:
ICANN).
Alocações da IANA

Embora essas soluções tenham diminuído a demanda por IPs, não foram suficientes para
Internet Assigned
Numbers Authority resolver os problemas decorrentes do crescimento da internet. A adoção dessas técnicas
(IANA) reduziu em apenas 14% a quantidade de blocos de endereços solicitados à IANA, e a curva
Autoridade respon- de crescimento da internet continuava apresentando aumento exponencial.
sável pela alocação
dos números de portas Essas medidas, na verdade, serviram para que houvesse mais tempo para o desenvolvimento
reservadas e regis-
de uma nova versão do IP, que fosse baseada nos princípios que fizeram o sucesso do IPv4,
tradas.
mas que também fosse capaz de suprir as falhas apresentadas por ele.

Mais informações:

11 RFC 1380: IESG Deliberations on Routing and Addressing.

11 RFC 1918: Address Allocation for Private Internets.

11 RFC 2131: Dynamic Host Configuration Protocol.

11 RFC 2775: Internet Transparency.

11 RFC 2993: Architectural Implications of NAT.

11 RFC 3022: Traditional IP Network Address Translator (Traditional NAT).

11 RFC 3027: Protocol Complications with the IP Network Address Translator.

11 RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and
Aggregation Plan.

Nova versão do IP
11 Essas medidas geraram mais tempo para desenvolver uma nova versão do IP. q
11 1992: IETF cria o grupo IP Next Generation (IPng).

11 Principais questões:
Capítulo 1 - Histórico do IPv6

22 Escalabilidade.

22 Segurança.

22 Configuração e administração de rede.

22 Suporte a QoS.

22 Mobilidade.

22 Políticas de roteamento.

22 Transição.

9
 A IETF formalizou através da RFC 1550, em dezembro de 1993, as pesquisas a respeito da
nova versão do protocolo IP, solicitando o envio de projetos e propostas para o novo proto-
colo. Essa foi umas das primeiras ações do grupo de trabalho da IETF denominado Internet
Protocol Next Generation (IPng).

Soluções
11 CATNIP. q
11 TUBA.

11 SIPP.

11 IPng.

11 IPv6.

IP Encaps SIP PIP Simple CLNP Nimrod TP/IX

IPAE TUBA CATNIP

SIP

SIPP

SIPP TUBA CATNIP

SIPP 128
bits ver.

Figura 1.6
IPng Evolução das
propostas de uma
nova versão do
IPv6 protocolo IP (fonte:
Migrating to IPv6).

Diversos projetos começaram a estudar os efeitos do crescimento da internet, sendo os

principais o CNAT, o IP Encaps, o Nimrod e o Simple CLNP. Dessas propostas surgiram o TCP
and UDP with Bigger Addresses (TUBA), que foi uma evolução do Simple CLNP, e o IP Address
Encapsulation (IPAE), uma evolução do IP Encaps. Alguns meses depois foram apresentados
os projetos Paul’s Internet Protocol (PIP), o Simple Internet Protocol (SIP) e o TP/IX. Uma nova
versão do SIP, que englobava algumas funcionalidades do IPAE, foi apresentada pouco antes
de agregar-se ao PIP, resultando no Simple Internet Protocol Plus (SIPP). No mesmo período,
o TP/IX mudou seu nome para Common Architecture for the Internet (CATNIP).

Em janeiro de 1995, na RFC 1752, o IPng apresentou um resumo das avaliações das três
principais propostas:

11 CATNIP: foi concebido como um protocolo de convergência, para permitir a qualquer

IPv6 Básico

protocolo da camada de transporte ser executado sobre qualquer protocolo de camada

de rede, criando um ambiente comum entre os protocolos da internet, OSI e Novell;

10
11 TUBA: sua proposta era aumentar o espaço para endereçamento do IPv4 e torná-lo mais
hierárquico, buscando evitar a necessidade de alteração dos protocolos das camadas de
transporte e aplicação. Pretendia uma migração simples e em longo prazo, baseada na
atualização dos hosts e servidores DNS, sem a necessidade, entretanto, de encapsula-
mento ou tradução de pacotes, ou mapeamento de endereços;

11 SIPP: concebido para ser uma etapa evolutiva do IPv4, sem mudanças radicais e man-
tendo a interoperabilidade com a versão 4 do protocolo IP, fornecia uma plataforma para
novas funcionalidades da internet, aumentava o espaço para endereçamento de 32 bits
para 64 bits, apresentava nível maior de hierarquia e era composto por um mecanismo
que permitia “alargar o endereço”, chamado de cluster addresses. Já possuía cabeçalhos
de extensão e um campo flow para identificar o tipo de fluxo de cada pacote;

Por que o protocolo IP passou da versão 4 direto para a versão 6? Existiu uma versão 5
experimental, também conhecida como IPST, para trafegar voz e vídeo sobre multicast.
Não chegou a ser amplamente utilizada. Ainda hoje podemos encontrar muitos de seus
conceitos no protocolo MPLS.

Entretanto, conforme relatado também na RFC 1752, todas as três propostas apresentavam
problemas significativos. Desse modo, a recomendação final para o novo Protocolo Internet
baseou-se em uma versão revisada do SIPP, que passou a incorporar endereços de 128 bits,
juntamente com os elementos de transição e autoconfiguração do TUBA, o endereçamento
baseado no CIDR e os cabeçalhos de extensão. O CATNIP, por ser considerado muito
incompleto, foi descartado.

Após essa definição, a nova versão do Protocolo Internet passou a ser chamada
oficialmente de IPv6.

Mais informações:

11 RFC 1550: IP: Next Generation (IPng) White Paper Solicitation;

11 RFC 1752: The Recommendation for the IP Next Generation Protocol.

IPv6
11 Definido pela RFC 2460 em 1998. q
11 128 bits para endereçamento.

11 Cabeçalho base simplificado.

11 Cabeçalhos de extensão.

11 Identificação de fluxo de dados (QoS).

11 Mecanismos de IPSec incorporados ao protocolo.

Capítulo 1 - Histórico do IPv6

11 Realiza a fragmentação e remontagem dos pacotes apenas na origem e no destino.

11 Não requer o uso de NAT, permitindo conexões fim-a-fim.

11 Mecanismos que facilitam a configuração de redes.

11
 As especificações da IPv6 foram apresentadas inicialmente na RFC 1883, em dezembro
de 1995. No entanto, essa RFC foi substituída em dezembro de 1998 pela RFC 2460.
Como principais mudanças em relação ao IPv4, destacam-se:

11 Maior capacidade para endereçamento: no IPv6 o espaço para endereçamento

aumentou de 32 bits para 128 bits, permitindo: níveis mais específicos de agregação de
endereços; identificação de quantidade muito maior de dispositivos na rede; e implemen-
tação de mecanismos de autoconfiguração. A escalabilidade do roteamento multicast
também foi melhorada através da adição do campo escopo no endereço multicast. E um
novo tipo de endereço, o anycast, foi definido;

11 Simplificação do formato do cabeçalho: alguns campos do cabeçalho IPv4 foram remo-

vidos ou tornaram-se opcionais, com o intuito de reduzir o custo do processamento dos
pacotes nos roteadores;

11 Suporte a cabeçalhos de extensão: as opções não fazem mais parte do cabeçalho base,
permitindo roteamento mais eficaz, limites menos rigorosos em relação ao tamanho e à
quantidade de opções, e maior flexibilidade para a introdução de novas opções no futuro;

11 Capacidade de identificar fluxos de dados: foi adicionado um novo recurso que

permite identificar pacotes que pertençam a determinados tráfegos de fluxos, para os
quais podem ser requeridos tratamentos especiais;

11 Suporte a autenticação e privacidade: foram especificados cabeçalhos de extensão

capazes de fornecer mecanismos de autenticação e garantir a integridade e a confiden-

d
cialidade dos dados transmitidos.

Além disso, o IPv6 também apresenta mudanças no tratamento da fragmentação dos

Saiba mais
pacotes, agora realizada apenas na origem; permite o uso de conexões fim-a-fim, princípio
que havia sido quebrado com o IPv4 devido à grande utilização de NAT; traz recursos que RFC 2460: Internet Pro-
facilitam a configuração de redes, além de outros aspectos que foram melhorados em tocol, Version 6 (IPv6)
Specification.
relação ao IPv4.

Por que utilizar IPv6 hoje?

A internet continua crescendo. q
11 Mundo:

22 1.966.514.816 usuários de internet.

22 28,7% da população.

22 Crescimento de 444,8% nos últimos 10 anos.

22 Em 2014, soma de celulares, smartphones, netbooks e modens 3G deve chegar a

2,25 bilhões de aparelhos.

11 Brasil:

22 27% de domicílios com acesso à internet.

22 3,5 milhões de conexões em banda larga móvel.

22 11 milhões de conexões em banda larga fixa.

IPv6 Básico

12
 Internet Domain Survey Host Count

800.000.000

700.000.000

600.000.000

500.000.000

400.000.000

300.000.000

200.000.000

100.000.000

0
Jan - 94

Jan - 95

Jan - 96

Jan - 97

Jan - 98

Jan - 99

Jan - 00

Jan - 01

Jan - 02

Jan - 03

Jan - 04

Jan - 05

Jan - 06

Jan - 07

Jan - 08

Jan - 09

Jan - 10
Figura 1.7 Source: Internet Systems Consortium (www.isc.org)
Crescimento do
número de hosts
na internet (fonte: Durante os últimos dez anos, durante o desenvolvimento do IPv6, a internet continuou
Internet Systems apresentando ritmo de crescimento cada vez mais acelerado. O número de hosts conec-
Consortium). tados à internet saltou de 30 milhões para aproximadamente 732 milhões em Jan/2010, com
número cada vez maior de usuários e dispositivos conectados à rede.

Essa expansão da internet pode ser medida por diversos fatores, e inúmeras pes-
quisas têm mostrado que esse crescimento não ocorre de forma isolada.

Estima-se que existam no mundo 1.966.514.816 usuários de internet, ou 28,7% da população da

Terra, o que representa, considerando os últimos nove anos, crescimento de 444,8%. Mantendo
esse ritmo de crescimento, dentro de dois anos serão dois bilhões de usuários, superando a pre-
visão de que esse número só seria alcançado em 2015. A tabela a seguir detalha esses números,
apresentando a penetração e o crescimento da internet em cada região do mundo.

Segundo dados da ABI Research, a quantidade de equipamentos móveis fabricados com

capacidade de acesso à internet, como celulares, smartphones, netbooks e modems 3G, foi
de 1,2 bilhão em 2009, número que deverá chegar a 2,25 bilhões em 2014.
Capítulo 1 - Histórico do IPv6

13
 Regiões População Usuários de Usuários de % por Região Crescimento
(em 2010) Internet Internet (atu- 2000-2010
(em 2000) almente)

África 1.013.779.050 4.514.400 110.931.700 10,9% 2.357,3%

Ásia 3.834.792.852 114.304.000 825.094.396 21,5% 621,8%

Europa 813.319.511 105.096.093 475.069.448 58,4% 352,0%

Oriente Médio 212.336.924 3.284.800 63.240.946 29,8% 1.825,3%

América Norte 344.124.450 108.096.800 266.224.500 77,4% 146,3%

América Latina 592.556.972 18.068.919 204.689.836 34,5% 1.032,8%

Caribe

Oceania 34.700.201 7.620.480 21.263.990 61,3% l79,0%

TOTAL 6.845.609.960 360.985.492 1.966.514.816 28,7% 444,8%

Seguindo essa tendência, no Brasil o percentual de domicílios com acesso à internet, via Tabela 1.3
computadores domésticos, aumentou de 12,93% em 2005, para 27% em 2009. Já o número Crescimento
dos usuários de
de conexões através de banda larga fixa alcançou o total de 11 milhões, superado em 2010 internet 2000-2009
pelo número de acessos a banda larga móvel. (fonte: www.
internetworldstats.
com).
Demanda crescente por endereços IPv4
Com isso, a demanda por endereços IPv4 também cresce: q
11 Em 2011 foram atribuídos pela IANA os últimos blocos /8 aos RIRs;

11 Estes últimos blocos poderão ser atribuídos pelos RIRs de forma restrita

Em setembro de 2008, os RIRs chegaram a um acordo quanto à política que será adotada pela RIR
IANA quando sua reserva de endereços atingir o limite de 5 blocos /8. Esses últimos /8 serão Regional Internet
Registries (Registros
imediatamente atribuídos a cada RIR, que os atribuirão entre os ISPs e Registros Nacionais.
Regionais de Internet).
Como consequência desse crescimento, a demanda por endereços IP também cresce
consideravelmente. Em 2011 foram atribuídos pelo IANA os últimos 5 blocos /8 ao RIRs.

IANA

Últimos blocos IPv4

LACNIC ARIN RIPENCC AFRINIC APNIC atribuídos
América América Eurásia/
Africa Asia/Pacífico
Latina do Norte Oriente Médio
102/8 – AfriNIC
Registros 103/8 – APNIC
Regionais da 104/8 – ARIN
NIC Internet 179/8 – LACNIC
APJII KRNIC
185/8 – RIPE NCC
México Indonésia Coréia

NIC CNNIC TWNIC

Brasil China Taiwan
IPv6 Básico

Registros
Nacionais da Figura 1.8
Internet JPNIC VNNIC Estrutura dos
Japão Vietnã Registros Regionais
da Internet.

14
 Governança da internet
11 Internet Assigned Numbers Authority (IANA). q
11 Internet Corporation for Assigned Names and Numbers (ICANN).

11 Registros Regionais de Internet (Regional Internet Registries – RIR).

22 African Network Information Centre (AfriNIC).

22 Asia-Pacific Network Information Centre (APINIC).

22 American Registry for Internet Numbers (ARIN).

22 Latin American and Caribbean Internet Addresses Registry (LACNIC).

22 Réseaux IP Européens Network Coordination Centre (RIPE NCC).

11 Registro Nacional de Internet (National Internet Registry – NIR).

22 Núcleo de Informação e Coordenação do Ponto BR (NIC.br).

11 Registros Locais de Internet (Local Internet Registry – LIR).

Figura 1.9
Gerenciamento
dos endereços IP
na internet (fonte:
IANA).

Embora a internet seja conhecida como uma rede mundial livre de uma coordenação
central, há órgãos responsáveis por administrar os principais aspectos técnicos necessários

l
ao seu funcionamento. As atribuições desses órgãos são distribuídas em nível mundial,
respeitando uma estrutura hierárquica.
A responsabilidade pela
distribuição local dos A Internet Assigned Numbers Authority (IANA) é a responsável pela coordenação e alocação
endereços IP é dos
Registros de Internet global do espaço de endereços IP e dos ASNs. Desde 1998, a IANA passou a operar através
(Internet Registry – IR), da Internet Corporation for Assigned Names and Numbers (ICANN), uma organização inter-
que são classificados
nacional dirigida por um conselho de diretores, provenientes de diversos países, que super-
de acordo com sua
função principal e visiona a ICANN e as políticas elaboradas por ela, trabalhando em parceria com governos,
alcance territorial empresas e organizações criadas por tratados internacionais, envolvidos na construção e
dentro da estrutura
Capítulo 1 - Histórico do IPv6

manutenção da internet.
hierárquica da internet.

Os Registros Regionais de Internet (Regional Internet Registries – RIR) são órgãos, reconhe-
cidos pela IANA, que atuam e representam grandes regiões geográficas. A função primordial
de um RIR é gerenciar e distribuir endereços IP públicos dentro de suas respectivas regiões.
Existem cinco RIRs:

11 African Network Information Centre (AfriNIC), que atua na região da África;

11 Asia-Pacific Network Information Centre (APINIC), atuando na Ásia e na região do Pacífico;

15
 11 American Registry for Internet Numbers (ARIN), responsável pela América do Norte;

11 Latin American and Caribbean Internet Addresses Registry (LACNIC), que atua na América
Latina e em algumas ilhas do Caribe;

11 Réseaux IP Européens Network Coordination Centre (RIPE NCC), que serve a Europa e
países da Ásia Central.

Um Registro Nacional de Internet (National Internet Registry – NIR) é o responsável pela alo-
cação dos endereços IP em nível nacional, distribuindo-os aos Registros Locais de Internet
(Local Internet Registry – LIR). Os LIRs são geralmente Internet Service Providers (ISPs), que
por sua vez podem oferecer esses endereços aos usuários finais ou outros ISPs.

No Brasil, o NIR responsável pela distribuição de endereços IP e do registro de nomes de

domínios (usando “.br”) é o Núcleo de Informação e Coordenação do Ponto BR (NIC.br).

Evolução do estoque de blocos IP na IANA

125

107 103
96 92
100 87

78

75 65
55
48
50
34
26
25
14

0
0
1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

Figura 1.10
Esse gráfico apresenta a evolução do estoque de blocos IP na IANA ao longo dos últimos Evolução do estoque
anos, até 2011. de blocos IPs até
2011 (fonte: NIC.br).
IPv6 Básico

16
6
/8s

0
1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009

AfriNIC APNIC ARIN LACNIC RIPE NCC

Figura 1.11
Registros de IP e
registro de nomes
de domínios por Como está a implantação do IPv6?
regiões, até 2009.
11 Ritmo lento da adoção do IPv6. q
11 Expectativa de que o IPv6 fosse o padrão da internet.

11 NAT e DHCP.

11 IPv4 se mostrou confiável.

11 Dificuldades na implementação do IPv6.

22 Receio de mudanças e seus impactos.

22 Investimento na atualização de roteadores e switches.

22 Capacitação dos técnicos.

Capítulo 1 - Histórico do IPv6

17
 IPv4 disponíveis

v6
IP
do
rnet ão
n to da inte taç
Crescime an
pl
Im

Transição utilizando pilha dupla

6 - 10 anos

2000 2006 - 2010

Embora todos os números confirmem a necessidade de mais endereços IP, questão que será Figura 1.12
resolvida com a adoção do IPv6, o ritmo de implantação da nova versão do protocolo IP não Previsão inicial de
crescimento do
está ocorrendo da forma prevista no início de seu desenvolvimento, que apontava o IPv6 IPv6 (fonte: Geoff
como protocolo padrão da internet em aproximadamente dez anos após sua definição; se Huston e George
isso realmente tivesse ocorrido, o objetivo desse curso provavelmente seria outro. Michaelson).

Hoje

IPv4 disponíveis

ternet
nto da in
Crescime

Transição ?

Implantação do IPv6

Ainda há muita discussão em torno da implantação do IPv6 e alguns fatores têm atrasado a Figura 1.13
implantação do novo protocolo. Técnicas como NAT e o DHCP, apesar de dar-nos tempo para Situação atual do
crescimento do
desenvolver o IPv6, colaboraram para a demora em sua adoção. Aliado a isso, há o fato de o
IPv6 Básico

IPv6 (fonte: Geoff

IPv4 não apresentar graves problemas de funcionamento. Huston e George
Michaelson).
Também é preciso destacar que até o momento, a utilização do IPv6 está ligada princi-
palmente à área acadêmica, e para que a internet passe a utilizá-lo em grande escala, é

18
 necessário que a infraestrutura dos principais ISPs seja capaz de transmitir tráfego IPv6 de
forma nativa. No entanto, sua implantação em redes maiores tem encontrado dificuldades,
entre outros fatores por causa do receio de mudanças radicais na forma de gerenciá-las, dos
gastos com a troca de equipamentos como roteadores e switches, e despesas com o apren-
dizado e treinamento para a área técnica.

A transição do IPv4 para o IPv6

O IPv6 foi projetado de tal forma que não é compatível com o IPv4. Eles não podem intero-
perar diretamente. Ainda assim, o plano inicial para a transição era muito simples: ambos os
protocolos podem conviver, sem problemas, nos mesmos equipamentos e softwares.
O plano inicial era, então, fazer uma transição gradual, mantendo o IPv4, e adicionando o
IPv6 em todos os dispositivos da internet ao longo do tempo, de forma que, antes dos ende-
reços livres IPv4 esgotaram-se, o IPv6 estivesse instalado em toda a internet.

IPv4
Jan 1983 Esgotamento do IPv4

Desativação do IPv4
Projeto

Implantação IPv6 em toda a Internet

IPv6
1994
Figura 1.14 IPv6
Plano inicial de 1998
Técnicas de Transição / Túneis
transição para o
IPv6.

Tecnicamente, o plano ilustrado na Figura 1.13 era muito simples de ser executado. Contudo,
este não levou em consideração aspectos econômicos e políticos em toda a sua complexi-
dade. Embora o IPv6 tenha sido projetado para ser um protocolo melhor do que o IPv4, a
característica que realmente se sobressai é a grande capacidade de endereçamento. Ele
pode até ser superior em outros aspectos, mas não de forma que seja considerado um
grande diferencial. Os gestores de TI viram-se ante a seguinte situação: na última década
ou pouco mais, sabiam da importância do IPv6 e de sua implantação, mas sabiam também
que teriam de gastar recursos para isso, sem benefícios a curto prazo, e que se não fizessem
nada o problema real só se manifestaria após muito tempo. Ou seja, poderiam adiar a
implantação do IPv6, aparentemente sem consequências negativas, e assim a maioria o fez.

O atraso na implantação do IPv6 na internet nos fez chegar em um ponto em que o esgota-

l mento do IPv4 já é uma realidade, e o IPv6 está longe de estar difundido em toda a internet.
Capítulo 1 - Histórico do IPv6

Nessa situação os novos usuários da rede necessitam ainda de IPs versão 4, para acessar
Nessa situação, são
necessárias tecnologias conteúdo e serviços que ainda não implantaram o novo protocolo.
para a transição que
permitam que, ao É uma situação transitória, e espera-se que dure muito pouco. Em alguns lugares pode ser
mesmo tempo em que mesmo que ainda possa ser evitada, caso se acelere suficientemente a implantação do IPv6
se implanta o IPv6, se
por parte dos provedores de serviço na rede. Espera-se que a transição para o IPv6 seja rápida.
compartilhe também
endereços IPv4. Provavelmente ele estará plenamente difundido na internet nos próximos dois a quatro anos.

19
 IPv4 Esgotamento
Jan 1983 do IPv4

IPv4 Desativação do IPv4

Compartilhado

Projeto
Implantação IPv6 em toda a Internet
IPv6
1994
Figura 1.15
IPv6 Novas técnicas / Túneis / Tradução Novo plano de
1998
Técnicas de Transição / Túneis transição.

No Brasil, construiu-se o cronograma ilustrado na Figura 1.15, como referência para a implan-
tação do protocolo no país. Ele foi construído com base no diálogo com diversos provedores
de acesso, de serviços e operadoras de telecomunicações, em diversas reuniões de coorde-
nação ao longo dos anos de 2011 e 2012. Ele tem por trás de si, uma lógica muito simples:

11 Em primeiro lugar os provedores de trânsito internet (as grandes operadoras de telecom e

Sistemas Autônomos em geral que oferecem trânsito para outros ASes) devem preparar-se;

11 Uma vez que os provedores de serviços e companhias em geral tenham como conseguir
conectividade internet, os serviços (sites em geral, comércio eletrônico, bancos, governos
etc.) devem migrar para IPv6. Essa migração deve ser feita rapidamente. Quanto mais
rápida e efetiva for essa migração, melhor será para todos: os sites não terão o risco de
perderem audiência, ou terem usuários que os acessarão com potenciais problemas, e os
provedores de acesso terão menos motivos para utilizarem o compartilhamento de IPv4
numa fase de transição;

11 Por fim, os provedores de acesso devem fazer chegar o IPv6 aos usuários domésticos.
Primeiro aos novos usuários, e depois aqueles já conectados à internet via IPv4.

Com base nesse cronograma, o Comitê Gestor da Internet no Brasil emitiu a Resolução
CGI.br/RES/2012/007/P.

Semana IPv6
Websites brasileiros e outros
serviços na Internet, como e-mail,
Provedores de trânsito devem ativar o IPv6
brasileiros devem
Provedores e operadoras de oferecer IPv6 a seus Os provedores devem
telecom devem oferecer IPv6 clientes corporativos oferecer IPv6 para os
para seus grandes clientes, novos usuários Internet
como grandes sites, outros Os que puderem, devem
provedores e datacenters participar do world IPv6 Launch IPv6 para todos

Dez 2011 Fev 2012 Jun/Jul 2012 Jan 2013 Jan 2014

30 anos de IPv4 na Internet

IPv6 Básico

Figura 1.16
Cronograma
Brasileiro de
migração para
o IPv6.

20
 IPv6 em uso
11 15% dos ASs trabalham sobre IPv6. q
11 9 dos 13 root DNS servers são acessíveis via IPv6.

11 3% dos 1.000.000 de sítios web mais visitados da Internet são acessíveis via IPv6.

11 0,51% de clientes da Google possuem IPv6 ativado.

0.300%
0.264% 0.261%

0.250%

0.200%

0.189% 0.192%

0.150%

0.100%

0.050%

0.000%
10 - Ago

24 - Ago

07 - Set

21 - Set

05 - Out

19 - Out

02 - Nov

16 - Nov

30 - Nov

14 - Dez

28 - Dez

11 - Jan
Figura 1.17 Diversos estudos tentam mensurar a quantidade de informação sobre o protocolo IPv6 que
Porcentagem de clientes trafega na internet. Análises sobre o número de ASs anunciando IPv6, de consultas a servidores
IPv6 do Google em 2009
(fonte: Angus Lees e DNS e que relatam a quantidade de páginas na internet usando IPv6, são alguns exemplos de
Steinar H. Gunderson). como vem se tentando medir a evolução da implantação da versão 6 do Protocolo Internet.

O Google tem realizado uma avaliação do estado atual do uso de IPv6 por usuários comuns,
coletando informações fornecidas pelos navegadores de uma parcela de usuários de seus
Autonomous System
(AS)
serviços. Com isso, foi possível determinar que aproximadamente 0,2% de seus clientes têm

Conjunto de redes o IPv6 ativado, e que a quantidade de acessos utilizando IPv6 subiu de 0,189% (agosto de
controladas por uma 2008) para 0,261% (janeiro de 2009).
única autoridade admi-
nistrativa, que possui Outros dados interessantes apontam que apenas 6,9% dos ASs trabalham sobre IPv6. Des-
total autonomia para taca-se também que 9 dos 13 root DNS servers são acessíveis via IPv6 (A, B, F, H, I, J, K, L e M).
selecionar o protocolo
de roteamento a ser
adotado internamente Troca de tráfego IPv6
q
Capítulo 1 - Histórico do IPv6

no sistema autônomo.
11 Pelo menos 23% dos PTTs no mundo trocam tráfego IPv6.

11 No AM-IX, o tráfego IPv6 trocado é de aproximadamente 1Gbps.

11 O PTTMetro-SP oferece trânsito IPv6 experimental gratuito a seus participantes.

21
 Figura 1.18
Tráfego IPv6 anual
no AMS-IX.

Ponto fundamental da infraestrutura da internet, 23% dos PTTs no mundo trocam tráfego Figura 1.19
IPv6, e em um dos maiores IXPs, o Amsterdam Internet Exchange (AM-IX), o tráfego IPv6 Tráfego IPv6 no
PTTMetro-SP:
trocado é de aproximadamente 1Gbps, o que corresponde a 0,3% do tráfego total. média mensal
(fonte: CEPTRO.br).
No Brasil, desde fevereiro de 2010 o NIC.br oferece para os participantes do PTTMetro-SP o
serviço de trânsito IPv6 experimental gratuitamente. Com a iniciativa, o NIC.br tem o obje-
tivo de promover o uso do protocolo, reduzindo o tempo entre a atribuição dos blocos para
as entidades e seu uso efetivo, permitindo experimentação e facilitando sua implantação.

Alocação de blocos IPv6

11 Dos ~73.000 blocos /32 já alocados pelos RIRs. q
22 Apenas 3% são efetivamente utilizados.
IPv6 Básico

22
 3500

3000

2500
Active BGP entries (FIB)

2000

1500

1000

500

0
04

05

06

07

08

09

10
Date

Figura 1.20 Blocos de endereços IPv6 vêm sendo alocados pelos RIRs há aproximadamente doze anos.
Entradas IPv6 na No entanto, o fato dos RIRs alocarem endereços aos Registros Nacionais ou aos ISPs não
tabela de rotas
global (fonte: bgp. significa que esses endereços estejam sendo utilizados. Ao cruzar os dados sobre a quanti-
potaroo.net). dade de blocos /32 IPv6 já alocados, com o número de rotas anunciadas na tabela de
roteamento, nota-se que apenas 7,5% desses recursos estão sendo efetivamente utilizados,
isto é, dos 103.000 blocos já alocados, apenas pouco mais de 7.700 estão presentes na
Figura 1.21 tabela global de roteamento..
Blocos alocados
para o Brasil versus
blocos roteados Os blocos alocados para o Brasil (apenas 20%) estão sendo efetivamente utilizados.
(fonte: CEPTRO.br).

200

152
150

95
100

50 43
32
13 21
Capítulo 1 - Histórico do IPv6

6
2 3 3 8
4 4
0
12 / 2003

12 - 2004

12 - 2005

12 - 2006

12 - 2007

12 - 2008

12 - 2009

08 - 2010

23
 Como está a implantação do IPv6 no Brasil?
11 No Brasil, e em toda a América Latina, a situação é similar. q
11 Os blocos atribuídos para o LACNIC correspondem a apenas 1,8% dos já atribuídos
mundialmente.

22 Desses 1,8%, 36% estão alocados para o Brasil.

O LACNIC é um RIR que atua na América Latina e Caribe, que já alocou cerca de 700 blocos
/32 IPv6, o que corresponde a aproximadamente 1,8% do total de blocos já alocados
mundialmente.Desses, 36% estão alocados no Brasil, embora apenas 20% estejam sendo
efetivamente utilizados.”.

ASNs

20,437
ARIN

19,961
RIPE NCC
576
AfriNIC
1,644 Figura 1.22
LACNIC
Alocações IPv6
feitas pelos RIRs
5,961 em 23/07/2010
APNIC (fonte: NRO.org).

Riscos de não implantar o IPv6

11 Embora ainda seja pequena, a utilização do IPv6 tem aumentado gradativamente. q
22 Porém, precisa avançar ainda mais.

11 A não implementação do IPv6 vai:

22 Impedir o surgimento de novas redes.

22 Diminuir o processo de inclusão digital, reduzindo o número de novos usuários.

22 Dificultar o surgimento de novas redes.

22 Aumentar a utilização de técnicas como a NAT.

11 O custo de não implementar o IPv6 poderá ser maior que o custo de implementá-lo.

11 Provedores de internet precisam inovar e oferecer novos serviços a seus clientes.

É importante observar que, embora a utilização do IPv6 ainda não tenha tanta representativi-
dade, todos os dados apresentados mostram que sua penetração nas redes tem aumentado
gradativamente. No entanto, é preciso avançar ainda mais. Adiar por mais tempo a implan-
tação do IPv6 pode trazer diversos prejuízos para o desenvolvimento de toda a internet.
IPv6 Básico

24
Como vimos, existe hoje uma demanda muito grande por mais endereços IP, e mesmo que
a internet continue funcionando sem novos endereços, ela terá muita dificuldade para
crescer. A cada dia surgem novas redes, graças à expansão das empresas e ao surgimento
de novos negócios; iniciativas de inclusão digital têm trazido novos usuários para a internet;
o crescimento das redes 3G, assim como a utilização da internet em dispositivos eletrônicos
e eletrodomésticos são exemplos de novas aplicações que colaboram com seu crescimento.

A não implantação do IPv6 provavelmente impedirá o desenvolvimento de todas essas áreas.

Além disso, com o IPv6 elimina-se a necessidade da utilização de NAT, favorecendo o funcio-
namento de várias aplicações. Desse modo, o custo da não utilização, ou do adiamento da
implantação do protocolo IPv6, será muito maior do que o custo de utilizá-lo.

É importante que os provedores internet ofereçam novos serviços a seus clientes, principal-
mente porque a inovação é a chave para competir e manter-se à frente da concorrência.

Capítulo 1 - Histórico do IPv6

25
26
IPv6 Básico
 2
Cabeçalho IPv6
objetivos

Analisar as mudanças na estrutura do cabeçalho do IPv6, e descrever os cabeçalhos

de extensão e seu funcionamento.

conceitos
Cabeçalhos IPv4 e IPv6, campos do cabeçalho IPv6 e aspectos dos cabeçalhos
de extensão.

Cabeçalho IPv4
O cabeçalho IPv4 é composto por 12 campos fixos, podendo conter ou não opções, q
fazendo com que seu tamanho possa variar entre 20 e 60 bytes.

Esses campos são destinados a transmitir informações sobre:

11 A versão do protocolo.

11 O tamanho do cabeçalho e dos dados.

11 Fragmentação.

11 O tipo de dados.

11 O tempo de vida do pacote.

11 O protocolo da camada seguinte (TCP, UDP e ICMP).

11 A integridade dos dados.

11 A origem e o destino do pacote.

Capítulo 2 - Cabeçalho IPv6

27
 0 7 15 31
Versão Tamanho do Tipo de serviço Tamanho total
(Version) cabeçalho (ToS) (Total Length)
(IHL)

Identificação Deslocamento de fragmento

(Identification) Flags (Fragment Offset)

Tempo de vida Protocolo Soma de verificação do cabeçalho

(TTL) (Protocol) (Checksum)

Endereço de origem (Source address)

Endereço de destino (Destination address)

Opções + Complemento
(Options + Padding)

Figura 2.1
Cabeçalho IPv6 Cabeçalho IPv4 –

q
composto por 12
Mais simples: campos fixos.

l
11 40 bytes (tamanho fixo).

11 Apenas duas vezes maior que o cabeçalho da versão anterior.

Essas alterações
Mais flexível: permitiram que, mesmo
com um espaço para
11 Extensão por meio de cabeçalhos adicionais. endereçamento de 128
bits, quatro vezes maior
Mais eficiente:
que os 32 bits do IPv4, o
11 Minimiza o overhead nos cabeçalhos. tamanho total do
cabeçalho IPv6 seja
11 Reduz o custo do processamento dos pacotes. apenas duas vezes maior
que o da versão anterior.
Algumas mudanças foram realizadas no formato do cabeçalho base do IPv6, de modo a
torná-lo mais simples, com apenas oito campos (tamanho fixo de 40 bytes), além de mais
flexível e eficiente, prevendo sua extensão por meio de cabeçalhos adicionais que não pre- Figura 2.2
cisam ser processados por todos os roteadores intermediários. Foram removidos
seis campos do
cabeçalho IPv4.

0 7 15 31

Versão Tamanho do Tipo de serviço Tamanho total

(Version) cabeçalho (ToS) (Total Length)
(IHL)

Identificação Deslocamento de fragmento

(Identification) Flags (Fragment Offset)

Tempo de vida Protocolo Soma de verificação do cabeçalho

(TTL) (Protocol) (Checksum)

Endereço de origem (Source address)

IPv6 Básico

Endereço de destino (Destination address)

Opções + Complemento
(Options + Padding)

28
 0 7 15 31

Versão Classe de tráfego Identificador de fluxo

(Version) (Traffic class) (Flow label)

Tamanho de dados Próximo cabeçalho Limite de encaminhamento

(Payload length) (Next header) (Hop limit)

Endereço de origem (Source address)

Endereço de destino (Destination address)

Figura 2.3 Entre essas mudanças, destaca-se a remoção de seis campos do cabeçalho IPv4, uma vez que
Cabeçalho IPv6: mais simples suas funções não são mais necessárias ou são implementadas pelos cabeçalhos de extensão.
que o cabeçalho IPv4.
No IPv6, as opções adicionais agora fazem parte dos seus cabeçalhos de extensão. Desse
modo, os campos Opções e Complementos puderam ser removidos.
Soma de Verificação
Valor de tamanho fixo O campo Tamanho do Cabeçalho também foi removido, porque o tamanho do cabeçalho IPv6 é fixo.
calculado a partir de um
bloco arbitrário de dados Os campos Identificação, Flags e Deslocamento do Fragmento foram removidos porque as
digitais para a detecção informações referentes à fragmentação são indicadas agora em um cabeçalho de extensão
de erros acidentais que
possam ter sido apropriado.
introduzidos durante a
sua transmissão ou Com o intuito de aumentar a velocidade do processamento dos roteadores, o campo
armazenamento. Soma de Verificação (ou hash) foi retirado, pois esse cálculo já é realizado pelos proto-
colos das camadas superiores.
Capítulo 2 - Cabeçalho IPv6

29
 Versão Tamanho do Tipo de serviço Tamanho total
(Version) cabeçalho (ToS) (Total Length)
(IHL)

Identificação Deslocamento de fragmento

(Identification) Flags (Fragment Offset)

Tempo de vida Protocolo Soma de verificação do cabeçalho

(TTL) (Protocol) (Checksum)

Endereço de origem (Source address)

Endereço de destino (Destination address)

Opções + Complemento
(Options + Padding)

Figura 2.4
Outra mudança refere-se à alteração do nome e do posicionamento de outros quatro campos. Quatro campos
tiveram seus
IPv4 IPv6 nomes alterados e
posicionamentos
Tipo de Serviço Classe de Tráfego modificados.

Tamanho Total Tamanho dos Dados

Tempo de Vida (TTL) Limite de Encaminhamento

Protocolo Próximo Cabeçalho

Esses reposicionamentos foram definidos para facilitar o processamento dessas informações

pelos roteadores.
IPv6 Básico

30
 Versão Classe de tráfego Identificador de fluxo
(Version) (Traffic class) (Flow label)

Tamanho dos dados Próximo cabeçalho Limite de encaminhamento

(Payload length) (Next header) (Hop limit)

Endereço de origem (Source address)

Endereço de destino (Destination address)

Figura 2.5 Também foi adicionado um novo campo, Identificador de Fluxo, sendo acrescentado ao
O campo protocolo IP um mecanismo extra de suporte a QoS.
‘Identificador
de Fluxo’ foi Mais detalhes sobre esse campo e de como o protocolo IPv6 trata a questão do QoS serão
acrescentado
apresentados ao longo deste curso.

Tamanho do
Versão Tipo de serviço Tamanho total
cabeçalho
(Version) (ToS) (Total Length)
(IHL)

Identificação Deslocamento de fragmento

(Identification) Flags (Fragment Offset)

Tempo de vida Protocolo Soma de verificação do cabeçalho

(TTL) (Protocol) (Checksum)

Endereço de origem (Source address)

Capítulo 2 - Cabeçalho IPv6

Endereço de destino (Destination address)

Opções + Complemento
(Options + Padding)

Figura 2.6
Três campos foram
mantidos, do IPv4
para o IPv6.

31
 Versão Classe de tráfego Identificador de fluxo
(Version) (Traffic class) (Flow label)

Tamanho dos dados Próximo cabeçalho Limite de encaminhamento

(Payload length) (Next header) (Hop limit)

Endereço de origem (Source address)

Endereço de destino (Destination address)

Os campos Versão, Endereço de Origem e Endereço de Destino foram mantidos, sendo alterado Figura 2.7
apenas o tamanho do espaço reservado para o endereçamento, que passa a ter 128 bits. Dois campos foram
alterados, do IPv4
Vamos conhecer um pouco sobre cada campo do cabeçalho base do IPv6: para o IPv6.

11 Versão (4 bits): identifica a versão do protocolo IP utilizado. No caso do IPv6, o valor

desse campo é 6;

11 Classe de Tráfego (8 bits): identifica e diferencia os pacotes por classes de serviços

ou prioridade. Continua provendo as mesmas funcionalidades e definições do campo
Tipo de Serviço do IPv4;

11 Identificador de Fluxo (20 bits): identifica e diferencia pacotes do mesmo fluxo na

camada de rede. Esse campo permite ao roteador identificar o tipo de fluxo de cada
pacote, sem a necessidade de verificar sua aplicação;

11 Tamanho dos Dados (16 bits): indica o tamanho, em bytes, apenas dos dados enviados
junto ao cabeçalho IPv6. Substituiu o campo Tamanho Total do IPv4, que indica o tamanho
do cabeçalho acrescido do tamanho dos dados transmitidos. Os cabeçalhos de extensão
também são incluídos no cálculo do tamanho;

11 Próximo Cabeçalho (8 bits): identifica cabeçalho que se segue ao cabeçalho IPv6. Esse
campo foi renomeado (no IPv4, chamava-se Protocolo) refletindo a nova organização dos
IPv6 Básico

pacotes IPv6, pois agora esse campo não contém apenas valores referentes a outros
protocolos, mas também indica os valores dos cabeçalhos de extensão;

32
 11 Limite de Encaminhamento (8 bits): indica o número máximo de roteadores pelos quais
o pacote IPv6 pode passar antes de ser descartado, sendo decrementado a cada salto.
Padronizou o modo como o campo Tempo de Vida (TTL) do IPv4 tem sido utilizado, apesar
da definição original do campo TTL indicar o tempo que o pacote levaria (em segundos)
para ser descartado caso não chegasse ao seu destino;

11 Endereço de Origem (128 bits): indica o endereço de origem do pacote;

11 Endereço de Destino (128 bits): indica o endereço de destino do pacote.

Cabeçalhos de extensão
Figura 2.8
11 No IPv6, opções adicionais são tratadas por meio de cabeçalhos de extensão. q
Exemplos de 11 Localizam-se entre o cabeçalho base e o cabeçalho da camada de transporte.
cabeçalhos de
extensão IPv6. 11 Não há quantidade nem tamanho fixo para esses cabeçalhos.

Cabeçalho IPv6

Próximo Cabeçalho TCP Dados

cabeçalho = 6

Cabeçalho IPv6 Cabeçalho Routing

Próximo Próximo Cabeçalho TCP Dados
cabeçalho = 43 cabeçalho = 6

Cabeçalho IPv6 Cabeçalho Routing Cabeçalho

Fragmentation
Próximo Próximo Cabeçalho TCP Dados
Próximo
cabeçalho = 43 cabeçalho = 44
cabeçalho = 6

Diferente do IPv4, que inclui no cabeçalho base todas as informações opcionais, o IPv6
trata essas informações através de cabeçalhos de extensão. Esses cabeçalhos localizam-se
entre o cabeçalho base e o cabeçalho da camada imediatamente acima, não havendo nem
quantidade, nem tamanho fixo para eles. Caso existam múltiplos cabeçalhos de extensão no
mesmo pacote, eles serão adicionados em série, formando uma “cadeia de cabeçalhos”.

As especificações do IPv6 definem 6 cabeçalhos de extensão:

11 Hop-by-Hop Options;
Hop-by-Hop
Técnica de rotea- 11 Destination Options;
mento na qual a
11 Routing;
estação origem e
cada roteador inter- 11 Fragmentation;
Capítulo 2 - Cabeçalho IPv6

mediário entregam
o datagrama ao 11 Authentication Header;
próximo roteador
11 Encapsulating Security Payload.
do caminho, até que
algum deles possa A utilização de cabeçalhos de extensão do IPv6 visa aumentar a velocidade de processa-
entregar o data-
grama diretamente
mento nos roteadores, já que o único cabeçalho de extensão processado em cada roteador
à estação destino. é o Hop-by-Hop; os demais são tratados apenas pelo nó identificado no campo Endereço de
Destino do cabeçalho base. Além disso, novos cabeçalhos de extensão podem ser definidos
e usados sem a necessidade de se alterar o cabeçalho base.

33
 Hop-by-Hop Options
11 Identificado pelo valor 0 no campo Próximo Cabeçalho. q
11 Carrega informações que devem ser processadas por todos os nós ao longo do
caminho do pacote.

Próximo Tam. cab.

Cabeçalho de extensão

Opções

Figura 2.9
Cabeçalho Hop_
by_Hop

Identificado pelo valor 0 no campo Próximo Cabeçalho, o cabeçalho de extensão Hop-by-Hop

deve ser colocado imediatamente após o cabeçalho base IPv6. As informações carregadas por
ele devem ser examinadas por todos os nós intermediários ao longo do caminho do pacote
até o destino. Na sua ausência, o roteador sabe que não precisa processar nenhuma infor-
mação adicional, e assim pode encaminhar o pacote para o destino final imediatamente.

As definições de cada campo do cabeçalho são:

11 Próximo Cabeçalho (1 Byte): identifica o tipo de cabeçalho seguinte ao Hop-by-Hop;

l
11 Tamanho do Cabeçalho (1 Byte): indica o tamanho do cabeçalho Hop-by-Hop em
unidades de 8 bytes, excluídos os oito primeiros;
O terceiro bit desse
11 Opções: contém uma ou mais opções e seu tamanho é variável. Nesse campo, o primeiro campo especifica se
byte contém informações sobre como essas opções devem ser tratadas, caso o nó que a informação opcional
pode mudar de rota
esteja processando a informação não a reconheça. O valor dos primeiros dois bits
(valor 01) ou não
especifica as ações a serem tomadas: (valor 00).
22 00: ignorar e continuar o processamento;

22 01: descartar o pacote;

22 10: descartar o pacote e enviar uma mensagem ICMP Parameter Problem para o ende-
reço de origem do pacote;

22 11: descartar o pacote e enviar uma mensagem ICMP Parameter Problem para o ende- Multicast Listener
reço de origem do pacote, apenas se o destino não for um endereço de multicast. Discovery
Usado para descobrir
11 Até o momento, existem dois tipos definidos para o cabeçalho Hop-by-Hop – a Router ouvintes multicast em
Alert e a Jumbogram: um link diretamente
ligado, assim como faz o
11 Router Alert: utilizado para informar aos nós intermediários que a mensagem a ser IGMP no IPv4.
encaminhada exige tratamento especial. Essa opção é utilizada pelos protocolos Resource Reservation
Multicast Listener Discovery (MLD) e Resource Reservation Protocol (RSVP); Protocol
Destinado à reserva de
11 Jumbogram: utilizado para informar que o tamanho do pacote IPv6 é maior do que 64 KB.
recursos como banda e
latência através da rede.
IPv6 Básico

34
 Destination Options
11 Identificado pelo valor 60 no campo Próximo Cabeçalho. q
11 Carrega informações que devem ser processadas pelo nó de destino do pacote.

Próximo Tam. cab.

de extensão Tipo de Routing Saltos restantes
Cabeçalho

Reservado

Figura 2.10
Estrutura do
cabeçalho Endereço de Origem
Destination
Options.

Identificado pelo valor 60 no campo Próximo Cabeçalho, o cabeçalho de extensão Destination

Mais informações na
d Options carrega informações que devem ser processadas pelo nó de destino do pacote, indi-
cado no campo Endereço de Destino do cabeçalho base. A definição de seus campos é igual à
RFC 2711 – IPv6 do cabeçalho Hop-by-Hop, usado no suporte à mobilidade do IPv6 através da opção Home
Router Alert Option.
Address, que contém o Endereço de Origem do Nó Móvel quando este está em trânsito.

Routing
11 Identificado pelo valor 43 no campo Próximo Cabeçalho. q
11 Desenvolvido inicialmente para listar um ou mais nós intermediários que deveriam
ser visitados até o pacote chegar ao destino.

11 Atualmente utilizado como parte do mecanismo de suporte à mobilidade do IPv6.

Próximo Tam. cab.

de extensão Tipo de Routing Saltos restantes
Cabeçalho

Reservado

Figura 2.11 Endereço de Origem

Estrutura do
cabeçalho Routing.

Identificado pelo valor 43 no campo Próximo Cabeçalho, o cabeçalho de extensão Routing foi

Loose Source e Record desenvolvido inicialmente para listar um ou mais nós intermediários que deveriam ser visi-
Route (LSRR) tados até o pacote chegar ao destino, semelhante às opções Loose Source e Record Route
Informação de rote- do IPv4. Essa função, realizada pelo cabeçalho Routing Type 0, tornou-se obsoleta pela RFC
amento no pacote IP
5095 devido a problemas de segurança.
usada pelos roteadores
Capítulo 2 - Cabeçalho IPv6

no encaminhamento do
Um novo cabeçalho Routing, o Type 2, foi definido para ser utilizado como parte do meca-
pacote para o destino e
para registro da rota. nismo de suporte à mobilidade do IPv6, carregando o Endereço de Origem do Nó Móvel em
pacotes enviados pelo Nó Correspondente.

As definições de cada campo do cabeçalho são:

11 Próximo Cabeçalho (1 byte): identifica o tipo de cabeçalho que segue ao cabeçalho Routing;

11 Tamanho do Cabeçalho (1 byte): indica o tamanho do cabeçalho Routing em unidades

de 8 bytes, excluídos os oito primeiros;

35
 11 Routing Type (1 byte): identifica o tipo de cabeçalho Routing. Atualmente apenas o Type 2
está definido;

11 Saltos restantes: definido para ser utilizado com o Routing Type 0, indica o número de
saltos a serem visitados antes do pacote atingir seu destino final;

11 Endereço de Origem: carrega o Endereço de Origem de um Nó Móvel.

Mais informações na RFC 3775 – Mobility Support in IPv6 - 6.4. Type 2 Routing Header e na
RFC 5095 – Deprecation of Type 0 Routing Headers in IPv6.

Fragmentation
11 Identificado pelo valor 44 no campo Próximo Cabeçalho. q
11 Carrega informações sobre os fragmentos dos pacotes IPv6.

Próximo Deslocamento de
Reservado Res M
Cabeçalho fragmento
Figura 2.12
Estrutura do
Identificação cabeçalho
Fragmentation

Identificado pelo valor 44 no campo Próximo Cabeçalho, o cabeçalho de extensão Fragmen-

tation é utilizado quando o pacote IPv6 a ser enviado é maior que o Path MTU.

As definições de cada campo do cabeçalho são:

11 Próximo Cabeçalho (1 byte): identifica o tipo de cabeçalho que segue ao cabeçalho

Fragmentation;

11 Deslocamento do Fragmento (13 bits): indica, em unidades de 8 bytes, a posição dos

dados transportados pelo fragmento atual em relação ao início do pacote original;

11 Flag M (1 bit): se marcado com o valor 1, indica que há mais fragmentos. Se marcado com
o valor 0, indica que é o fragmento final;

11 Identificação (4 bytes): valor único, gerado pelo nó de origem, para identificar o pacote
original. Utilizado para detectar os fragmentos de um mesmo pacote.O processo de frag-
mentação de pacotes do IPv6 será detalhado nos próximos capítulos.

Authentication Header (AH) e Encapsulating Security Payload (ESP)

Authentication Header (AH): q
11 Identificado pelo valor 51 no campo Próximo Cabeçalho.

11 Utilizado pelo IPSec para prover autenticação e garantia de integridade aos pacotes IPv6.

Encapsulating Security Payload (ESP):

11 Identificado pelo valor 52 no campo Próximo Cabeçalho.

11 Também utilizado pelo IPSec, garante a integridade e confidencialidade dos pacotes.

Os cabeçalhos de extensão Authentication Header e Encapsulating Security Payload,

indicados respectivamente pelos valores 51 e 52 no campo Próximo Cabeçalho, fazem parte
do cabeçalho IPsec. IPsec
IPv6 Básico

Padrão desenvolvido
Embora as funcionalidades do IPsec sejam idênticas tanto no IPv4 quanto no IPv6, sua utili- para prover interope-
zação com IPv6 é facilitada pelo fato de seus principais elementos serem parte integrante da rabilidade e segurança
nova versão do protocolo IP. Outros aspectos também facilitam essa utilização, como o fato baseada em criptografia
de dados para os proto-
de não se utilizar NAT com IPv6. colos IP versões 4 e 6.
36
 Resumo de cabeçalho de extensão
Quando houver mais de um cabeçalho de extensão, recomenda-se que eles apareçam q
na seguinte ordem:

11 Hop-by-Hop Options.

11 Routing.

11 Fragmentation.

11 Authentication Header.

11 Encapsulating Security Payload.

Essa questão será

l 11 Destination Options.

aprofundada nos 11 Se o campo Endereço de Destino tiver um endereço multicast, os cabeçalhos de

próximos capítulos,
extensão serão examinados por todos os nós do grupo.
juntamente com o
detalhamento dos 11 Pode ser utilizado o cabeçalho de extensão Mobility pelos nós que possuírem suporte
cabeçalhos de
à mobilidade IPv6.
extensão AH e ESP.
Alguns aspectos sobre os cabeçalhos de extensão devem ser observados.

Primeiro, é importante destacar que, para evitar que os nós existentes ao longo do caminho
do pacote tenham de percorrer toda a cadeia de cabeçalhos de extensão para conhecer as
informações que deverão tratar, esses cabeçalhos devem ser enviados respeitando uma
determinada ordem. Geralmente, os cabeçalhos importantes para todos os nós envolvidos
no roteamento devem ser colocados em primeiro lugar. Cabeçalhos importantes apenas
para o destinatário final são colocados no final da cadeia.

A vantagem dessa sequência é que o nó pode parar de processar os cabeçalhos assim que
encontrar algum cabeçalho de extensão dedicado ao destino final, tendo certeza de que não
há mais cabeçalhos importantes a seguir. Com isso, é possível melhorar significativamente
o processamento dos pacotes, porque, em muitos casos, apenas o processamento do
cabeçalho base será suficiente para encaminhar o pacote.

Vale observar que, se um pacote for enviado para um endereço multicast, os cabeça-
lhos de extensão serão examinados por todos os nós do grupo.

Em relação à flexibilidade oferecida pelos cabeçalhos de extensão, merece destaque o desen-

volvido o cabeçalho Mobility, utilizado pelos nós que possuem suporte à mobilidade IPv6.
Capítulo 2 - Cabeçalho IPv6

37
38
IPv6 Básico
 3
Endereçamento IPv6
objetivos

Entender as diferenças entre os endereços IPv4 e IPv6; reconhecer a sintaxe dos

endereços IPv6 e os tipos de endereços IPv6, além de suas principais características.

conceitos
Representação dos endereços e tipos de endereços IPv6; endereços unicast,
identificadores de interface, endereços especiais, endereços Anycast e Multicast
e políticas de alocação e designação.

Endereçamento
A principal justificativa para o desenvolvimento do protocolo IPv6 é o aumento no espaço
para endereçamento. Por isso, é importante conhecer as diferenças entre os endereços IPv4
e IPv6, saber reconhecer a sintaxe dos endereços IPv6 e conhecer seus tipos de endereços
existentes e suas principais características.

Um endereço IPv4 é formado por 32 bits. q

11 2 = 4.294.967.296
32

Um endereço IPv6 é formado por 128 bits.

11 2128 = 340.282.366.920.938.463.463.374.607.431.768.211.456

11 ~ 56 octilhões (5,6x1028) de endereços IP por ser humano.

11 ~ 79 octilhões (7,9x1028) de vezes a quantidade de endereços IPv4.

No IPv4, o campo do cabeçalho reservado para o endereçamento possui 32 bits.

Esse tamanho possibilita o máximo de 4.294.967.296 (2 32) endereços distintos. No momento
em que era desenvolvido, essa quantidade era considerada suficiente para identificar todos
os computadores na rede e suportar o surgimento de novas sub-redes. No entanto, com o
Capítulo 3 - Endereçamento IPv6

rápido crescimento da internet, surgiu o problema da escassez dos endereços IPv4, moti-
vando a criação de uma nova geração do protocolo IP.

O IPv6 possui um espaço para endereçamento de 128 bits, sendo possível obter 340.282.366.
920.938.463.463.374.607.431.768.211.456 endereços (2128). Esse valor representa aproxi-
madamente 79 octilhões (7,9x1028) de vezes a quantidade de endereços IPv4 e representa,
também, mais de 56 octilhões (5,6x1028) de endereços por ser humano na Terra, conside-
rando-se a população estimada em 6 bilhões de habitantes.

39
 A representação dos endereços IPv6 divide o endereço em oito grupos de 16 bits, q
separando-os por “:”, escritos com dígitos hexadecimais.

11 2001:0DB8:AD1F:25E2:CADE:CAFE:F0CA:84C1

Na representação de um endereço IPv6 é permitido:

11 Utilizar caracteres maiúsculos ou minúsculos.

11 Omitir os zeros à esquerda.

11 Representar os zeros contínuos por “::”.

Exemplo:

11 2001:0DB8:0000:0000:130F:0000:0000:140B

11 2001:db8:0:0:130f::140b

Formato inválido: 2001:db8::130f::140b (gera ambiguidade)

Os 32 bits dos endereços IPv4 são divididos em quatro grupos de 8 bits cada, separados por “.”,
escritos com dígitos decimais. Por exemplo: 192.168.0.10.

A representação dos endereços IPv6 divide o endereço em oito grupos de 16 bits,

separando-os por “:”, escritos com dígitos hexadecimais (0-F). Por exemplo:
2001:0DB8:AD1F:25E2:CADE:CAFE:F0CA:84C1

Na representação de um endereço IPv6, é permitido utilizar tanto caracteres maiúsculos

quanto minúsculos. Além disso, regras de abreviação podem ser aplicadas para facilitar Essa abreviação
a escrita de alguns endereços muito extensos. É permitido omitir os zeros à esquerda pode ser feita também
no fim ou no início
de cada bloco de 16 bits, além de substituir uma sequência longa de zeros por “::”. Por do endereço, como
exemplo, o endereço 2001:0DB8:0000:0000:130F:0000:0000:140B pode ser escrito como ocorre em
2001:DB8:0:54:0:0:0:0,
2001:DB8:0:0:130F::140B ou 2001:DB8::130F:0:0:140B. Nesse exemplo é possível observar
que pode ser escrito da
que a abreviação do grupo de zeros só pode ser realizada uma única vez, caso contrário forma 2001:DB8:0:54::.
poderão existir ambiguidades na representação do endereço. Se esse endereço fosse
escrito como 2001:DB8::130F::140B, não seria possível determinar se corresponde a
2001:DB8:0:0:130F:0:0:140B, a 2001:DB8:0:0:0:130F:0:140B ou 2001:DB8:0:130F:0:0:0:140B.

Representação dos prefixos: q

11 Como o CIDR (IPv4)þ.

22 “Endereço-IPv6/tamanho do prefixo”.

Exemplo:

11 Prefixo 2001:db8:3003:2::/64

11 Prefixo global 2001:db8::/32

CIDR
11 ID da sub-rede 3003:2 Classless Inter-Domain
Routing é uma técnica
URL:
que especifica um
11 http://[2001:12ff:0:4::22]/index.html esquema de endereça-
mento e roteamento
11 http://[2001:12ff:0:4::22]:8080 que adota blocos
contíguos de endereços
Outra representação importante é a dos prefixos de rede. Em endereços IPv6 ela continua
ao invés de endereços
sendo escrita do mesmo modo que no IPv4, utilizando a notação CIDR. Essa notação é classe A, B e C.
IPv6 Básico

representada da forma “endereço-IPv6/tamanho do prefixo”, onde “tamanho do prefixo” é

um valor decimal que especifica a quantidade de bits contíguos à esquerda do endereço que
compreendem o prefixo. O exemplo de prefixo de sub-rede apresentado a seguir indica que
dos 128 bits do endereço, 64 bits são utilizados para identificar a sub-rede.

40
 11 Prefixo: 2001:db8:3003:2::/64

11 Prefixo global: 2001:db8::/32

11 ID da sub-rede: 3003:2

Essa representação também possibilita a agregação dos endereços de forma hierárquica,

identificando a topologia da rede através de parâmetros como posição geográfica, provedor
de acesso, identificação da rede, divisão da sub-rede, entre outros. Com isso, é possível
diminuir o tamanho da tabela de roteamento e agilizar o encaminhamento dos pacotes.

URL Com relação à representação dos endereços IPv6 em URLs, estes agora passam a ser
Universal Resource representados entre colchetes. Desse modo, não haverá ambiguidades caso seja necessário
Locator é o identificador indicar o número de uma porta juntamente com a URL. Observe os exemplos a seguir:
universal de docu-
mentos e sítios web. 11 http://[2001:12ff:0:4::22]/index.html

11 http://[2001:12ff:0:4::22]:8080

No IPv6 existem três tipos de endereços definidos: q

11 Unicast: identificação Individual.

11 Anycast: identificação Seletiva.

11 Multicast: identificação em Grupo.

Não existe mais Broadcast.

11 Unicast: esse tipo de endereço identifica uma única interface, de modo que um pacote
enviado a um endereço unicast é entregue a uma única interface;

11 Anycast: identifica um conjunto de interfaces. Um pacote encaminhado a um endereço

anycast é entregue à interface pertencente a esse conjunto, mais próxima da origem, de
acordo com a distância medida pelos protocolos de roteamento. Um endereço anycast é
utilizado em comunicações de um-para-um-de-muitos;

11 Multicast: também identifica um conjunto de interfaces; entretanto, um pacote enviado

a um endereço multicast é entregue a todas as interfaces associadas a esse endereço.
Um endereço multicast é utilizado em comunicações de um-para-muitos.

Diferente do IPv4, no IPv6 não existe endereço broadcast, responsável por direcionar um
pacote para todos os nós de um mesmo domínio. No IPv6, essa função foi atribuída a tipos
específicos de endereços multicast.

Unicast
11 Global unicast. q
11 Link local.

11 Unique local.
Capítulo 3 - Endereçamento IPv6

11 Identificador da Interface (IID)þ.

11 EUI-64.

11 Endereços especiais.

Global Unicast
11 2000::/3 q
11 Globalmente roteável (similar aos endereços públicos IPv4).

11 13% do total de endereços possíveis.

11 2(45) = 35.184.372.088.832 redes /48 distintas.

41
 n 64-n 64

Figura 3.1
ID da Estrutura de
Prefixo de roteamento global sub-rede Identificador de interface endereços Global
Unicast.

Os endereços unicast são utilizados para comunicação entre dois nós, por exemplo, em
telefones VoIPv6, computadores em uma rede privada etc. Sua estrutura foi definida para
permitir agregações com prefixos de tamanho flexível, similar ao CIDR do IPv4.

Existem alguns tipos de endereços unicast IPv6: Global Unicast; Unique-Local; e Link-Local.
Existem também alguns tipos para usos especiais, como endereços IPv4 mapeados em IPv6, Endereço de
endereço de loopback e endereço não-especificado, entre outros. Loopback
Endereço IP reservado
11 Global Unicast: equivalente aos endereços públicos IPv4, o endereço global unicast é que é utilizado para
globalmente roteável e acessível na internet IPv6. É constituído por três partes: referenciar a interface
de loopback.
33 Prefixo de roteamento global: usado para identificar o tamanho do bloco atribuído
a uma rede;

33 Identificação da sub-rede: utilizada para identificar um enlace em uma rede;

33 Identificação da interface: deve identificar de forma única uma interface dentro de Isso representa 13%
do total de endereços
um enlace. possíveis com IPv6,
o que nos permite
Sua estrutura foi projetada para utilizar os 64 bits mais à esquerda para identificação da
criar: 2(64−3) =
rede e os 64 bits mais à direita para identificação da interface. Portanto, exceto em casos 2.305.843.009.213.
específicos, todas as sub-redes em IPv6 têm o mesmo tamanho de prefixo, 64 bits (/64), o 693.952 (2,3x1018)
sub-redes (/64)
que possibilita 264 = 18.446.744.073.709.551.616 dispositivos por sub-rede.
diferentes
ou 2(48−3) =
Atualmente, está reservada para atribuição de endereços a faixa 2000::/3 (001), que corres-
35.184.372.088.832
ponde aos endereços de 2000:: a 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff. (3,5x1013) redes /48.

Link local

11 FE80::/64. q
11 Deve ser utilizado apenas localmente.

11 Atribuído automaticamente (autoconfiguração stateless).

64 64

Figura 3.2
Estrutura de
FE80 0 Identificador de interface endereços
Link Local.

Podendo ser usado apenas no enlace específico onde a interface está conectada, o endereço
link-local é atribuído automaticamente utilizando o prefixo FE80::/64. Os 64 bits reser-
vados para a identificação da interface são configurados utilizando o formato IEEE EUI-64. IEEE EUI-64
Vale ressaltar que os roteadores não devem encaminhar para outros enlaces pacotes que Também conhecido
possuam como origem ou destino um endereço link-local. como IEEE-bit Extended
Unique Identifier, é um
formato que permite
IPv6 Básico

Unique local a um host atribuir-se

q
automaticamente um
11 FC00::/7 endereço único IPv6
64-bits sem a necessi-
11 Prefixo globalmente único (com alta probabilidade de ser único). dade de configuração
manual ou DHCP.

42
 11 Utilizado apenas na comunicação dentro de um enlace ou entre um conjunto limitado q
de enlaces.

11 Não é esperado que seja roteado na internet.

7 1 40 16 64

Figura 3.3
Estrutura ID da
de endereços Pref L Identificador global Identificador de interface
sub-rede
Unique Local.

O Unique Local Address (ULA) é um endereço com grande probabilidade de ser globalmente
único, utilizado apenas para comunicações locais, geralmente dentro de um mesmo enlace
ou conjunto de enlaces. Um endereço ULA não deve ser roteável na internet global. Um
endereço ULA, criado utilizando um ID global alocado pseudo-randomicamente, é composto
pelas seguintes partes:

11 Prefixo: FC00::/7;

11 Flag Local (L): se o valor for 1 (FD), o prefixo é atribuído localmente. Se o valor for 0 (FC),
o prefixo deve ser atribuído por uma organização central (ainda a definir);

11 Identificador global: identificador de 40 bits usado para criar um prefixo globalmente único;

A estrutura de um endereço ULA é: FDUU:UUUU:UUUU:<ID da sub-rede>:<Id da interface>.

Onde U são os bits do identificador único, gerado aleatoriamente por um algoritmo específico.

11 Identificador da Interface: identificador da interface de 64 bits.

Sua utilização permite que qualquer enlace possua um prefixo /48 privado e único global-
mente. Desse modo, caso duas redes, de empresas distintas por exemplo, sejam interco-
nectadas, provavelmente não haverá conflito de endereços ou necessidade de renumerar
a interface que o esteja usando. Além disso, o endereço ULA é independente de provedor,
podendo ser utilizado na comunicação dentro do enlace, mesmo que não haja uma conexão
com a internet. Outra vantagem é que seu prefixo pode ser facilmente bloqueado, e caso um
endereço ULA seja anunciado acidentalmente para fora do enlace, através de um roteador
ou via DNS, não haverá conflito com outros endereços.

Identificador da Interface (IID)

11 Devem ser únicos dentro do mesmo prefixo de sub-rede. q
11 O mesmo IID pode ser usado em múltiplas interfaces de um único nó, desde que
estejam associadas a sub-redes diferentes.

11 Normalmente utiliza-se um IID de 64 bits, que pode ser obtido:

Capítulo 3 - Endereçamento IPv6

22 Manualmente.

22 Autoconfiguração stateless.

22 DHCPv6 (stateful).

22 A partir de uma chave pública (CGA).

22 IID pode ser temporário e gerado randomicamente.

22 Normalmente é baseado no endereço MAC (Formato EUI-64).

43
 Os identificadores de interface (IID), utilizados para distinguir as interfaces dentro de um
enlace, devem ser únicos dentro do mesmo prefixo de sub-rede. O mesmo IID pode ser
CGA
usado em múltiplas interfaces em um único nó; porém, elas dever estar associadas a dife-
Cryptographically
rentes sub-redes.
Generated Address é
um endereço IPv6
Normalmente utiliza-se um IID de 64 bits, que pode ser obtido de diversas formas. Ele pode
gerado a partir de uma
ser configurado manualmente, a partir do mecanismo de autoconfiguração stateless do IPv6, função hash de
a partir de servidores DHCPv6 (stateful) ou formados a partir de uma chave pública (CGA). criptografia one-way.

Embora eles possam ser gerados randomicamente e de forma temporária, recomenda-se

que o IID seja construído baseado no endereço MAC da interface, no formato EUI-64.
Esses métodos serão
detalhados no decorrer
Endereço MAC 48 1E C9 21 85 0C
desse curso.

Endereço EUI-64 48 1E C9 48
21 85
1E 0C
C9

0
48 1 1E 0 C90 121 0 85 0 0C
0 FF FE

Bit U/L

0
48 1 1E 0 C90 121 0 85 1 0C
0

Figura 3.4
Formação do
Identificador de Interface 4A 48
1E C9
1E C9
FF 21
FE 21
85 0C
85 0C IID baseado no
formato EUI-64.

d
EUI-64
Um IID baseado no formato EUI-64 é criado da seguinte forma: caso a interface possua um Mais informações na
endereço MAC de 64 bits (padrão EUI-64), basta complementar o sétimo bit mais à esquerda RFC 3986 – Uniform
Resource Identifier
(chamado de bit U/L – Universal/Local) do endereço MAC, isto é, se for 1, será alterado para (URI): Generic Syntax;
0; se for 0, será alterado para 1. Caso a interface utilize um endereço MAC de 48 bits (padrão RFC 4291 – IP Version 6
Addressing Architec-
IEEE 802), primeiro são adicionados os dígitos hexadecimais FF-FE entre o terceiro e quarto
ture; RFC 4193 – Unique
byte do endereço MAC (transformando no padrão EUI-64) e, em seguida, o bit U/L é comple- Local IPv6 Unicast
mentado. Por exemplo: Addresses; RFC 5156 –
Special-Use IPv6
11 Se o endereço MAC da interface for: Addresses e RFC 3587
– IPv6 Global Unicast
22 48-1E-C9-21-85-0C

11 São adicionados os dígitos FF-FE na metade do endereço:

22 48-1E-C9-FF-FE-21-85-0C

11 Complementa-se o bit U/L:

Conheça o Internet
22 48 = 01001000 Protocol Version 6
Address Space: http://
22 01001000 + 01 = 01001010 = 4A www.iana.org/
assignments/
22 IID = 4A-1E-C9-FF-FE-21-85-0C
ipv6-address-space
33 Um endereço link-local atribuído a essa interface seria FE80::4A1E:C9FF:FE21:850C.
IPv6 Básico

44
 w Endereços e faixas especiais e endereços obsoletos
q
Mais informações:
Guidelines for 64-bit Endereços especiais:
Global Identifier
(EUI-64) Registration 11 Localhost: ::1/128 (0:0:0:0:0:0:0:1)þ
Authority –
http://standards. 11 Não especificado: ::/128 (0:0:0:0:0:0:0:0)þ
ieee.org/
11 IPv4-mapeado: ::FFFF:wxyz

Faixas Especiais:

11 6to4: 2002::/16

11 Documentação: 2001:db8::/32

11 Teredo: 2001:0000::/32

Obsoletos:

11 Site local: FEC0::/10

11 IPv4-compatível: ::wxyz

11 6Bone: 3FFE::/16 (rede de testes desativada em 06/06/06)þ

Existem alguns endereços IPv6 especiais utilizados para fins específicos:

11 Endereço Não-Especificado (Unspecified): é representado pelo endereço 0:0:0:0:0:0:0:0

ou ::0 (equivalente ao endereço IPv4 unspecified 0.0.0.0). Ele nunca deve ser atribuído a
nenhum nó, indicando apenas a ausência de um endereço. Ele pode, por exemplo, ser
utilizado no campo Endereço de Origem de um pacote IPv6 enviado por um host durante
o processo de inicialização, antes que este tenha seu endereço exclusivo determinado. O
endereço unspecified não deve ser utilizado como endereço de destino de pacotes IPv6.

11 Endereço Loopback: representado pelo endereço unicast 0:0:0:0:0:0:0:1 ou ::1 (equivalente

ao endereço IPv4 loopback 127.0.0.1). Esse endereço é utilizado para referenciar a própria
máquina, sendo muito utilizado para testes internos. Esse tipo de endereço não deve ser
atribuído a nenhuma interface física, nem usado como endereço de origem em pacotes
IPv6 enviados para outros nós. Além disso, um pacote IPv6 com um endereço loopback
como destino não pode ser enviado por um roteador IPv6, e caso um pacote recebido em
uma interface possua um endereço loopback como destino, este deve ser descartado.

11 Endereços IPv4-mapeado: representado por 0:0:0:0:0:FFFF:wxyz ou ::FFFF:wxyz, é usado

para mapear um endereço IPv4 em um endereço IPv6 de 128-bit, onde wxyz representa
os 32 bits do endereço IPv4, utilizando dígitos decimais. É aplicado em técnicas de tran-
sição para que nós IPv6 e IPv4 se comuniquem. Por exemplo: ::FFFF:192.168.100.1.

Algumas faixas de endereços também são reservadas para usos específicos:

11 2002::/16: prefixo utilizado no mecanismo de transição 6to4;

11 2001:0000::/32: prefixo utilizado no mecanismo de transição TEREDO;

Capítulo 3 - Endereçamento IPv6

11 2001:db8::/32: prefixo utilizado para representar endereços IPv6 em textos e documen-

tações.Outros endereços, utilizados no início do desenvolvimento do IPv6 tornaram-se
obsoletos e não devem mais ser utilizados:

Mais informações na 22 FEC0::/10: prefixo utilizado pelos endereços do tipo site local, desenvolvidos para
RFC 3849 – IPv6 serem utilizados dentro de uma rede específica sem a necessidade de um prefixo
Address Prefix
global, equivalente aos endereços privados do IPv4. Sua utilização foi substituída
Reserved for Documen-
tation e na RFC 3879 pelos endereços ULA;
– Deprecating Site Local
22 ::wxyz: utilizado para representar o endereço IPv4-compatível. Sua função é a mesma
Addresses.
do endereço IPv4-mapeado, tornando-se obsoleto por desuso;

45
 22 3FFE::/16: prefixo utilizado para representar os endereços da rede de teste 6Bone. Criada
para ajudar na implantação do IPv6, essa rede foi desativada em 6 de junho de 2006.

Anycast
Identifica um grupo de interfaces. q
11 Entrega o pacote apenas para a interface mais próxima da origem.

Atribuídos a partir de endereços unicast (são sintaticamente iguais).

Possíveis utilizações:

11 Descobrir serviços na rede (DNS, proxy HTTP)þ.

11 Balanceamento de carga.

11 Localizar roteadores que forneçam acesso a uma determinada sub-rede.

11 Utilizado em redes com suporte à mobilidade IPv6, para localizar os Agentes de Origem.

Subnet-Router.

Um endereço IPv6 anycast é usado para identificar um grupo de interfaces; porém, com a
propriedade de que um pacote enviado a um endereço anycast é encaminhado apenas para
a interface do grupo mais próxima da origem do pacote.

Os endereços anycast são atribuídos a partir da faixa de endereços unicast e não há dife-
renças sintáticas entre eles. Portanto, um endereço unicast atribuído a mais de uma interface
transforma-se em um endereço anycast. Deve-se, nesse caso, configurar explicitamente os
nós para que saibam que lhes foi atribuído um endereço anycast. Além disso, esse endereço
deve ser configurado nos roteadores como uma entrada separada (prefixo /128 – host route).

Esse esquema de endereçamento pode ser utilizado para descobrir serviços na rede, como
servidores DNS e proxies HTTP, garantindo a redundância desses serviços. Também pode
ser utilizado para fazer balanceamento de carga em situações onde múltiplos hosts ou
roteadores proveem o mesmo serviço, para localizar roteadores que forneçam acesso a
uma determinada sub-rede ou para localizar os Agentes de Origem em redes com suporte à
mobilidade IPv6.

Todos os roteadores devem ter suporte ao endereço anycast Subnet-Router. Esse tipo w
de endereço é formado pelo prefixo da sub-rede e pelo IID preenchido com zeros (ex.: Mais informações sobre
2001:db8:cafe:dad0::/64). Um pacote enviado para o endereço Subnet-Router será entregue o Internet Protocol
Version 6 Anycast
para o roteador mais próximo da origem dentro da mesma sub-rede. Addresses: http://
www.iana.org/
Também foi definido um endereço anycast para ser utilizado no suporte à mobilidade IPv6. assignments/
Esse tipo de endereço é formado pelo prefixo da sub-rede seguido pelo IID dfff:ffff:ffff:fffe ipv6-anycast-
-addresses
(exemplo: 2001:db8::dfff:ffff:ffff:fffe). Ele é utilizado pelo Nó Móvel, quando este precisar
localizar um Agente de Origem em sua rede original.
IPv6 Básico

46
 Multicast
11 Identifica um grupo de interfaces. q
11 O suporte a multicast é obrigatório em todos os nós IPv6.

11 O endereço multicast deriva do bloco FF00::/8

11 O prefixo FF é seguido de quatro bits utilizados como flags e mais quatro bits que
definem o escopo do endereço multicast.

22 Os 112 bits restantes são utilizados para identificar o grupo multicast.

8 4 4 112

Figura 3.5
Estrutura de Flags
endereços FF 0RPT Escopo Identificador do grupo multicast
multicast.

Endereços multicast são utilizados para identificar grupos de interfaces. Cada interface
pode pertencer a mais de um grupo. Os pacotes enviados para esses endereços são
entregues a todas as interfaces que compõem o grupo.

No IPv4, o suporte a multicast é opcional, já que foi introduzido apenas como uma extensão
ao protocolo. Entretanto, no IPv6 é requerido que todos os nós suportem multicast, uma vez
que muitas funcionalidades da nova versão do protocolo IP usam esse tipo de endereço.

Broadcast Seu funcionamento é similar ao do broadcast, já que um único pacote é enviado a vários
Técnica que permite a hosts, diferenciando-se apenas pelo fato de que no broadcast o pacote é enviado a todos os
entrega de cópias de
hosts da rede, sem exceção, enquanto que no multicast apenas um grupo de hosts receberá
um mesmo pacote a
todas as estações de esse pacote. Desse modo, a possibilidade de transportar apenas uma cópia dos dados a
uma determinada rede. todos os elementos do grupo, a partir de uma árvore de distribuição, pode reduzir a utili-
zação de recurso de uma rede, bem como otimizar a entrega de dados aos hosts receptores.
Aplicações como videoconferência, distribuição de vídeo sob demanda, atualizações de sof-
twares e jogos on-line são exemplos de serviços que vêm ganhando notoriedade e podem
utilizar as vantagens apresentadas pelo multicast.

Os endereços multicast não devem ser utilizados como endereço de origem de um pacote.
Esses endereços derivam do bloco FF00::/8, onde o prefixo FF, que identifica um endereço
multicast, é precedido por quatro bits, que representam quatro flags, e um valor de quatro
bits que define o escopo do grupo multicast. Os 112 bits restantes são utilizados para
identificar o grupo multicast.

Flags e escopo
Flag Valor Descrição
(binário)
Capítulo 3 - Endereçamento IPv6

Primeiro bit 0 Marcado como 0 (Reservado para uso futuro)

R 1 Endereço de um ponto de encontro (rendez-vous point)

R 0 Não representa um endereço de Ponto de Encontro

P 1 Endereço multicast baseado no prefixo da rede

P 0 Endereço multicast não baseado no prefixo da rede
Tabela 3.1
Opções do T 1 Endereço multicast temporário (não alocado pela IANA)
campo ‘Flag’. T 0 Endereço multicast permanente (alocado pela IANA)

47
 Valor (4 bits hex) Descrição

1 Interface
2 Enlace
3 Sub-rede
4 Admin
5 Site
8 Organização
E Global
(0, F) Reservados Tabela 3.2
Opções do campo
(6, 7, 9, A, B, C, D) Não alocados
‘Escopo’.

As flags são definidas da seguinte forma:

11 O primeiro bit mais à esquerda é reservado e deve ser marcado com 0;

11 Flag R: se o valor for 1, indica que o endereço multicast “carrega” o endereço de um

Ponto de Encontro (Rendezvous Point). Se o valor for 0, indica que não há um endereço
de Ponto de Encontro embutido;

11 Flag P: se o valor for 1, indica que o endereço multicast é baseado em um prefixo de rede.
Se o valor for 0, indica que o endereço não é baseado em um prefixo de rede;

11 Flag T: se o valor for 0, indica que o endereço multicast é permanente, ou seja, é atribuído
pela IANA. Se o valor for 1, indica que o endereço multicast não é permanente, ou seja, é
atribuído dinamicamente;

11 Os quatro bits que representam o escopo do endereço multicast são utilizados para deli-
mitar a área de abrangência de um grupo multicast. Valores atribuídos a esse campo:

22 1: abrange apenas a interface local;

22 2: abrange os nós de um enlace;

22 3: abrange os nós de uma sub-rede

22 4: abrange a menor área que pode ser configurada manualmente;

22 5: abrange os nós de um site;

22 8: abrange vários sites de uma mesma organização;

22 E: abrange toda a internet;

22 0, F: reservados;

22 6, 7, 9, A, B, C, D: não estão alocados.

Desse modo, um roteador ligado ao backbone da internet não encaminhará pacotes com
escopo menor do que 14 (E em hexa), por exemplo. No IPv4, o escopo de um grupo multicast
é especificado através do campo TTL (Time-to-Live)do cabeçalho. TTL
Técnica usada em
sistemas de entrega,
Endereços multicast permanentes baseada no paradigma
do melhor esforço que
A lista a seguir apresenta alguns endereços multicast permanentes:
evita a circulação de
pacotes na rede por um
Endereço Escopo Descrição tempo infinito.

FF01::1 Interface Todas as interfaces em um nó (all-nodes)

IPv6 Básico

FF01:: Interface Todos os roteadores em um nó (all-routers)

FF02::1 Enlace Todos os nós do enlace (all-nodes)

FF02::2 Enlace Todos os roteadores do enlace (all-routers)þ

48
 Endereço Escopo Descrição

FF02::5 Enlace Roteadores OSFP

FF02::6 Enlace Roteadores OSPF designados

FF02::9 Enlace Roteadores RIP

FF02::D Enlace Roteadores PIM

FF02::1:2 Enlace Agentes DHCP

FF02::1:FFXX:XXXX Enlace Solicited-node

FF05::2 Site Todos os roteadores em um site

FF05::1:3 Site Servidores DHCP em um site

Tabela 3.3
Endereços FF05::1:4 Site Agentes DHCP em um site
multicast
permanentes. FF0X::101 Variado Network Time Protocol (NTP(

Endereço Solicited-Node
11 Todos os nós devem fazer parte desse grupo. q
11 Formado pelo prefixo FF02::1:FF00:0000/104 agregado aos 24 bits mais à direita do IID.

11 Utilizado pelo protocolo de Descoberta de Vizinhança (Neighbor Discovery).

O endereço multicast solicited-node identifica um grupo multicast do qual todos os nós

passam a fazer parte, assim que um endereço unicast ou anycast lhes é atribuído. Um ende-
reço solicited-node é formado agregando-se ao prefixo FF02::1:FF00:0000/104 os 24 bits
mais à direita do identificador da interface, e para cada endereço unicast ou anycast do nó,
existe um endereço multicast solicited-node correspondente.

Em redes IPv6, o endereço solicited-node é utilizado pelo protocolo de Descoberta de Vizi-

nhança para resolver o endereço MAC de uma interface. Para isso, envia-se uma mensagem
Neighbor Solicitation para o endereço solicited-node. Com isso, apenas as interfaces regis-
tradas nesse grupo examinam o pacote. Em uma rede IPv4, para se determinar o endereço
MAC de uma interface, envia-se uma mensagem ARP Request para o endereço broadcast da
camada de enlace, de modo que todas as interfaces do enlace examinam a mensagem.

Endereço multicast derivado de um prefixo unicast

11 Flag P = 1 q
11 Flag T = 1

11 Prefixo FF30::/12
Capítulo 3 - Endereçamento IPv6

11 Exemplo:

Figura 3.6 22 prefixo da rede = 2001:DB8::/32

Layout endereço
multicast. 22 endereço = FF3E:20:2001:DB8:0:0:CADE:CAFE

8 4 4 8 8 64 32

Flags Tamanho Prefixo ID do

FF 0RPT Escopo Reservado
do Prefixo da Rede Grupo

49
 Com o intuito de reduzir o número de protocolos necessários para a alocação de endereços
multicast, foi definido um formato estendido de endereço multicast, que permite a alocação
de endereços baseados em prefixos unicast e de endereços Source-Specific Multicast (SSM). SSM
Endereços de destino
Em endereços baseados no prefixo da rede, a flag P é marcada com o valor 1. Nesse caso, SSM devem ser na faixa
o uso do campo Escopo não muda; porém, o escopo desse endereço multicast não deve de 232.0.0.0 / 8 para
exceder o escopo do prefixo unicast “carregado” junto a ele. Os 8 bits após o campo Escopo IPv4 ou FF3x::/32 para o
IPv6.
são reservados e devem ser marcados com zeros. Na sequência, há 8 bits que especificam o
tamanho do prefixo da rede indicado nos 64 bits que os seguem. Caso o prefixo da rede seja
menor que 64 bits, os bits não utilizados no campo Tamanho do Prefixo devem ser marcados
com zeros. O campo Identificador do Grupo utiliza os 32 bits restantes. Note que, em um
endereço onde a flag P é marcada com o valor 1, a flag T também deve ser marcada com o
valor 1, pois este não representa um endereço definido pela IANA.

Endereços Multicast SSM

11 Prefixo: FF3X::/32 q
11 Formato do endereço: FF3X::/96

11 Tamanho do prefixo = 0

11 Prefixo = 0

11 Exemplo: FF3X::CADE:CAFE/96 (onde X é o escopo e CADE:CAFE é o identificador

do grupo).

No modelo tradicional de multicast, chamado de Any-Source Multicast (ASN), o participante

Os métodos de
de um grupo multicast não controla de que fonte deseja receber os dados. Com o SSM, uma gerenciamento dos
interface pode registrar-se em um grupo multicast e especificar as fontes de dados. O SSM grupos multicast serão
abordados no próximo
pode ser implementado utilizando o protocolo Multicast Listener Discovery version 2 (MLDv2).
módulo deste curso.
Para um endereço SSM, as flags P e T são marcadas com o valor 1. Os campos Tamanho do
Prefixo e Prefixo da Rede são marcados com zeros, chegando ao prefixo FF3X::/32, onde X é o
valor do escopo. O campo Endereço de Origem do cabeçalho IPv6 identifica o dono do ende-
reço multicast. Todo endereço SSM tem o formato FF3X::/96.

Do mesmo modo que no IPv4, os endereços IPv6 são atribuídos a interfaces físicas e q
não aos nós.

Com o IPv6 é possível atribuir a uma única interface múltiplos endereços, independente-
mente do seu tipo.

11 Com isso, um nó pode ser identificado através de qualquer endereço de suas interfaces.

22 Loopback ::1

22 Link Local FE80:....

22 Unique local FD07:...

22 Global 2001:....

11 A RFC 3484 determina o algoritmo para seleção dos endereços de origem e destino.

Também é importante destacar algumas características relacionadas ao endereço, apresen-

tadas pela nova arquitetura do protocolo IPv6. Assim como no IPv4, os endereços IPv6 são
IPv6 Básico

atribuídos às interfaces físicas, e não aos nós, de modo que cada interface precisa de pelo
menos um endereço unicast. No entanto, é possível atribuir a uma única interface múltiplos
endereços IPv6, independentemente do tipo (unicast, multicast ou anycast) ou sub-tipo
(loopback, link-local ou 6to4). Desse modo, um nó pode ser identificado através de qualquer

50
 endereço das suas interfaces, e com isso torna-se necessário escolher, dentre seus múltiplos
endereços, qual será usado como endereço de origem e qual será utilizado como endereço
de destino, ao estabelecer uma conexão.

Para resolver essa questão, foram definidos dois algoritmos: um para selecionar o endereço

d
de origem e outro para o de destino. Esses algoritmos, que devem ser implementados por
todos os nós IPv6, especificam o comportamento padrão desse nós, porém não substituem
Mais informações: RFC as escolhas feitas por aplicativos ou protocolos da camada superior. Entre as regras mais
2375 – IPv6 Multicast importantes destacam-se:
Address Assignments;
RFC 3306 – Unicast-
11 Pares de endereços do mesmo escopo ou tipo têm preferência;
-Prefix-based IPv6
Multicast; RFC 3307 11 O menor escopo para endereço de destino tem preferência (utiliza-se o menor
– Allocation Guidelines
escopo possível);
for IPv6 Multicast
Addresses; RFC 3484 11 Endereços cujo tempo de vida não expirou têm preferência sobre endereços com tempo
– Default Address
de vida expirado;
Selection for Internet
Protocol version 6 11 Endereços de técnicas de transição (ISATAP, 6to4) não podem ser utilizados se um ende-
(IPv6); RFC 3569 – An
reço IPv6 nativo estiver disponível;
Overview of Source-
-Specific Multicast 11 Se todos os critérios forem similares, pares de endereços com o maior prefixo comum
(SSM); RFC 3956 –
Embedding the terão preferência;
Rendezvous Point (RP) 11 Para endereços de origem, endereços globais terão preferência sobre endereços temporários;
Address in an IPv6
Multicast Address e 11 Em um Nó Móvel, o Endereço de Origem tem preferência sobre um Endereço Remoto.
RFC 4007 – IPv6
Scoped Address Essas regras devem ser utilizadas quando não houver nenhuma outra especificação. As
Architecture.
especificações também permitem a configuração de políticas que possam substituir esses
padrões de preferências com combinações entre endereços de origem e destino.

Saiba mais sobre o Internet Protocol Version 6 Multicast Addresses:

http://www.iana.org/assignments/ipv6-multicast-addresses/

Políticas de alocação e designação

11 Cada RIR recebe da IANA um bloco /12. q

11 O bloco 2800::/12 corresponde ao espaço reservado para o LACNIC – o NIC.br tra-
balha com um /16 que faz parte desse /12.

11 A alocação mínima para ISPs é um bloco /32.

11 Alocações maiores podem ser feitas mediante apresentação de justificativa de utilização.

Diferentemente do IPv4, com o IPv6 a utilização é medida em relação ao número

de designações de blocos de endereços para usuários finais, e não em relação ao
número de endereços designados aos usuários finais.
Capítulo 3 - Endereçamento IPv6

Na hierarquia das políticas de atribuição, alocação e designação de endereços, cada RIR recebe
da IANA um bloco /12 IPv6. O bloco 2800::/12 corresponde ao espaço reservado para o LACNIC
alocar na América Latina. O NIC.br, por sua vez, trabalha com um /16 que faz parte desse /12.

A alocação mínima para ISPs é um bloco /32, no entanto, alocações maiores podem ser
feitas mediante apresentação de justificativa de utilização. Um aspecto importante que
merece destaque é que, diferente do IPv4, com o IPv6 a utilização é medida em relação ao
número de designações de blocos de endereços para usuários finais, e não em relação ao
número de endereços designados aos usuários finais.

51
 Abordagem one size fits all
Recomendações para designação de endereços (RFC 3177): q
11 De um modo geral, redes /48 são recomendadas para todos os tipos de usuários.

11 Empresas grandes podem receber um /47, prefixos um pouco menores, ou múltiplos /48.

11 Redes /64 são recomendadas quando houver certeza de que apenas uma sub-rede
é necessária.

11 Uma rede /128 pode ser utilizada quando houver certeza de que apenas uma
interface será conectada.

Em relação à alocação e designação de endereços a usuários finais, a RFC 3177 recomenda

que seja seguida uma abordagem conhecida como one size fits all.

A abordagem one size fits all apresenta algumas vantagens: q

11 Facilita a renumeração da rede em caso de troca de provedor (troca de prefixo).

11 Permite a expansão da rede sem a necessidade de solicitar mais endereços ao provedor.

11 Facilita o mapeamento entre o endereço global e o endereço Unique Local (ULA

fc00:xyzw:klmn::/48).

11 Há redes que já utilizam prefixos /48 6to4;

11 Permite a manutenção de regras únicas para zonas reversas de diversos prefixos;

11 Facilita a administração;

11 Há quem acredite que desperdiça demasiados endereços e que pode gerar pro-
blemas em algumas décadas.

Abordagem conservadora
11 Se usarmos one size fits all. q
11 Um /32 possibilita 65.536 /48

11 Não delegar /48 a todos, atribuindo /56 para usuários domésticos – PMEs.

11 Reduz o consumo total de endereços de 6 a 7 bits.

Uma abordagem mais conservadora, oposta à one size fits all, recomenda que não sejam
delegados /48 a todo tipo de usuário, atribuindo /56 para usuários domésticos e pequenas e
médias empresas. Desse modo, o consumo total de endereços de 6 a 7 bits é reduzido.

Além disso, um /32 possibilita “apenas” 65,536 /48, que, no caso de grandes provedores, não
seria suficiente para atender toda a sua demanda.

O que os RIRs e ISPs têm praticado?

LACNIC e AFRINIC: q
11 Avaliam a requisição de blocos adicionais por parte dos ISPs baseando-se na quanti-
dade de blocos /48 designados.

11 Threshold – HD-Ratio = 0.94

APNIC, ARIN e RIPE:

IPv6 Básico

11 Avaliam a requisição de blocos adicionais por parte dos ISPs baseando-se na quanti-
dade de blocos /56 designados.

11 Threshold – HD-Ratio = 0.94

52
 Entre os RIRs, temos duas políticas distintas sendo praticadas em relação à recomendação
de uso aos ISPs e ao critério para alocação de blocos de endereços adicionais.

Os RIRs LACNIC e AFRINIC seguem a recomendação one size fits all, sugerindo que os prove-
dores de suas regiões também o sigam. A avaliação das requisições de blocos adicionais por
parte dos ISPs também segue essa abordagem, baseando-se na quantidade de blocos /48
designados por eles.

Já os RIRs APNIC, ARIN e RIPE seguem uma abordagem mais conservadora, utilizando a
quantidade de blocos /56 designados pelos provedores como base para avaliação das requi-
sições de blocos adicionais. Em todos os casos, é utilizada como medida para avaliação o
HD-Ratio valor do Host-Density Ratio (HD-Ratio). Fórmula para calcular o HD-Ratio:
Modo de medir o uso
do espaço de ende- HD = log (número de objetos alocados)
reçamento, onde seu
valor é relacionado à Log (número de objetos alocáveis)
porcentagem de uso
[RFC 3194]. Todos os RIRs utilizam como valor de limite (threshold) o HD-Ratio = 0,94, mas o LACNIC e
o AFRINIC sobre a utilização de blocos /48, enquanto APNIC, ARIN e RIPE sobre a utilização
de blocos /56.

Bloco Qtd. /48 Threshold (HD=0,94) % de Utilização

/32 65.536 33.689 51,41%

/31 131.072 64.634 49,31%

/30 262.144 124.002 47,30%

/29 524.288 237.901 45,38%

/28 1.048.576 456.419 43,53%

/27 2.097.152 875.653 41,75%

/26 4.194.304 1.679.965 40,05%

/25 8.388.608 3.223.061 38,42%

/24 16.777.216 6.183.533 36,86%

/23 33.554.432 11.863.283 35,36%

Tabela 3.4
/22 67.108.864 22.760.044 33,92%
Porcentagem de
utilização de blocos
/22 67.108.864 22.760.044 33,92%
/48 com base no
cálculo do HD-Ratio
/20 268.435.456 83.774.045 31,21%
igual a 0,94.

Bloco Qtd. /56 Threshold (HD=0,94) % de Utilização

Capítulo 3 - Endereçamento IPv6

/32 16.777.216 6.183.533 36,86%

/31 33.554.432 11.863.283 35,36%

/30 67.108.864 22.760.044 33,92%

/29 134.217.728 43.665.787 32,53%

/28 268.435.456 83.774.045 31,21%

/27 536.870.912 160.722.871 29,94%

53
 Bloco Qtd. /56 Threshold (HD=0,94) % de Utilização

/26 1.073.741.824 308.351.367 28,72%

/25 2.147.483.648 591.580.804 27,55%

/24 4.294.967.296 1.134.964.479 26,43%

/23 8.589.934.592 2.177.461.403 25,35%

Tabela 3.5
/22 17.179.869.184 4.177.521.189 24,32% Porcentagem de
utilização de blocos
/21 34.359.738.368 8.014.692.369 23,33% /56 baseando-se no
cálculo do HD-Ratio
/20 68.719.476.736 15.376.413.635 22,38%
igual a 0,94.

Provedores

NTT Communications: q
11 Japão.

11 IPv6 nativo (ADSL).

11 /48 a usuários finais.

11 http://www.ntt.com/business_e/service/category/nw_ipv6.html

Internode:

11 Austrália.

11 IPv6 nativo (ADSL).

11 /64 dinâmico para sessões PPP.

11 Delega /60 fixos.

11 http://ipv6.internode.on.net/configuration/adsl-faq-guide/

IIJ:

11 Japão.

11 Túneis.

11 /48 a usuários finais.

11 http://www.iij.ad.jp/en/service/IPv6/index.html

Arcnet6:

11 Malásia.

11 IPv6 nativo (ADSL) ou Túneis.

11 /48 a usuários finais.

11 /40 e /44 podem ser alocados (depende de aprovação).

11 http://arcnet6.net.my/how.html

Em relação à política seguida por alguns provedores no mundo, que já fornecem a seus clientes
endereços IPv6, existem algumas visões diferentes, como mostram os exemplos citados.

Considerações
q
IPv6 Básico

/32 =

11 65 mil redes /48 (33 mil, se considerarmos desperdício).

11 16 milhões de redes /56 (6 milhões, se considerarmos HD-Ratio).

54
 11 É suficiente para seu provedor? q
11 Reservar um bloco (/48 ?) para infraestrutura.

Links ponto a ponto:

11 /64? /112? /120? /126? /127?

RFC 3531.

Antes de solicitar um bloco de endereços IPv6, é preciso elaborar cuidadosamente o plano

de endereçamento da rede. Nesse momento, alguns aspectos importantes precisam ser
considerados.

Um bloco /32 permite 65 mil redes /48, ou 33 mil, se considerarmos o desperdício; 16

milhões de redes /56, ou 6 milhões, se considerarmos o HD-Ratio. Cada provedor deverá
analisar se esses valores atendem às suas necessidades ou se precisará solicitar ao Registro
de Internet um bloco de endereços maior.

Também é preciso considerar os endereços que serão utilizados para infraestrutura, o

tamanho de bloco que será reservado para as redes internas, para links ponto-a-ponto etc.

A RFC 3531 propõe um método para gerenciar a atribuição dos bits de um bloco de ende-
reços IPv6 ou de um prefixo, de modo que estes sejam alocados reservando espaço maior
entre eles. Com isso, caso seja necessário alocar novos blocos a um usuário, a probabilidade
de se alocar blocos contíguos ao que ele já possui será maior.

Figura 3.7
Exemplo
de alocações de 1 2
bloco sugerida pela
RFC 3531.
3 4
5 7 6 8

Exercício de fixação 1 e
Planejamento de endereçamento IP
Você é um provedor e recebeu o bloco 2001:0db8::/32. Presente em cinco estados, q
você atende usuários domésticos, pequenas, médias e grandes empresas, e tem
planos de expansão.

Rio Grande do Sul

Capítulo 3 - Endereçamento IPv6

São Paulo Santa Catarina

Provedor
2001:db8::/32

Paraná

Figura 3.8
Rio de Janeiro
Cenário para
exercício de
endereçamento.

55
 Você decidiu que a melhor forma de dividir os endereços é hierarquicamente. Qual o
tamanho do bloco de cada estado?

Qual o tamanho do bloco a ser designado para cada tipo de usuário?

Quantos usuários de cada tipo poderão ser atendidos dessa forma?

11 Indique o bloco correspondente a cada localidade.

11 Escolha uma localidade e indique os blocos correspondentes a cada tipo de usuário.

11 Nessa mesma localidade, indique o primeiro e o segundo blocos designados para cada
tipo de usuário (os dois primeiros usuários de cada tipo).

11 Para o segundo bloco/usuário de cada tipo, indique o primeiro e o último endereço.

Exercício de fixação 2 e
Tipo de endereços
1.  Indique a que tipo pertence cada um dos seguintes endereços:

Endereço Tipo

2001:db8:cafe:f0ca:faca:2:3

2804:1:2:b0ca:2c0:17ff:fe00:d1ca

fe80::dad0:baba:ca00:a7a2

fe80::2c0:17ff:fe00:d1ca

2002:c8A0:79c::b010:de:c0c0

::1

fd00:ada:2345:b0ba::1

ff0e::beba:d012:3:4

ff05::baba:bebe:baba

2. Comprima ao máximo os seguintes endereços:

2001:0db8:0000:1200:0fe0:0000:0000:0003

2001:0db8::ca5a:0000:2000

2001:0db8:face:b00c:0000:0000:0100:00ab

3. Descomprima ao máximo os seguinte endereços:

2001:db8:0:ca1::1:abcd
IPv6 Básico

2001:db8:4::2

2001:db8:200::bdb:110

56
 4. Utilizando o padrão EUI64, crie endereços IPv6 a partir do prefixo 2001:db8:ba1a:d0ce::/64
baseados nos seguintes endereços MAC:

 00:e0:4c:70:89:8d

 5c:1d:e0:8c:e7:e7

 07:00:27:00:e8:8b

5. Divida o prefixo 2001:db8::/32 pela metade para que sejam gerados dois subprefixos.

6. Divida o prefixo 2001:db8:c000::/34 nos seguintes tamanhos:

 /35

 /36

7. Divida o prefixo 2001:db8:a000::/35 no seguinte tamanho:

 /37

8. Você precisa subdividir o prefixo 2001:db8::/32 para atender a diversas sub-redes em sua
organização. Para cada caso, diga qual é o prefixo mais curto que atende sua necessidade,
o número de sub-redes geradas e o número de redes /64 possíveis em cada sub-rede. Diga
também qual é o prefixo mais curto possível sem “cortar caracteres” (indo de 4 em 4 bits),
o número de sub-redes geradas e o número de redes /64 possíveis em cada sub-rede.

9. A partir do prefixo 2001:0db8::/32, atribuir os prefixos às redes e computadores da orga-
nização ilustrada na figura a seguir:

necessidade prefixo Número redes /64 prefixo Número redes /64

de sub-redes de sub-redes

2 redes /33 2 2^31 /36 16 2^28

Capítulo 3 - Endereçamento IPv6

56 redes

1500 redes

30000 redes

57
 Descrição Endereço/Prefixo Descrição Endereço Prefixo

Infraestrutura rot. /48 Rede 7 (R7) /56

Gestão e Monit. /48 Rede do Host1 /64

Rede 1 (R1) /48 Rede do Host2 /64

Rede 2 (R2) /48 Rede do Host3 /64

Rede 3 (R3) /48 Host1 /64

Rede 4 (R4) /56 Host2 /64

Rede 5 (R5) /56 Host3 /64

Rede 6 (R6) /56
IPv6 Básico

58
 4
ICMPv6 – Parte 1
objetivos

Estudar o protocolo ICMPv6 e algumas de suas funcionalidades.

conceitos
Estrutura do ICMPv6 e suas funcionalidades e descoberta de vizinhança.

O protocolo IPv6 apresenta uma série de novas funcionalidades e outras, aprimoradas em

relação ao IPv4. Na primeira parte deste capítulo, conheceremos um pouco mais sobre essas
funcionalidades, começando pelo estudo do protocolo Internet Control Message Protocol
version 6 (ICMPv6), peça fundamental para a execução de ferramentas como o protocolo de Des-
Stateless coberta de Vizinhança (Neighbor Discovery) e os mecanismos de autoconfiguração stateless,
Serviço que trata cada que também serão tratados aqui. Analisaremos o funcionamento do protocolo DHCPv6 e como
pedido como uma suas funcionalidades podem auxiliar no trabalho de renumeração de redes.
operação independente
de qualquer pedido
anterior ICMPv6
Definido na RFC 4443. q
Mesmas funções do ICMPv4 (mas não são compatíveis):

11 Informar características da rede.

11 Realizar diagnósticos.

11 Relatar erros no processamento de pacotes.

Assume as funcionalidades de outros protocolos:

11 ARP/RARP.

11 IGMP.

Identificado pelo valor 58 no campo Próximo Cabeçalho.

Capítulo 4 - ICMPv6 – Parte 1

Deve ser implementado em todos os nós.

Definido na RFC 4443 para ser utilizado com o IPv6, o ICMPv6 é uma versão atualizada do
Internet Control Message Protocol (ICMP) utilizado com IPv4.

Essa nova versão do ICMP apresenta as mesmas funções que o ICMPv4, como reportar
erros no processamento de pacotes e enviar mensagens sobre o status das características
da rede. No entanto, ela não é compatível com o seu antecessor, apresentando agora um
número maior de mensagens e funcionalidades e possuem diferenças significativas.

59
 Uma das principais diferenças é que o ICMPv6 assume funções de protocolo que existem
isoladamente no IPv4. Tal mudança foi projetada com o intuito de reduzir a multiplicidade
de protocolos, que é prejudicial, uma vez que piora a coerência e aumenta o tamanho das
implementações nos diversos dispositivos. As funções assumidas se referem às funcionali-
dades dos seguintes protocolos integrantes do IPv4:

11 ARP (Address Resolution Protocol): o objetivo é mapear os endereços físicos através de

endereços lógicos;

11 RARP (Reverse Address Resolution Protocol): possui funcionalidade inversa à do ARP, e

é responsável por mapear os endereços lógicos em endereços físicos;

11 IGMP (Internet Group Management Protocol): atua com o gerenciamento de membros

de grupos multicast.

É importante notar que tanto o ARP quanto o RARP são protocolos que operam entre as
camadas 2 e 3 do modelo ISO/OSI, pois não dependem de pacotes IP. Já o ICMPv6 funciona
inteiramente na camada 3, sendo encapsulado em pacotes IP. Isso significa que firewalls
que operam na camada de rede exigem atenção extra com o IPv6, já que podem bloquear
funções extremamente básicas, como a descoberta de vizinhos e a autoconfiguração.

Outra diferença importante é a utilização do ICMPv6 pelos subsequentes protocolos

e funcionalidades:

11 MLD (Multicast Listener Discovery): opera com o gerenciamento de grupos multicast;

11 NDP (Neighbor Discovery Protocol): é responsável por identificar e aprender caracterís-

ticas de rede da vizinhança;

11 Path MTU (Maximum Transfer Unity) Discovery: trabalha no processo de descoberta

do menor MTU no caminho de comunicação entre dois nós;

11 Mobility Support: cuida do gerenciamento de endereços de origem de host dinamicamente;

11 Autoconfiguração Stateless: permite a aquisição de endereços IP globais sem o uso de DHCP.

Deve-se ter em mente que, de forma geral, o ICMPv6 é muito mais importante para o funcio-
namento do IPv6 do que o ICMP é para o funcionamento do IPv4.

O valor no campo Próximo Cabeçalho, que indica a presença do protocolo ICMPv6, é 58, q
e o suporte a esse protocolo deve ser implementado em todos nós.

11 É precedido pelos cabeçalhos de extensão, se houver, e pelo cabeçalho base do IPv6.

11 Protocolo chave da arquitetura IPv6.

11 Essencial em funcionalidades do IPv6.

22 Gerenciamento de grupos multicast.

22 Descoberta de Vizinhança (Neighbor Discovery).

22 Mobilidade IPv6.

22 Descoberta do Path MTU.

IPv6 Básico

60
 IPv6

cadeia de cab.
de extensão

Figura 4.1
Encapsulamento do
ICMPv6
cabeçalho ICMPv6.

Em um pacote IPv6, o ICMPv6 posiciona-se logo após o cabeçalho base do IPv6 e dos cabe-
çalhos de extensão, se houver.

O ICMPv6 é um protocolo-chave na arquitetura IPv6 uma vez que, além do gerenciamento

dos grupos multicast, através do protocolo Multicast Listener Discovery (MLD), e da reso-
lução de endereços da camada de enlace, suas mensagens são essenciais para o funciona-
mento do protocolo de Descoberta de Vizinhança (Neighbor Discovery), responsável por
localizar roteadores vizinhos na rede, detectar mudanças de endereço no enlace, detectar
endereços duplicados etc.; no suporte à mobilidade, gerenciando Endereços de Origem
dos hosts dinamicamente; e no processo de descoberta do menor Maximum Transmit Unit
(MTU) no caminho de um pacote até o destino.

Cabeçalho simples: q
11 Tipo (8 bits): especifica o tipo da mensagem;

11 Código (8 bits): oferece algumas informações adicionais para determinados tipos

de mensagens;

11 Soma de Verificação (16 bits): utilizada para detectar dados corrompidos no cabe-
çalho ICMPv6 e em parte do cabeçalho IPv6;

11 Dados: apresenta as informações de diagnóstico e erro de acordo com o tipo de men-

sagem. Seu tamanho pode variar de acordo com a mensagem.

Tipo Código Soma de verificação

(Type) (Code) (Checksum)

Figura 4.2 Dados

Estrutura do
cabeçalho ICMPv6.

O cabeçalho de todas as mensagens ICMPv6 tem a mesma estrutura simples, sendo com-
posto por quatro campos:

11 Tipo: especifica o tipo da mensagem, o que determinará o formato do corpo da men-

sagem. Seu tamanho é de oito bits;

11 Código: oferece algumas informações adicionais para determinados tipos de mensagens.

Capítulo 4 - ICMPv6 – Parte 1

Também possui oito bits de tamanho;

11 Soma de Verificação: detecta dados corrompidos no cabeçalho ICMPv6 e em parte do

cabeçalho IPv6. Seu tamanho é de 16 bits;

11 Dados: apresenta as informações de diagnóstico e erro de acordo com o tipo de men-

sagem. Para ajudar na solução de problemas, as mensagens de erro trarão nesse campo
o pacote que invocou a mensagem, desde que o tamanho total do pacote ICMPv6 não
exceda o MTU mínimo do IPv6, que é 1280 bytes.

61
 Possui duas classes de mensagens: q
11 Mensagens de erro:

22 “Destination Unreachable”.

22 “Packet Too Big”.

22 “Time Exceeded”.

22 “Parameter Problem”.

11 Mensagens de informação:

22 “Echo Request e Echo Reply”.

22 “Multicast Listener Query”.

22 “Multicast Listener Report”.

22 “Multicast Listener Done”.

22 “Router Solicitation e Router Advertisement”.

22 “Neighbor Solicitation e Neighbor Advertisement”.

22 “Redirect”.

As mensagens ICMPv6 são divididas em duas classes, cada uma composta por diversos tipos
de mensagens:

Tipo Nome Descrição

1 Destination Indica falhas na entrega do pacote, como endereço, porta

Unreachable desconhecida ou problemas na comunicação.

2 Packet Too Big Indica que o tamanho do pacote é maior que a Unidade
Máxima de Trânsito (MTU) de um enlace.

3 Time Exceeded Indica que o Limite de Encaminhamento ou o tempo de

remontagem do pacote foi excedido.

4 Parameter Indica erro em algum campo do cabeçalho IPv6 ou que o tipo

Problem indicado no campo Próximo Cabeçalho não foi reconhecido.

100-101 Uso experimental.

102-126 Não utilizado.

Tabela 4.1
Mensagens de
127 Reservado para expansão das mensagens de erro ICMPv6.
erro ICMPv6.

Tipo Nome Descrição

128 Echo Request Utilizadas pelo comando ping.

129 Echo Reply

130 Multicast Listener Query Utilizadas no gerenciamento de

grupos multicast.
131 Multicast Listener Report

132 Multicast Listener Done

IPv6 Básico

62
 Tipo Nome Descrição

133 Router Solicitation Utilizadas com o protocolo Descoberta

de Vizinhança.
134 Router Advertisement

135 Neighbor Solicitation

136 Neighbor Advertisement

137 Redirect Message

138 Router Renumbering Utilizada no mecanismo de Re-endereçamento

(Renumbering) de roteadores.

139 ICMP Node Information Utilizadas para descobrir informações sobre

Query nomes e endereços, são atualmente limitadas
a ferramentas de diagnóstico, depuração e
140 ICMP Node Information gestão de redes.
Response

141 Inverse ND Solicitation Utilizadas em uma extensão do protocolo de

Message Descoberta de Vizinhança.

142 Inverse ND Advertisement

Message

143 Version 2 Multicast Utilizada no gerenciamento de

Listener Report grupos multicast.

144 HA Address Discovery Utilizadas no mecanismo de Mobilidade IPv6.

Req. Message

145 HA Address Discovery

Reply Message

146 Mobile Prefix Solicitation

147 Mobile Prefix

Advertisement

148 Certification Path Utilizadas pelo protocolo SEND.

Solicitation Message

149 Cert. Path Advertisement

Message

150 Utilizada experimentalmente com protocolos

de mobilidade como o Seamoby.

151 Multicast Router Adverti- Utilizadas pelo mecanismo Multicast

sement Router Discovery.

152 Multicast Router Solicita-

tion

153 Multicast Router Termina-

Capítulo 4 - ICMPv6 – Parte 1

tion

154 FMIPv6 Messages Utilizadas pelo protocolo de mobilidade

Fast Handovers.

Tabela 4.2 200-201 Uso experimental.

Mensagens de
informação do 255 Reservado para expansão das mensagens de
ICMPv6. erro ICMPv6.

63
 Descoberta de Vizinhança
11 Neighbor Discovery – definido na RFC 4861. q
11 Assume as funções de protocolos ARP, ICMP Router Discovery e ICMP Redirect, do IPv4.

11 Adiciona novos métodos não existentes na versão anterior do protocolo IP.

11 Torna mais dinâmicos alguns processos de configuração de rede:

22 Determinar o endereço MAC dos nós da rede.

22 Encontrar roteadores vizinhos.

22 Determinar prefixos e outras informações de configuração da rede.

22 Detectar endereços duplicados.

22 Determinar as acessibilidades dos roteadores.

22 Redirecionamento de pacotes.

22 Autoconfiguração de endereços.

Definido pela RFC 4861, o protocolo de Descoberta de Vizinhança torna mais dinâmicos
alguns processos de configuração de rede em relação ao IPv4, combinando as funções de
protocolos como ARP, ICMP Router Discovery e ICMP Redirect, além de adicionar novos
métodos não existentes na versão anterior do protocolo IP.

O protocolo de Descoberta de Vizinhança do IPv6 é utilizado por hosts e roteadores.

11 Utiliza cinco tipos de mensagens ICMPv6: q

22 Router Solicitation (RS): ICMPv6 Tipo 133;

22 Router Advertisement (RA): ICMPv6 Tipo 134;

22 Neighbor Solicitation (NS): ICMPv6 Tipo 135;

22 Neighbor Advertisement (NA): ICMPv6 Tipo 136;

22 Redirect: ICMPv6 Tipo 137.

11 São configuradas com o valor 255 no campo Limite de Encaminhamento.

11 Podem ou não conter opções:

22 Source link-layer address;

22 Target link-layer address;

22 Prefix information;

22 Redirected header;

22 MTU.

As mensagens Neighbor Discovery são configuradas com um Limite de Encaminhamento de

255 para assegurar que as mensagens recebidas são originadas de um nó do mesmo enlace,
descartando as mensagens com valores diferentes.

No caso da autoconfiguração de nós, esse protocolo fornece suporte para a realização q

de três funcionalidades:

11 Parameter Discovery: atua na descoberta, por um nó, de informações sobre o

IPv6 Básico

enlace (como MTU) e a internet (como hop limit);

11 Address Autoconfiguration: trabalha com a autoconfiguração stateless de ende-

reços nas interfaces de um nó;

11 Duplicate Address Detection: opera em um nó com a finalidade de descobrir se o

endereço que se deseja configurar já está sendo utilizado por um outro nó na rede.
64
A transmissão de pacotes entre nós contribui para o funcionamento de seis processos: q
11 Router discovery: trabalha com a descoberta dos roteadores pertencentes ao enlace;

11 Prefix discovery: implementa a descoberta de prefixos de redes do enlace, cuja fina-

lidade é decidir para onde os pacotes serão direcionados numa comunicação (se para
um roteador específico ou direto para um nó do enlace);

11 Address resolution: descobre o endereço físico de uma interface de rede através de

seu endereço lógico IPv6;

11 Neighbor Unreachability Detection: permite que os nós descubram se um vizinho

é ou continua sendo alcançável. Isso é necessário uma vez que diversos problemas
podem acontecer tanto nos nós como na própria rede;

11 Redirect: possibilita que o roteador informe a um nó uma rota melhor para ser utili-
zada no envio de pacotes a um determinado destino;

11 Next-hop Determination: algoritmo para mapear endereços IP vizinhos para os

quais pacotes devem ser enviados segundo seus endereços de destino.

O Neighbor Discovery usa cinco mensagens ICMPv6: q

11 Router Solicitation (ICMPv6 tipo 133): utilizada por hosts para requisitar aos rotea-
dores mensagens Router Advertisements imediatamente. Normalmente é enviada
para o endereço multicast FF02::2 (all-routers on link).

11 Router Advertisement (ICMPv6 tipo 134): enviada periodicamente, ou em resposta a

uma Router Solicitation, é utilizada pelos roteadores para anunciar sua presença em
um enlace.

11 Neighbor Solicitation (ICMPv6 tipo 135): mensagem multicast enviada por um nó

para determinar o endereço MAC e a acessibilidade de um vizinho, além de detectar a
existência de endereços duplicados. Essa mensagem possui um campo para indicar o
endereço de origem da mensagem.

11 Neighbor Advertisement (ICMPv6 tipo 136): é enviada em resposta a uma men-

sagem Neighbor Solicitation ou espontaneamente para anunciar a mudança de
alguma característica do dispositivo na rede de maneira rápida.

11 Redirect (ICMPv6 tipo 137): informa ao nó solicitante de uma comunicação a melhor

opção de caminho para ser usada. Em outras palavras, envia o endereço do próximo
salto que deve ser usado para encaminhar pacotes quando se comunicar com aquele
determinado destino.

Router Solicitation (ICMPv6 tipo 133)

Sua importância vem da necessidade da descoberta instantânea de informações (como
rotas, MTU, hop limit e outras) que são disponibilizadas por roteadores. De tempos em
tempos, roteadores enviam esses dados a todos os nós do enlace. Contudo, esse processo
Capítulo 4 - ICMPv6 – Parte 1

pode ser demasiadamente lento para um dispositivo que queira se comunicar logo.

Essa mensagem serve para solicitar ao roteador que envie uma mensagem
extra imediatamente.

Geralmente essa situação acontece quando uma máquina tenta se conectar ou reconectar
a uma rede (no momento em que ele habilita sua interface) e, por isso, ainda desconhece
quaisquer detalhes das configurações do enlace e da internet.

65
 O pacote transmitido deve conter as seguintes características: q
11 O endereço de destino do cabeçalho IPv6 deve ser All-Router (FF02::2) multicast
Group, uma vez que o dispositivo não conhece os roteadores e suas informações;

11 O endereço de origem do cabeçalho IPv6 deve ser o unicast link local da interface
que está enviando a mensagem caso ele exista e, caso contrário, ele não deverá ser
especificado, ou seja, utiliza-se o endereço (::);

11 O campo Hop Limit do cabeçalho IPv6 deve ser marcado com o valor 255 para que
o protocolo fique imune ao recebimento de mensagem vindas de equipamentos
externos ao enlace;

11 O campo Type do cabeçalho ICMPv6 deve ser padronizado com o valor 133;

11 O campo Code do cabeçalho ICMPv6 deve ser padronizado com o valor 0, não apre-
sentando outras opções;

11 O campo Data do cabeçalho ICMPv6 deve ser dividido em dois subcampos:

22 Reserved de 32 bits: não é utilizado e deve ser inicializado com 0 na transmissão.

O receptor ignorará esse campo;

22 Options de tamanho variável: pode conter dados extras para auxiliar nas fun-
cionalidades básicas. No momento, apenas a opção Source Link-Layer Address
está implementada. Contudo, no futuro é possível que existam outras. Caso seja
transmitido uma opção não implementada para esse tipo de mensagem, ela será
ignorada pelo receptor.

0 1 2 3 4 5 6 7 8 9 1 1 2 3 4 5 6 7 8 9 2 1 2 3 4 5 6 7 8 9 3 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Type Code
Checksum
133 0

Reserved

Figura 4.3
Options... Formato do Pacote
Router Solicitation.

Router Advertisement (ICMPv6 tipo 134)

Sua importância provém do caráter informativo dessa mensagem. Além de anunciar o
roteador como alternativa para rota de tráfego no enlace, ela também contém dados (como
prefixos, MTU, DNS e outros) para que os nós realizem autoconfiguração. Nenhum outro dis-
positivo da rede possui tais dados de forma persistente, o que faz dos roteadores os únicos
responsáveis por disseminá-los.

O pacote transmitido deve conter as seguintes características: q

11 O endereço de destino do cabeçalho IPv6 depende do motivo que originou a mensagem:

22 Caso seja periódico, deverá ser All-Node (FF02::1) multicast address;

22 Se for uma resposta, deverá ser um unicast link local, ou seja, direcionado para o
IPv6 Básico

dispositivo requisitante.

66
11 O endereço de origem do cabeçalho IPv6 é o unicast link local da interface do rote- q
ador que está enviando a mensagem;

11 O campo Hop Limit do cabeçalho IPv6 é marcado com o valor 255 para que o protocolo
fique imune ao recebimento de mensagens vindas de equipamentos externos ao enlace;

11 O campo Type do cabeçalho ICMPv6 é padronizado com o valor 134;

11 O campo Code do cabeçalho ICMPv6 é padronizado com o valor 0, não apresentando

outras opções;

11 O campo Data do cabeçalho ICMPv6 é dividido em vários subcampos:

22 Cur Hop Limit de 8 bits: indica ao nó o valor que deve ser utilizado no campo
Hop limit do cabeçalho IPv6 quando for enviar um pacote. O valor 0 indicará que o
roteador não sugere nenhum valor default ao nó;

22 Managed Address Configuration Flag (M) de 1 bit: indica se o nó deve utilizar a

autoconfiguração de endereços stateful, DHCPv6, (1) ou não (0);

22 Other Stateful Configuration Flag (O) de 1 bit: indica se o nó deve receber infor-
mações adicionais via DHCPv6 (1) ou não (0). Caso a Flag M esteja configurada, a
opção marcada nessa flag será ignorada;

22 Mobile IPv6 Home Agent Flag (H) de 1 bit: indica se o roteador que está
enviando essa mensagem também funciona como Mobile IPv6 home agent no
enlace (1) ou não (0);

22 Router Selection Preferences (Prf) de 2 bits: indica qual nível de preferência

desse roteador em relação aos outros roteadores da vizinhança. Os possíveis
valores que esse campo pode assumir são:

33 01: prioridade alta (High);

33 00: prioridade média (medium) utilizada como default;

33 11: prioridade baixa (low);

33 10: reservado e não deve ser utilizada.

22 Neighbor Discovery Proxy Flag (P) de 1 bit: determina se a mensagem enviada

foi repassada por um proxy (1) ou não (0);

22 Reserved (Res) de 2 bits: não é utilizado e deve ser inicializado com 0 na trans-
missão. O receptor ignorará esse campo;

22 Router Lifetime de 16 bits: marca o tempo, em segundos, em que o roteador

deve ser considerado como roteador default. Caso o valor do campo seja 0, o rote-
ador não pode ser adicionado à lista de roteamento default do nó;

22 Rechable Time de 32 bits: determina o tempo máximo, em milissegundos, que

um nó pode assumir que o roteador é alcançável depois de receber uma men-
sagem de confirmação de acessibilidade. Esse campo serve para auxiliar na funcio-
nalidade Neighbor Unreachability Detection, que será explicada posteriormente;
Capítulo 4 - ICMPv6 – Parte 1

22 Retrans Timer de 32 bits: contém o intervalo de tempo, em milissegundos, que

deve existir entre retransmissões de mensagens Neighbor Solicitation. Esse campo
serve para auxiliar em duas funcionalidades: a Address Resolution e a Neighbor
Unreachability Detection, que serão explicadas posteriormente;

22 Options de tamanho variável: pode conter dados extras para auxiliar nas fun-
cionalidades básicas. No momento, só estão implementadas as opções Source
Link Layer Address, MTU, Prefix Information, Route Information e Recursive DNS
Server; contudo, no futuro é possível que novas opções sejam criadas. Caso seja
transmitida uma opção não implementada, o campo será ignorado.
67
 0 1 2 3 4 5 6 7 8 9 1 1 2 3 4 5 6 7 8 9 2 1 2 3 4 5 6 7 8 9 3 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Type Code
Checksum
134 0

Cur Hop Limit M O H Prf P Res Router lifetime

Reachable Time

Retrans Timer
Figura 4.4
Formato do
Options... Pacote Router
Advertisement.

Neighbor Solicitation (ICMPv6 tipo 135)

A mensagem é enviada por um dispositivo para solicitar que um determinado vizinho se
apresente imediatamente através de uma resposta do tipo Neighbor Advertisement. Por
causa dessa característica, ela é utilizada para suprir três necessidades básicas da comuni-
cação em redes IPv6.

A primeira consiste na descoberta de um endereço físico através de um endereço lógico.

Nesse caso, a resposta ao Neighbor Solicitation vai conter o endereço requisitado. No IPv4, o
Address Resolution Protocol (ARP) realiza a mesma função.

Utiliza o endereço multicast solicited-node em vez de broadcast. O host envia uma men-
sagem NS informando seu endereço MAC e solicita o endereço MAC do vizinho.

A segunda consiste no teste de acessibilidade de nós vizinhos do enlace. Nesse caso, a mensagem
pode ser enviada para verificar se determinado endereço lógico existe ou se ainda responde.

A terceira é a detecção de endereços IPv6 duplicados na vizinhança. A mensagem, nesse

caso, serve para que um equipamento descubra se existe alguma interface de rede já confi-
gurada com o endereço lógico que se deseja assumir.

O pacote transmitido deve conter as seguintes características: q

11 O endereço de destino do cabeçalho IPv6 depende do propósito da origem da mensagem:

22 Caso seja para a descoberta de um endereço físico ou para a detecção de um

endereço IPv6 duplicado, será preenchido com o Solicited Node Multicast Address
(FF02::1:FFXX:XXXX), uma vez que não se conhece todas as informações do destino;

22 Se for para verificar a acessibilidade, será preenchido com um unicast (linklocal ou

global), já que as informações sobre o destino são previamente conhecidas.

11 O endereço de origem do cabeçalho IPv6 depende do motivo da origem da mensagem:

22 Para a descoberta de um endereço físico ou para a verificação de acessibilidade,

será o unicast (link-local ou global) da interface do dispositivo requisitante;

22 Para detecção de endereços duplicados, não será especificado (::).

IPv6 Básico

11 O campo Hop Limit do cabeçalho IPv6 é marcado com o valor 255 para que o protocolo
fique imune ao recebimento de mensagem vindas de equipamentos externos ao enlace;

68
 11 O campo Type do cabeçalho ICMPv6 é padronizado com o valor 135; q
11 O campo Code do cabeçalho ICMPv6 e padronizado com o valor 0, não apresentando
outras opções;

11 O campo Data do cabeçalho ICMPv6 é dividido em três subcampos:

22 Reserved de 32 bits: não é utilizado e deve ser inicializado com 0 na transmissão.

O receptor ignorará esse campo;

22 Target Address de 128 bits: contém o endereço IPv6 do destino da mensagem

Neighbor Solicitation. Ao contrário do campo de destino do cabeçalho ICMPv6,
esse campo não pode conter endereços multicast;

22 Options de tamanho variável: pode conter dados extras para auxiliar nas funcio-
nalidades básicas. No momento só está implementada a opção Source Link-Layer
Address, que serve para especificar o endereço MAC do solicitante. Contudo, no
futuro existe a possibilidade de que outras sejam criadas. Caso seja transmitida
uma opção não implementada, o campo será ignorado pelo receptor.

0 1 2 3 4 5 6 7 8 9 1 1 2 3 4 5 6 7 8 9 2 1 2 3 4 5 6 7 8 9 3 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Type Code
Checksum
135 0

Reserved

Target Address

Figura 4.5
Formato do
Pacote Neighbor Options...
Solicitation.

Neighbor Advertisement (ICMPv6 tipo 136)

Enviada como resposta a uma Neighbor Solicitation, pode também ser enviada para anun- q
ciar a mudança de algum endereço dentro do enlace. Essa mensagem possui três flags:

11 A primeira indica se quem está enviando a mensagem é um roteador;

11 A segunda indica se a mensagem é uma resposta a uma NS;

11 A terceira indica se a informação carregada na mensagem é uma atualização de ende-

reço de algum nó da rede.
Capítulo 4 - ICMPv6 – Parte 1

69
 O pacote transmitido deve conter as seguintes características: q
11 O endereço de destino do cabeçalho IPv6 depende do propósito que originou a mensagem:

22 Para anunciar uma mudança ou para responder uma mensagem que possua o
endereço de origem não especificado, o campo deverá ser o All-Node (FF02::1)
multicast address, uma vez que ou pretende-se informar todos os nós vizinhos ou a
origem é desconhecida.

22 Caso seja resposta a uma mensagem que possua endereço de origem, o campo
deverá ser o endereço unicast (link-local ou global) especificado, uma vez que as
informações sobre o destino foram previamente fornecidas pela mensagem Nei-
ghbor Solicitation.

11 O endereço de origem do cabeçalho IPv6 deve ser o unicast da interface pela qual a
mensagem será enviada.

11 O campo Hop Limit do cabeçalho IPv6 deve ser marcado com o valor 255 para que
o protocolo fique imune ao recebimento de mensagem vindas de equipamentos
externos ao enlace.

11 O campo Type do cabeçalho ICMPv6 deve ser padronizado com o valor 136.

11 O campo Code do cabeçalho ICMPv6 deve ser padronizado com o valor 0, não apre-
sentando outras opções.

11 O campo Data do cabeçalho ICMPv6 deve ser dividido em seis subcampos:

22 Router Flag (R) de 1 bit: indica se a origem é um roteador (1) ou não (0). Esse
campo auxilia na funcionalidade Neighbor Unreachability Detection, que será
explicada posteriormente.

22 Solicited Flag (S) de 1 bit: indica se a mensagem foi enviada por causa de uma
mensagem Neighbor Solicitation com origem especificada (1) ou não (0). Esse campo
auxilia na funcionalidade Neighbor Unreachability Detection, que será explicada
posteriormente.

22 Override Flag (O) de 1 bit: indica se o destinatário deve sobrescrever o endereço

físico armazenado anteriormente no cache de vizinhança (Neighbor cache) (1) ou
não (0). Caso não haja nenhuma informação registrada, independente do valor da
flag, o cache receberá uma entrada nova.

22 Reserved de 29 bits: não é utilizado e deve ser inicializado com 0 na transmissão.

O receptor ignorará esse campo.

22 Target Address de 128 bits: depende de duas situações:

33 Caso seja uma resposta, o campo deverá conter o endereço IPv6 do nó que
está respondendo;

33 Caso seja um anúncio de mudança, o campo deverá conter o endereço IPv6 que
possuirá mudança no endereço físico.

22 Options de tamanho variável: pode conter dados extras para auxiliar nas fun-
cionalidades básicas. No momento só está implementada a opção Target linklayer
address, que pode especificar o endereço MAC para aonde a mensagem será
enviada. Contudo, no futuro outras podem ser criadas. Caso seja transmitida uma
opção não implementada, o campo será ignorado.
IPv6 Básico

70
 0 1 2 3 4 5 6 7 8 9 1 1 2 3 4 5 6 7 8 9 2 1 2 3 4 5 6 7 8 9 3 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Type Code
Checksum
136 0

R S O Reserved

Target Address

Figura 4.6
Formato do
Pacote Neighbor Options...
Advertisement.

Redirect (ICMPv6 tipo 137)

Utilizada por roteadores para informar ao host o melhor roteador para encaminhar o q
pacote ao destino. Essa mensagem traz como informação o endereço do roteador consi-
derado o melhor salto, o endereço do nó que está sendo redirecionado.

Esse mecanismo é igual ao existente no IPv4. As Figuras 4.7, 4.8 e 4.9 mostram o funcio-
namento do mecanismo Redirect.

Roteador B Computador C Roteador A

Figura 4.7
Mecanismo Pacote IPv6
Redirect – passo 1.
Capítulo 4 - ICMPv6 – Parte 1

71
 Roteador B Computador C Roteador A

ICMPv6 type 137

Origem - Endereço Link-local do roteador A
Destino - Endereço Link-local do computador C
Informação - Endereço Link-local do roteador B

Figura 4.8
Mecanismo
Redirect – passo 2.
Roteador B Computador C Roteador A

Pacotes IPv6 Figura 4.9

subsequentes Mecanismo Redirect –
passo 3.

O pacote transmitido deve conter as seguintes características: q

11 O endereço de destino do cabeçalho IPv6 deve ser o endereço unicast (link local ou
global) do dispositivo que requisitou uma comunicação através desse roteador;

11 O endereço de origem do cabeçalho IPv6 tem que ser o link local address da interface
do roteador;

11 O campo Hop Limit do cabeçalho IPv6 tem de ser marcado com o valor 255 para que o proto-
colo fique imune ao recebimento de mensagem vindas de equipamentos externos ao enlace;

11 O campo Type do cabeçalho ICMPv6 deve ser padronizado com o valor 137;

11 O campo Code do cabeçalho ICMPv6 deve ser padronizado com o valor 0, não apre-
sentando outras opções;

11 O campo Data do cabeçalho ICMPv6 deve ser dividido em quatro subcampos:

22 Reserved de 32 bits: não é utilizado e deve ser inicializado com 0 na transmissão. O

receptor vai ignorar esse campo;

22 Target Address de 128 bits – depende de duas situações:

IPv6 Básico

33 Caso o destino da comunicação seja o mesmo que o redirecionado, deverá

conter o endereço IPv6 do destino e deve repetir o campo Destination Address
do cabeçalho ICMPv6;

72
 33 Caso contrário, deverá conter o endereço IPv6 de link local do roteador que q
será o primeiro passo na nova rota.

22 Destination Address de 128 bits: contém o endereço IPv6 do destino da comuni-

cação que será redirecionado para outro nó;

22 Options de tamanho variável: pode conter dados extras para auxiliar nas fun-
cionalidades básicas. No momento só estão implementados o Target link-layer
address e o Redirect Header. Contudo, no futuro será possível que existam outras
possibilidades. Caso seja transmitida uma opção não implementada para esse tipo
de mensagem, ela será ignorada pelo receptor.

0 1 2 3 4 5 6 7 8 9 1 1 2 3 4 5 6 7 8 9 2 1 2 3 4 5 6 7 8 9 3 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Type Code
Checksum
137 0

Reserved

Target Address

Destination Address

Figura 4.10
Options...
Formato do Pacote
Redirect.

As mensagens pertencentes ao protocolo Neighbor Discovery podem ou não incluir dados

opcionais para agregar informações relevantes, e assim auxiliar nas funcionalidades básicas.

Todas as opções possuem uma estrutura básica de dois campos de 8 bits, o type e o length .
O primeiro serve para indicar qual é a opção que está sendo transmitida. Já o segundo serve
para demarcar o tamanho, incluindo os campos type e length, do campo opcional.
Capítulo 4 - ICMPv6 – Parte 1

Atualmente existem várias opções com distintas funções, porém só algumas serão
detalhadas por serem mais utilizadas nas funcionalidades básicas do IPv6.

Essas mensagens podem trazer zero ou mais opções, definidas na RFC 4861.

73
 Source link-layer address
Contém o endereço MAC do remetente do pacote. Sua função é carregar o endereço q
físico do nó de origem da mensagem. É utilizado nas seguintes mensagens: Neighbor
Solicitation, Router Solicitation e Router Advertisement.

O campo transmitido deve conter as seguintes características:

11 Type de 8 bits: contém o valor 1, que é o identificador do campo opcional Source Link
Layer Address;

11 Length de 8 bits: indica o tamanho do campo opcional Source Link Layer Address;

11 Link-Layer Address de tamanho variável: contém o endereço físico (MAC address)

do nó de origem.

0 1 2 3 4 5 6 7 8 9 1 1 2 3 4 5 6 7 8 9 2 1 2 3 4 5 6 7 8 9 3 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Type
Length
1

Link-Layer Address Figura 4.11

Formato do Pacote
Source Link Layer
Address.

Target link-layer address

Contém o endereço MAC de destino do pacote. Sua função é carregar o endereço físico q
do nó de destino questionado por outra mensagem. É utilizado nas mensagens Neighbor
Advertisement e Redirect. O campo transmitido deve conter as seguintes características:

11 Type de 8 bits: contém o valor 2, que é o identificador do campo opcional Target Link
Layer Address.

11 Length de 8 bits: indica o tamanho do campo opcional Target Link Layer Address.

11 Link-Layer Address de tamanho variável: contém o endereço físico do nó de destino.

0 1 2 3 4 5 6 7 8 9 1 1 2 3 4 5 6 7 8 9 2 1 2 3 4 5 6 7 8 9 3 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Type
Length
2

Link-Layer Address Figura 4.12

Formato do Pacote
Target Link Layer
Address.
IPv6 Básico

74
Prefix information
Fornece a hosts os prefixos do enlace e os prefixos para autoconfiguração do endereço. q
Sua função é prover ao nó solicitante um prefixo de rede que pode ser utilizado tanto
para que esse dispositivo se autoconfigure quanto para que identifique se um endereço
de destino pertence ao enlace. É utilizado nas mensagens Router Advertisement e deve
ser ignorado em outras mensagens. O campo transmitido deve conter as seguintes
características:

11 Type de 8 bits: contém o valor 3, que identifica o campo opcional Prefix Information;

11 Length de 8 bits: contém o valor 4, que indica o tamanho dos campos fixos do campo
opcional Prefix Information;

11 Prefix Length de 8 bits: contém o tamanho do prefixo enviado;

11 On-Link Flag (L) de 1 bit: indica se o prefixo enviado pode (1) ou não (0) ser utilizado
para identificar endereços vizinhos do enlace. Caso o valor seja zero, o receptor não
deve assumir que o prefixo não é do enlace e não pode utilizar essa informação para
alterar sua tabela de prefixos do enlace (Prefix List);

11 Autonomous Address-Configuration Flag (A) de 1 bit: indica se o prefixo pode ser

utilizado para autoconfiguração stateless (1) ou não (0);

11 Reserved1 de 6 bits: não é utilizado e tem de ser inicializado com 0 na transmissão. O

receptor tem de ignorar esse campo;

11 Valid Lifetime de 32 bits: seu valor depende de duas situações:

22 Se a mensagem for utilizada para identificar um prefixo no enlace: esse campo

marcará o tempo, em segundos, em que o prefixo é considerado válido para se iden-
tificar os endereços lógicos pertencentes ao enlace. O valor (0xffffffff) indica infinito;

22 Se a mensagem for utilizada para a autoconfiguração de endereços Stateless: esse

campo marcará o tempo, em segundos, em que o endereço pode ser identificado
como pertencente ao estado válido (olhar capítulo sobre estados dos endereços).

11 Preferred Lifetime de 32 bits: marca o tempo, em segundos, em que o endereço

gerado via autoconfiguração stateless pode ser identificado como pertencente ao
estado preferencial (ver capítulo sobre estados dos endereços). O valor (0xffffffff)
indica infinito;

11 Reserved2 de 32 bits: não é utilizado e tem de conter o valor zero na transmissão. O

receptor tem de ignorar esse campo;

11 Prefix de tamanho variável: contém o prefixo de rede a ser utilizado ou para a auto-
configuração ou para auxiliar na identificação de endereços do enlace.
Capítulo 4 - ICMPv6 – Parte 1

75
 0 1 2 3 4 5 6 7 8 9 1 1 2 3 4 5 6 7 8 9 2 1 2 3 4 5 6 7 8 9 3 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Type
Length Prefix Length L A Reserved1
3

Valid Lifetime

Preferred Lifetime

Reserved2

Prefix... Figura 4.13

Formato do Pacote
Prefix Information.

Redirected header
Contém todo ou parte do pacote que está sendo redirecionado. Sua função é enviar q
parte ou a totalidade da mensagem original que deverá ser redirecionada pelo nó de
origem a outro nó. É usado nas mensagens Redirect e deve ser ignorado em outras men-
sagens. O campo transmitido deve conter as seguintes características:

11 Type de 8 bits: contém o valor 4, que é o identificador do campo opcional Redirect

Header;

11 Length de 8 bits: indica o tamanho do campo opcional Redirect Header;

11 Reserved de 48 bits: não é utilizado e tem de ser inicializado com 0 na transmissão.

O receptor tem de ignorar esse campo;

11 IP Header + Data de tamanho variável: contém parte ou a totalidade da mensagem

original que deverá ser redirecionada. Esse campo não pode fazer com que o pacote
Redirect exceda o tamanho mínimo de MTU para suportar o IPv6.

0 1 2 3 4 5 6 7 8 9 1 1 2 3 4 5 6 7 8 9 2 1 2 3 4 5 6 7 8 9 3 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Type
Length
4

Reserved

IP Header + Data...
Figura 4.14
Formato do Pacote
Redirect Header.
IPv6 Básico

76
 MTU
Indica o valor do MTU do enlace. Sua função é transmitir a todos os nós do enlace q
o mesmo tamanho de MTU válido. É usado nos casos em que o MTU da camada de
enlace não é bem conhecido.

Esse campo opcional é enviado nas mensagens Router advertisement e deve ser ignorado
em outras mensagens. O campo transmitido deve conter as seguintes características:

11 Type de 8 bits: contém o valor 5, que é o identificador do campo opcional MTU;

11 Length de 8 bits: indica o tamanho do campo opcional MTU;

11 Reserved de 16 bits: não é utilizado e tem de ser inicializado com 0 na transmissão. O

receptor tem de ignorar esse campo;

11 MTU de 32 bits: informa o tamanho máximo de MTU que deve ser utilizado em comu-
nicações naquele enlace.

0 1 2 3 4 5 6 7 8 9 1 1 2 3 4 5 6 7 8 9 2 1 2 3 4 5 6 7 8 9 3 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Type
Length Reserved
5

Figura 4.15
Formato do MTU
Pacote MTU.

Recursive DNS Server Option (RDNSS)

Sua função é transmitir um ou mais endereços lógicos de servidores recursivos de DNS. q
É utilizado em mensagens Router Advertisement e deve ser ignorado em outras mensa-
gens. O pacote transmitido deve conter as seguintes características:

11 Type de 8 bits: contém o valor 25, que é o identificador do campo opcional RDNSS;

11 Length de 8 bits: indica o tamanho do campo opcional RDNSS;

11 Reserved de 16 bits: não é utilizado e tem de ser inicializado com 0 na transmissão.

O receptor tem de ignorar esse campo;

11 Lifetime de 32 bits: marca o tempo máximo, em segundos, em que os endereços

lógicos de RDNSS podem ser utilizados para resolução de endereços. O valor (0xffffffff)
indica infinito enquanto o valor 0 indica que o endereço não deve ser mais usado;

11 Address of IPv6 Recursive DNS Servers de tamanho variável (mas múltiplo de

128 bits): contém os endereços lógicos IPv6 dos servidores que devem ser utili-
zados para a resolução de nomes.
Capítulo 4 - ICMPv6 – Parte 1

77
 0 1 2 3 4 5 6 7 8 9 1 1 2 3 4 5 6 7 8 9 2 1 2 3 4 5 6 7 8 9 3 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Type
Length Reserved
25

Lifetime

Figura 4.16
Address of IPv6 Recursive DNS Servers... Formato do
Pacote RDNSS.

Novas opções foram definidas para novas funcionalidades do protocolo de Descoberta de Vizi-
nhança. Essas opções serão detalhadas conforme essas novas funções forem apresentadas.
IPv6 Básico

78
 5
ICMPv6 – Parte 2
objetivos

Estudar o protocolo ICMPv6 e algumas de suas funcionalidades e conhecer

o protocolo DHCPv6.

Descoberta de endereços de Camada de Enlace; descoberta de roteadores

conceitos
e prefixos; detecção de endereços duplicados; detecção de vizinhos inacessíveis;
redirecionamento; autoconfiguração de endereços stateless e stateful; protocolo
DHCPv6; estado dos endereços.

Descoberta de endereços da camada de enlace

11 Determina o endereço MAC dos vizinhos do mesmo enlace. q
11 Substitui o protocolo ARP.

11 Utiliza o endereço multicast solicited-node em vez de broadcast.

22 O host envia uma mensagem NS informando seu endereço MAC e solicita o ende-
reço MAC do vizinho.

22 O vizinho responde enviando uma mensagem NA informando seu endereço MAC.

Figura 5.1
Envios de Essa funcionalidade é utilizada para determinar o endereço MAC dos vizinhos do mesmo
mensagem
Neighbor enlace, quando um host envia uma mensagem NS para o endereço multicast solicited-node
Solicitation. do vizinho, informando seu endereço MAC.

2001:db8::faca:cafe:1234 A B 2001:db8::ca5a:f0ca:5678
MAC AB-CD-C9-21-58-0C MAC AB-CD-C0-12-85-C0
Capítulo 5 - ICMPv6 – Parte 2

ICMPv6 type 135 (Neighbor Solicitation)

Origem - 2001:db8::faca:cafe:1234
Destino - FF02::1FFCA:5678 (33-33-FF-CA-56-78)
Who is 2001:db8::ca5a:f0ca:5678?
79
 A B
2001:db8::faca:cafe:1234 2001:db8::ca5a:f0ca:5678
MAC AB-CD-C9-21-58-0C MAC AB-CD-C0-12-85-C0

ICMPv6 type 136 (Neighbor Advertisement)

Origem - 2001:db8::ca5a:f0ca:5678
Destino - 2001:db8::faca:cafe:1234 (AB-CD-C9-21-58-0C)
Use AB-CD-C0-12-85-C0

Ao receber a mensagem, o vizinho a responde enviando uma mensagem NA informando seu Figura 5.2
endereço MAC. Essa característica do protocolo Descoberta de Vizinhança substitui, no IPv6, Envios de
mensagem
o protocolo ARP do IPv4, utilizando no lugar de um endereço broadcast o endereço multi- Neighbor
cast solicited-node como endereço de destino. Advertisement.

Descoberta de roteadores e prefixos

11 Localizar roteadores vizinhos dentro do mesmo enlace. q
11 Determina prefixos e parâmetros relacionados à autoconfiguração de endereço.

11 No IPv4, essa função é realizada pelas mensagens ARP Request.

11 Roteadores enviam mensagens RA para o endereço multicast all-nodes.

ICMPv6 Type 134

Origem - Endereço Link-local do roteador
Destino - Endereço multicast all-nodes
Informação - Opções, prefixos, lifetime, Figura 5.3
flag de auto-configuração
Envios de
mensagem Router
Advertisement.

Essa funcionalidade do protocolo de Descoberta de Vizinhança é utilizada para localizar

roteadores vizinhos dentro do mesmo enlace, bem como para aprender prefixos e parâmetros
relacionados à autoconfiguração de endereço. Essas informações são enviadas a partir de um
roteador local, através de mensagens RA encaminhadas para o endereço multicast all-nod
IPv6 Básico

80
 No IPv4, o mapeamento dos endereços da rede local é realizado através de mensa-
gens ARP Request.

Detecção de Endereços Duplicados (DAD)

11 Verifica a unicidade dos endereços de um nó dentro do enlace. q
11 Deve ser realizado antes de se atribuir qualquer endereço unicast a uma interface.

11 Consiste no envio de uma mensagem NS pelo host, com o campo target address pre-
enchido com seu próprio endereço. Caso alguma mensagem NA seja recebida como
resposta, isso indicará que o endereço já está sendo utilizado.

A Detecção de Endereços Duplicados é o procedimento utilizado pelos nós para verificar a

unicidade dos endereços em um enlace, devendo ser realizado antes de se atribuir qualquer
endereço unicast a uma interface, independentemente de este ter sido obtido através de
autoconfiguração stateless, DHCPv6 ou configuração manual.

O mecanismo DAD consiste no envio de uma mensagem NS pelo host, com o campo target
address preenchido com seu próprio endereço. Caso alguma mensagem NA seja recebida
em resposta, isso indicará que o endereço já está sendo utilizado e o processo de configu-
ração deve ser interrompido.

Gratuitous ARP No IPv4, os nós utilizam mensagens ARP Request e o método chamado Gratuitous ARP
Pacote de broadcast para detectar endereços unicast duplicados dentro do mesmo enlace, definindo os campos
ARP usado para se ter Source Protocol Address e Target Protocol Address, do cabeçalho da mensagem ARP Request,
certeza de que nenhum
outro dispositivo na com o endereço IPv4 que está sendo verificado.
rede tem o mesmo
endereço IP que o A topologia do exemplo a seguir é constituída por três computadores interconectados q
dispositivo de envio. Se por um switch, como indicado na próxima figura. O computador Cópia trocará seu
chegar uma resposta ao endereço lógico pelo mesmo endereço do computador Original, porém não pode haver
Gratuitous ARP gratuito,
significa que outro com- endereços repetidos no enlace. Cada computador possui uma diferente descrição:
putador na rede tem o 11 Original: é o verdadeiro dono do endereço IPv6 global (2001:db8::10) e do link local
mesmo endereço IP.
(FE80::200:FF:FEAA:0). A partir do endereço global, a máquina pode se comunicar
tanto na internet como na rede local;

11 Cópia: é o dono do endereço IPv6 link local (FE80::200:FF:FEAA:2) e não possui

endereço global. Contudo, por algum motivo não especificado, ela tenta adicionar o
mesmo endereço IPv6 global da máquina Original (2001:db8::10) à sua interface;

11 Cliente: é o dono do endereço IPv6 global (2001:db8::11) e do link local

(FE80::200:FF:FEAA:1). Ele participa do exemplo como observador de quem é o verda-
deiro dono do endereço IPv6 (2001:db8::10).
Capítulo 5 - ICMPv6 – Parte 2

81
 Rede Local Figura 5.4
Topologia do
exemplo da
funcionalidade
Detecção de
Original Cópia Endereços
Local fe80::200:ff:feaa:0 Local fe80::200:ff:feaa:2 Duplicados.
Global 2001:db8::10/64 Global 2001:db8::10/64

Figura 5.5
Troca de
Cliente mensagens do
Local fe80::200:ff:feaa:1 exemplo da
Global 2001:db8::11/64 funcionalidade

q
Detecção de
No momento em que a máquina Cópia tentar adicionar o endereço repetido à sua Endereços
interface, a seguinte troca de mensagens acontece: Duplicados.

Cópia Original Cliente

Local fe80::200:ff:feaa:2 Local fe80::200:ff:feaa:0 Local fe80::200:ff:feaa:1
Global 2001:db8::10/64 Global 2001:db8::10/64 Global 2001:db8::11/64

NS-Source Ipv6 ::, Dest IPv6 ff02::1:ff00:10

Target ICMPv6 2001:db8::10

NS-Source Ipv6 ::, Dest IPv6 ff02::1:ff00:10

Target ICMPv6 2001:db8::10

NA-Source IPv6 2001:db8::10 NA-Source IPv6 2001:db8::10

Dest IPv6 ff02::1 Dest IPv6 ff02::1
IPv6 Básico

Target link-layer address Target link-layer address

82
No final do processo, a máquina Cópia não consegue se autoconfigurar e a máquina q
Cliente só reconhece a máquina Original como o dono do endereço IPv6 (2001:db8::10).

Detecção de vizinhos inacessíveis

11 Utilizado para rastrear a acessibilidade dos nós ao longo do caminho. q
11 Um nó considera um vizinho acessível se ele recebeu recentemente a confirmação de
entrega de algum pacote a esse vizinho.

22 Pode ser uma resposta a mensagens do protocolo de Descoberta de

Vizinhança ou algum processo da camada de transporte que indique que
uma conexão foi estabelecida.

11 Executado apenas para endereços unicast.

11 Neighbor Cache (similar à tabela ARP).

11 Destination Cache.

Esse mecanismo é utilizado na comunicação host-a-host, host-a-roteador e roteador-a-host

para rastrear a acessibilidade dos nós ao longo do caminho. Um nó considera um vizinho
acessível se ele recebeu recentemente a confirmação de entrega de algum pacote a esse
vizinho. Essa confirmação pode ocorrer de dois modos: ser uma resposta a uma mensagem
do protocolo de Descoberta de Vizinhança; ou algum processo da camada de transporte que
indique que uma conexão foi estabelecida.

Esse processo é executado apenas quando os pacotes são enviados a um endereço q

unicast, não sendo utilizado no envio para endereços multicast. Para acompanhar os
estados de um vizinho, o nó IPv6 utiliza duas importantes tabelas:

11 Neighbor Cache: mantém uma lista de vizinhos locais para os quais foi enviado
tráfego recentemente, armazenado seus endereços IP, informações sobre o endereço
MAC e uma flag indicando se o vizinho é um roteador ou um host. Também informa
se ainda há pacotes na fila para serem enviados, a acessibilidade dos vizinhos e o
próximo agendamento de um evento de detecção de vizinhos inacessíveis. Essa
tabela pode ser comparada à tabela ARP do IPv4;

11 Destination Cache: mantém informações sobre destinos para os quais foi enviado
tráfego recentemente, incluindo tanto destinos locais quanto remotos, sendo atua-
lizado com informações recebidas por mensagens Redirect. O Neighbor Cache pode
ser considerado um subconjunto das informações do Destination Cache.

A topologia do exemplo a seguir é constituída por dois computadores interconectados q

por um roteador. Existe uma rota alternativa, mas que possui mais saltos. Cada disposi-
tivo possui uma diferente descrição:

11 Cliente1: possui o endereço IPv6 global (2001:db8:cafe::10) e realiza uma comuni-

cação unidirecional ativa com o Cliente2 através do Roteador;
Capítulo 5 - ICMPv6 – Parte 2

11 Cliente2: é o dono do endereço IPv6 global (2001:db8:dado::10) e está recebendo

dados do Cliente1 através do roteador;

11 Roteador: possui duas interfaces configuradas com os seguintes endereços IPv6

globais: (2001:db8:cafe::11) do lado do Cliente1, e (2001:db8:dado::11) do lado Cliente2.
A comunicação entre os dois clientes é feita através desse roteador;

11 RoteadorAlternativo1 e RoteadorAlternativo2: representam uma segunda rota

para comunicar o Cliente1 ao Cliente2.

83
 RoteadorAlternativo 1 RoteadorAlternativo2

eth0 eth1
Local fe80::200:ff:feaa:1 Local fe80::200:ff:feaa::2
Global 2001:db8:cafe::11/64 Global 2001:db8:dado::11/64

Cliente1 Roteador Cliente2

Local fe80::200:ff:feaa:0 Local fe80::200:ff:feaa:3
Global 2001:db8:cafe::10/64 Global 2001:db8:dado::10/64

Nessa situação, durante a comunicação entre os clientes, acontece um problema no Rote- Figura 5.6
ador. Passado certo tempo, a máquina Cliente1 começa a desconfiar que o Roteador pode Topologia do
exemplo da
não estar operando devido à falta de mensagens dele provenientes. Isso acarreta na reali- funcionalidade
zação do mecanismo de detecção de vizinhos inacessíveis. de detecção
de vizinhos
inacessíveis.
IPv6 Básico

84
 eth0 eth1
Local fe80::200:ff:feaa:1 Local fe80::200:ff:feaa::2
Global 2001:db8:cafe::11/64 Global 2001:db8:dado::11/64

Cliente1 Cliente2
Local fe80::200:ff:feaa:0 Local fe80::200:ff:feaa:3
Global 2001:db8:cafe::10/64 Roteador Global 2001:db8:dado::10/64

Pacote IPv6 para o cliente2 Pacote IPv6 para o cliente2

Passado algum tempo ainda enviando pacotes...

NS-Source IPv6 2001:db8:cafe::10. Dest IPv6 ff02::1:ff00:11

Source Link-Layer Address

NS-Source IPv6 2001:db8:cafe::10. Dest IPv6 ff02::1:ff00:11

Source Link-Layer Address

NS-Source IPv6 2001:db8:cafe::10. Dest IPv6 ff02::1:ff00:11

Source Link-Layer Address

Trocando de Rota olhando a Routing Table

Pacote IPv6 para o cliente2 Pacote IPv6 para o cliente2

RoteadorAlternativo1 RoteadorAlternativo2

Figura 5.7 No final do processo, como o roteador não responde às mensagens de neighbor solicitation,
Troca de o Cliente1 por conhecer que o prefixo não pertence ao enlace, opta por procurar uma nova
mensagens do
exemplo da rota em sua tabela de roteamento e continua sua comunicação com o Cliente2.
funcionalidade
de detecção Redirecionamento
q
de vizinhos
inacessíveis. 11 Envia mensagens Redirect.

11 Redireciona um host para um roteador mais apropriado para o primeiro salto.

11 Informar ao host que destino encontra-se no mesmo enlace.

11 Esse mecanismo é igual ao existente no IPv4.

Capítulo 5 - ICMPv6 – Parte 2

85
 Roteador B Computador C Roteador A

Pacote IPv6

Roteador B Computador C Roteador A

ICMPv6 type 137

Origem - Endereço Link-local do roteador A
Destino - Endereço Link-local do computador C
Informação - Endereço Link-local do roteador B

Roteador B Computador C Roteador A

Figura 5.8
Pacotes IPv6 Mecanismos de
subsequentes redirecionamento
IPv6 Básico

de pacotes.

86
Mensagens Redirect são enviadas por roteadores para redirecionar um host automatica-
mente a um roteador mais apropriado ou para informar ao host que o destino encontra-se
no mesmo enlace. Esse mecanismo é igual ao que existe no IPv4.

Autoconfiguração de endereços stateless

11 Mecanismo que permite a atribuição de endereços unicast aos nós. q
11 Sem a necessidade de configurações manuais.

11 Sem servidores adicionais.

11 Apenas com as configurações mínimas dos roteadores.

11 Gera endereços IP a partir de informações enviadas pelos roteadores e de dados

locais, como o endereço MAC.

11 Gera um endereço para cada prefixo informado nas mensagens RA.

11 Se não houver roteadores presentes na rede, é gerado apenas um endereço link-local.

11 Roteadores utilizam apenas para gerar endereços link-local.

O mecanismo de autoconfiguração stateless, definido na RFC 4862, permite que endereços

IPv6 sejam atribuídos às interfaces sem a necessidade de configurações manuais, sem a uti-
lização de servidores adicionais (DHCP), apenas com configurações mínimas de roteadores.

Para gerar o endereço IP, um host utiliza uma combinação entre dados locais, como o
endereço MAC da interface ou um valor randômico para gerar o ID, e informações rece-
bidas dos roteadores, como múltiplos prefixos. Se não houver roteadores presentes, o
host gera apenas o endereço link-local com o prefixo “FE80::”.

11 Um endereço link-local é gerado.

22 Prefixo FE80::/64 + identificador da interface.

11 Endereço adicionado aos grupos multicast solicited-node e all-node.

11 Verifica-se a unicidade do endereço.

22 Se já estiver sendo utilizado, o processo é interrompido, exigindo uma

configuração manual.

22 Se for considerado único e válido, ele será atribuído à interface.

11 Host envia uma mensagem RS para o grupo multicast all-routers.

11 Todos os roteadores do enlace respondem com mensagem RA.

11 Estados dos endereços:

22 Endereço de Tentativa.

22 Endereço Preferencial.

22 Endereço Depreciado.

22 Endereço Válido.
Capítulo 5 - ICMPv6 – Parte 2

22 Endereço Inválido.

O mecanismo de autoconfiguração de endereços é executado respeitando os q

seguintes passos:

11 Um endereço link-local é gerado anexando ao prefixo FE80::/64 o identificador da

interface;

11 Esse endereço passa a fazer parte dos grupos multicast solicited-node e all-node;

11 É feita a verificação da unicidade do endereço de link-local gerado;

87
 11 Caso outro nó no enlace esteja utilizando o mesmo endereço, o processo de autocon- q
figuração é interrompido, exigindo uma configuração manual;

11 Se o endereço for considerado único e válido, será automaticamente inicializado

para a interface;

11 O host envia uma mensagem Router Solicitation para o grupo multicast all-routers;

11 Todos os roteadores do enlace respondem com uma mensagem Router Advertise-

ment informando: os roteadores padrão; um valor predefinido para o campo Limite
de Encaminhamento; o MTU do enlace; e a lista de prefixos da rede, para os quais
também serão gerados endereços automaticamente.

Um endereço IPv6 pode assumir diferentes estados: q

11 Endereço de Tentativa: endereço que ainda não foi atribuído. É o estado anterior à
atribuição, enquanto o processo de DAD é realizado. Não pode ser utilizado na comu-
nicação do nó, apenas por mensagens relativas à Descoberta de Vizinhança;

11 Endereço Preferencial: endereço atribuído à interface. Pode ser utilizado sem restri-
ções, até expirar seu tempo de vida;

11 Endereço Depreciado: endereço cujo tempo de vida expirou. Pode ser utilizado para
continuar as comunicações abertas por ele, mas não para iniciar novas comunicações;

11 Endereço Válido: termo utilizado para designar tanto os endereços preferenciais

quanto os depreciados;

11 Endereço Inválido: endereço que não pode ser atribuído a uma interface. Um ende-
reço se torna inválido quando seu tempo de vida expira.

A topologia desse exemplo é constituída de um computador conectado a um roteador. q

Nessa situação, o Cliente requisita informações da rede ao roteador que responde via
Router Advertisement. Cada dispositivo possui uma diferente descrição:

11 Cliente: possui o endereço IPv6 de link local (fe80::200:ff:feaa:0) e ainda não adquiriu
endereço global que permita conexão com a internet. Então, ele requisita ao roteador
informações para realizar sua autoconfiguração;

11 Roteador: possui o endereço IPv6 (2001:db8::11) e conhece os dados da rede, do

enlace e o prefixo, utilizados para que Cliente se autoconfigure.

Rede Local

Figura 5.9
Topologia do
exemplo da
funcionalidade
Autoconfiguração
Roteador Stateless via Router
Cliente Local fe80::200:ff:feaa::1 Advertisement.
Local fe80::200:ff:feaa:0 Global 2001:db8::11/64

Nesse exemplo, o cliente envia uma mensagem Router Solicitation para o roteador. q
Este responde com uma mensagem Router Advertisement, que será processada e utili-
IPv6 Básico

zada para autoconfiguração do dispositivo.

88
 Roteador
Cliente Local fe80::200:ff:feaa::1
Local fe80::200:ff:feaa:0 Global 2001:db8::11/64

RS-Source IPv6 fe80::200:ff:feaa:0, Dest IPv6 FF02::2

Source Link-Layer Address

RA-Source IPv6 fe80::200:ff:feaa:1, Dest IPv6 fe80::200:ff:feaa:0

Figura 5.10 Prefix Information 2001:db80::/64

Troca de Source Link-Layer Address
mensagens do MTU
exemplo da Outros
funcionalidade
Autoconfiguração
Stateless via Router Endereço global
Advertisement. 2001:db8::200:ff:feaa:0

Após a criação do endereço global, convém lembrar que, antes do dispositivo adicioná-lo q
à interface, o procedimento de detecção de endereços duplicados (Duplicate Address
Resolution) deve ser executado.

Autoconfiguração de endereços stateful

11 Usada pelo sistema quando nenhum roteador é encontrado. q
11 Usada pelo sistema quando indicada nas mensagens RA.

11 Fornece:

22 Endereços IPv6.

22 Outros parâmetros (servidores DNS, NTP).

11 Clientes utilizam um endereço link-local para transmitir ou receber mensagens DHCP.

11 Servidores utilizam endereços multicast para receber mensagens dos clientes

(FF02::1:2 ou FF05::1:3).

11 Clientes enviam mensagens a servidores fora de seu enlace utilizando um Relay DHCP.

O Dynamic Host Configuration Protocol (DHCP) é um protocolo de autoconfiguração stateful

usado na distribuição de endereços IP dinamicamente em uma rede, a partir de um servidor
Capítulo 5 - ICMPv6 – Parte 2

DHCP, fornecendo controle maior na atribuição de endereços aos hosts.

Definido na RFC 3315, o DHCPv6 é uma opção ao mecanismo de autoconfiguração stateless

do IPv6, podendo ser utilizado quando não há roteadores na rede ou quando seu uso for
indicado nas mensagens RA, sendo capaz de fornecer endereços IPv6 e diversos parâmetros
de rede, como endereços de servidores DNS, NTP, SIP etc.

No DHCPv6, a troca de mensagens entre cliente e servidor é realizada utilizando-se o proto-

colo UDP. Os clientes utilizam um endereço link-local para transmitir ou receber mensagens
DHCP, enquanto os servidores utilizam um endereço multicast reservado
89
 (FF02::1:2 ou FF05::1:3) para receber mensagens dos clientes. Caso o cliente necessite enviar
uma mensagem a um servidor que esteja fora de sua sub-rede, é utilizado um relay DHCP.

Permite controle maior na atribuição de endereços aos hosts. q

Os mecanismos de autoconfiguração de endereços stateful e stateless podem ser utili-
zados simultaneamente.

11 Por exemplo: utilizar autoconfiguração stateless para atribuir os endereços e DHCPv6

para informar o endereço do servidor DNS.

DHCPv6 e DHCPv4 são independentes. Redes com Pilha Dupla precisam de serviços
DHCP separados.

A utilização de DHCPv6 oferece controle maior na atribuição de endereços, uma vez que,
além de fornecer opções de configuração de rede, é possível definir políticas de alocação de
endereços e atribuir endereços aos hosts que não sejam derivados do endereço MAC.

Em uma rede IPv6, é possível combinar o uso de autoconfiguração stateless com servidores
DHCP. Nesse cenário é possível, por exemplo, utilizar autoconfiguração stateless na atri-
buição de endereços aos hosts e servidores DHCPv6 para fornecer informações adicionais
de configuração, como o endereço de servidores DNS.

Os protocolos DHCPv6 e DHCPv4 são independentes, de modo que, em uma rede com
Pilha Dupla (dual stack), será necessário rodar um serviço para cada protocolo. Com Pilha Dupla
DHCPv4, é preciso configurar no cliente se este usará DHCP, enquanto que com o DHCPv6 Envolve a presença
sua utilização é indicada através das opções das mensagens RA. simultânea do IPv4 e

q
IPv6 no mesmo sistema.
11 Hosts: autoconfiguração stateless ou DHCPv6.

11 Roteadores: Router Renumbering.

11 Mensagens ICMPv6 Tipo 138.

11 Formato da mensagem.

11 Cabeçalho RR + Corpo da Mensagem.

Tipo Código Soma de verificação

Número sequencial

Número de segmento Flags Atraso máximo

Reservado

Corpo da mensagem Figura 5.11

Mensagem de comando / Mensagem de resultado Estrutura do
cabeçalho Router
Renumbering.

O endereçamento de uma rede muitas vezes é baseado nos prefixos atribuídos por ISPs.
No caso de uma mudança de provedor, é necessário renumerar todos os endereços da rede.
IPv6 Básico

No IPv6, o processo de reendereçamento dos hosts pode ser feito de forma relativamente
simples. Através dos mecanismos do protocolo de Descoberta de Vizinhança, um novo prefixo

90
pode ser anunciado pelo roteador a todos os hosts do enlace. É possível também a utilização
de servidores DHCPv6. Para tratar a configuração e reconfiguração dos prefixos nos roteadores
tão facilmente quanto nos hosts, foi definido na RFC 2894 o protocolo Router Renumbering.

O mecanismo Router Renumbering utiliza mensagens ICMPv6 do tipo 138, enviadas aos
roteadores através do endereço multicast all-routers, contendo as instruções de como
atualizar seus prefixos.

As mensagens Router Renumbering são formadas pelos seguintes campos: q

11 Tipo: 138 (decimal);

11 Código: 0 para mensagens de comando;

22 1 para mensagens de resultado;

22 255 para zerar Número Sequencial;

33 Soma de Verificação: verifica a integridade da mensagem ICMPv6 e de parte

do cabeçalho IPv6;

33 Número Sequencial: identifica as operações;

33 Número de Segmento: enumera diferentes mensagens RR válidas que tenham

o mesmo Número Sequencial.

33 Flags:

33 T: indica se a configuração do roteador deve ser modificada ou se é um teste;

33 R: indica se uma mensagem de Resultado deve ser enviada;

33 A: indica se o comando deve ser aplicado a todas as interfaces, indepen-

dente do seu estado;

33 S: indica que o comando deve ser aplicado a todas as interfaces, indepen-

dente de qual sub-rede pertençam;

33 P: indica que a mensagem de Resultado contém o relatório completo

do processamento da mensagem de Comando, ou que a mensagem de
Comando foi previamente tratada (e não é um teste), e que o roteador não
está processando-a novamente.

33 Atraso Máximo: especifica o tempo máximo, em milisegundos, que um rote-

ador deve atrasar o envio de qualquer resposta à mensagem de comando.

As mensagens de comando são formadas por sequências de operações, Match-Prefix e

Use-Prefix. O Match-Prefix indica qual prefixo deve ser modificado, e o Use-Prefix indica o
novo prefixo. As operações podem ser ADD, CHANGE ou SET-GLOBAL, que instruem, respec-
tivamente, o roteador a adicionar os prefixos indicados em Use-Prefix ao conjunto de pre-
fixos configurados; a remover o prefixo indicado em Match-Prefix, se existirem, e trocá-los
pelos contidos em Use-Prefix; ou substituir todos os prefixos de escopo global pelos prefixos
do Use-Prefix. Se o conjunto de Use-Prefix for vazio, a operação não ADD não faz nenhuma
Capítulo 5 - ICMPv6 – Parte 2

adição e as outras duas operações apenas apagam o conteúdo indicado.

Os roteadores também enviam mensagens de Resultados contendo um Match

Report para cada prefixo igual aos enviados na mensagem de comando.

91
 A topologia do exemplo a seguir é constituída por um computador conectado a um ser- q
vidor DHCPv6. Nessa situação o cliente requisita um endereço global ao servidor DHCPv6.
A partir disso, uma negociação acontece entre as duas máquinas até que um endereço
seja reservado para o cliente. A descrição dos dispositivos que compõe tal topologia é:

11 Cliente: possui o endereço IPv6 de link local (FE80::200:FF:FEAA:0) e ainda não

adquiriu endereço global que permita sua conexão com a internet. Requisita ao ser-
vidor um endereço para realizar sua autoconfiguração;

11 ServidorDHCPv6: possui o endereço global IPv6 (2001:db8::11) e administra um conjunto

(pool) de endereços IPv6 do qual disponibilizará um para que a máquina Cliente se auto-
configure.

Figura 5.12
Topologia do
exemplo da
ServidorDHCPv6 funcionalidade
Cliente Local fe80::200:ff:feaa::1 Autoconfiguração
Local fe80::200:ff:feaa:0 Global 2001:db8::11/64 Stateful DHCPv6.

Nesse exemplo, o Cliente envia uma mensagem Solicit para a rede procurando por servi- q
dores habilitados. O ServidorDHCPv6 responde com uma mensagem Advertise se anun-
ciando para fornecer informações. Essa mensagem carrega o endereço solicitado para
auxiliar o Cliente na escolha entre os servidores que responderam. Então, ele elege um
servidor (no exemplo só há um servidor) e envia uma mensagem Request para requisitar
permissão de uso do endereço global passado. O ServidorDHCPv6 armazena, num registro,
o endereço passado ao Cliente e manda uma mensagem Reply como confirmação.
IPv6 Básico

92
 ServidorDHCPv6
Cliente Local fe80::200:ff:feaa::1
Local fe80::200:ff:feaa:0 Global 2001:db8::11/64

Solicit - Source IPv6 fe80::200:ff:feaa:0, Dest IPv6 ff02::1:2

Client Identifier
Identity Association for Non-temporary Address
Elapsed time

Advertise - Source IPv6 fe80::200:ff:feaa:1, Dest IPv6 fe80::200:ff:feaa:0

Client Identifier
Server Identifier
Identity Association for Non-temporary Address

Request - Source IPv6 fe80::200:ff:feaa:0, Dest IPv6 ff02::1:2

Client Identifier
Server Identifier
Elapsed time
Identity Association for Non-temporary Address

Figura 5.13 Replay - Source IPv6 fe80::200:ff:feaa:1, Dest IPv6 fe80::200:ff:feaa:0

Troca de
mensagens do Client Identifier
exemplo da Server Identifier
Identity Association for Non-temporary Address
funcionalidade
Autoconfiguração
Stateful via Endereço global
DHCPv6. 2001::db8::10/64

Após a última mensagem, a Reply, o Cliente inicia o procedimento de detecção de q

endereços duplicados no enlace. E só a partir de então utiliza o endereço em suas
comunicações.

Estado dos endereços

Todo endereço IPv6, desde a sua criação, possui um estado de operação atrelado que q
indica como ele deve ser utilizado na rede. No total, são cinco esses estados:

11 Tentativa: o endereço nesse estado ainda não foi atribuído a uma interface, principal-
mente porque o processo de detecção de endereços ainda não foi concluído. Todos os
pacotes que forem direcionados a um endereço nesse estado serão descartados;

11 Preferencial: o endereço nesse estado já foi atribuído a uma interface e pode ser
Capítulo 5 - ICMPv6 – Parte 2

utilizado indistintamente para comunicação na rede. Ou seja, pode ser utilizado tanto
como origem quanto como destino dos pacotes IPv6;

93
 11 Depreciado: o endereço nesse estado já foi atribuído a uma interface, porém não q
pode ser utilizado como origem em novas comunicações. Contudo, os pacotes de
comunicações previamente estabelecidas trafegam normalmente;

11 Válido: o endereço nesse estado já foi atribuído a uma interface e serve para
designar os endereços tanto no estado preferencial quanto no depreciado;

11 Inválido: o endereço nesse estado não pode ser atribuído a uma interface e não deve
ser utilizado para comunicações na rede. Ou seja, ele não pode ser utilizado nem
como origem nem no destino de pacotes IPv6.
l
Uma consideração que

q
pode ser feita sobre o
Existe uma ordem para esses estados serem designados aos endereços, o que remete estado dos endereços
é a de que nem todo
à ideia de ciclo de vida. O endereço, ao ser criado, recebe o estado de tentativa. Com
endereço passa por
ele permanece até que o processo de detecção de endereços duplicados indique sua todos os estados. Isso
unicidade no enlace. A seguir, ele é adicionado a uma interface e recebe o estado prefe- pode acontecer por
dois motivos. O
rencial, o que lhe permite ser utilizado em comunicações com a internet. Após o término
primeiro provém da
do tempo chamado Preferred Lifetime, o endereço passa do estado preferencial para o habilidade dos
depreciado, no qual ele serve apenas para manter as comunicações já em andamento. dispositivos de
conseguirem reiniciar
Passado o tempo designado como Valid Lifetime, o endereço entra no estado Inválido e
os contadores de
não pode mais ser utilizado. tempo relacionados ao
Preferred lifetime e ao
Valid Lifetime. O
Estados segundo é o fato de
esses tempos não
Válido
serem necessaria-
mente limitados.
Tentativa Preferencial Depreciado Inválido Algumas implementa-
ções permitem que eles
sejam infinitos.

Valid Lifetime

Preferred Lifetime Figura 5.14

Estados dos
endereços IPv6.

Saiba mais na RFC 3315

– Dynamic Host
Configuration Protocol
for IPv6 (DHCPv6); RFC
4443 – Internet Control
Message Protocol
(ICMPv6) for the
Internet Protocol
Version 6 (IPv6)
Specification; RFC 4861
– Neighbor Discovery
for IP version 6 (IPv6) e
na RFC 5006 – IPv6
Router Advertisement
Option for DNS
Configuration.
IPv6 Básico

94
 6
Funcionalidades do IPv6
objetivos

Descrever o tratamento da fragmentação de pacotes e o gerenciamento de

grupos multicast; apresentar as melhorias referentes à aplicação de QoS e
ao suporte à mobilidade.

conceitos
Path MTU Discovery; jumbograms; gerenciamento de grupos multicast;
Quality of Service (QoS); suporte à mobilidade.

Path MTU Discovery

Maximum Transmit Unit (MTU) é o tamanho máximo do pacote que pode trafegar q
através do enlace. A fragmentação permite o envio de pacotes maiores que o MTU
de um enlace.

11 IPv4: todos os roteadores podem fragmentar os pacotes que sejam maiores que o
MTU do próximo enlace.

22 Dependendo do desenho da rede, um pacote IPv4 pode ser fragmentado mais de

uma vez durante seu trajeto.

11 IPv6: fragmentação é realizada apenas na origem.

Path MTU Discovery: busca garantir que o pacote será encaminhado com o maior
tamanho possível.

Todos os nós IPv6 devem suportar PMTUD:

11 Implementações mínimas de IPv6 podem omitir esse suporte, utilizando 1280 bytes
como tamanho máximo de pacote.

Determinado pelos protocolos de roteamento, cada enlace na rede pode possuir um valor
Capítulo 6 - Funcionalidades do IPv6

diferente de MTU, ou seja, uma limitação distinta em relação ao tamanho máximo do

pacote que pode trafegar através dele. Para que um pacote maior que o MTU de enlace
seja encaminhado, deve ser fragmentado em pacotes menores, que serão remontados ao
chegarem em seu destino.

Na transmissão de um pacote IPv4, cada roteador ao longo do caminho pode fragmentar

os pacotes, caso estes sejam maiores do que o MTU do próximo enlace. Dependendo do
desenho da rede, um pacote IPv4 pode ser fragmentado mais de uma vez durante seu
trajeto através da rede, sendo reagrupado no destino final.

95
 No IPv6, a fragmentação dos pacotes é realizada apenas na origem, não sendo permitida em
roteadores intermediários. Esse processo tem o intuito de reduzir o overhead do cálculo dos
cabeçalhos alterados nos roteadores intermediários.

Para isso, é utilizado, no início do processo de fragmentação, o protocolo Path MTU Dis-
covery (PMTUD), descrito na RFC 1981, que descobre de forma dinâmica qual o tamanho
máximo permitido ao pacote, identificando previamente os MTUs de cada enlace no
caminho até o destino. O protocolo PMTUD deve ser suportado por todos os nós IPv6. No
entanto, implementações mínimas de IPv6 podem omitir esse suporte, utilizando 1280 bytes
como tamanho máximo de pacote.

11 1: assume que o MTU máximo do caminho é igual ao MTU do primeiro salto; q

11 2: pacotes maiores do que o suportado por algum roteador ao longo do caminho
são descartados;

11 Uma mensagem ICMPv6 packet too big é retornada.

11 3: após o recebimento dessa mensagem, o nó de origem reduz o tamanho dos

pacotes de acordo com o MTU indicado na mensagem packet too big;

11 4: o procedimento termina quando o tamanho do pacote for igual ou inferior ao

menor MTU do caminho;

11 5: essas iterações podem ocorrer diversas vezes até se encontrar o menor MTU;

11 6: pacotes enviados a um grupo multicast utilizam tamanho igual ao menor PMTU de

todo o conjunto de destinos.

O processo de PMTUD se inicia assumindo que o MTU de todo o caminho é igual ao MTU do
primeiro salto. Se o tamanho dos pacotes enviados for maior do que o suportado por algum
roteador ao longo do caminho, este vai descartá-lo e retornará uma mensagem ICMPv6
packet too big que devolve, juntamente com a mensagem de erro, o valor do MTU do enlace
seguinte. Após o recebimento dessa mensagem, o nó de origem reduzirá o tamanho dos
pacotes de acordo com o MTU indicado na mensagem packet too big.

Esse procedimento termina quando o tamanho do pacote for igual ou inferior ao menor
MTU do caminho, sendo que essas iterações, de troca de mensagens e redução do tamanho
dos pacotes, podem ocorrer diversas vezes até se encontrar o menor MTU. Caso o pacote
seja enviado a um grupo multicast, o tamanho utilizado será o menor PMTU de todo o con-
junto de destinos.

De um ponto de vista teórico, o PMTUD pode parecer imperfeito, dado que o roteamento Mais informações
dos pacotes é dinâmico, e cada pacote pode ser entregue através de uma rota diferente. No na RFC 1981 – Path
MTU Discovery for IP
entanto, essas mudanças não são tão frequentes, e caso o valor do MTU diminua devido a version 6.
uma mudança de rota, a origem receberá a mensagem de erro e reduzirá o valor do Path MTU.

Jumbograms
O IPv6 permite o envio de pacotes que possuam entre 65.536 e 4.294.967.295 bytes de q
comprimento.

Um jumbograms é identificado utilizando:

11 O campo Tamanho dos Dados com valor 0 (zero).

IPv6 Básico

11 O campo Próximo Cabeçalho indicando o cabeçalho Hop-by-Hop.

O cabeçalho de extensão Hop-by-Hop trará o tamanho do pacote.

Devem ser realizadas alterações também nos cabeçalhos TCP e UDP, ambos limitados a
16 bits para indicar o tamanho máximo dos pacotes.
96
 A RFC 2675 define uma opção do cabeçalho de extensão Hop-By-Hop chamada Jumbo
Payload. Essa opção permite o envio de pacotes IPv6 com cargas úteis entre 64KB e 4GB de
Jumbogram comprimento, conhecidos como jumbograms.
Pacote de qualquer
tamanho superior Ao enviar jumbograms, o cabeçalho IPv6 trará os campos Tamanho dos Dados e Próximo
ao padrão Maximum Cabeçalho com o valor zero. Este último indicará que as opções do cabeçalho de extensão
Transmission Unit (MTU)
Hop-By-Hop devem ser processadas pelos nós, onde são indicados os tamanhos dos
da rede de tecnologia
subjacente em ambas pacotes jumbograms.
camadas de enlace ou
rede. O cabeçalho UDP possui um campo de 16 bits chamado Tamanho, que indica o tamanho do
cabeçalho UDP mais o tamanho dos dados, não permitindo o envio de pacotes com mais
de 65.536 bytes. Entretanto, é possível o envio de jumbograms definindo o campo Tamanho
como zero, deixando que o receptor extraia o tamanho real do pacote UDP a partir do
tamanho do pacote IPv6.

Nos pacotes TCP, as opções Maximum Segment Size (MSS), que negociam no início da
conexão o tamanho máximo do pacote TCP a ser enviado, e Urgent Pointer, que indica um
deslocamento de bytes a partir do número de sequência em que dados com alta prioridade
devem ser encontrados, também não podem referenciar pacotes maiores que 65.535 bytes.
Desse modo, para se enviar jumbograms é preciso, no caso do MSS, determinar seu valor
como 65.535, que será tratado como infinito pelo receptor do pacote. Em relação ao Urgent
Aprenda mais sobre os
jumbograms na RFC Pointer, a solução é semelhante, uma vez que se pode determinar o valor do Urgent Pointer
2675 – IPv6 Jumbograms. como 65.535, indicando que está além do final deste pacote.

Gerenciamento de grupos multicast

Multicast Listener Discovery (MLD): q
11 Equivalente ao IGMPv2 do IPv4.

11 Utiliza mensagens ICMPv6.

11 Utiliza endereços link-local como endereço de origem.

11 Usa a opção Router Alert do cabeçalho de extensão Hop-by-Hop.

11 Nova versão:

22 MLDv2 (equivalente ao IGMPv3).

Multicast Router Discovery (MRD):

11 Mecanismo utilizado para descobrir roteadores multicast.

11 Utiliza três novas mensagens ICMPv6.

Recapitulando o que foi dito no Capítulo 3, multicast é uma técnica que permite endereçar
múltiplos nós como um grupo, possibilitando o envio de pacotes a todos os nós que o
compõem, a partir de um endereço único que o identifica.
Capítulo 6 - Funcionalidades do IPv6

Os membros de um grupo multicast são dinâmicos. Os nós podem entrar e sair de um grupo
a qualquer momento, não existindo limitações para o tamanho de um grupo multicast.

O gerenciamento dos grupos multicast no IPv6 é realizado pelo Multicast Listener q

Discovery (MLD), definido na RFC 2710. Esse protocolo é o responsável por informar aos
roteadores multicast locais o interesse dos nós em fazer parte ou sair de um determi-
nado grupo multicast. No IPv4, esse trabalho é realizado pelo protocolo Internet Group
Management Protocol (IGMPv2).

97
 O MLD utiliza três tipos de mensagens ICMPv6: q
11 Multicast Listener Query (Tipo 130): as mensagens Query possuem dois subtipos.
A General Query é utilizada por roteadores para verificar periodicamente os
membros do grupo, solicitando a todos os nós multicast que reportem todos os
grupos de que fazem parte. A Multicast-Address-Specific Query é utilizada por rotea-
dores para descobrir se existem nós fazendo parte de um determinado grupo;

11 Multicast Listener Report (Tipo 131): mensagens Report não solicitadas são
enviadas por um nó quando este começa a fazer parte de grupo multicast. Elas
também são geradas em resposta a mensagens Query;

11 Multicast Listener Done (Tipo 132): enviada pelos nós quando estes estão deixando
um determinado grupo.

Essas mensagens são enviadas com um endereço de origem link-local e com o valor 1 no
campo Limite de Encaminhamento, garantindo que elas permaneçam na rede local. Caso o
pacote possua um cabeçalho Hop-by-Hop, a flag Router Alert será marcada; desse modo, os
roteadores não descartarão o pacote, ainda que o endereço do grupo multicast em questão
não esteja sendo ouvido por eles.

Uma nova versão do protocolo MLD, chamada de MLDv2, foi definida na RFC 3810. Equiva-
lente ao IGMPv3, além de incorporar as funcionalidades de gerenciamento de grupos do
MLD, essa nova versão introduziu o suporte à filtragem de origem, que permite a um nó
especificar se não deseja receber pacotes de uma determinada origem ou informar o inte-
resse em receber pacotes somente de endereços específicos. Por padrão, os membros de
um grupo recebem pacotes de todos os membros desse grupo.

Outro mecanismo importante para o funcionamento dos grupos multicast é o Multicast q

Router Discovery (MRD). Definido na RFC 4286, é utilizado na descoberta de roteadores
multicast na rede. Ele utiliza três mensagens ICMPv6:

11 Multicast Router Advertisement (Tipo 151): essa mensagem é enviada por rotea-
dores para anunciar que o roteamento IP multicast está habilitado. É enviada a partir
do endereço link-local do roteador para o endereço multicast all-snoopers (FF02::6A);

11 Multicast Router Solicitation (Tipo 152): essa mensagem é enviada pelos dispositivos
para solicitar mensagens Multicast Router Advertisement aos roteadores multicast. Ela
é enviada a partir do endereço link-local do dispositivo para o endereço multicast all-
-routers (FF02::2);

11 Multicast Router Termination (Tipo 153): essa mensagem é enviada por rotea-
dores para anunciar que suas interfaces não estão mais encaminhando pacotes IP
multicast. Ela é enviada a partir do endereço link-local do roteador para o endereço
multicast all-snoopers (FF02::6A). Mais informações na
RFC 2710 – Multicast
Listener Discovery
O endereço multicast IPv4 para all-snoopers é 224.0.0.106 e para all-routers é 224.0.0.2. (MLD) for IPv6 – e na
RFC 4286 – Multicast
Router Discovery.
Todas as mensagens MRD também são enviadas com um Limite de Encaminhamento igual a 1
e contendo a opção Router Alert.
IPv6 Básico

98
Quality of Service (QoS)
O protocolo IP trata todos os pacotes da mesma forma, sem nenhuma preferência. q
Algumas aplicações necessitam que seus pacotes sejam transportados com a garantia
de que haja o mínimo de atraso, latência ou perda de pacotes.

11 VoIP.Videoconferência.

11 Jogos on-line.

11 Entre outros.

Conceito de Quality of Service (QoS) ou Qualidade de Serviço.

Arquiteturas principais:

11 Differentiated Services (DiffServ).

11 Integrated Services (IntServ).

Ambas utilizam políticas de tráfego e podem ser combinadas para permitir QoS em
LANs ou WANs.

A princípio, o protocolo IP trata todos os pacotes da mesma forma, sem nenhuma prefe-
rência no momento de encaminhá-los. Isso pode acarretar diversas implicações no desem-
penho de uma aplicação, uma vez que atualmente muitas dessas aplicações, como voz e
vídeo sobre IP, requerem transmissão e reprodução praticamente em tempo real, podendo
ter sua qualidade diminuída devido à ocorrência de perda de pacotes, entrega fora de
ordem, atraso ou variação de sinal. Esses problemas podem acontecer devido à forma como
o tráfego chega e é manipulado pelos roteadores, já que, vindo de diferentes interfaces e
diversas redes, o roteador processa os pacotes na ordem em que são recebidos.

O conceito de Quality of Service (QoS) – ou, em português, Qualidade de Serviço – é empre-

gado para protocolos cuja tarefa seja prover a transmissão de determinados tráfegos de
dados com prioridade e garantia de qualidade. Existem atualmente duas arquiteturas princi-
pais: Differentiated Services (DiffServ) e Integrated Services (IntServ). Ambas utilizam políticas
de tráfego e podem ser combinadas para permitir QoS em redes locais, regionais e nacionais.

DiffServ
Trabalha por meio de classes, agregando e priorizando pacotes com requisitos q
de QoS similares.

11 IPv4: campo Tipo de Serviço (ToS).

11 IPv6: campo Classe de Tráfego:

22 Mesma definição do campo ToS do IPv4.

22 Pode ser definido na origem ou por roteadores.

Capítulo 6 - Funcionalidades do IPv6

22 Pode ser redefinido por roteadores ao longo do caminho.

22 Em pacotes que não necessitam de QoS, o campo Classe de Tráfego apresenta

o valor 0 (zero).

DiffServ não exige identificação ou gerência dos fluxos.

Muito utilizado devido à sua facilidade de implantação.

O DiffServ trabalha por meio de classes, agregando e priorizando pacotes com requisitos
QoS similares. Pacotes DiffServ são identificados pelos oito bits dos campos Tipo de Serviço
do IPv4 e Classe de Tráfego do IPv6, com o intuito de identificar e distinguir as diferentes
classes ou prioridades de pacotes que necessitem de QoS.

99
 Ambos os campos possuem as mesmas definições, e as prioridades atribuídas a cada tipo
de pacote podem ser definidas tanto na origem quanto nos roteadores, podendo também Comparado com o
ser redefinidas ao longo do caminho, por roteadores intermediários. Em pacotes que não IntServ, o DiffServ não
exige qualquer
necessitem de QoS, o campo Classe de Tráfego apresenta o valor zero. identificação ou gerência
dos fluxos, além de ser
geralmente mais
IntServ
q
utilizado nas redes,
devido à sua facilidade
11 Baseia-se na reserva de recursos por fluxo.
de implantação.
Normalmente é associado ao protocolo Resource ReSerVation Protocol (RSVP).

11 IPv6: campo Identificador de Fluxo é preenchido pela origem com valores aleatórios
entre 00001 e FFFFF para identificar o fluxo que necessita de QoS.

22 Pacotes que não pertencem a um fluxo devem marcá-lo com zeros.

22 Os hosts e roteadores que não têm suporte às funções do campo Identificador de

Fluxo devem preencher esse campo com zeros quando enviarem um pacote, não
alterá-lo ao encaminharem um pacote, ou ignorá-lo quando receberem um pacote.

Pacotes de um mesmo fluxo devem possuir o mesmo endereço de origem e destino, e o

mesmo valor no campo Identificador de Fluxo.

RSVP utiliza alguns elementos do protocolo IPv6, como o campo Identificador de Fluxo e o
cabeçalho de extensão Hop-by-Hop.

O modelo IntServ baseia-se na reserva de recursos por fluxo e sua utilização está normal-
mente associada ao protocolo RSVP. O RSVP é utilizado para reservar o recurso ao longo do
caminho da fonte até o destino de um fluxo que requer QoS.

No IPv6, para identificar os fluxos que necessitam de QoS, são utilizados os 20 bits do
campo Identificador de Fluxo, que são preenchidos com valores aleatórios entre 00001 e
Para mais informações,
FFFFF. Pacotes que não pertencem a um fluxo devem marcar o campo Identificador de Fluxo leia a RFC 1633 – Inte-
com zeros. Os hosts e roteadores que não têm suporte às funções desse campo devem grated Services in the
Internet Architecture:
preenchê-lo com os zeros quando enviarem um pacote, não alterá-lo ao encaminharem um
an Overview; RFC 2205
pacote, ou ignorá-lo quando receberem um pacote. Pacotes de um mesmo fluxo devem possuir – Resource ReSerVation
o mesmo endereço de origem e destino, e o mesmo valor no campo Identificador de Fluxo. Protocol (RSVP); RFC
2475 – An Architecture
O RSVP utiliza alguns elementos do protocolo IPv6, como o campo Identificador de Fluxo e for Differentiated
Services e RFC 3260
o cabeçalho de extensão Hop-by-Hop. Pacotes RSVP são enviados com o mesmo valor no
– New Terminology and
campo Identificador de Fluxo, junto com o cabeçalho de Extensão Hop-By-Hop, usado para Clarifications for
transportar uma mensagem Router Alert, indicando para cada roteador no caminho do Diffserv.

tráfego QoS, que o pacote IP deverá ser processado.

Suporte à mobilidade no IPv6

Permite que um dispositivo móvel se desloque de uma rede para outra sem necessidade q
de alterar seu endereço IP de origem, tornando a movimentação entre redes invisível
para os protocolos das camadas superiores.
IPv6 Básico

100
 Nó móvel
Movimentação do nó

Endereço de origem
Agente de origem

Nó móvel Rede de origem

Internet

Endereço de origem
+
Endereço remoto

Rede remota

Nó correspondente

Figura 6.1 O suporte à mobilidade permite que um dispositivo móvel se desloque de uma rede para outra
Mobilidade sem a necessidade de alterar seu endereço IP de origem, tornando a movimentação entre redes
IPv6
invisível para os protocolos das camadas superiores. Com isso, todos os pacotes enviados para
esse Nó Móvel continuarão sendo encaminhados a ele usando o endereço de origem.

No suporte à mobilidade IPv6, existem alguns componentes-chave para o q

seu funcionamento:

11 Nó Móvel: dispositivo que pode mudar de uma rede para outra enquanto continua
recebendo pacotes através de seu Endereço de Origem;

11 Rede de Origem: rede que atribui o Endereço de Origem ao Nó Móvel;

11 Agente de Origem: roteador localizado na Rede de Origem que mantém a associação

entre o Endereço de Origem e o Endereço Remoto do Nó Móvel;

11 Endereço de Origem: endereço global unicast atribuído pela Rede de Origem ao Nó

Móvel. É utilizado como endereço permanente, para o qual os pacotes são encami-
nhados;

11 Rede Remota: qualquer rede, diferente da origem, onde o Nó Móvel se encontra;

11 Endereço Remoto: endereço global unicast atribuído ao Nó Móvel pela Rede Remota;

11 Nó Correspondente: nó que se comunica com o Nó Móvel. Pode ser móvel ou

estacionário.
Capítulo 6 - Funcionalidades do IPv6

Binding Updates
Funcionamento: q
11 O Nó Móvel utiliza o Endereço de Origem para receber pacotes na Rede de Origem.

11 Deslocamento:

22 Adquire Endereço Remoto via autoconfiguração stateless ou stateful.

22 Agente de Origem realiza a associação entre o Endereço Remoto e o Endereço

de Origem.

11 O Nó Móvel também pode se registrar diretamente com o Nó Correspondente.

101
 Mensagem Binding Updates

Figura 6.2
Troca de mensages
Mensagem Binding Acknowledgement
Binding.

O Nó Móvel possui um Endereço de Origem fixo, atribuído pela sua Rede de Origem. Mesmo
quando o nó se desloca de sua Rede de Origem, esse endereço é mantido.

Ao ingressar em uma Rede Remota, o Nó Móvel recebe um ou mais Endereços Remotos

através dos mecanismos de autoconfiguração, constituídos de um prefixo válido na Rede
Remota. Para assegurar que os pacotes IPv6 destinados ao seu Endereço de Origem sejam
recebidos, o nó realiza uma associação entre o Endereço de Origem e o Endereço Remoto,
registrando seu novo endereço no Agente de Origem, através do envio de uma mensagem
Binding Updates. Como resposta a essa mensagem, o roteador da Rede de Origem envia
uma mensagem Binding Acknowledgement.

Essa associação de endereços também pode ser feita diretamente com o Nó Corres-
pondente, com o intuito de otimizar a comunicação.

Para o Nó Móvel detectar que retornou à sua rede, é utilizado o processo de Descoberta
de Vizinhos Inacessíveis, para detectar se o seu roteador padrão está ativo. Caso localize
um novo roteador padrão, o Nó Móvel vai gerar um novo endereço baseado no prefixo
anunciado na mensagem RA. No entanto, encontrar um novo roteador padrão não significa
necessariamente que ele esteja em uma nova rede, porque pode ser apenas uma renume-
ração em sua rede ou a adição de um novo roteador. Com isso, antes de realizar a asso-
ciação de endereços com o Agente de Origem e com os Nós Correspondentes, o Nó Móvel
tenta localizar novamente seu roteador padrão para comparar se o intervalo entre o envio
de mensagens RA não solicitadas é o mesmo que o configurado em sua Rede Original.

Quando o Nó Móvel retorna à sua Rede de Origem, ele envia uma mensagem Binding
Updates informando ao Agente de Origem o seu retorno e que este não precisa mais lhe
encaminhar os pacotes.

O encaminhamento de pacotes para o nó móvel pode acontecer de dois modos: q

Tunelamento bidirecional e Otimização de rota.”.
IPv6 Básico

102
 Tunelamento bidirecional

Rede de origem

Nó correspondente
Agente de origem

Internet

Figura 6.3
Tunelamento
bidirecional:
Rede remota
pacotes enviados
interceptados pelo
Agente de Origem. Nó móvel

No Tunelamento Bidirecional, os pacotes enviados pelo Nó Correspondente para o Endereço

Original do Nó Móvel são interceptados pelo Agente de Origem, que os encaminhará, através
de um túnel, para o Nó Móvel, utilizando o Endereço Remoto. Em seguida, o Nó Móvel
responde ao Agente de Origem, através do túnel, que reenvia o pacote ao Nó Correspondente.
Nesse caso, o Nó Correspondente não necessita ter suporte à mobilidade IPv6 e o Nó Móvel
Figura 6.4 não precisa se registrar no Nó Correspondente.
Otimização de
Rota: comunicação
direta. Otimização de Rota
Rede de origem

Nó correspondente
Agente de origem
Capítulo 6 - Funcionalidades do IPv6

Internet

Rede remota

Nó móvel

103
 No modo Otimização de Rota, a comunicação entre o Nó Móvel e o Nó Correspondente
ocorre diretamente, sem a necessidade da utilização do Agente de Origem. Para que essa
comunicação ocorra, o Nó Móvel registra seu Endereço Remoto no Nó Correspondente, que
associa os Endereços de Origem e Remoto do Nó Móvel.

A troca de mensagens entre os dois nós funciona do seguinte modo: q

11 1: o Nó Correspondente envia pacotes com o campo Endereço de Destino do cabeçalho
base preenchido com o Endereço Remoto do Nó Móvel. O cabeçalho base é seguido pelo
cabeçalho de extensão Routing Tipo 2, que carrega o Endereço de Origem do Nó Móvel;

11 2: ao receber o pacote, o Nó Móvel processa o cabeçalho Routing e insere o Endereço

de Origem do cabeçalho Routing no campo Endereço de Destino do cabeçalho base.
As camadas superiores continuam o processamento do pacote normalmente;

11 3: os pacotes enviados pelo Nó Móvel têm o campo Endereço de Origem do cabe-

çalho base preenchido com o Endereço Remoto. O cabeçalho base é seguido pelo
cabeçalho de extensão Destination Options, que carrega na opção Home Address o
Endereço de Origem do Nó Móvel;

11 4: ao receber o pacote, o Nó Correspondente insere o Endereço de Origem do cabe-

çalho Destination Options no campo Endereço de Origem do cabeçalho base.
As camadas superiores continuam o processamento do pacote normalmente.

Mobility
11 Identificado no campo Próximo Cabeçalho pelo valor 135. q
11 Utilizado nas trocas de mensagens relacionadas à criação e gerenciamento das
associações de endereços.

11 Cabeçalho de extensão Mobility.

22 Principais tipos de mensagem Mobility:

33 Binding Refresh Request (Tipo 0).

33 Binding Update (Tipo 5).

33 Binding Ack (Tipo 6).

33 Binding Error (Tipo 7).

Protocolos Tam. cab. Tipo de mensagem

Reservado
de dados de extensão Mobility

Soma de verificação

Dados Figura 6.5

Estrutura do
cabeçalho de
extensão Mobility.

Para otimizar o funcionamento desse serviço, foi adicionado à especificação do IPv6 um

novo cabeçalho de extensão, o Mobility.
IPv6 Básico

O cabeçalho de extensão Mobility é indicado no campo Próximo Cabeçalho pelo valor 135.
Ele é utilizado pelo Nó Móvel, pelo Agente Remoto e pelo Nó Correspondente nas trocas de
mensagens relacionadas à criação e gerenciamento das associações de endereços.

104
Esse cabeçalho possui os seguintes campos:

11 Protocolo de dados: corresponde ao campo Próximo Cabeçalho. Atualmente apenas o

valor 59, em decimal, é utilizado, indicando que não há próximo cabeçalho;

11 Tamanho do cabeçalho de extensão: contém o tamanho do cabeçalho Mobility em

unidades de 8 bytes. O tamanho desse cabeçalho deve ser sempre múltiplo de 8;

11 Tipo de mensagem Mobility: indica o tipo da mensagem enviada;

11 Soma de verificação: verifica a integridade do cabeçalho Mobility;

11 Dados: o seu formato e tamanho dependem do tipo de mensagem Mobility que está
sendo enviada.

Principais tipos de mensagem Mobility:

11 Binding Refresh Request (Tipo 0): enviada pelo Nó Correspondente, solicitando ao

Nó Móvel a atualização da associação de endereços;

11 Binding Update (Tipo 5): enviada pelo Nó Móvel notificando ao Agente de Origem ou
ao Nó Correspondente sobre um novo Endereço Remoto;

11 Binding Ack (Tipo 6): enviada como confirmação de recebimento de uma mensagem
Binding Update;

11 Binding Error (Tipo 7): enviada pelo Nó Correspondente para relatar erros.

Novas mensagens ICMPv6

11 Home Agent Address Discovery Request.Home Agent Address Discovery Reply.Mobile q
Prefix Solicitation.Mobile Prefix Advertisement.

Também foram criadas quatro novas mensagens ICMPv6 utilizadas na configuração de pre-
fixos na Rede de Origem e na descoberta de Agentes de Origem.

O par de mensagens Home Agent Address Discovery Request e Home Agent Address
Discovery Reply são utilizadas para descobrir dinamicamente um Agente de Origem em
sua rede. Isso evita a necessidade de configurações manuais e problemas no caso da renu-
meração do Agente de Origem.

O Nó Móvel envia uma mensagem Discovery Request para o endereço anycast do Agente
de Origem em sua rede. O campo Endereço de Origem do cabeçalho base carrega o Endereço
Remoto do Nó Móvel. O Agente de Origem responde enviando uma mensagem Discovery
Reply. As mensagens Discovery Request e Reply são identificadas, respectivamente, pelos
valores 150 e 151 no campo Próximo Cabeçalho.

Já a mensagem Mobile Prefix Solicitation é enviada pelo Nó Móvel ao Agente de Origem, para
Capítulo 6 - Funcionalidades do IPv6

determinar mudanças nas configurações de prefixo em sua rede. O Agente Remoto responde
enviando uma mensagem Mobile Prefix Advertisement. Baseado nessa resposta, o Nó Móvel
pode ajustar seu Endereço de Origem. As mensagens Mobile Prefix Solicitation e Advertisement
são identificadas no campo Próximo Cabeçalho pelos valores 152 e 153, respectivamente.

Mudanças no protocolo Descoberta de Vizinhança

11 Modificação no formato das mensagens RA.Modificação no formato do Prefix Information. q
Adicionada a opção Advertisement Interval.Adicionada a opção Home Agent Information.

Algumas modificações também foram feitas no protocolo de Descoberta de Vizinhança.

105
 Foi adicionada à mensagem RA a flag H, que permite a um roteador anunciar se atua como
um Agente de Origem na rede. A partir desse anúncio, um Nó Móvel forma uma lista de
Agentes de Origem da sua rede.

No entanto, para manter essa lista atualizada, o Nó Móvel precisa saber os endereços global
unicast dos roteadores. Porém, as mensagens RA trazem apenas o endereço link-local. Para
resolver esse problema, foi adicionada uma nova flag à opção Prefix Information, a flag R.
A marcação dessa flag indica que a opção Prefix Information não contém um prefixo, mas
sim o endereço global unicast do roteador.

Também foram criadas duas novas opções ao protocolo, a Advertisement Interval e a Home
Agent Information. A primeira indica o intervalo entre mensagens RA não solicitadas, infor-
mação que é utilizada no algoritmo de detecção de mudança de rede. Nas especificações do
protocolo de Descoberta de Vizinhança, o intervalo mínimo entre o envio dessas mensagens
deve ser de três segundos. No entanto, para garantir que o Nó Móvel detecte a mudança de
rede e aprenda as informações sobre a nova rede o mais rápido possível, roteadores com
suporte à mobilidade IPv6 podem ser configurados com um intervalo de tempo menor para
o anúncio de mensagens RA.

A opção Home Agent Information é utilizada para indicar o nível de preferência de

associação de cada Agente de Origem.

Mobilidade IPv4 x Mobilidade IPv6

11 Não necessita da implantação de Agentes Remotos; q
11 A otimização da rota passou a incorporada ao protocolo;

11 A autoconfiguração stateless facilita a atribuição de Endereços Remotos;

11 Aproveita os benefícios do protocolo IPv6:

22 Descoberta de Vizinhança, ICMPv6, cabeçalhos de extensão;

11 Utiliza o protocolo de Descoberta de Vizinhança, em vez de ARP;

11 Utiliza anycast para localizar Agentes de Origem em vez de broadcast.

As principais diferenças entre o suporte à mobilidade do IPv6 e do IPv4 podem ser resumidas
nos seguintes tópicos:

11 Não há mais a necessidade de se implantar roteadores especiais atuando como

agentes remotos;

11 A otimização da rota passou a ser incorporada ao protocolo, em vez de fazer parte de um

conjunto de extensões opcionais;

11 A autoconfiguração stateless facilita a atribuição de Endereços Remotos;

11 Aproveita os benefícios do protocolo IPv6, como o protocolo de Descoberta de Vizinhança,

as mensagens ICMPv6 e os cabeçalhos de extensão;

11 O uso do protocolo de Descoberta de Vizinhança, em vez de ARP, permite que o processo

de interceptação dos pacotes destinados ao nó móvel não dependa da camada de enlace,
simplificando o protocolo e aumentando sua eficiência;
IPv6 Básico

11 A busca por agentes de origem realizada pelo Nó Móvel passou a ser feita utilizando Leia mais na RFC 3775
– Mobility Support in
anycast. Dessa forma, o Nó Móvel receberá apenas a resposta de um único Agente de IPv6.
Origem. Com o IPv4, utiliza-se broadcast, o que implica uma resposta separada para cada
Agente de Origem existente.

106
 7
Protocolo DNS
objetivos

Descrever o funcionamento do protocolo DNS.

conceitos
Componentes do DNS.

O protocolo DNS
O Serviço de Tradução de Nomes, ou simplesmente “serviço de nomes”, é um componente
dos serviços em redes que permite a aplicativos e serviços localizar e fazer referência a
informações em um ambiente de rede. Os nomes são parte crítica dos serviços em redes,
pois ajudam na administração de todos os recursos disponíveis na rede.

Domain Name Service (DNS) fornece serviços de nomes e diretórios em redes que imple-
mentam a pilha de protocolos Transmission Control Protocol/Internet Protocol (TCP/IP).
Podemos considerá-lo como um sistema de banco de dados distribuído, que traduz nomes
de estações em endereços, fornecendo informações sobre roteamento e domínios.

O DNS é essencial para os sites que se conectam diretamente à internet. Porém, mesmo para
redes locais isoladas que utilizam protocolos da pilha TCP/IP, sempre faz sentido utilizá-lo.
É particularmente importante para o sistema de correio eletrônico, pois é nele que são defi-
nidos registros que identificam a máquina que manipula as correspondências relativas a um
dado nome, identificando, assim, onde determinado usuário recebe suas correspondências.

O DNS é um dos componentes básicos da internet. Podemos considerá-lo como um sistema

de banco de dados distribuídos de nível mundial, que traduz endereços simbólicos de esta-
ções em endereços IP numéricos e vice-versa. Funções resolvedoras (resolver functions) do
DNS traduzem esse endereço simbólico para um endereço IP numérico.

11 Serviço para tradução de nomes em endereços IP e vice-versa. q

Capítulo 7 - Protocolo DNS

11 Também denominado Domain Name System ou Domain Name Server.

11 Torna o acesso aos serviços de rede independente do endereço IP do servidor.

11 A troca do IP do servidor é transparente para o usuário, pois sua localização (IP) é

fornecida pelo serviço DNS.

11 Arquitetura hierárquica, com dados dispostos em uma árvore invertida, distribuída

eficientemente em um sistema descentralizado e com cache.

107
 O rápido crescimento da internet levou à introdução dos conceitos de domínios e subdo-
mínios DNS. Os domínios compõem a estrutura básica do DNS e podem ser comparados a
diretórios em um sistema de arquivos, com cada domínio aparecendo como sub-árvores
de informações no espaço de nomes de domínio. Um endereço simbólico de estação em
um domínio deve ser único, porém esse mesmo endereço simbólico pode existir em outros
domínios. Os domínios são implementados como uma hierarquia, que pode ser vista como
uma árvore invertida, começando no domínio-raiz, cujo endereço simbólico real é “ ”, ou
seja, um rótulo (label) nulo.

“”

arpa com gov edu mil net org br ...

rnp

esr

Figura 7.1
Domínios genéricos Domínios
Árvore de
geográficos domínios DNS.

O domínio raiz é implementado por um grupo de servidores de nomes chamados de ser-

vidores raiz. Os servidores raiz só têm informações completas a respeito dos domínios de
topo, que se localizam imediatamente abaixo do domínio-raiz na árvore de hierarquia de
domínios. Os domínios de topo, por sua vez, têm apontadores para os servidores em domí-
nios de níveis inferiores. Nenhum servidor, nem mesmo os servidores raiz, tem informações
completas sobre todos os domínios, mas os seus apontadores podem indicar que outros
servidores podem fornecer a informação desejada. Assim, os servidores raiz podem até não
saber a resposta para uma pergunta, mas certamente saberão para quem direcioná-la.

Definições
11 Domínio. q
11 Zonas de autoridade.

11 Registro de recursos.

11 Mapeamento:

22 Direto.

22 Reverso.

Domínio
11 Domínio: sub-árvore do espaço de nomes DNS. q
11 Nome de domínio completo, também denominado Fully Qualified Domain Name
(FQDN), consiste em:
IPv6 Básico

22 Nome da máquina.

22 Nome do domínio.

22 Domínio de topo.

108
11 Exemplo: q
22 www.rnp.br

22 www: máquina (ou host).

22 rnp: domínio.

22 br: domínio de topo (top level domain).

Você possui, provavelmente, vários nomes de domínios guardados na cabeça. Exemplos:

rnp.br, receita.fazenda.gov.br, g1.com.br, mit.edu, google.com etc. As partes “com”, “edu” e
“br” desses servidores são chamadas de domínios principais ou domínios de primeiro nível.
Existem vários domínios principais, incluindo “com”, “edu”, “gov”, “mil”, “net” e “org”, além das
siglas de duas letras de cada país, para identificar a origem, em inglês. Não custa lembrar
que os domínios registrados nos EUA não possuem a identificação (“us”). Em cada domínio
principal existe uma enorme lista de domínios secundários.

Um domínio é uma sub-árvore do espaço de nomes DNS. Um domínio completo, também

denominado de Fully Qualified Domain Name (FQDN), consiste basicamente de um nome
de máquina, um nome de domínio e um domínio de topo. O endereço www.rnp.br é um
exemplo de FQDN, onde:

11 www: nome da máquina (ou host).

11 rnp: nome do domínio.

11 br: domínio de topo.

Cada sub-árvore é considerada parte de um domínio. Nesse caso, “rnp” faz parte do
domínio “br”. Considere o endereço www.df.rnp.br, no qual “df” é uma sub-árvore de “rnp”
e faz parte desse domínio.

Zonas de autoridade
Também denominadas Start of Authority (SOA). q
Domínios e zonas de autoridade não são sempre sinônimos.

11 Um nome de domínio se refere a um único ponto no espaço de nomes.

11 Uma zona de autoridade refere-se ao local no qual estão armazenados os dados

sobre as máquinas (hosts) do domínio.

Cada nome de domínio possui um registro de zona de autoridade que apresenta informa-
ções do domínio e da zona em que o domínio está inserido. Entre essas informações estão:

11 Nome do servidor de nomes primário;

11 Endereço eletrônico (e-mail) do responsável pelo domínio;

11 Número de série (serial number) da zona;

11 Intervalo de refresh: indica o tempo, em segundos, que o servidor de nomes secundário

Capítulo 7 - Protocolo DNS

deve checar por atualizações junto ao servidor de nomes primário;

11 Intervalo de retry: indica o tempo, em segundos, que o servidor de nomes secundário

aguarda por uma resposta do servidor de nomes primário, antes de indicar uma falha;

11 Tempo de expire: informa o tempo, em segundos, após o qual o servidor não mais res-
ponde por informações daquela zona;

11 Tempo de vida TTL (Time-to-Live): valor passado pelo servidor de nomes indicando, para a
máquina que originou a pergunta, o tempo que a informação pode ser mantida em cache.

109
 Registro de recursos
11 Todos os domínios podem ter um conjunto de registro de recursos associado. q
11 A verdadeira função do DNS é mapear nomes de domínio em registros de recurso.

11 Os registros do banco de dados do DNS possuem o seguinte formato:

22 <nome> <TTL> <classe> <tipo> <dados>

22 Nome: identifica o objeto. Exemplo: um computador.

22 TTL: tempo que o registro deve ser mantido em cache.

22 Classe: define o tipo de servidor.

33 IN (Servidor Internet): padrão; HS (Servidor Hesiod); CH (Servidor Chaosnet).

22 Tipo: define o tipo de registro.

22 Dados: dados específicos para o tipo de registro de recurso.

33 Exemplo: Tipo A contém um endereço; Tipo MX contém prioridade e endereço.

Um registro de recurso é composto por cinco campos: Domínio, Tempo de vida (TTL),
Classe, Tipo e Valor.

11 Domínio: refere-se ao domínio para o qual esse registro é aplicado. Normalmente,

existem muitos registros para cada domínio e cada cópia do banco de dados carrega
informação sobre múltiplos domínios. Esse campo é a chave primária de procura usada
para satisfazer as buscas. A ordem dos registros no banco de dados não é significante.
Quando uma busca é feita sobre um determinado domínio, são devolvidos todos os
registros pedidos, emparelhados em classe;

11 Tempo de vida (Time To Live): dá uma indicação do nível de estabilidade do registro. Infor-
mações muito estáveis recebem um valor alto, como 86400 (o número de segundos em um
dia). Informações altamente voláteis têm um valor pequeno, como 60 (em minutos);

11 Classe: terceiro campo de todo registro de recurso. Para informação de servidor internet,
é sempre IN. Para informações não relacionadas com a internet, são usados outros
códigos, que na prática são vistos raramente.

11 Tipo: fornece a informação do tipo de registro. Os tipos mais importantes são:

22 Start of Authority Information (SOA): contém informações referentes ao servidor

de nomes DNS do domínio, versão do banco de dados DNS, e-mail do administrador
responsável pelo domínio etc.;

22 A (Host Adress): mantém a tabela de endereços IP dos hosts mantendo compatibi-

lidade com a tabela antiga de hosts. Permite mapear um nome de host para um ou
cada endereço IP;

22 Name Server Identification (NS): especifica os servidores de nomes responsáveis

pelo domínio, zona ou subzona;

22 General Purpose Pointer (PTR): permite obter um nome de host, a partir do conheci-
mento do seu endereço IP. É a contraparte do registro A;

22 Canonical Name Alias (CNAME): permite criar um apelido para um host. Esse registro
IPv6 Básico

é útil para ocultar detalhes de implementação da sua intranet, por exemplo:

ftp.marketing.corporação.com pode ser apenas um apelido do verdadeiro servidor
que executa ftp do marketing;

110
 22 Host Information (HINFO): permite identificar propriedades de hardware e do
Sistema Operacional do host que serão exibidas toda vez que o usuário acessar esse
host. A padronização de identificação do tipo de CPU e do Sistema Operacional deve
obedecer aos nomes listados na RFC 1700;

22 Mail Exchange (MX): mantém informações referentes aos hosts responsáveis pelo
e-mail do domínio.

Finalmente, nós temos o campo Valor. Esse campo pode ser um número, um nome de
domínio, ou um conjunto de caracteres ASCII. A semântica depende do tipo de registro.

Tipo Descrição Valor

SOA Início de autoridade Informações do domínio e da zona

A Mapeamento de nome para endereço Endereço IP (32 bits)

PTR Mapeamento de endereço para nome Alias para endereço IP

MX Servidor de correio eletrônico Domínio e prioridade

NS Servidor de nomes Nome de um servidor de nomes

CNAME Nome canônico (para alias) Nome no domínio

HINFO Informações sobre o computador Recursos de hardware e software

Tabela 7.1
Tipos de registro. TXT Informações textuais Informação de uso geral

Exemplo: www 604800 IN A 200.130.77.75

Considere que todos os domínios podem ter associado um conjunto de registro de recursos.
Conforme mencionado anteriormente, uma zona de autoridade refere-se a um local onde
estão armazenados os dados sobre as máquinas do domínio.

Todos os registros de um determinado domínio estão em uma zona de autoridade respon-

sável por este. Nesse caso podemos ter, considerando os domínios df.rnp.br e rnp.br, duas
zonas de autoridade. A primeira responsável pelas informações referentes aos servidores
daquele domínio. A segunda, pelas informações dos servidores do outro domínio. Nesse
caso podemos ter:

11 Servidor 1: SOA do domínio rnp.br e responsável pelas informações de DNS dessa rede;

11 Servidor 2: SOA do domínio df.rnp.br e responsável pelas informações de DNS dessa rede.

Esses servidores podem estar inclusive em localidades diferentes, sem relação direta (pri-
mário e secundário) um com o outro.
Capítulo 7 - Protocolo DNS

111
 Mapeamento direto

DNS

Qual o endereço de
mail.rnp.br? Servidor DNS raiz
2
3
DNS
DNS

1 4

8 5
Servidor DNS raiz
Resposta: Servidor DNS local
6
200.130.38.66
7
DNS

Figura 7.2
Mapeamento
de um nome em
Servidor DNS raiz endereço IP.

O mapeamento direto é utilizado na tradução de nomes em endereços IP, que será usado
como destinatário do pacote a ser transmitido pela rede.

A consulta segue um entre dois processos:

11 O computador do usuário encaminha uma consulta ao servidor DNS presente em sua

rede local. Como este não tem a informação em seu banco de dados, procederá com
várias consultas até a determinação do endereço IP associado ao nome informado. Em
última instância, quem informará o endereço IP associado é o servidor DNS da rede de
destino. Todavia, para localização do servidor DNS da rede de destino é feita uma con-
sulta a um servidor raiz da internet para a determinação do domínio de topo. Em seguida
é feita uma consulta sobre a máquina responsável pelo DNS do domínio procurado. Por
último, é feita uma consulta ao servidor DNS da rede de destino, que por sua vez infor-
mará o endereço IP da máquina desejada;

11 O servidor DNS local já possui em cache o endereço procurado. Nesse caso, a resposta é
enviada diretamente ao computador que fez a consulta, sem necessidade de encaminhar
consultas a outros servidores.
IPv6 Básico

112
 Mapeamento reverso

Qual o nome da máquina com IP DNS

200.130.77.75?

2
DNS

1 3 Servidor DNS raiz

4
6
Resposta: Servidor DNS local Servidor
www.rnp.br 5

Figura 7.3
resposta:
Mapeamento de
um endereço IP em Classe C
um nome. 200.130.77

O mapeamento reverso é utilizado na tradução de endereços IP em nomes, na consulta

encaminhada ao servidor DNS da rede local. O servidor DNS local consulta um servidor DNS

l raiz
Esse tipo de consulta é
e em seguida o servidor DNS na rede de destino. O nome é então passado ao compu-
tador que efetuou a consulta.
utilizado frequente-
mente em diagnósticos
e na localização de um Resolução direta no IPv6
spammer ou hacker.
Registros: q
11 IPv4 = A - traduz nomes para endereços IPv4.

11 IPv6 = AAAA (quad-A) - traduz nomes para endereços IPv6.

22 Exemplo: www.ipv6.br. IN A 200.160.4.22

IN AAAA 2001:12ff:0:4::22

Para que o DNS trabalhe com a versão 6 do protocolo IP, algumas mudanças foram definidas
na RFC 3596. Um novo registro foi criado para armazenar os endereços IPv6 de 128 bits, o
AAAA ou quad-A. Sua função é traduzir nomes para endereços IPv6, equivalente ao registro
A utilizado com o IPv4. Caso um host possua mais de um endereço IPv6, ele terá um registro
quad-A para cada endereço. Os registros são representados como a seguir:

www.ipv6.br. IN A 200.160.4.22

IN AAAA 2001:12ff:0:4::22

Resolução reversa no IPv6

q
Capítulo 7 - Protocolo DNS

Registro PTR: Resolução de Reverso.

11 IPv4 = in-addr.arpa - traduz endereços IPv4 em nomes.

11 IPv6 = ip6.arpa - traduz endereços IPv6 em nomes.

22 Exemplo:
22.4.160.200.in-addr.arpa PTR www.ipv6.br.

33 2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.0.0.0.0.f.f.2.1.1.0.0.2.ip6.arpa PTR www.ipv6.br.

113
 22 Obsoletos q
33 Registros

33 A6

33 DNAME

33 Domínio para a resolução de reverso

33 ip6.int

Para resolução de reverso, foi adicionado o registro PTR ip6.arpa, responsável por traduzir
Os outros tipos de
endereços IPv6 em nomes. Em sua representação, omitir sequência de zeros não é permitido registro DNS não
e o bit menos significativo é colocado mais à esquerda, como é possível observar no exemplo: sofreram alterações,
apenas foram adap-
11 22.4.160.200.in-addr.arpa PTR www.ipv6.br; tados para suportar o
novo tamanho dos
11 2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.0.0.0.0.f.f.2.1.1.0.0.2.ip6.arpa PTR www.ipv6.br. endereços.
A RFC 2874 introduziu os registros A6 e DNAME, com o intuito de facilitar a renumeração de
redes, onde cada nameserver detém apenas uma parte do endereço IPv6. Inicialmente o
domínio para resolução de reverso, definido na RFC 1886, era o ip6.int; no entanto, houve mani-
festações contrárias à sua utilização, pois o “.int” significa “internacional”, não devendo servir
para fins administrativos na internet. Os registros A6 e DNAME tornaram-se obsoletos pelo
desuso, e o domínio “.int” foi substituído pelo “.arpa”, respectivamente nas RFCs 3363 e 3152.

Cliente e servidor DNS

Resolver (resolvedor): cliente. q
11 Efetua a montagem das consultas.

11 Biblioteca de rotinas ligada a qualquer aplicação que deseja ter um endereço traduzido.

11 Utiliza o arquivo /etc/resolv.conf para localizar o servidor DNS.

Named: Servidor de nomes.

11 Daemon (serviço) responde às consultas efetuadas.

O software de serviços de nomes do DNS é dividido conceitualmente em dois componentes:

11 Resolver (lado cliente): módulo de software responsável pela montagem das consultas;

11 Named (servidor de nomes): processo responsável por responder às perguntas,

fornecendo as respostas apropriadas.

A implementação mais comumente encontrada do DNS, tanto para o resolver quanto

para o servidor de nomes, é chamada Berkeley Internet Name Domain Server (BIND), para
ambientes Unix. Unix
Sistema Operacional
O resolver não existe como um processo distinto executado no computador. Ele é, na portátil, multitarefa e
realidade, uma biblioteca de rotinas de software (chamadas código do resolver) que é ligada multiutilizador, desen-
volvido em 1969, pela
(link-editada) a qualquer aplicação que deseja traduzir endereços. Essa biblioteca sabe como
Bell Laboratories.
solicitar do servidor de nomes informações a respeito de uma determinada estação. Do
ponto de vista de uma aplicação, o acesso ao DNS se dá pelo uso de um módulo de software
chamado resolver, que faz parte da própria aplicação, isto é, ele não faz parte do núcleo do
Sistema Operacional (já os protocolos TCP/IP são ligados ao núcleo).
IPv6 Básico

Os protocolos TCP/IP no núcleo não conhecem nada a respeito do DNS. Uma aplicação (ou
um serviço não transparente TCP/IP) precisa traduzir o endereço simbólico de seu compu-
tador hospedeiro para um endereço IP, antes de poder iniciar uma conexão de transporte
(TCP ou UDP), e é o resolver que faz essa tradução.

114
 O resolver se comunica como os servidores de nomes, geralmente por meio de conexões
UDP. No Unix, para efetuar a tradução, o resolver contata um ou mais servidores de nomes
na rede, conforme indicado no arquivo /etc/resolv.conf.

Suporte IPv6 do DNS

d A base de dados de um servidor DNS pode armazenar tanto registros IPv6 quanto IPv4. q
Saiba mais na Esses dados são independentes da versão de IP em que o servidor DNS opera:
RFC 3596: DNS
Extensions to Support 11 Um servidor com conexão apenas IPv4 pode responder a consultas AAAA ou A.
IP Version 6; RFC 3363:
Representing Internet 11 As informações obtidas na consulta IPv6 devem ser iguais às obtidas na consulta IPv4.
Protocol version
O suporte a IPv6 do DNS deve ser observado por dois aspectos. O primeiro é que um ser-
6 (IPv6) Addresses in
the Domain Name vidor DNS deve ser capaz de armazenar registros quad-A para endereços IPv6. O segundo
System (DNS), e RFC aspecto é se um servidor DNS é capaz de transportar consultas e respostas através de cone-
3364: Tradeoffs in
xões IPv6, isto é, a base de dados de um servidor DNS pode armazenar tanto registros IPv6
Domain Name System
(DNS) Support for quanto IPv4, independente da versão de IP em que esse servidor opera.
Internet Protocol
version 6 (IPv6). Com isso, um servidor com conexão apenas IPv4 pode responder tanto a consultas AAAA
quanto A. No entanto, as informações obtidas na consulta via IPv6 devem ser iguais às
obtidas na consulta IPv4.

Capítulo 7 - Protocolo DNS

115
 IPv6 Básico

116
 8
Segurança
objetivos

Analisar as novas ferramentas de segurança do IPv6 e apresentar uma comparação

entre as ameaças ao IPv4 e ao IPv6.

conceitos
Segurança no IPv4; Segurança no IPv6; Incidentes de segurança no IPv6; Ferramentas
de segurança no IPv6.

A questão da segurança
A questão da segurança foi pensada desde o início do projeto IPv6. Mecanismos de autenticação e
encriptação passaram a fazer parte do novo protocolo, disponibilizando para qualquer par de dis-
positivos de uma conexão fim-a-fim métodos para garantir a segurança dos dados que trafegam
pela rede. No entanto, inúmeros problemas ainda existem e novas falhas de segurança surgiram.

IPv4: q
11 Destinado principalmente a interligar redes de pesquisa acadêmicas, o projeto
original do IPv4 não apresentava nenhuma grande preocupação com a questão da
segurança das informações transmitidas. No entanto, o aumento da importância
da internet para a realização de transações entre empresas e consumidores, por
exemplo, fez com que um nível maior de segurança passasse a ser exigido, como
Criptografia identificação de usuários e criptografia de dados, tornando necessário anexar novos
Procedimento adotado mecanismos ao protocolo original, que garantissem tais serviços. Contudo, as solu-
para cifrar informações,
ções adotadas normalmente são específicas para cada aplicação.
transformada da sua
forma original para Esse fato é bastante claro hoje na internet. Há quem defenda que deveria haver uma nova
outra ilegível.
internet, projetada do zero (abordagem clean-slate) para resolver esse problema.

Clean-slate
Segurança no IPv6
q
Abordagem radical,
onde todos os nós
O IPv6 é mais seguro?
Capítulo 8 - Segurança

suportam somente IPv6.

11 Apresenta novos problemas:

22 Técnicas de transição.

22 Descoberta de vizinhança e autoconfiguração.

22 Modelo fim-a-fim.

22 Mobilidade IPv6.

22 Falta de melhores práticas, políticas, treinamento e ferramentas.

117
 Alguns aspectos de segurança foram abordados no projeto do IPv6, mas a implementação
desses aspectos ainda é imatura. Apesar de ter mais de dez anos, não há boa experiência de
uso. As melhores práticas ainda são adaptadas do IPv4, e isso nem sempre funciona bem.

O IPv6 é mais seguro? q

11 Ferramentas de segurança.

11 IPSec.

11 Secure Neighbor Discovery (SEND).

11 Estrutura dos endereços.

11 Cryptographically Generated Address (CGA).

11 Extensões de privacidade.

11 Unique Local Addresses (ULA).

No IPv6, a segurança foi uma preocupação desde o início: várias ferramentas de segurança
foram implementadas no protocolo.

Estratégia de implantação q
11 Sem planejamento. Exemplos:

22 Roteadores wireless.

33 Sistemas sem firewall.

33 Projetos de última hora ou demonstrações.

33 Projetos sem o envolvimento de especialistas em segurança

22 Ou:

33 Planejamento (Plan).

33 Implantação (Do).

33 Verificação (Check).

33 Ação (Act).

CICLO DE GERENCIAMENTO
(Ciclo para atingir metas) Mais informações na
RFC 4864 – Local
Network Protection
6. Padronizar 1. Localizar problemas for IPv6.
e treinar e estabelecer metas
no sucesso
A P 2. Estabelecer
5. Tomar ação planos de ação
corretiva
no insucesso
C D

Figura 8.1
4. Verificar o 3. Conduzir Ciclo de
atingimento a execução gerenciamento
da meta do plano PDCA.

Antes de entrar em detalhes sobre as ferramentas, vamos pensar um pouco sobre a estra-
IPv6 Básico

tégia de implantação do IPv6. Podemos pensar em vários exemplos históricos de implanta-

ções de tecnologias novas em que não houve uma preocupação com aspectos de segurança
desde o início, como quando surgiram os roteadores wireless. Podemos pensar, certamente,
em vários exemplos do dia a dia, de projetos de última hora, demonstrações para clientes,
que acabam tornando-se sistemas em produção e apresentando várias vulnerabilidades.
118
 w O ideal é que a implantação do IPv6 seja feita de uma forma planejada e organizada, com a
Para ler a apresentação preocupação com a segurança presente desde o início. Os dados seguintes foram retirados
completa, acesse “IPV6 da apresentação de Joe Klein, na Google IPv6 Implementors Conference 2009.
Security – Are you
ready? You better be!”.
Desenvolvimento de sistemas com IPv6 habilitado

Data Produtos Suporte ao IPv6 IPv6 habilitado

1996 OpenBSD/NetBSD/ FreeBSD Sim Sim

Linux Kernel 2.1.6 Sim Não

1997 AIX 4.2 Sim Não

2000 Windows 95/98/ME/NT 3.5/ Sim (pacotes adicionais) Não

NT 4.0

Windows 2000 Sim Não

Solaris 2.8 Sim Sim

2001 Cisco IOS (12.x e superior) Sim Não

2002 Juniper (5.1 e superior) Sim A maioria

IBM z/OS Sim Sim

Apple OS/10.3 Sim Sim

Windows XP Sim Não

Linux Kernel 2.4 Sim Não

AIX 6 Sim Sim

IBM AS/400 Sim Sim

2006 Roteadores Linksys (Minds- Sim Não

pring)

Telefones celulares (vários) Sim Sim

Solaris 2.10 Sim Sim

Linux Kernel 2.6 Sim Sim

2007 Apple Airport Extreme Sim Sim

BlackBerry (telefone celular) Sim Não

Windows Vista Sim Sim

HP-UX 11iv2 Sim Sim

Open VMS Sim Sim

Tabela 8.1 MAC OS/X Leopard Sim Sim

Sistemas
Capítulo 8 - Segurança

Operacionais e a 2009 Cloud Computing e sistemas Sim Sim

presença do IPv6. embarcados

É interessante notar quantos sistemas são capazes de executar o IPv6, e que muitos deles
vêm com o protocolo habilitado por padrão. A lista inclui Sistemas Operacionais, telefones
celulares, equipamentos de redes, entre outros.

119
 Ano Incidente

2001 Revisão de logs, após anúncio do Projeto Honeynet.

2002 Projeto Honeynet: Lance Spitzner: Solaris.

Snort: Martin Roesch: IPv6 adicionado, depois removido.

2003 Worm: W32. HLLW. Raleka: download de arquivos de um local pré-definido e conecta em um IRC server.

2005 Trojan: Troj/LegMir-AT: conecta em um IRC server.

CERT: Backdoors usando Teredo IPv6.
Mike Lynn: Blackhat: captura de pacotes IPv6.

2006 CAMSECWest: THC IPv6 Hacking Tools.

RP Murphy: DefCon: Backdoors IPv6.

2007 Rootkit: W32/Agent.EZM!tr.dldr: TCP HTTp SMTP.

James Hoagland: Blackhat: falha relatada no Teredo IPv6 do Vista.

2008 HOPE: vulnerabilidade em telefones móveis com IPv6.

Novembro: “atacantes estão tentando ou usando-o como mecanismo de
transporte para botnets. IPv6 tornou-se um problema do lado operacional.” Arbor Networks.

Incidentes de segurança envolvendo IPv6 vêm sendo reportados há tempos. Tabela 8.2
Vejamos um exemplo. Incidentes de
segurança no IPv6.

De: Lance Spitzner <lance_at_honeynet.org> 

Data: Terça-feira, 17 de dezembro de 2002 20:34:33 -0600 (CST)

Recentemente um dos Honeypot do Projeto Solaris de Honeynet foi comprometido. 

O que fez esse ataque de diferente foi que, após quebrar o sistema, os atacantes
habilitaram o tunelamento IPv6 no sistema, com as comunicações sendo encami-
nhadas para outro país. O ataque e as comunicações foram capturadas usando
Snort, entretanto os dados não puderam ser decodificados devido ao tunelamento
IPv6. Também, uma vez tunelado, isto poderia potencialmente desabilitar/contornar
as capacidades de alguns sistemas IDS.

Marty está abordando este assunto e adicionou suporte à decodificação de IPv6 ao

Snort. Não faz parte do atual Snort (2.0) ainda, está ainda no processo de teste.
Se você quiser testar esta nova capacidade, você pode encontrá-la online em
http://www.snort.org/~roesch/

Marty está à procura de feedback. A medida em que o uso de IPv6 se espalha, espe-
cialmente na Asia, você vai querer estar preparado para isso. Lembre-se que, mesmo
em ambientes IPv4 (como no nosso Honeynet Solaris) atacantes podem codificar
seus dados em IPv6 e então tunelá-los através de IPv4. Nós provavelmente veremos
mais deste tipo de comportamento.

Apenas um amistoso heads-up :) 

Lance Spitzner http://www.tracking-hackers.com

IPv6 Básico

120
 Malwares

Data Infecção Nome

2001 10/1/2001 DOS bot Ipv4.ipv6.tcp.connection

2003 9/26//2003 Worm W32/Raleka!worm

2004 7/6/2004 Worm W32/Sbdbot-JW

2005 2/18/2005 Worm W32/Sdbot-VJ

8/24/2005 Trojan Troj/LegMir-AT

9/5/2005 Trojan Troj/LegMir-AX

2006 4/28/2006 Trojan W32/Agent.ABU!tr.dldr

2007 1/2/2007 Trojan Cimuz.CS

4/10/2007 Trojan Cimuz.EL

5/4/2007 Trojan Cimuz.FH

11/5/2007 Worm W32/Nofupat

11/15/2007 Trojan Trojan.Astry

12/1/2007 Rootkit W32/Agent.EZM!tr.dldr

12/16/2007 Trojan W32/Agent.GBU!tr.dldr

12/29/2007 Worm W32/VB-DYF

Tabela 8.3
Malwares 2008 4/22/2008 Trojan Troj/PWS-ARA
que usam o IPv6
atacam sistemas
5/29/2008 Trojan Generic.dx!DAEE3B9
desse tipo.

Da mesma forma, malwares que fazem uso do IPv6 ou atacam sistemas IPv6 vêm sendo q
reportados pelo menos desde 2001.
Capítulo 8 - Segurança

121
 Vulnerabilidades IPv6 publicadas ao longo do tempo

70

60

50

40

30

20

10

0
2000 2001 2002 2003 2004 2005 2006 2007 2008
Figura 8.2
Vulnerabilidades
IPv6 (fonte:
Total Não corrigidas
Joe Klein).

O número de vulnerabilidades (encontradas) deve crescer, com o aumento do uso do IPv6. q

5% 4%
Overflow Execução de Código
5%
Divulgação
de Informações 2%
Obtenção de privilégio
22%
Outros

Figura 8.3
Impactos das
62% vulnerabilidades
DoS (fonte: Joe Klein).

A maior parte das vulnerabilidades torna os sistemas sujeitos a ataques DoS. q

4% 4%
Firewall / Teredo IPSec / IKE

6%
Teredo
11%
Aplicações

Figura 8.4
Núcleo dos
IPv6 Básico

75% problemas (fonte:

Firewall Joe Klein).

122
 A maior parte das vulnerabilidades publicadas afeta equipamentos de rede. q

IPv4 Pilha dupla IPv6

Nativo Nativo

Pilha dupla
+
Túneis
IPv4 IPv6
+ +
Túneis Túneis

Túneis
Encapsulado
e/ou encriptado

Figura 8.5
Áreas de ataque
(fonte: Joe Klein).

Durante a transição de IPv4 para IPv6, há o uso de ambas as tecnologias q

nativamente e de túneis. Observando a figura, vemos sete superfícies de ataque
possíveis, nesse contexto.

Camada de aplicação
Interface de usuário
Bibliotecas de programação
Camada de apresentação
Tratamento de erros
Problemas de codificação
Camada de sessão
Problemas de Logs
API's
Camada de transporte

Implementações impróprias
Camada de rede Incompatibilidade L2/L3, MTU, etc

Figura 8.6 Camada de enlace

Alvos nas sete
camadas
Camada física
(fonte: Joe Klein).

Apesar de o IP tratar da camada de rede, implicações nas outras camadas podem levar
Capítulo 8 - Segurança

também a vulnerabilidades ou problemas.

123
 Ferramentas de segurança no IPv6
11 O IPv6 oferece várias ferramentas tanto para defesa quanto para ataque. q
11 Defesa:

22 IPSec.

22 SEND.

22 Crypto-Generated Address.

22 Unique Local Addresses.

22 Privacy Addresses.

11 Ataque:

22 Túnel automático.

22 Neighbor Discovery e autoconfiguração.

22 Modelo fim a fim.

22 Novidade ou complexidade.

22 Falta de políticas, treinamentos e ferramentas.

Para aumentar a segurança no IPv6, é necessário envolver a equipe de segurança desde o

início, obter equipamentos certificados, investir em educação e treinamento, fazer upgrade
das ferramentas e processos de segurança, desenvolver práticas de programação adequadas
e seguras para IPv6, além de procurar auditorias ou equipes de teste que conheçam IPv6.

IPSec
11 Implementa criptografia e autenticação de pacotes na camada de rede. q
11 Fornece solução de segurança fim-a-fim.

22 Associações de segurança.

11 Garante a integridade, confidencialidade e autenticidade dos dados.

11 Desenvolvido como parte integrante do IPv6.

22 Suporte obrigatório.

11 Adaptado para funcionar com o IPv4.

22 Suporte opcional.

O IPSec foi desenvolvido para o IPv4 e pouca coisa muda com o IPv6. Contudo, o suporte
passa a ser mandatório, e não há a NAT para atrapalhar o funcionamento.

IPSec – Modos de operação

O IPSec pode operar em dois modos: q
11 Modo de transporte.

11 Modo túnel (VPN de Camada 3).

Cabeçalho IP original Cabeçalho IPsec TCP Dados

Figura 8.7
IPv6 Básico

IPSec no modo
Pode ser encriptado transporte.

124
 Novo cab. IP Cabeçalho IPsec Cab. IP original TCP Dados
Figura 8.8
IPSec no
modo túnel. Pode ser encriptado

O IPSec pode ser usado de duas formas distintas, em modo de transporte ou em modo de
túnel. No modo de transporte, ambos os extremos da comunicação necessitam de suporte
IPSec, entre os quais se realiza a comunicação segura.

VPN ou Virtual Ao contrário do modo de transporte, no modo de túnel (também conhecido por VPN) o IPSec
Private Network é implementado em dispositivos próprios (exemplo: concentradores VPN), entre os quais será
Rede privada construída
efetuada a comunicação IPSec encapsulando todos os pacotes IP dos respectivos extremos.
sobre uma rede pública,
normalmente a internet,
É de salientar que, no caso de uma comunicação em modo de transporte, o cabeçalho do
onde os dados trafegam
criptografados. pacote IP original é mantido. No modo de túnel, este é codificado, e é criado um novo cabe-
çalho, possibilitando a ligação entre o dispositivo emissor e o dispositivo receptor (do túnel).

11 Transporte: protege apenas os protocolos das camadas superiores, pois o cabeçalho de

segurança aparece imediatamente após o cabeçalho IP e antes dos cabeçalhos dos proto-
colos das camadas superiores;

11 Túnel: protege todo o pacote IP, encapsulando-o dentro de outro pacote IP, deixando
visível apenas o cabeçalho IP externo.

IPSec – Framework de segurança

Usa recursos independentes para realizar suas funções. q
11 Authentication Header (AH).

22 Integridade de todo o pacote.

22 Autenticação da origem.

22 Proteção contra o reenvio do pacote.

11 Encapsulating Security Payload (ESP).

33 Confidencialidade.

33 Integridade do interior do pacote.

33 Autenticação da origem.

33 Proteção contra o reenvio do pacote.

33 Internet Key Exchange (IKE).

11 Gera e gerencia chaves de segurança.

IPSec – AH
Authentication Header (AH): q
11 É adicionado após os cabeçalhos Hop-by-Hop, Routing e Fragmentation (se houver).
Capítulo 8 - Segurança

11 Pode ser usado em ambos os modos de operação.

125
 Próximo cabeçalho Tam. cabeçalho de extensão Reservado

Índice de parâmetros de segurança

Número de sequência Figura 8.9

Estrutura do
Autenticação dos dados cabeçalho de
extensão AH.

IPSec – ESP
11 Encapsulating Security Payload (ESP). q
11 Responsável pela criptografia dos dados (opcional).

11 Pode ser utilizado em ambos os modos de operação.

11 Pode ser combinado com o AH.

Índice de parâmetros de segurança

Número de sequência

Dados + complemento

Tamanho do complemento Próximo cabeçalho Figura 8.10

Estrutura do
Autenticação dos dados cabeçalho de
extensão ESP.

IPSec – Gerenciamento de chaves

Manual: q
11 Chaves configuradas em cada sistema.

Automática:

11 Internet Key Exchange (IKE).

22 Baseado em três protocolos:

33 ISAKMP.

33 OAKLEY.

33 SKEME.

22 Funciona em duas fases.

22 Possui duas versões.

33 IKEv1.

33 IKEv2. Mais informações na

RFC 4301 – Security
Architecture for the
O gerenciamento de chaves é uma das dificuldades operacionais para implantação do IPSec Internet Protocol.
no IPv4, e continua tendo o mesmo nível de complexidade no IPv6.
IPv6 Básico

126
 SEcure Neighbor Discovery – SEND
IPv4 – ataques ao ARP e DHCP (Spoofing). q
11 Não há mecanismos de proteção.

IPv6 – utiliza o protocolo de Descoberta de Vizinhança.

11 Mensagens ICMPv6: não depende da camada de enlace.

11 Possui as mesmas vulnerabilidades que o ARP e o DHCP.

11 Há dificuldades na implementação de IPSec.

11 Problemas na geração automática de chaves.

Cadeia de certificados:

11 Utilizados para certificar a autoridade dos roteadores.

Usar endereços CGA.

11 Gerados criptograficamente.

Nova opção do protocolo de Descoberta de Vizinhança.

11 RSA signature – protege as mensagens relativas ao Neighbor Discovery e

d ao Router Discovery.

Mais informações na Duas novas opções do protocolo de Descoberta de Vizinhança.

RFC 3756 – IPv6 11 Timestamp e nonce – previne ataques de reenvio de mensagens.
Neighbor Discovery
(ND) Trust Models and
Threats e na RFC 3971
– SEcure Neighbor Estrutura dos endereços
Discovery (SEND).
11 Os 128 bits de espaço para endereçamento podem dificultar alguns tipos de ataques. q
11 Novas formas de gerar IID.

11 A filtragem dos endereços também muda.

22 Endereços bogons.

11 Novos tipos de ataques.

11 Varredura de endereços (scanning).

11 Tornou-se mais complexo, mas não impossível.

11 Com uma máscara padrão /64, são possíveis 264 endereços por sub-rede.

11 Percorrendo 1 milhão de endereços por segundo, seria preciso mais de 500.000 anos
para percorrer toda a sub-rede.

22 NMAP só tem suporte para escanear um único host de cada vez.

11 Worms que utilizam essa técnica para infectar outros dispositivos também terão
dificuldades para continuar se propagando.

11 Varredura de endereços (scanning).

22 Devem surgir novas técnicas:

Capítulo 8 - Segurança

33 Explorar endereços de servidores públicos divulgados no DNS.

33 Procura por endereços fáceis de memorizar usados por administradores de redes.

33 ::10, ::20, ::DAD0, ::CAFE

33 Último byte do endereço IPv4.

33 Explorar endereços atribuídos automaticamente com base no MAC, fixando a

parte do número correspondente ao fabricante da placa de rede.

127
 Endereços – CGA
11 Endereços IPv6 cujas IIDs são geradas criptograficamente utilizando uma função hash q
de chaves públicas.

22 Prefixo /64 da sub-rede.

22 Chave pública do proprietário do endereço. d

Mais informações na
22 Parâmetro de segurança. RFC 3972 – Cryptogra-
phically Generated
11 Utiliza certificados X.509. Addresses (CGA).
11 Utiliza a função hash SHA-1.

Endereços: extensões de privacidade

d
q
Mais informações na
11 Extensão do mecanismo de autoconfiguração stateless. RFC 4864 – Local
Network Protection
11 Gera endereços temporários e/ou randômicos. for IPv6 e na RFC 4941
– Privacy Extensions
11 Dificulta o rastreamento de dispositivos ou usuários. for Stateless Address
Autoconfiguration
11 Os endereços mudam de acordo com a política local.
in IPv6.
11 Para cada endereço gerado, deve-se executar a detecção de endereços duplicados.

Resumindo segurança no IPv6

11 A segurança em redes IPv6 não difere substancialmente da segurança em redes IPv4. q
11 Muitas formas de ataque continuam idênticas e a forma de evitá-las também.

22 Sniffing.

22 Ataques à camada de aplicação.

33 Man-in-the-Middle.

33 Vírus.

33 DoS.

11 IPSec não é a solução de todos os problemas.

Muitas implementações da pilha IPv6 ainda não suportam IPSec integralmente. Assim, ele
vem sendo usado sem o suporte criptográfico. Mesmo quando este é usado, várias questões
de segurança em redes IP ainda estão presentes. Mas o IPv6 pode potencialmente melhorar
a segurança na internet.

11 DoS: não existem endereços broadcast em IPv6.

22 Evita ataques através do envio de pacotes ICMP para o endereço de broadcast.

11 As especificações do IPv6 proíbem a geração de pacotes ICMPv6 em resposta a mensagens

enviadas para endereços globais multicast (com a exceção da mensagem packet too big).

22 Muitos Sistemas Operacionais seguem a especificação.

22 Ainda há alguma incerteza sobre o perigo que pode ser criado por pacotes ICMPv6
com origem em endereços multicast globais.
IPv6 Básico

128
 Recomendações
11 Implementar extensões de privacidade apenas em comunicações externas. q
22 Cuidado com o uso indiscriminado, que pode dificultar auditorias internas.

11 Endereços de uso interno devem ser filtrados nos roteadores de borda.

22 Endereços multicast, como:

33 FF02::1(all-nodes on link).

33 FF05::2 (all-routers on link).

33 FF05::5 (all DHCPv6 servers) podem se tornar novos vetores de ataque.

11 Filtrar tráfego ingresso de pacotes com endereços de origem multicast.

11 Não usar endereços óbvios.

11 Filtrar serviços desnecessários no firewall.

11 Filtrar mensagens ICMPv6 não essenciais.

11 Filtrar endereços bogon.

22 Filtragem no IPv6 é diferente da feita no IPv4.

33 No IPv4, as faixas não alocadas são bloqueadas (há poucas).

33 No IPv6 é o inverso. É mais fácil liberar apenas as faixas alocadas.

11 Bloquear fragmentos de pacotes IPv6 com destino a equipamentos de rede.

11 Descartar pacotes com tamanho menor do que 1280 bytes (exceto o último).

11 Os mecanismos de segurança do BGP e do IS-IS não mudam.

d 11 Com OSPFv3 e RIPng deve-se usar IPSec.

Mais informações na 11 Limite o número de saltos para proteger dispositivos de rede.
RFC 3704 – Ingress
Filtering for Multihomed 11 Utilize IPSec sempre que necessário.
Networks e na RFC 4890
– Recommendations for
Filtering ICMPv6
Messages in Firewalls.

Capítulo 8 - Segurança

129
 IPv6 Básico

130
 9
Coexistência e transição – Parte 1
objetivos

Apresentar as técnicas de transição do IPv4 para o IPv6.

conceitos
Cenários de coexistência de IPv6 e IPv4; Classificação das técnicas de transição;
Descrição da Pilha Dupla e Técnicas de Tunelamento; Túneis GRE; Tunnel Broker;
Dual Stack Lite (DS-Lite); IVI, dIVI e dIVI-pd; NAT64 e DNS64; 464XLAT.

Coexistência e transição
Para que a transição entre os protocolos IPv4 e IPv6 ocorra de forma gradativa e sem mais
impactos no funcionamento das redes, é necessário que exista um período de coexistência
entre os dois protocolos internet.

Este Capítulo tem como objetivo apresentar as técnicas de transição do IPv4 para o IPv6,
mostrando alguns aspectos práticos e exemplos.

11 Toda a estrutura da internet está baseada no IPv4. q

11 A troca imediata de protocolo é inviável devido ao tamanho e à proporção que essa
rede possui.

11 A adoção do IPv6 deve ser realizada de forma gradual.

11 Haverá inicialmente um período de transição e coexistência entre os dois protocolos.

11 Redes IPv4 precisarão comunicar-se com redes IPv6 e vice-versa.

11 Para facilitar esse processo, foram desenvolvidas técnicas para manter a compatibili-
Capítulo 9 - Coexistência e transição – Parte 1

dade de toda a base das redes instaladas sobre IPv4 com o protocolo IPv6.

Com o intuito de facilitar o processo de transição entre as duas versões do protocolo

internet, algumas técnicas foram desenvolvidas para que toda a base das redes instaladas
sobre IPv4 mantenha-se compatível com o protocolo IPv6. Nesse primeiro momento de
coexistência entre os dois protocolos, essa compatibilidade é essencial para o sucesso da
transição para o IPv6.

Como o período de coexistência entre os dois protocolos pode durar indefinidamente, a

implementação de métodos que possibilitem a interoperabilidade entre o IPv4 e o IPv6
poderá garantir a migração segura para o novo protocolo, através da realização de testes
que permitam conhecer as opções oferecidas por esses mecanismos, além de evitar, no
futuro, o surgimento de ilhas, redes isoladas de comunicação.

131
 Cada uma dessas técnicas apresenta uma característica específica, podendo ser utilizada
individualmente ou em conjunto com outras técnicas, de modo a atender as necessidades
de cada situação, seja a migração para o IPv6 feita passo a passo, iniciando por um único
host ou sub-rede, ou até de toda uma rede corporativa.

A importância desse tópico vem do fato de o IPv4 e o IPv6 não serem diretamente compatí-
veis entre si. O IPv6 não foi projetado para ser uma extensão, ou complemento, do IPv4, mas
sim um substituto que resolve o problema do esgotamento de endereços.

Embora não interoperem, ambos os protocolos podem funcionar simultaneamente q

nos mesmos equipamentos e, com base nisso, a transição foi pensada para ser feita de
forma gradual. No projeto inicial do IPv6, uma vez que o protocolo estivesse pronto, sua
implantação começaria a ser feita gradualmente na internet, de forma que funcionasse
simultaneamente ao IPv4. A isso chamamos de pilha dupla ou dual stack. Quando o IPv6
estivesse implantado em todos os dispositivos, o IPv4 deixaria de ser realmente útil e
poderia ser abandonado paulatinamente.

No período de implantação do IPv6 haveria necessidade de técnicas auxiliares de tran-

sição, inicialmente para interconectar ilhas IPv6 em uma internet majoritariamente IPv4
e, depois de algum tempo, para fazer o contrário.

A transição feita dessa forma seria muito simples de ser executada tecnicamente. Contudo,
por diversas razões, não foi o que aconteceu. Atualmente o IPv6 ainda não está sendo
amplamente utilizado na internet e o esgotamento do IPv4 já se tornou uma realidade. Hoje
existe a necessidade de se implantar o IPv6 numa internet sempre crescente, onde os novos
usuários ainda precisam de conectividade IPv4, mas não há mais endereços IPv4 livres para
atendê-los. Assim, novas técnicas auxiliares foram e continuam sendo desenvolvidas para
essa nova realidade.

Esse Capítulo está organizado da seguinte forma: inicialmente apresentam-se os cenários

possíveis para a coexistência de redes IPv6 e IPv4. Essa apresentação é seguida por uma
introdução às técnicas de coexistência e transição, classificando-as segundo suas funciona-
lidades. Após isso, abordam-se algumas delas em detalhes, incluindo as mais amplamente
utilizadas e aquelas cujo desenvolvimento recente parece promissor. Encaixam-se aí a
própria pilha dupla, os túneis ponto a ponto 6over4 e GRE, os Tunnel Brokers, o DSLite, o
NAT64, o IVI, o 464XLAT, o 6PE, o 6VPE, o 6rd e o 4rd. São apresentadas também algumas
técnicas já em desuso, como 6to4, Teredo e ISATAP, mas com as quais ainda se convive no
ambiente da internet ou outras redes, principalmente por serem usadas de forma automá-
tica por alguns Sistemas Operacionais e equipamentos, como Customer Premises Equip-
ment (CPEs). Por fim, são apresentados alguns mecanismos para estender a vida do IPv4,
que não são exatamente técnicas de transição, mas podem ser utilizados como tais, em
conjunto com a implantação do IPv6, como NAT444 e A+P.

O estudo das técnicas de transição é importante mesmo para aqueles que não pretendem
fazer uso ou para os que administram redes em que a implantação do IPv6 ainda não foi
iniciada. Algumas dessas técnicas, como afirmado anteriormente, são utilizadas de forma
automática por computadores e equipamentos de rede, permitindo o uso do IPv6 por
equipamentos numa rede IPv4 e eventualmente contornando mecanismos de segurança e
controle. É o caso, por exemplo, de redes com computadores Windows Vista ou Windows 7.
IPv6 Básico

132
 Cenários de coexistência de IPv6 e IPv4
Na transição do IPv4 para o IPv6 é necessária a coexistência e interoperabilidade entre
ambos os protocolos e, para isso, é necessário o uso de tecnologias auxiliares, conhecidas
como técnicas de transição. A necessidade de coexistência ocorre em diferentes cenários,
cada qual com características e demandas singulares e uma técnica de transição, de forma
isolada, normalmente não é capaz de atender de forma simultânea a todos. Assim, o pri-
meiro passo para entender as técnicas de transição é entender os cenários existentes, as
necessidades apresentadas e as dificuldades envolvidas.

l A enumeração dos cenários a seguir é uma generalização e extensão da enumeração feita

Esse cenário possui
complexidade simples na RFC 6144. Contudo, enquanto essa RFC trata apenas de cenários utilizados com soluções
e é de fácil solução, de tradução, estes são aqui usados para descrever também situações onde soluções de
sendo suportado tanto
tunelamento podem ser aplicadas.
por técnicas stateless
quanto stateful, que
Cenário 1: Rede IPv6 para internet IPv4
q
serão explicadas mais
adiante.
Devido à falta de endereços IPv4 ou outras limitações técnicas ou econômicas, a rede
cliente possui somente IPv6, mas necessita conectar-se à internet IPv4.

Rede Internet
Figura 9.1 IPv6 IPv4
Cenário 1:
necessidade de
conexão à rede
Sentido de início da comunicação
IPv4.

Greenfield networks Esse cenário também pode ocorrer em greenfield networks. Algumas empresas têm se
Expressão para se decidido por criar redes somente IPv6 nesse caso, por motivos de simplicidade, facilidade de
referir a projetos gerência e outros, mas necessitam ainda acessar servidores de clientes e fornecedores que
totalmente novos, aos
quais não se aplicam as estão na internet IPv4.
restrições normalmente
encontradas em tecno- Cenário 2: internet IPv4 para Rede IPv6
logias já em uso.
Mesma rede existente no cenário 1, mas que necessita receber conexões da internet q
IPv4, para o caso, por exemplo, de haver servidores IPv6 na rede, que devem atender
solicitações de clientes na internet IPv4.

Capítulo 9 - Coexistência e transição – Parte 1

Internet Rede
IPv4 IPv6
Figura 9.2
Cenário 2:
necessidade de
receber conexões Sentido de início da comunicação
da internet IPv4.

A inversão no sentido de origem da comunicação torna esse cenário muito mais complexo
que o cenário 1, pois normalmente não se consegue fazer um mapeamento 1:1 de todos
endereços IPv6 existentes na rede para endereços IPv4 válidos. Esse caso normalmente
exige soluções stateful, mas pode ser também atendido por soluções stateless, desde que
suportem conexões iniciadas via IPv4 para um subconjunto dos endereços IPv6 na rede.

133
 Cenário 3: internet IPv6 para Rede IPv4
Esse é um típico cenário onde uma rede legada, na qual não é possível fazer uma atuali- q
zação para IPv6, necessita continuar em uso e responder requisições da internet IPv6.

Internet Rede
IPv6 IPv4 Figura 9.3
Cenário 3:
impossibilidade de
fazer atualização
Sentido de início da comunicação para IPv6.

Para esse cenário só cabem soluções stateful, já que a rede IPv4 deve comunicar-se com
toda a internet IPv6.

Cenário 4: Rede IPv4 para internet IPv6

Esse cenário só deve ser encontrado em estágios bem avançados da implementação do q
IPv6, quando a maior parte dos serviços na internet já tiverem migrado para o novo pro-
tocolo. Técnicas de tradução na própria rede provavelmente não conseguirão solucionar
esse problema.

Rede Internet Figura 9.4

IPv4 IPv6 Cenário 4:
comum em estágios
bem avançados
da implementação
Sentido de início da comunicação do IPv6.

Cenário 5: Rede IPv6 para Rede IPv4

Ambas as redes desse cenário estão na mesma organização, e os endereços IPv6 e q
IPv4 podem ser públicos e válidos na internet ou privados e válidos somente dentro da
organização. Esse cenário é bastante similar ao cenário 1, e os mesmos tipos de técnicas
aplicadas a ele podem ser aplicadas nesse caso.

Rede Rede
IPv6 IPv4
Figura 9.5
Cenário 5: similar
Sentido de início da comunicação ao cenário 1.

Cenário 6: Rede IPv4 para Rede IPv6

De forma análoga ao cenário anterior, essa é uma situação semelhante ao cenário 2, q
mas com ambas as redes dentro da mesma organização. Os endereços IPv6 e IPv4 podem
IPv6 Básico

ser públicos e válidos na internet ou privados e válidos somente dentro da organização.

Os mesmos tipos de técnicas aplicadas ao cenário 2 podem ser aplicadas nesse caso.

134
 Rede Rede
IPv4 IPv6
Figura 9.6
Cenário 6:
semelhante ao
cenário 2. Sentido de início da comunicação

Cenário 7: internet IPv6 para internet IPv4

Esse cenário, onde qualquer dispositivo na internet IPv6 pode iniciar uma conexão com q
um dispositivo na internet IPv4, necessita da técnica de transição perfeita, que também
seria capaz de resolver todos os cenários anteriores, mas infelizmente ela não existe. A
grande diferença na quantidade de endereços torna, até este momento, uma solução
para esse cenário tecnicamente improvável.

Figura 9.7
Cenário 7: qualquer Internet Internet
dispositivo na IPv6 IPv4
internet IPv6 pode
iniciar uma conexão
com um dispositivo
Sentido de início da comunicação
na internet IPv4.

Cenário 8: internet IPv4 para internet IPv6

Similar ao cenário 7 e com mesma dificuldade técnica de implementação. q

Internet Internet
IPv4 IPv6
Figura 9.8
Cenário 8: similar
ao cenário 7. Sentido de início da comunicação

Cenário 9: Rede IPv6 para Rede IPv6 bidirecional via internet IPv4
Esse cenário apresenta o caso em que a comunicação entre duas redes com IPv6 neces- q
sita ser feita através da internet IPv4 ou de Rede IPv4. A comunicação pode ser iniciada
Figura 9.9 por ambas as Redes IPv6.
Capítulo 9 - Coexistência e transição – Parte 1

Cenário 9:
comunicação entre
duas redes com
IPv6 precisa ser
feita por meio da Rede Internet Rede
internet IPv4 ou de IPv6 IPv4 IPv6
Rede IPv4.

Cenário 10: Rede IPv4 para Rede IPv4 bidirecional via internet IPv6
Esse cenário apresenta o caso em que a comunicação entre duas redes com IPv4 neces- q
sita ser transmitida através da internet IPv6 ou de Rede IPv6. A comunicação pode ser
iniciada por ambas as Redes IPv4.

135
 Figura 9.10
Cenário 10:
comunicação
Rede Internet Rede entre duas redes
IPv4 IPv6 IPv4 com IPv4 precisa
ser transmitida
por meio da
internet IPv6 ou de
Classificação das técnicas de transição Rede IPv6.

Como já foi visto, desde 1983 a estrutura da internet é baseada no IPv4. Uma troca completa
e imediata do protocolo seria inviável devido ao tamanho e à proporção dessa rede. Por
isso, o IPv6 foi projetado para ser implantado gradualmente.

O período de transição e de coexistência dos dois protocolos exigiu o desenvolvimento de

técnicas auxiliares. O primeiro problema que elas procuravam resolver era como conectar
l
redes IPv6 a outras redes IPv6 por meio de equipamentos ou de uma internet que só No início da explicação
suportasse IPv4. Surgiram então diversos tipos de túneis IPv6 sobre IPv4 para atender tal de cada técnica de
transição, no decorrer
necessidade, usando diferentes técnicas, estabelecidos manualmente ou automaticamente. deste Capítulo, haverá
Foram criadas também técnicas para permitir que redes IPv6 e IPv4 interoperassem por um quadro informativo
para identificar quais
meio da tradução dos pacotes.
desses cenários são
suportados em cada
Mais recentemente, o problema principal a ser resolvido pelas técnicas de transição passou
uma das técnicas.
a ser a implantação do IPv6 num ambiente em que o IPv4 não está mais disponível, mas
ainda é necessário para os novos usuários da internet. Foram e continuam sendo desenvol-
vidos então diversos tipos de túneis IPv4 sobre IPv6 para, aliados a técnicas de tradução,
solucionar esse problema.

Pode-se, então, classificar as técnicas de transição segundo sua funcionalidade, em: q

11 Pilha dupla: consiste na convivência do IPv4 e do IPv6 nos mesmos equipamentos,
de forma nativa, simultaneamente. Essa é a técnica padrão escolhida para a transição
para IPv6 na internet e deve ser usada sempre que possível;

11 Túneis: permitem que diferentes redes IPv4 comuniquem-se através de uma rede
IPv6 ou vice-versa;

11 Tradução: faz com que equipamentos usando IPv6 comuniquem-se com outros que
usam IPv4, por meio da conversão dos pacotes.

Deve-se notar que tanto os túneis quanto as técnicas de tradução podem ser stateful ou
stateless. Técnicas stateful são aquelas em que é necessário manter tabelas de estado com
informações sobre os endereços ou pacotes para processá-los. Nas técnicas stateless não é
necessário guardar informações; cada pacote é tratado de forma independente. De forma
geral, técnicas stateful são mais caras: gastam mais CPU e memória, por isso não escalam
bem. Sempre que possível deve-se dar preferência a técnicas stateless.

Há casos em que é necessária a comunicação entre IPv4 e IPv6 para apenas um ou poucos
tipos de aplicações. Ou ainda: quando é usada uma técnica de tradução e ela funciona para
quase todas as aplicações, mas falha para algumas poucas, nomeadamente aquelas que car-
regam endereços IP literais no protocolo, na camada de aplicação. Para esses casos podem
ser usados gateways específicos, na camada de aplicação (são chamados de Application
Level Gateways ou ALGs).
IPv6 Básico

Uma grande dificuldade no processo de implantação do IPv6 é o desenvolvimento de uma

variedade enorme de técnicas de transição, o que dificulta a escolha do que efetivamente
usar. A figura 9.11 ilustra essa variedade, nomeando diversos tipos de técnicas para túneis

136
 hoje padronizadas ou em discussão na IETF, e organizando-as segundo sua funcionalidade e
método de funcionamento. Nem todas serão abordadas neste Capítulo.

De forma geral, os critérios que devem ser utilizados na escolha da técnica a ser q
utilizada são:

11 Prefira técnicas que impliquem na utilização de IPv6 nativo pelos usuários finais, de
forma que túneis IPv4 dentro de IPv6 devem ser preferidos em detrimento de túneis
IPv6 sobre IPv4;

11 Escolha técnicas stateless em detrimento de técnicas stateful;

11 Evite técnicas para prolongar o uso do protocolo IPv4, sem a adoção concomitante
do IPv6;

11 Confira a adequação da técnica à topologia da rede onde será aplicada;

11 Analise a maturidade da técnica e as opções de implantação. Por exemplo, suporte à

técnica nos equipamentos de rede e em softwares.

IPv4 sobre ou para IPv6

A+P
DS-Lite
DS-Lite
com A+P
464XLAT 4rd
Stateless
4over6 dIVI
LISP dIVI-pd
L2TP GRE
IVI
Stateful Stateless
GRE
L2TP
6to4
LISP
Tunnel Broker Tunnel Broker
6PE 6rd
6VPE 6over4

ISATAP
Tunelamento
BGP Teredo
Figura 9.11 6a44
Classificação
das técnicas de IPv6 sobre ou para IPv4
transição.

Como uma terceira possibilidade de classificação, pode-se dividir as técnicas conforme q Capítulo 9 - Coexistência e transição – Parte 1

seus casos de uso:

11 Fornecer IPv6 e IPv4 para todos os dispositivos: Pilha Dupla;

11 Oferecer conectividade IPv6 nativa em conjunto com conectividade IPv4 com comparti-
lhamento e preservação de endereços: DSLite, DSLite com A+P, 4rd, NAT64, IVI e 464XLAT;

11 Transportar IPv6 em uma rede MPLS IPv4: 6PE e 6VPE;

11 Obter conectividade IPv6, quando o provedor internet não a oferecer: tunnel broker e
túneis estáticos 6over4 ou GRE;

11 Oferecer conectividade IPv6 para os usuários sobre uma rede de transporte IPv4: 6rd
(normalmente usado em provedores) e ISATAP (para redes internas);

11 Mecanismos para compartilhar endereços IPv4, estendendo sua vida: A+P e NAT444.

137
 Pilha Dupla: IPv6 e IPv4 em todos os dispositivos
11 Os nós tornam-se capazes de enviar e receber pacotes, tanto para o IPv4 quanto q
para o IPv6.

11 Um nó IPv6/IPv4, ao se comunicar com um nó IPv6, se comporta como um nó IPv6, e

na comunicação com um nó IPv4, se comporta como nó IPv4.

11 O nó precisa de pelo menos um endereço para cada pilha.

11 Utiliza mecanismos IPv4, como DHCP, para adquirir endereços IPv4, e mecanismos do
IPv6 para endereços IPv6.

Na atual fase de implantação do IPv6, não é aconselhável ter nós com suporte apenas a
essa versão do protocolo IP, uma vez que muitos serviços e dispositivos na internet ainda
trabalham somente com IPv4. Como citado anteriormente, manter o IPv4 já existente fun-
cionando de forma estável e implantar o IPv6 nativamente, para que coexistam nos mesmos
equipamentos, é a forma básica escolhida para a transição na internet. Essa técnica é conhe-
cida como Pilha Dupla (Dual Stack ou DS) e deve ser usada sempre que possível.

A utilização desse método permite que dispositivos e roteadores estejam equipados com
pilhas para ambos os protocolos, tendo a capacidade de enviar e receber os dois tipos de
pacotes, IPv4 e IPv6. Com isso, um nó Pilha Dupla, ou nó IPv6/IPv4, se comportará como um
nó IPv6 na comunicação com outro nó IPv6 e se comportará como um nó IPv4 na comuni-
cação com outro nó IPv4.
No futuro, caso o IPv4
Cada nó IPv6/IPv4 é configurado com ambos endereços, utilizando mecanismos IPv4 não seja mais usado,
(exemplo: DHCP) para adquirir seu endereço IPv4 e mecanismos IPv6 (por exemplo: configu- basta simplesmente
desabilitar a pilha IPv4
ração manual, autoconfiguração stateless e/ou DHCPv6) para adquirir seu endereço IPv6.
em cada nó.
Esse método de transição permite uma implantação gradual, com a configuração de
pequenas seções do ambiente de rede de cada vez. O funcionamento da Pilha Dupla está
ilustrado na figura 9.12.

APLICAÇÃO

TCP/UDP (Transporte)

IPv6 IPv4

Enlace

IPv4 Figura 9.12

IPv6 IPv6 encapsulado
Funcionamento da
em IPv4
Pilha Dupla.
IPv6 Básico

138
 11 Uma rede Pilha Dupla é uma infraestrutura capaz de encaminhar ambos os q
tipos de pacotes.

11 Exige a análise de alguns aspectos:

22 Configuração dos servidores de DNS.

22 Configuração dos protocolos de roteamento.

22 Configuração dos firewalls.

22 Mudanças no gerenciamento das redes.

Alguns aspectos referentes à infraestrutura da rede devem ser considerados ao se imple-

mentar a técnica de Pilha Dupla: a estruturação do serviço de DNS e a configuração dos
protocolos de roteamento e de firewalls.

Em relação ao DNS, é preciso configurar os novos endereços IPv6, usando registros do tipo
AAAA (quadA), que armazenam seus endereços. Responder os endereços IPv6 (registros
AAAA) quando disponíveis para um determinado nome de domínio é o comportamento
padrão do servidor DNS, mesmo que este opere apenas com IPv4. O protocolo por meio do

d
qual é feita a consulta não interfere na resposta. Ao receber endereços IPv6 e IPv4 como
resposta a uma consulta no DNS, a aplicação decide qual protocolo usar. Normalmente a
Para mais detalhes preferência é pelo protocolo IPv6 e, em caso de falha, tenta-se o IPv4. Mais recentemente
sobre o suporte do têm sido experimentadas técnicas que implicam em tentativas simultâneas de conexão IPv6
DNS ao IPv6, consulte a
RFC 3596. e IPv4 e optam pela que for mais rápida (draft-ietf-v6ops-happy-eyeballs-07).

Em uma rede com Pilha Dupla, a configuração do roteamento IPv6 normalmente é inde-
pendente da configuração do roteamento IPv4. Isso implica no fato de que, se antes de
implementar o IPv6 a rede utilizava apenas o protocolo de roteamento interno OSPFv2 (com
suporte apenas ao IPv4), será necessário migrar para um protocolo de roteamento que
suporte tanto IPv6 quanto IPv4 (como IS-IS por exemplo) ou forçar a execução do OSPFv3
paralelamente ao OSPFv2.

A forma como é feita a filtragem dos pacotes que trafegam na rede pode depender da
plataforma usada. Em um ambiente Linux, por exemplo, os filtros de pacotes são total-
mente independentes uns dos outros, de modo que o iptables filtra apenas pacotes IPv4 e o
ip6tables apenas IPv6, não compartilhando nenhuma configuração. No FreeBSD, as regras
são aplicadas a ambos os protocolos no mesmo arquivo de configuração. Entretanto, a regra
pode ser aplicada simultaneamente aos dois protocolos ou a somente um. Para aplicar a
somente um deles, basta utilizar inet ou inet6, dependendo do protocolo ao qual as regras
devem ser aplicadas. De uma forma ou de outra, novas regras terão de ser configuradas no
firewall ao implantar-se o IPv6.
Capítulo 9 - Coexistência e transição – Parte 1

É importante reforçar que configurações independentes para IPv4 e IPv6 são necessárias
para diversos aspectos da rede, entre eles:

11 Informações nos servidores DNS autoritativos;

11 Protocolos de roteamento;

11 Firewalls;

11 Gerenciamento das redes.

Utilizar Pilha Dupla pode não ser possível em todas as ocasiões. Por exemplo, quando não
há mais IPv4 disponíveis e o provedor precisa atender a usuários novos com IPv6 e IPv4. Para
redes corporativas que já utilizam NAT isso não é um impedimento: o IPv6 nativo pode ser
usado em conjunto com o IPv4 compartilhado. Outra situação que dificulta a implantação

139
 do IPv6 usando Pilha Dupla é a existência de equipamentos que não o suportam e que
não podem ser facilmente substituídos. Para contornar essas situações existem diversas
técnicas disponíveis, algumas das quais serão abordadas mais adiante.

Túneis 6over4 (IPv6-over-IPv4)

A tabela a seguir ilustra a aplicação desta técnica nos diversos cenários descritos.

Cenário 1 2 3 4 5 6 7 8 9 10

Suporta Não Não Não Não Não Não Não Não Sim Não

Tabela 9.1
Aplicação nos
Técnicas de tunelamento cenários.

11 Também chamado de encapsulamento. q

11 O conteúdo do pacote IPv6 é encapsulado em um pacote IPv4.

11 Podem ser classificadas nos seguintes modos:

22 Roteador-a-Roteador.

22 Host-a-Roteador.

22 Roteador-a-Host.

22 Host-a-Host.

A figura 9.13 ilustra esse conceito.

Host IPv6

Rede IPv6

Roteador
IPv6/IPv4

Rede IPv4

Roteador Pacote IPv6 encapsulado em IPv4

IPV6/IPv4

Rede IPv6
Figura 9.13
Tunelamento
de pacote IPv6
Host IPv6 no IPv4.
IPv6 Básico

A técnica de criação de túneis, o tunelamento, permite transmitir pacotes IPv6 através da

infraestrutura IPv4 existente, sem a necessidade de realizar qualquer mudança nos meca-
nismos de roteamento, encapsulando o conteúdo do pacote IPv6 em um pacote IPv4.

140
 l Quando a utilização de Pilha Dupla não é possível, umas das alternativas a ser considerada é
Também é possível, de a utilização de túneis. As técnicas de tunelamento fazem o encapsulamento de pacotes IPv6
forma análoga, em pacotes IPv4. Esse encapsulamento é conhecido como 6in4 ou IPv6inIPv4 (RFC 4213), e
encapsular pacotes IPv4
em pacotes IPv6, consiste em colocar o pacote IPv6 dentro de um pacote IPv4, adequar os endereços de origem
técnica conhecida como e destino para o IPv4 e colocar no cabeçalho o tipo 41 (29 em hexadecimal). Esse tipo de
4in6. Algumas das
encapsulamento é conhecido por 6in4, ou como “protocolo 41”. Quando o destino receber o
técnicas de transição
estudadas mais à frente pacote com tipo 41, o cabeçalho IPv4 é removido e o pacote é tratado como IPv6. A figura 9.14
fazem isso. ilustra esse comportamento.

Cabeçalho IPv4

Cabeçalho IPv6 Cabeçalho IPv6 Cabeçalho IPv6

Encapsular Desencapsular
Cabeçalho Cabeçalho Cabeçalho
Camada de Transporte Camada de Transporte Camada de Transporte

~ Dados ~ ~ Dados ~ ~ Dados ~

Figura 9.14 É possível usar túneis criando-os manualmente. A técnica 6over4 (RFC 4213) usa um q
Funcionamento túnel manual estabelecido entre dois nós IPv4 para enviar o tráfego IPv6. Todo o tráfego
6in4.
IPv6 a ser enviado é encapsulado em IPv4 usando 6in4, explicado anteriormente.
A configuração manual consiste em definir quais serão os IPs v4 de origem e destino que
serão usados em cada ponta do túnel. Ao ser recebido pelo nó destino, o pacote IPv6 é
desencapsulado e tratado adequadamente.

Esse tipo de túnel pode ser usado para contornar um equipamento ou enlace sem
suporte a IPv6 numa rede, ou para criar túneis estáticos entre duas redes IPv6
através da internet IPv4.

É importante entender a diferença entre 6over4 e 6in4. O túnel 6over4 é um túnel estabele-
cido manualmente, que tem o objetivo de permitir conexão IPv6 entre dois nós de rede conec-
tados por uma rede via IPv4 – o encapsulamento 6in4 é usado. Já o encapsulamento 6in4, com
a utilização do tipo 41, pode ser usado também em outras técnicas de transição que trans-
portam pacotes IPv6 em redes IPv4, como poderá ser observado ao longo deste Capítulo.

Capítulo 9 - Coexistência e transição – Parte 1

141
 Criar um túnel 6over4 é bastante fácil. A seguir serão mostrados exemplos de como fazer essa
implementação no Linux e com roteadores Cisco. A topologia da implementação em Linux é:

Internet
ou rede somente IPv4

192.0.2.1/25 192.0.2.129/25

192.0.2.2/25 192.0.2.130/25

Host A Host B Figura 9.15

Túnel manual
Túnel 6over4 6over4 entre dois
2001:db8::ba1a/64 2001:db8::b0ca/64 dispositivos.

Os computadores Host A e Host B são computadores Linux e os roteadores simplesmente

representam uma rede somente IPv4 ou a internet IPv4. Os computadores devem ser
configurados com os seguintes passos:

No Host A, basta digitar os comandos: q

ip tunnel add toHostB mode sit ttl 64 remote 192.0.2.130 local
192.0.2.2

ip link set dev toHostB up

ip -6 route add 2001:db8::b0ca dev toHostB

De forma análoga, no Host B:

ip tunnel add toHostA mode sit ttl 64 remote 192.0.2.2 local

192.0.2.130

ip link set dev toHostA up

ip -6 route add 2001:db8::ba1a dev toHostA

Para verificar o correto funcionamento, pode-se usar o comando ping6 antes e depois de fazer
as configurações. Será possível notar que as duas máquinas passaram a comunicar-se via IPv6.
IPv6 Básico

142
 Para o exemplo de configuração em roteadores Cisco de túneis 6over4, a topologia será:

Internet
ou rede somente IPv4

198.51.100.6 203.0.113.197

198.51.100.5 203.0.113.198

Roteador A Roteador B
Figura 9.16 Rede 1 Rede 2
Túnel manual
2001:db8:10::/64 2001:db8:20::/64
6over4 entre dois Túnel 6over4
roteadores. 2001:db8:100::1/64 2001:db8100::2/64

Para a configuração do túnel, somente é necessária a configuração do Roteador A e do Rote-

ador B. No Roteador A:

configure terminal

interface Tunnel10

ipv6 address 2001:db8:100::1/64

tunnel source 198.51.100.5

tunnel destination 203.0.113.198

tunnel mode ipv6ip

end

Ainda no Roteador A, é necessário ativar o roteamento IPv6 e criar uma rota para a rede do
Roteador B, apontando para o Túnel 6over4:

ipv6 unicast-routing
Capítulo 9 - Coexistência e transição – Parte 1

ipv6 route 2001:db8:20::/64 2001:db8:100::2

De forma análoga, no Roteador B:

configure terminal

interface Tunnel20

ipv6 address 2001:db8:100::2/64

tunnel source 203.0.113.198

tunnel destination 198.51.100.5

tunnel mode ipv6ip

143
 end

ipv6 unicast-routing

ipv6 route 2001:db8:10::/64 2001:db8:100::1

Mais uma vez, é possível testar a configuração utilizando o ping para IPv6.

Túneis GRE
11 Generic Routing Encapsulation (GRE): túnel estático host-a-host desenvolvido para q
encapsular vários tipos diferentes de protocolos.

11 Suportado pela maioria dos sistemas operacionais e roteadores.

11 Seu funcionamento consiste em pegar os pacotes originais, adicionar o cabeçalho

GRE e enviar ao IP de destino.

11 Quando o pacote encapsulado chega à outra ponta do túnel, remove-se o cabeçalho

GRE, sobrando apenas o pacote original.

A tabela a seguir mostra a aplicação dessa técnica aos cenários descritos anteriormente.

Cenário 1 2 3 4 5 6 7 8 9 10

Suporta Não Não Não Não Não Não Não Não Sim Não

Outra opção de túnel estático para o transporte de IPv6 em redes IPv4 é o Generic Routing Tabela 9.2
Encapsulation (GRE) RFC 2784, um túnel estático entre dois nós originalmente desenvolvido Túneis GRE e os
cenários.
pela Cisco com a finalidade de encapsular vários tipos diferentes de protocolos, como por
exemplo IPv6 e IS-IS (a lista completa dos protocolos suportados pode ser encontrada em
http://www.iana.org/assignments/ethernetnumbers). Esse tipo de encapsulamento é
suportado na maioria do Sistemas Operacionais e roteadores, e possibilita a criação de um
link ponto a ponto. Assim como o 6over4, sua configuração é manual, de modo que pode
gerar um esforço na sua manutenção e gerenciamento proporcional à quantidade de túneis.

Pacote sendo Figura 9.17

Cabeçalho IPv4 Cabeçalho GRE
transportado Inserção do
cabeçalho GRE.

11 C (Checksum): se for 1, indica que existe o campo Checksum e que há informações

válidas nele e no Offset;

11 R (Routing): se for 1, indica que existe o campo Roteamento e que há informações de rote-
amento válidas nele e no Offset;

11 K (Key): se for 1, indica que o campo Chave existe e está sendo usado;

11 S (Sequence): se for 1, indica que o campo Número de sequência existe e está sendo utilizado;

11 Versão: geralmente preenchido com 0;

11 Protocolo: preenchido com o código do protocolo transportado, de acordo com os tipos

de pacotes Ethernet: http://www.iana.org/assignments/ethernet-numbers

11 Offset: indica a posição onde inicia o campo de roteamento;

IPv6 Básico

11 Checksum: contém o checksum IP (complemento de 1) do cabeçalho GRE e do pacote

sendo transportado;

11 Chave (Key): contém um número de 32 bits que é inserido pelo encapsulador. É usado
pelo destinatário para identificar o remetente do pacote;

144
 11 Número de sequência (Sequence number): contém um número inteiro de 32 bits que
é inserido pelo remetente do pacote. É utilizado pelo destinatário para sequenciar os
pacotes recebidos;

11 Roteamento (Routing): contém uma lista de entradas de roteamento, mas geralmente

não é usado.

O pacote com cabeçalho é explicado na figura a seguir:

32 bits
8 bits 8 bits 16 bits
4 bits 3 bits
Versão IHL Tipo de serviço Tamanho total
ID Flags Offset
Protocolo de envio Cabeçalho IPv4
TTL Protocolo (47) Checksum do cabeçalho
Origem
Protocolo de GRE Cabeçalho GRE Destino
Opções Padding
8 bits 8 bits 16 bits
4 bits 5 bits
Payload Pacote IPv6 C R K S Reserv Flags Versão Protocolo (para IPVv6 é 86dd)
Checksum Offset
Chave
Número de sequência
Roteamento

Cabeçalho IPv6

Cabeçalho
da camada
de transporte

Dados

Figura 9.18 A configuração dos túneis GRE é muito semelhante àquela feita para o 6over4. No exemplo
Pacote com dado para roteadores Cisco, no item 4, basta trocar:
cabeçalho GRE.
tunnel mode ipv6ip

por Capítulo 9 - Coexistência e transição – Parte 1

tunnel mode gre

Tunnel Broker
11 Consiste em criar um túnel IPv6 dentro da rede IPv4, do seu computador ou rede até q
o provedor que fornecerá a conectividade IPv6.

11 Basta cadastrar-se em um provedor de acesso Tunnel Broker e realizar o download de

um software ou script de configuração.

11 A conexão do túnel é feita através da solicitação do serviço ao servidor web do provedor.

11 Indicado para redes pequenas ou para um único host isolado.

145
 A tabela a seguir mostra a aplicação dessa técnica aos cenários descritos anteriormente.

Cenário 1 2 3 4 5 6 7 8 9 10

Suporta Não Não Não Não Não Não Não Não Sim Não

Descrita na RFC 3053, essa técnica permite que dispositivos isolados, ou toda uma rede IPv4, Tabela 9.3
obtenham conectividade IPv6 por meio do estabelecimento de um túnel com um provedor, Tunnel Broker
e os cenários.
tornando-se, na prática, dispositivos, ou uma rede Pilha Dupla.

Seu funcionamento é bastante simples: primeiramente é necessário realizar um cadastro,

normalmente via web, em um provedor que ofereça esse serviço, chamado, nesse contexto,
de Tunnel Broker. O provedor realizará de forma automática, ou semiautomática, a confi-
guração do seu lado do túnel e permitirá o download de instruções, ou de um software ou
script de configuração, para configurar o lado do usuário.

Os Tunnel Brokers normalmente oferecem blocos fixos IPv6 que variam de /64 a /48.

Entre as opções existentes, recomenda-se: q

11 Tunnel Broker (http://tunnelbroker.net/): serviço oferecido pela Hurricane Electric,
que provê túneis para usuários domésticos ou corporativos, inclusive com a possibili-
dade de se fechar sessões BGP para provimento de trânsito IPv6 via túnel;

11 SixXs (http://www.sixxs.net/main/): serviço oferecido de forma colaborativa por um

grande número de organizações. Não é possível fechar sessões BGP, mas é possível
obter redes fixas de tamanho /48 roteadas através do túnel. A Algar Telecom/CTBC é
responsável por um dos POPs em que são configurados os túneis, no Brasil, de forma
que para usuários em redes brasileiras os túneis funcionam com qualidade e veloci-
dade próximas às de conexões nativas.

Os Tunnel Brokers podem usar tecnologias diversas para prover os túneis. Podem usar, por
exemplo, túneis 6in4, encapsulamento em UDP, o protocolo AYIYA, que significa Anything in
Anything (draft-massar-v6ops-ayiya-02), ou Tunnel Setup Protocol (TSP), definido na RFC 5572.

A utilização de Tunnel Brokers é recomendada para usuários domésticos e corpora-

tivos que querem testar o IPv6, ou começar um processo de implantação em suas
redes, mas cujos provedores de acesso ainda não oferecem suporte ao protocolo.

Muitos Sistemas Autônomos brasileiros têm utilizado com sucesso túneis com a Hurricane
Electric para anunciar seus blocos em caráter de teste e muitas empresas e usuários domés-
ticos têm utilizado túneis SixXS para familiarizar-se com o IPv6.

A implantação de um serviço de Tunnel Broker em um provedor internet não é trivial, pois

não há softwares abertos disponíveis para a funcionalidade de Servidor Broker. As figuras
a seguir mostram a topologia lógica e física do Tunnel Broker.
IPv6 Básico

146
 Servidor
Broker Internet
IPv6
2

Servidor
de túnel
1 3
Internet
IPv4

Figura 9.19 Pilha dupla 4

Topologia lógica do esperando
Tunnel Broker. acesso IPv6

1. Cliente Pilha Dupla solicita túnel (pode ser solicitada autenticação) via IPv4. q
2. Broker cadastra usuário no servidor de túnel.

3. Broker informa cliente parâmetros para criação do túnel.

4. Túnel estabelecido.

Servidor
de túnel

Pilha dupla 1
Servidor Servidor Internet
esperando 2
acesso IPv6 Broker de túnel IPv6
3

Servidor
de túnel

Figura 9.20
Topologia física do
Capítulo 9 - Coexistência e transição – Parte 1
4
Tunnel Broker.

O exemplo de implementação de Tunnel Broker será baseado no OpenWRT (openwrt.org),

um firmware opensource para roteadores sem fio SOHO (small office/home office). Como
provedor do túnel, será utilizada a solução da Hurricane Eletric (tunnelbroker.com). A seguir,
o passo a passo da instalação:

5. Criar um usuário em tunnelbroker.com e solicitar um túnel;

6. Instalar os pacotes necessários no OpenWRT:

opkg install ip ip6tables kmod-sit kmod-iptunnel6 radvd

147
 7. Criar o arquivo /etc/hotplug.d/iface/15-ipv6 com o seguinte código (que considera que a
conexão com o provedor utiliza PPP. Se for outro tipo de conexão, o código necessita de
pequenas alterações):

. /etc/functions.sh

NAME=ipv6

COMMAND=/usr/sbin/ip

[ “$ACTION” = “ifup” –a “$INTERFACE” = “wan” –a “$DEVICE” = “ppp0” ]

&& { [ -x $COMMAND ] && {

# setup tunnel

logger “HE-IPv6:starting tunnel...”

IPADDR=$(ip -4 addr show dev $DEVICE |

awk ‘/inet / {print $2}’ |

cut d/ -f1)

username=”abcdef1234567890abcdef1234567890” # MD5 of your username

password=”abcdef1234567890abcdef1234567890” # MD5 of your password

tunnelid=”69999” # global tunnel-ID

# update tunnel to use dynamic ipv4

wget –q –O /dev/null “http://ipv4.tunnelbroker.net/ipv4_end.

php?ipv4b=

$IPADDR&pass=$password&user_id=$username&tunnel_id=$tunnelid”

SERVER_IPv4_ENDPOINT=216.66.80.30 # change this IP to your option

CLIENT_IPv6_ENDPOINT=2001:470:1f0a:9999::2/64 # change this, too

# setup tunnel

ip tunnel add he-ipv6 mode sit remote $SERVER_IPv4_ENDPOINT local

$IPADDR ttl 255

ip link set he-ipv6 up

ip addr add $CLIENT_IPv6_ENDPOINT dev he-ipv6

ip route add ::/0 dev he-ipv6

} &

[ “$ACTION” = “ifdown” –a “$INTERFACE” = “wan” –a “$DEVICE” =

“ppp0” ] && { [ -x $COMMAND ] && {

# destroy tunnel
IPv6 Básico

logger “HE-IPv6: destroying tunnel...”

ip route del ::/0 dev he-ipv6

148
 ip tunnel del he-ipv6

} &

# You got a routed /64

8. Adicionar um IP para a interface do túnel:

uci set network.lan.ip6addr=2001:470:1f0b:9999::1/64

uci commit

9. Configurar o firewall do OpenWRT para aceitar pacotes com protocolo 41 vindos da

interface WAN.

10. Configurar o anúncio da rede IPv6 na LAN, editando o arquivo /etc/config/radvd:

config interface

option interface ‘lan’

option AdvSendAdvert 1

option AdvManagedFlag 0

option AdvOtherConfigFlag 0

option ignore 0

config prefix

option interface ‘lan’

# If not specified, a non-link-local prefix of the interface is used

option prefix ‘2001:470:1f0b:9999::/64’

option AdvOnLink 1

option AdvAutonomous 1

option AdvRouterAddr 0

option ignore 0

config rdnss Capítulo 9 - Coexistência e transição – Parte 1

option interface ‘lan’

# If not specified, the link-local address of the interface is used

option addr ‘2001:470:1f0b:9999::/64’

option ignore 1

Alterar o endereço “:9999” para a rota que usamos. Salvar o arquivo e executar os comandos
para que as alterações sejam aplicadas:

/etc/init.d/radvd enable

/etc/init.d/radvd start

149
 11. A configuração está completa. Reiniciar o roteador e testar o túnel. Pode-se executar o
ping6 diretamente no roteador e, funcionando corretamente, executá-lo a partir de um
computador na LAN:

ping6 ipv6.google.com

Outro exemplo de configuração é a utilização de Tunnel Broker no Windows. É possível

Os tutoriais da
utilizá-lo em diversas versões do Windows (2000, XP, 2008, Vista e 7), desde que o suporte Hurricane Eletric e do
IPv6 seja instalado nas versões que não o suportam nativamente. A configuração deve ser OpenWRT podem ser
consultados em: http://
feita através do console usando um usuário com permissões administrativas. As configura-
www.tunnelbroker.net/
ções para essas versões do Windows são: forums – HOWTO setup
an IPv6 tunnel using
Explicação das variáveis usadas: OpenWrt 10.03
(Backfire) e http://wiki.
$ipv4a = IPv4 do servidor do túnel openwrt.org – Dynamic
IPv6-in-IPv4 tunnel (HE.
$ipv4b = IPv4 do usuário do túnel net only).

$ipv6a = rede /64 alocada ao lado do servidor do túnel

$ipv6b = rede /64 alocada ao lado do usuário do túnel

Windows 2000/XP:

ipv6 install

ipv6 rtu ::/0 2/::$ipv4a pub

ipv6 adu 2/$ipv6b

Windows 2008/Vista/7

netsh interface ipv6 add v6v4tunnel interface=IP6Tunnel $ipv4b

$ipv4a

netsh interface ipv6 add address IP6Tunnel $ipv6b

netsh interface ipv6 add route ::/0 IP6Tunnel $ipv6a

Dual Stack Lite (DS-Lite)

A tabela a seguir mostra a aplicação dessa técnica aos cenários descritos anteriormente.

Cenário 1 2 3 4 5 6 7 8 9 10

Suporta Sim Não Não Não Sim Não Não Não Não Não

Serão analisadas agora algumas técnicas bastante pertinentes ao momento atual da Tabela 9.4
transição para o IPv6, num cenário em que não há mais IPv4 disponíveis, mas a base de DS-Lite e os
cenários.
usuários do provedor continua a crescer e ainda há muitos serviços exclusivamente
disponíveis em IPv4 na internet. Dessa forma, o provedor não pode oferecer exclusivamente
conectividade IPv6 ao usuário final, sendo forçado a oferecer também conectividade IPv4,
mas com IPs de alguma forma compartilhados.

11 RFC 6333 – Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion q

IPv6 Básico

11 Address Family Transition Router (AFTR)

11 Carrier Grade NAT (CGN)

11 Túnel IPv4 sobre IPv6 (entre AFTR e o CPE)

150
 11 Endereços IPv4 192.0.0.0/29 nas extremidades do túnel q
11 Endereços RFC 1918 para a rede do usuário

11 DHCPv4 no CPE

11 Proxy DNS para consultas via IPv4

A primeira técnica a ser analisada será o Dual Stack Lite (Pilha Dupla simplificada), padroni-
zada na RFC 6333, que pode ser aplicada em situações em que o provedor já oferece IPv6
nativo para seus usuários. Sua implementação necessita de um equipamento denominado
Address Family Transition Router (AFTR), que implementa um Carrier Grade NAT (CGN), que
é um NAT de grande porte, na rede do provedor. Entre o AFTR e o CPE do usuário utiliza-se
um túnel IPv4 sobre IPv6 para transportar o tráfego IPv4. No contexto do DS-Lite, o CPE do
B4 usuário é chamado de B4. Nas extremidades desses túneis são usados endereços da faixa
Abreviação para 192.0.0.0/29, especialmente reservada para esse fim. Para o CPE do usuário e os demais
DSLite Basic Bridging
equipamentos da rede do usuário são utilizados IPs da RFC 1918 e não há problema se dife-
BroadBand.
rentes usuários utilizarem faixas de IPs repetidas, dado que o AFTR identifica os diferentes
túneis com base no IPv6 de origem dos pacotes encapsulados. Na CPE do usuário deve
existir um DHCP v4 para a distribuição dos endereços na rede interna. Deve existir também

l um Proxy DNS, que permita consultas via IPv4, mas faça essas consultas ao DNS recursivo
É possível usar do provedor via IPv6, evitando traduções desnecessárias no AFTR.

q
roteadores Linksys
WRT54GL e outros É importante destacar alguns pontos:
compatíveis com o
firmware OpenWRT, 11 O AFTR usa CGN, mas não força o usuário a utilizar duplo NAT. Ou seja, AFTR realiza a
disponível em: http:// função de NAT, de forma concentrada, para cada um dos dispositivos de cada usuário;
www.kangaroo.
comcast.net/wiki/ 11 O DS-Lite usa endereços privados na faixa 192.0.0.0/29 para as extremidades dos
(DS-Lite Linksys túneis v4 sobre v6, evitando a utilização desnecessária de endereços IPv4 na infraes-
WRT-54GL v1.1
trutura do provedor.
Installation).

A figura 9.21 mostra um exemplo de topologia.

Túnel IPv4 sobre IPv6

192.168.0.2/24
2001:db8:cl1::2/64

Rede IPv6
Provedor 192.0.0.1
192.0.0.2 2001:db8:c::1/64
2001
:db8
:a::1
/64
2001:db8:b::1/64 203.0.113.130/25
192.168.0.1/24
2001:db8:cl1::1/64 Internet
Core IPv6 nativo IPv4 Capítulo 9 - Coexistência e transição – Parte 1
B4 (CPE) AFTR
DHCPv4 Nat Pool: 203.0.113.1/32
Proxy DNS

192.168.0.3/24
Figura 9.21 2001:db8:cl1::3/64 Internet
IPv6
Exemplo de
topologia DS-Lite.

Uma alternativa para implantar o DS-Lite é a utilização do software AFTR desenvolvido pelo
Internet Systems Consortium (ISC), inicialmente por solicitação e com financiamento da
Comcast, um grande provedor que opera com cabo nos Estados Unidos. O software está
disponível em http://www.isc.org/software/aftr e pode ser usado em servidores GNU/Linux
no provedor, permitindo implementação de baixo custo, robusta e escalável. Para o B4 (CPE)
podem ser utilizados também dispositivos rodando Linux.

151
 A configuração dessa topologia é bastante simples. Para configurar o AFTR, basta criar um
arquivo chamado aftr-script, contendo:

aftr_start() {

set -x

ip link set tun0 up

ip addr add 192.0.0.1 peer 192.0.0.2 dev tun0

ip route add 203.0.113.1/32 dev tun0

ip -6 addr add fe80::1 dev tun0

ip -6 route add 2001:db8:c::1/64 dev tun0

aftr_stop() {

set -x

ip link set tun0 down

case “$1” in

start)

aftr_start

;;

stop)

aftr_stop

;;

*)

echo “Usage: $0 start|stop”

exit 1

;;

esac

exit 0

E um arquivo de configuração chamado aftr.conf, contendo:

default tunnel mss on

defmtu 1450

address endpoint 2001:db8:c::1

IPv6 Básico

address icmp 203.0.113.1

pool 203.0.113.1

acl6 ::0/0

152
E então iniciar o serviço.

Para o B4 (CPE), basta criar o túnel IPv4 sobre IPv6:

modprobe ip6_tunnel

ip -6 tunnel add dsltun mode ipip6 remote 2001:db8:c::1 local

2001:db8:0:b::1 dev eth1

ip addr add 192.0.0.2 peer 192.0.0.1 dev dsltun

ip link set dev dsltun up

ip route add default dev dsltun

Além disso, deve-se configurar o DHCPv4 e o proxy DNS no B4.

Esse exemplo de configuração usa apenas um endereço para o pool de NAT, mas poderiam
ser usados mais. Note que o endereço IPv4 da interface física do servidor AFTR não está na
mesma rede dos endereços usados no pool. O endereço IPv6 da extremidade AFTR do túnel
não é o endereço físico da interface, mas outro, numa rede diferente. Os pacotes direcio-
nados para os endereços do Pool IPv4 e para o endereço IPv6 da extremidade do túnel são
roteados para a interface de túnel e tratados pelo software AFTR. Por fim, é importante
notar que os mesmos endereços 192.0.0.1 e 192.0.0.2 são usados para múltiplos clientes e
que a detecção de novos túneis de clientes é feita automaticamente pelo AFTR, com base no
endereço IPv6 de origem destes.

Uma variação dessa técnica, que tenta resolver o mesmo problema, é a combinação do
DS-Lite com o Address Plus Port (A+P), e é conhecida como DS Lite A+P (o A+P será apresen-
tado com mais detalhes neste capítulo). O funcionamento do DS Lite A+P é similar ao do DS
Lite, mas, ao invés de ser um endereço IPv4 privado, o CPE do usuário recebe um endereço
IPv4 público. As portas disponíveis para utilização, contudo, são limitadas, pois esse IP
público é compartilhado com outros nós. O CPE deve então realizar a função de tradução
de endereços (NAT), oferecendo IPs privados (RFC 1918) para os demais nós na rede, mas
obedecendo à restrição das portas imposta pelo A+P na tradução.

Com a utilização do DS-Lite com A+P, a escalabilidade é melhor, uma vez que o NAT é feito
de forma distribuída, nos CPEs. O usuário pode também realizar o mapeamento de portas
no NAT e receber conexões entrantes, numa situação muito próxima à que existiria sem o
compartilhamento de endereços.

O DS Lite com A+P é ilustrado na figura a seguir. Na imagem, o CPE recebe o endereço IPv4
restrito das portas 1024 a 2047, como exemplo, mas tanto as portas disponíveis quanto a
Capítulo 9 - Coexistência e transição – Parte 1

quantidade poderiam ser outras.

153
 Túnel IPv4 sobre IPv6
192.168.0.2/24
2001:db8:cl1::2/64

Rede IPv6
Provedor 192.0.0.1
192.0.0.2 2001:db8:c::1/64
2001
:db8
:a::1
/64
2001:db8:b::1/64 203.0.113.130/25
192.168.0.1/24
2001:db8:cl1::1/64 Internet
Core IPv6 nativo IPv4
203.0.113.1:1024~2047 AFTR
B4 (CPE) A+P Pool: 203.0.113.1/32
DHCPv4
Proxy DNS
Nat 44

192.168.0.3/24
2001:db8:cl1::3/64 Internet
IPv6

Deve-se notar que o DS-Lite e o DS-Lite com A+P usam IPv4 sobre IPv6, mas utilizam-se de Figura 9.22
técnicas stateful para o compartilhamento dos endereços IPv4. Exemplo topologia
DS-Lite com A+P.

IVI, dIVI e dIVI-pd

Cenário 1 2 3 4 5 6 7 8 9 10

Suporta Sim Não Não Não Sim Não Não Não Não Não

11 Compartilhamento de IPs v4 com restrição de portas q Tabela 9.5

IVI, dIVI e dIVI-pd, e
11 Extensões do IVI (RFC 6219) os cenários.

11 Mecanismo de tradução stateless 1:1

11 Soluções experimentais usadas na CERNET2 chinesa

No item anterior foi apresentado o DS-Lite, que era útil para utilização no provedor, num
cenário em que não há mais endereços IPv4 disponíveis, mas onde sua base de usuários
continua a crescer. Dessa forma, o provedor não pode oferecer exclusivamente conectivi-
dade IPv6 ao usuário final, sendo forçado a oferecer também conectividade IPv4, mas com
IPs de alguma forma compartilhados.

O dIVI (draft-xli-behave-divi-04) e o dIVIpd (draft-xli-behave-divi-pd-01) são alternativas de

solução para o mesmo problema, mas têm a vantagem de usar técnicas stateless baseadas
numa dupla tradução de pacotes, diferentemente do DS-Lite, que é stateful e baseado em
tunelamento. Esses métodos de tradução stateless são capazes de manter a transparência
fim a fim do endereço IP, não necessitando de técnicas auxiliares, como DNS64 (tradução de
DNS) ou ALG (gateways para aplicações específicas). Ambos os protocolos usam comparti-
lhamento de IPs v4 com restrição de portas, de forma análoga ao A+P.
IPv6 Básico

Todas as soluções são extensões do IVI (RFC6219), cujo nome vem da concatenação dos
numerais romanos IV (4) e VI (6). O IVI é um mecanismo de tradução stateless 1:1, desenvol-
vido por pesquisadores da CERNET2, a rede acadêmica chinesa, que é somente IPv6. A China
optou por criar uma rede acadêmica IPv6 pura, totalmente nova, no lugar de implantar o

154
 IPv6 em Pilha Dupla na rede já existente. Essa estratégia pode parecer estranha atualmente,
mas permitiu o desenvolvimento da indústria nacional de equipamentos de rede e, em con-
junto com incentivos econômicos para uso da nova rede, alavancou a implantação do IPv6
nas universidades e o desenvolvimento de diversas aplicações. Em muitas universidades
chinesas, hoje, o tráfego IPv6 é maior do que o IPv4.

O IVI foi criado inicialmente para permitir que servidores IPv6, ligados à CERNET2, pudessem
comunicar-se com a internet IPv4. Para isso, um endereço IPv4 é atribuído virtualmente ao
dispositivo, utilizando um mecanismo de tradução de pacotes stateless.

As três soluções, IVI, dIVI e dIVI-pd, são experimentais. Existem relatos de implantação e
teste realizados na CERNET/CERNET2 e pela China Telecom. Para o IVI há código disponível
publicamente, na forma de um patch para o kernel do Linux. Para o dIVI e o dIVI-pd não há
implementações públicas disponíveis.

IVI
Pode-se entender o conceito do funcionamento do IVI imaginando-se que este cria um nó
IPv6 espelho para o IPv4 e um nó IPv4 espelho para o IPv6, sendo que um nó espelho é um
endereço que simula a presença do dispositivo na rede, mas que na verdade encaminha os
pacotes enviados a ele para o dispositivo real através da tradução stateless. O servidor ou
usuário IPv6 nativo na rede atendida pelo IVI, embora não tenha um endereço IPv4 atribuído
a si, é visto por um nó IPv4 na internet por meio de seu “endereço espelho” e, de forma
análoga, enxerga um nó IPv4 qualquer na internet por meio de seu “endereço IPv6 espelho”.
A figura a seguir demonstra o conceito.

Subconjunto dos
Internet Rede endereços IPv6
Tradutor IVI
IPv4 IPv6

Figura 9.23
Explicação Host IPv4 Host IPv6 espelhado Host IPv4 espelhado com Host IPv6 com
conceitual do IVI. na rede IPv4 endereço IPv4-traduzido endereço IPv4-traduzível

O provedor, para implantar o IVI, escolhe um subconjunto de seu bloco IPv4, que será usado
para formar endereços IPv6, a fim de atender os servidores – ou usuários somente IPv6 –
Capítulo 9 - Coexistência e transição – Parte 1

que se comunicarão com a internet IPv4 por meio do IVI. Os endereços são mapeados
conforme a figura a seguir.

155
 Endereços IPv4 na internet Endereços IPv6 na internet

Bloco IPv4 do Provedor Bloco IPv6 do Provedor

IVI IVI
IPv4 IPv6

Mapeamento 1:1 Figura 9.24

Mapeamento de
endereços IPv6 em
IVI IPv6: Prefixo v6 IVI IPv4 sufixo
IPv4 e vice-versa.

Por exemplo, um provedor cujo bloco IPv6 é 2001:db8::/32 e cujo bloco IPv4 é
192.61.100.0/24 pode escolher o prefixo IPv6 2001:db8:ff00::/40 e o bloco IPv4
192.51.100.0/26 para formar os endereços IVI. Os endereços IPv4 são mapeados para IPv6,
então, da seguinte forma:

192.51.100.1 - 2001:db8:ffc0:3364:0100::0

192.51.100.2 - 2001:db8:ffc0:3364:0200::0

(...)

192.51.100.62 - 2001:db8:ffc0:3364:3e00::0

Na implementação feita pela CERNET, o prefixo é um /40 e os bits de 32 a 39 são todos 1,

para identificar o endereço IVI. Os bits 40 a 71 abrigam o endereço válido IPv4, representado
no formato hexadecimal. Nesse formato, um IPv4 /24 é mapeado para um IPv6 /64 e um
IPv4 /32 é mapeado para um IPv6 /72, mas o sufixo usado é sempre composto por zeros, de
forma que apenas um endereço IPv6 é, na prática, mapeado para um endereço IPv4.

Note que o IVI não é uma solução para o esgotamento do IPv4. Para seu funcionamento, é
necessário separar um conjunto de endereços IPv4 válidos do bloco disponível no provedor
e mapeá-lo para um conjunto de endereços IPv6 globais. A tradução no IVI é feita de forma
stateless, o que é simples de implementar e escala bem. Note também que o IVI precisa
funcionar em conjunto com o DNS64, caso seja necessário resolver os nomes de dispositivos
IPv4. Veja ainda que os métodos de tradução como IVI e NAT64 não funcionam com aplica-
ções que carregam os endereços IP na camada de aplicação, sendo necessária a utilização
de Application Layer Gateways (ALGs) nesses casos.

O IVI oferece conectividade fim a fim, seja IPv4 ou IPv6, para os dispositivos atendidos.
IPv6 Básico

156
 ORG: 192.51.100.1 ORG: 2001:db8:ffc0:3364:0100::0
DST: 203.0.113.1 DST: 2001:db8:ffcb:0071:0100::0

Internet Rede
IPv4 Host IPv6
Host com
somente Tradutor IVI prefixo IVI
IPv4

ORG: 203.0.113.1 ORG: 2001:db8:ffcb:0071:0100::0

DST: 192.51.100.1 DST: 2001:db8:ffc0:3364:0100::0 Internet
IPv6

Figura 9.25 As regras aplicadas na tradução do cabeçalho dos pacotes estão especificadas na RFC 6145 e
Tradução de são mostradas a seguir:
endereços no IVI.

Campo IPv4 Tradução para IPv6

Versão (0x4) Versão (0x6)

IHL (descartado)

Tipo de Serviço Classe de Tráfego

Tamanho Total Tamanho do Payload = Tamanho Total – IHL * 4

Identificação (descartado)

Flags (descartado)

Offset (descartado)

Tempo de vida Limite de nós

Protocolo Próximo Cabeçalho

CRC do Cabeçalho (descartado)

Endereço de Origem Aplicar mapeamento stateless IVI

Tabela 9.6
Endereço de Destino Aplicar mapeamento stateless IVI
Conversão de
cabeçalhos IPv4
Opções (descartado)
para IPv6.

Campo IPv6 Cabeçalho IPv4Traduzido

Versão (0x6) Versão (0x4) Capítulo 9 - Coexistência e transição – Parte 1

Classe de Tráfego Tipo de Serviço

Etiqueta de Fluxo (descartado)

Tamanho do Payload Tamanho Total = Tamanho do Payload +20

Próximo Cabeçalho Protocolo

Limite de nós Tempo de vida

Endereço de Origem Aplicar mapeamento stateless IVI

Endereço de Destino Aplicar mapeamento stateless IVI

Tabela 9.7
Conversão de ..... IHL = 5
cabeçalhos IPv6
para IPv4. ..... CRC do Cabeçalho Recalculado

157
 O caso de aplicação mais comum para o IVI é oferecer visibilidade IPv4 para servidores
somente IPv6 dentro de uma determinada rede, mas ele poderia ser utilizado também para
usuários, com a mesma finalidade, desde que haja uma quantidade suficiente de endereços
IPv4 disponíveis. Os dispositivos que utilizarem o IVI devem usar endereçamento manual ou
DHCPv6, pois o endereço precisa seguir um padrão específico que não pode ser obtido pela
autoconfiguração IPv6.

O IVI ainda não está largamente implementado e atualmente a única maneira de testá-lo é
através do Linux. Para usar o IVI é necessário aplicar um patch ao kernel do Linux.
Esse patch está disponível em http://www.ivi2.org/IVI/.

Após aplicar o patch é necessário habilitar a opção IVI e o protocolo IPv6 deve ser adicionado
no modo “built in”, e não como módulo. No menu config do kernel essas opções estão em:

Networking →

Networking Options →

[*] IVI(test only)

<*> The IPv6 protocol

Deve-se então compilar e instalar o kernel, e executar o script de configuração a seguir,

fazendo as modificações de endereço necessárias para a rede onde a técnica será aplicada:

#!/bin/bash

# habilite o redirecionamento (forwarding)

echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

echo 1 > /proc/sys/net/ipv4/conf/all/forwarding

# configure rota para IVI6 = 2001:0db8:ffc0:3364::/70,

# IVI4 = 192.51.100.0/26

# configure rota IPv6, sempre configurar rotas explicitas para as

# redes mapeadas, nao usar rotas default

route add –A inet6 2001:0db8:ffc0:3364::/70 gw 2001:db8::1 dev eth0

# configure mapeamento para source-PF = 2001:db8::/48

# configure mapeamento para destination-PF = 2001:db8::/48

# para cada mapeamento, um pseudo-endereço único (10.0.0.x/8) deve

ser configurado

ip addr add 10.0.0.1/8 dev eth0

# Mapeamento IPv4-to-IPv6, múltiplos mapeamentos podem ser feitos #

via múltiplos comandos:

# mroute IVI4-network IVI4-mask pseudo-address interface source-PF

IPv6 Básico

Destination-PF

mroute 192.51.100.0 255.255.255.192 10.0.0.1 eth0 2001:db8::

2001:db8::

158
 # Mapeamento IPv6-to-IPv4

# mroute6 destination-PF destination-PF-pref-len

mroute6 2001:db8:ff00:: 40

Uma vez apresentado o IVI, pode-se entender o funcionamento do dIVI e do dIVI-pd. Ambas
as técnicas utilizam tradução dupla e compartilhamento de endereços IPv4, com restrição de
portas. Dessa forma, os nós atendidos por elas usam Pilha Dupla, tendo IPv6 nativo para a
comunicação com a internet IPv6 e um IPv4 compartilhado. Com o dIVI e o dIVI-pd a comuni-
cação fim a fim é possível, tanto com o uso de IPv4, como com o uso de IPv6, guardando-se a
restrição de que apenas um subconjunto do total de portas está disponível para um deter-
minado dispositivo no IPv4. Não é necessário o uso de NAT64 e nem de ALG. A figura 9.26
representa tanto o funcionamento do dIVI quanto o do dIVI-pd.

CPE1
Host 1
Internet
IPv4

IPv4
+ Rede Tradução N:1
IPv6 CPE2 IPv6 IPv6 para IPv4

Internet
IPv6
Figura 9.26 Host 2 Tradução 1:1
Topologia da rede IPv4 - IPv6 Stateless
com a utilização do
dIVI e dIVI-pd. Mapeamento de portas parc. statefull

dIVI
No dIVI, os endereços IPv4 são mapeados em IPv6 usando um formato definido no
draft-bcx-behave-address-fmt-extension, que é uma extensão da RFC 6052. Nesse formato,
que pode usar prefixos IPv6 com diferentes tamanhos, é possível carregar o endereço IPv4
que está sendo compartilhado e também informações que identificam quais são as faixas de
portas que podem ser utilizadas pelo nó: o PSID, que é uma espécie de identificador da CPE,
e o Q, que indica qual a taxa de compartilhamento de endereços. Com essas informações,
um algoritmo muito simples na CPE identifica quais portas podem e quais não podem ser
Capítulo 9 - Coexistência e transição – Parte 1

usadas. De forma análoga, o tradutor IVI N:1 na rede do provedor traduz o IPv4 de destino
para o endereço IPv6 correspondente, baseando-se tanto no endereço quanto na porta.
Os bits de 64 a 71, representados por “u”, devem possuir valor zero. Eles são reservados
para compatibilidade com o formato de identificação de dispositivo na arquitetura de ende-
reçamento IPv6, de acordo com a RFC 4291.

159
 0 32 40 48 56 64 72 80 88 96 104 112 120 128
32 bits 8 bits 8 bits 8 bits 8 bits 8 bits 8 bits 8 bits 8 bits 8 bits 8 bits 8 bits 8 bits

32 prefixo v4 (32) u PSID 0 Q

40 prefixo v4 (24) u (8) PSID 0 Q

48 prefixo v4 (16) u v4 (16) PSID 0 Q

56 prefixo (8) u v4 (24) PSID 0 Q

64 prefixo u v4 (32) PSID 0 Q

Na CPE pode haver dois tipos de tradução. Pode ser feita uma tradução totalmente stateless, Figura 9.27
mas, nesse caso, o nó deve conhecer a priori a restrição das portas e enviar os pacotes já Endereçamento
IPv6 traduzido do
obedecendo a isso. Outra possibilidade é a tradução na CPE ser parcialmente statefull, de IPv4 pelo dIVI.
forma que o nó não precise obedecer a qualquer restrição quanto à porta de origem. Nesse
segundo caso, a CPE deve fazer a tradução das portas e manter o estado dessa tradução.

Note que no dIVI apenas um endereço IPv4 e um endereço IPv6 são atribuídos ao disposi-
tivo. Um caso de uso esperado para essa técnica é o uso para dispositivos móveis, em redes
3G ou 4G. O Sistema Operacional do dispositivo poderia suportar as funções da CPE dIVI, ou
seja, tradução 1:1 de IPv4 para IPv6 e mapeamento de portas, de forma que, funcionando
como um nó somente IPv6 na realidade, ainda assim pudesse oferecer uma API Pilha Dupla
para as aplicações.

dIVI-pd
O dIVI e o dIVI-pd são, de fato, muito parecidos. O dIVI-pd permite que seja designado um
prefixo IPv6 para o dispositivo no lugar de um único endereço. Dessa forma, é possível uti-
lizar a autoconfiguração stateless ou ainda endereçar toda uma rede com diversos nós.
É importante observar que apenas um endereço IPv4 continua sendo atribuído para cada
CPE no dIVI-pd, de forma que se for necessário atribuir endereços IPv4 para mais de um nó,
a CPE deverá fazê-lo utilizando NAT44 e endereços privados, da RFC 1918.

O dIVI-pd também usa os endereços no formato definido pela RFC 6052, com o prefixo de Figura 9.28
comprimento /64 e dois tipos de extensões, o CPE index, como parte do prefixo e o sufixo no Endereçamento
IPv6 traduzido do
mesmo formato utilizado pelo dIVI. IPv4 pelo dIVI-pd.

0 32 56 64 72 104 120 128

32 bits 24 bits 8 bits 8 bits 32 bits 16 bits 8 bits

64 prefixo u v4 (32) sufixo

prefixo do domínio índice do CPE 0 u v4 (32) sufixo 0

EXT
IPv6 Básico

(d) bits (s+k) bits (m) (8) (32) bits (16) bits (8)

160
 Note que para os usuários é possível atribuir prefixos /64, ou mais curtos, como /60 ou /56.
Isso determina o valor de m (preenchimento com zeros). Note ainda que o fato de o formato
de sufixo ser o mesmo utilizado pelo dIVI permite a construção de CPEs compatíveis com as
duas técnicas.

O dIVI e o dIVI-pd são realmente ótimas soluções, tendo características praticamente ideais
para uso por provedores de acesso, por isso seu desenvolvimento e padronização devem
ser acompanhados com muita atenção:

11 Operam com base em redes somente IPv6, que é para onde caminha a internet;

11 Usam traduções stateless, que são simples de implementar e baratas do ponto de vista
computacional, permitindo boa escalabilidade;

11 Permitem conexões em ambos os sentidos, mantendo a conectividade de fim a fim;

11 Não necessitam de ALG ou DNS64;

11 Quando necessário o uso de técnicas statefull, para a tradução de portas, isso é feito no
lado do usuário, mantendo o princípio de que a complexidade na internet deve estar nas
extremidades, e não próxima ao core da rede;

11 A tradução implementada no provedor, de IPv6 para IPv4, N:1, pode ser usada de forma
isolada, em conjunto com DNS64 e eventualmente ALGs, para clientes somente IPv6;
CPEs com suporte à tradução no sentido inverso poderiam ser implementados apenas
para os clientes para os quais esse método não for suficiente e que realmente necessi-

Tabela 9.8 tarem de endereços IPv4 nos dispositivos.

NAT64 e DNS64, e
os cenários. NAT64 e DNS64
Cenário 1 2 3 4 5 6 7 8 9 10

Suporta Sim Não Não Não Sim Não Não Não Não Não

11 NAT64 – RFC 6146 q

11 DNS64 – RFC 6147

11 Nós somente IPv6 acessando a internet IPv4

11 NAT64 traduz endereços IPv4 em IPv6

Outra técnica de tradução aplicável em situações similares às do IVI, dIVI e dIVI-pd, ou seja,
para nós somente IPv6 acessarem a internet IPv4, é o NAT64 (RFC 6146). O NAT64 é uma
técnica stateful de tradução de pacotes IPv6 em IPv4, que necessita de uma técnica auxiliar
Capítulo 9 - Coexistência e transição – Parte 1

para a conversão do DNS, chamada de DNS64 (RFC 6147). São sistemas distintos, mas que

O processo é definido
d trabalham em conjunto para permitir a comunicação entre as redes IPv6 e IPv4.

em detalhes na O NAT64 necessita fazer a tradução de endereços IPv4 em IPv6, esta tradução é feita
RFC 6052. conforme ilustrado na figura a seguir.

0 96 128
96 bits 32 bits
Figura 9.29
Endereçamento
IPv6 traduzido do Prefixo v4 (32)
IPv4 pelo NAT64.

161
 O prefixo IPv6 pode ser escolhido pela operadora, mas é recomendada a utilização do
prefixo 64:ff9b::/96, reservado especificamente para a utilização em algoritmos de mapea-
mento de endereços IPv4 em IPv6. Por exemplo, o IPv4 203.0.113.1 seria convertido para o
endereço IPv6 64:ff9b::203.0.113.1.

Já a tradução do cabeçalho IPv6 em cabeçalho IPv4 e vice-versa é feita da mesma maneira

que no IVI, já estudado anteriormente. O processo está ilustrado nas tabelas 9.6 e 9.7 e é
especificado em detalhes na RFC 6145. O funcionamento do NAT64 é ilustrado no diagrama
de sequência e na topologia das figuras 9.30 e 9.31, a seguir:

DNS
DNS

DNS Servidor
Cliente IPv6 DNS64 Autoritativo NAT64 IPv4
DNS Query
AAAA exemplo.com DNS Query
AAAA exemplo.com
DNS Response
NXDOMAIN
DNS Query
A exemplo.com
DNS Response
DNS Response A 200.0.113.1
AAAA
64:ffb9::200.0.113.1

TCP em IPv6
Dst: [64:ffb9::200.0.113.1]:80 Alocação de um IPv4
Org: [2001:db8::abcd]:xyz do pool de endereços

TCP em IPv4
Dst: 200.0.113.1:80
Org: 192.0.2.45:6853
TCP em IPv4
TCP em IPv6 Dst: 192.0.2.45:6853
Dst: [2001:db8::abcd]:xyz Org: 200.0.113.1:80
Org: [64:ffb9::200.0.113.1]:80

Figura 9.30
Diagrama de
sequência do
NAT64/DNS64.
IPv6 Básico

162
 Rede IPv6 Internet IPv4
DNS

1 DNS64
2
3 4

6 5

Cliente IPv6 NAT64 Servidor IPv4

2001:db8::abcd 200.0.113.1

Figura 9.31 O NAT64 possui implementações para Linux, Windows, grandes roteadores (Cisco e Juniper)
Topologia de rede e roteadores domésticos baseados em Linux. Como exemplo, serão apresentadas a seguir
do NAT64/DNS64.
configurações para Linux e Cisco.

Há várias opções de implementação do NAT64 no Linux: uma delas é a desenvolvida pelo

projeto Ecdysis (http://ecdysis.viagenie.ca), que também pode ser utilizada em Sistemas
Operacionais *BSD. Apesar da necessidade de instalar um módulo ao kernel do Linux, sua
instalação é bastante simples.

O arquivo fonte deve ser baixado em http://ecdysis.viagenie.ca/download/ecdysis-nf-nat64-

20101117.tar.gz e descompactado em uma pasta adequada. Na sequência, os seguintes
comandos devem ser executados como root:

1. Após o download, compile o módulo do kernel:

make && make install

2. No arquivo nat64-config.sh, comente as seguintes linhas:

# Load the nf_nat64 module

#modprobe –r nf_nat64

#modprobe nf_nat64 nat64_ipv4_addr=$IPV4_ADDR nat64_prefix_

addr=$PREFIX_ADDR nat64_prefix_len=$PREFIX_LEN

3. Habilite o módulo do kernel:

insmod nf_nat64.ko nat64_ipv4_addr=$IPV4_ADDR nat64_prefix_

addr=$PREFIX_ADDR nat64_prefix_len=$PREFIX_LEN

Os parâmetros usados anteriormente são os seguintes:

Capítulo 9 - Coexistência e transição – Parte 1

11 $IPV4_ADDR = Endereço IPv4 da interface conectada à internet;

11 $PREFIX_ADDR = 64:ff9b::

11 $PREFIX_LEN = 96

4. Verifique, através do comando lsmod, se o módulo foi lido corretamente. A saída do

comando deve ser algo parecido com:

Module Size Used by

nf_nat64 14542 0

5. Rode o arquivo de configuração:

./nat64-config.sh $IPV4_ADDR

163
 6. Verifique se a interface Nat64 está “up”, através do comando ip link.

7. Pode-se testar a conectividade via Nat64 através do comando:

ping6 64:ff9b::200.160.4.22

Para fazer a configuração do NAT64 em roteadores Cisco, os comandos são:

Router> enable

Router# configure terminal

Router(config)# ipv6 unicast-routing

Router(config)# interface gigabitethernet0/0/0

Router(config-if)# description interface towards ipv4 side

Router(config-if)# ipv6 enable

Router(config-if)# ipv6 address 64:ff9b::/96

Router(config-if)# nat64 enable

Router(config-if)# exit

Router(config)# interface gigabitethernet1/2/0

Router(config-if)# description interface towards ipv6 side

Router(config-if)# ip address 192.0.2.0 255.255.255.0

Router(config-if)# nat64 enable

Router(config-if)# exit

Router(config)# nat64 prefix stateless 64:ff9b::/96

Router(config)# nat64 route 192.0.2.0/24 gigabitethernet0/0/1

Router# end

Para o DNS64, as principais opções são o Bind (http://www.isc.org/software/bind), que possui

versões para Linux e Windows, ou o Totd (http://www.dillema.net/software/totd.html), com
versões para Linux e FreeBSD. Por ser mais atual e amplamente usado, o exemplo de con-
figuração será baseado no Bind. Após a instalação do Bind, as seguintes linhas devem ser
adicionadas ao arquivo de configuração:

options {

dns64 64:ff9b::/96 {

clients {any;};

mapped {any;};

suffix ::;

recursive-only yes;
IPv6 Básico

break-dnssec yes;

};

Depois, basta reiniciar o Bind para que a alteração tenha efeito.

164
 É interessante notar que o DNS64 pode apresentar problemas em sua interação com o
DNSSEC. Um validador DNSSEC que não saiba lidar com o DNS64 pode rejeitar todos os
dados que vêm deste, como se não fossem válidos. A RFC 6147, onde o DNS64 é definido,
especifica formas de contornar o problema.

464XLAT
Cenário 1 2 3 4 5 6 7 8 9 10

Suporta Sim Não Não Não Sim Não Não Não Não Não

Tabela 9.9 11 Usa dupla tradução de IPv4 para IPv6 q

O 464XLAT e os
cenários. 11 Oferece IPv4 compartilhado para usuários IPv6 nativos

11 Tradutor stateless – CLAT

11 Tradutor stateful – PLAT

O 464XLAT (draft-ietf-v6ops-464xlat-01) é uma solução similar ao dIVI e ao dIVI-pd, que usa

dupla tradução de IPv4 para IPv6, a fim de oferecer um IPv4 compartilhado para usuários
IPv6 nativos. Essa técnica usa uma tradução stateless e outra stateful. O tradutor stateless
é chamado de CLAT (customer side translator) e faz uma tradução 1:1, ou seja, cada IPv4
Figura 9.32
Diagrama de possui um IPv6 correspondente. O tradutor stateful é o PLAT (provider side translator) e faz
sequência do uma tradução 1:N, onde vários IPv6 globais são representados por um IPv4 global para falar
464XLAT. com a internet IPv4. O funcionamento do 464XLAT é mostrado nas figuras a seguir.

Servidor
Cliente IPv4 CLAT PLAT IPv4

TCP em IPv4
Dst: 200.0.113.1
Org: 192.168.1.2 TCP em IPv6
Dst: 2001:db8:bbbb::200.0.113.1
Org: 2001:db8:aaaa::192.168.1.2

Alocação de um IPv4
do pool de endereços

TCP em IPv4
Capítulo 9 - Coexistência e transição – Parte 1

Dst: 200.0.113.1
Org: 192.0.2.45

TCP em IPv4
Dst: 192.0.2.45
TCP em IPv6 Org: 200.0.113.1

Dst: 2001:db8:aaaa::192.168.1.2
TCP em IPv4 Org: 2001:db8:bbbb::200.0.113.1
Dst: 192.168.1.2
Org: 200.0.113.1

165
 2001:db8:cafe::1
2001:db8:aaaa::1

IPv6 Público
Internet IPv6 Internet IPv4
IPv4 Privado

2001:db8:aaaa:2 CLAT PLAT 203.0.113.1

192.168.1.2

É recomendado que haja um cache DNS implementado no CLAT, capaz de responder às Figura 9.33
solicitações dos clientes IPv4, fazendo as perguntas ao servidor DNS recursivo do provedor Topologia de rede
do 464XLAT.
por meio do protocolo IPv6, evitando assim traduções desnecessárias para esse fim.

O uso da tradução stateless na extremidade do usuário e stateful no provedor não é a

melhor escolha, se levarmos em consideração os princípios básicos de projeto da internet.
O inverso, como feito no dIVI, ou dIVI-pd, é mais recomendável. Contudo, o 464XLAT não é
realmente uma técnica nova, projetada do zero, mas sim uma aplicação inovadora de duas
técnicas já padronizadas e relativamente maduras.

O CLAT é uma tradução stateless baseada na RFC 6145 e funciona de maneira semelhante
ao IVI, mas utiliza IPv4 privado e não público. A forma como o endereço IPv4 é incluído no
endereço IPv6 também é um pouco diferente. A regra de tradução é:

0 96 128
96 bits 32 bits

Figura 9.34
Prefixo XLAT IPv4 (32) Endereço IPv6
traduzido do IPv4
pelo 464XLAT.

Esse prefixo XLAT de 96 bits é único por cliente e é atribuído a este pelo provedor do serviço.
Como o prefixo utilizado é um /96, a autoconfiguração stateless não é possível e é neces- w
sária a utilização de DHCPv6 para a atribuição de endereços. O CLAT pode ser implemen-
tado no CPE ou em celulares. Para a implementação
do CLAT em celulares,
Já o PLAT é um NAT64 (RFC 6146) que converte o endereço IPv6 em um dos endereços IPv4 existe um projeto
disponível para Android
disponíveis no banco de endereços do provedor. Para fazer a sua implementação, basta
em http://code.google.
seguir as recomendações feitas no Capítulo anterior. com/p/androidclat/.
Para a implementação
Testes foram realizados por pelo provedor norte-americano TMobile e o pelo Ponto de em CPE, pode-se
Troca de Tráfego japonês JPIX, em conjunto com seus participantes. Sua implementação em utilizar o IVI (http://
www.ivi2.org/IVI/), com
larga escala está sendo considerada. Os softwares ou implementações do CLAT e XLAT não
as configurações
são vinculadas e diferentes versões de um ou do outro podem ser utilizadas para obter o adequadas.
sistema desejado.

Embora não seja a solução ideal, do ponto de vista técnico, é uma solução que poderá ser
usada em larga escala em breve, pois já existem implementações funcionais de seus compo-
nentes básicos. Outro ponto a considerar é que o 464XLAT pode funcionar em conjunto com
NAT64, já que o PLAT é um NAT64. Basta acrescentar o DNS64 ao sistema. Usuários podem
IPv6 Básico

ser somente IPv6 e usar o NAT64/DNS64, e migrar para a utilização do 464XLAT acrescen-
tando um CPE que execute a função de CLAT, caso haja, por exemplo, aplicações que não
funcionem com o NAT64.

166
 10
Coexistência e transição – Parte 2
objetivos

Apresentar as técnicas de transição do IPv4 para o IPv6.

conceitos
O 4rd; 6PE e 6VPE; 6rd; 6to4; Teredo; ISATAP; A+P; NAT444; Técnicas de tradução:
SIIT, BIS, BIA, TRT, ALG e DNS-ALG; Segurança na transição.

4rd
O 4rd é uma solução similar ao DS-Lite, uma vez que usa túneis 4in6 para fornecer IPs q
versão 4 compartilhados para usuários que já têm IPv6 nativo. Mas, de forma análoga
às técnicas de tradução dIVI e 464XLAT, o 4rd é stateless e usa compartilhamento de IPs
com restrição de portas.

A técnica foi desenvolvida com base no 6rd, que será estudado mais à frente, e está em
processo de padronização, definida atualmente no draft-despres-intarea-4rd-01. Produtos
Figura 10.1
O 4rd em uso: da linha SEIL, do provedor japonês IIJ, também implementam o protocolo. A figura a seguir
similar ao DS-Lite. ilustra uma situação típica de uso do 4rd.

Túnel IPv4 sobre IPv6

IPv4 (rfc1918)
IPv6 (nativo)
Provedor
Pool de IPs V4
para compartilhar
Capítulo 10 - Coexistência e transição – Parte 2

Internet
IPv4

4rd CE 4rd BR
Core IPv6 nativo Stateless A+P
IPv4 válido
compartilhado
com restrição
de portas A+P
Internet
IPv4 (rfc1918) NAT44 IPv6
IPv6 (nativo)

167
 É importante considerar que o 4rd, além de distribuir IPs versão 4 compartilhados com A+P, pode
também distribuir IPs válidos sem restrição de portas, para cada CPE, além de sub-redes IPv4. Existe uma implemen-
tação pública do 4rd
A figura a seguir representa a forma como os endereços IPv4 e IPv6 são mapeados 1:1, que funciona no vyatta
e pode ser encontrada
para o caso em que os endereços IPv4 são compartilhados com A+P. Perceba que o
em http://bougaidenpa.
mapeamento é stateless. org/masakazu/
archives/176.
Prefixo CE 4rd (47 bit max)

Endereço IPv4 compartilhado Port-set ID

15 bit max Sufixo

Prefixo IPv6 do domínio 6rd CE - Index 0 (64bits)

Endereço IPv6 do CE (128 bits)

Para o mapeamento das portas, regras simples foram estabelecidas. As portas baixas, de Figura 10.2
0 a 4096, nunca são designadas a um cliente. O tamanho do port-set-ID pode ir de 1 a 15 bits. Tradução de
endereços feita
Os clientes podem receber de 1 a 4 blocos diferentes de portas, de tamanhos variados, pelo 4rd.
conforme o tamanho do portsetID. Os 16 bits de cada porta disponível são definidos da
seguinte forma:

11 1º bloco: 0001 + port-set-ID (n=1 a 12 bits) + sufixo (que varia de 0 a 12-n);

11 2º bloco: 001 + port-set-ID (n=1 a 13 bits) + sufixo (que varia de 0 a 13-n);

11 3º bloco: 01 + port-set-ID (n=1 a 14 bits) + sufixo (que varia de 0 a 14-n);

11 4º bloco: 1 + port-set-ID (n=1 a 15 bits) + sufixo (que varia de 0 a 15-n). Tabela 10.1
Note que, se o port-set-ID tiver 15 bits, apenas um bloco estará disponível; se tiver 14 bits, 2 blocos; Modos de
compartilhamento
se tiver 13 bits, 3 blocos; e se tiver de 1 a 12 bits, 4 blocos de portas estarão disponíveis. de portas.

Tamanho Quantidade Head=0001 Head=001 Head=01 Head=1 Total Portas

do de IDs 1o. bloco 2o. bloco 3o. bloco 4o. bloco de não utilizadas
port set (CPEs) portas
(bits)

1 2 2048 4096 8192 16384 30720 4096

2 4 1024 2048 4096 8192 15360 4096

3 8 512 1024 2048 4096 7680 4096

4 16 256 512 1024 2048 3840 4096

5 32 128 256 512 1024 1920 4096

6 64 64 128 256 512 960 4096

7 128 32 64 128 256 480 4096

8 256 16 32 64 128 240 4096

9 512 8 16 32 64 120 4096

IPv6 Básico

10 1024 4 8 16 32 60 4096

11 2048 2 4 8 16 30 4096

168
Tamanho Quantidade Head=0001 Head=001 Head=01 Head=1 Total Portas
do de IDs 1o. bloco 2o. bloco 3o. bloco 4o. bloco de não utilizadas
port set (CPEs) portas
(bits)

12 4096 1 2 4 8 15 4096

13 8192 – 1 2 4 7 8192

14 16384 – – 1 2 3 16384

15 32768 – – – 1 1 32768

A configuração dos CPEs pode ser feita manualmente, mas a proposta também define uma
opção de configuração via DHCPv6, que pode ser usada.

Assim como as técnicas dIVI e dIVI-pd, a técnica 4rd tem características praticamente ideais
para uso por provedores de acesso, por isso seu desenvolvimento e padronização devem
ser acompanhados com muita atenção:

11 Opera com base em redes somente IPv6, que é para aonde caminha a internet;

11 Utiliza traduções stateless, que são simples de implementar e baratas do ponto de vista
computacional, permitindo boa escalabilidade;

11 Permitem conexões em ambos os sentidos, mantendo a conectividade de fim a fim;

11 Quando necessário o uso de técnicas stateful, para restrição de portas e compartilhamento

via NAT44, isso é feito no lado do usuário, mantendo o princípio de que a complexidade na
internet deve estar nas extremidades e não próxima ao core da rede.

6PE e 6VPE
Cenário 1 2 3 4 5 6 7 8 9 10

Suporta Não Não Não Não Não Não Não Não Sim Não

Tabela 10.2

q
6PE e 6VPE e os
cenários. 11 6PE – RFC 4798

11 6VPE – RFC 4659

11 Redes IPv6 usam um core MPLS IPv4

11 MBGP sobre IPv4 para trocar rotas IPv6

11 Roteadores de borda são Pilha Dupla

Capítulo 10 - Coexistência e transição – Parte 2

O roteamento através de MPLS tem sido largamente utilizado nas redes dos grandes prove-
dores de conectividade internet. Entretanto, grande parte desses equipamentos já insta-
lados não possuem suporte a IPv6. Dado o alto custo desses equipamentos, pode existir a
necessidade de mantê-los em operação. No intuito de resolver esse problema, podemos usar
as técnicas conhecidas como 6PE e o 6VPE, definidas, respectivamente, nas RFCs 4798 e 4659,
que permitem que redes IPv6 estabeleçam a comunicação por meio de um core MPLS IPv4,
usando Label Switch Paths (LSPs). Sua implementação usa Multiprotocol BGP (MBGP) sobre
IPv4 para trocar rotas IPv6 e necessita que os PEs (Roteador de Borda) sejam Pilha Dupla.
Através do MBGP os roteadores de borda recebem as rotas IPv6, mas aplicam MPLS IPv4
sobre os pacotes para realizar o roteamento. Quando o pacote chegar à rede IPv6 de destino,
o cabeçalho MPLS é removido e o pacote é encaminhado normalmente através do IPv6.

169
 A diferença entre o 6PE e o 6VPE é que, no primeiro caso, os roteadores mantêm apenas
uma tabela global de roteamento, de forma que o 6PE é mais indicado para provimento de
conectividade internet. Já os roteadores 6VPE são capazes de manter várias tabelas de rote-
amento separadas logicamente, de forma que a técnica é apropriada para prover serviços
de redes privadas (VPNs). A seguir o diagrama que explica o funcionamento do 6PE.

Figura 10.3
Topologia de
rede 6PE.
MPLS
IPv4

Pilha dupla Pilha dupla

IPv6 e IPv4 IPv6 e IPv4

PE PE
Pilha Dupla Pilha Dupla

Tabela 10.3
6rd 6rd e os cenários.

Cenário 1 2 3 4 5 6 7 8 9 10

Suporta Não Não Não Não Não Não Não Não Sim Não

11 6rd – RFC 5569 q

11 Operadora funciona em IPv4

11 Usuário acessa redes IPv6

O 6rd tem o objetivo de permitir ao usuário final ter conexão com as redes IPv6 apesar de a
rede da operadora continuar funcionando em IPv4.

O 6rd (RFC5569) é uma extensão da técnica 6to4, que está em desuso e será melhor expli-
cada a seguir. O 6rd resolve algumas das limitações técnicas do 6to4, como, por exemplo,
sua assimetria e a falta de controle sobre os relays utilizados, permitindo sua utilização em
larga escala.

Para entender o funcionamento do 6rd, pode-se observar a figura a seguir, que ilustra a
topologia típica de uso. Esse tipo de técnica,
assim como o
6PE/6VPE, permite que
os provedores usem a
infraestrutura IPv4 já
CPE Internet existente para fazer
6rd IPv4 uma implantação
rápida do IPv6.
Rede Relay
IPv4 6rd

2001:db8:cb00:7101::1
203.0.113.1 Figura 10.4
Internet
IPv6 Básico

Túnel 6over4 Topologia de

IPv6 rede 6rd.

170
 Analisando a figura, é possível notar que o 6rd depende basicamente de dois componentes:

11 CPE 6rd: instalado como interface entre a rede da operadora e do usuário;

11 Relay 6rd: instalado na interface entre a rede IPv4 da operadora e a internet IPv6.

O CPE 6rd é um CPE tradicional (xDSL modem, cable modem, 3G modem etc.), cujo software
foi modificado para permitir o uso do 6rd. A necessidade dessa modificação dificulta a
implementação da técnica, uma vez que requer a substituição, lógica ou física, de equipa-
mentos em campo. Tal modificação nos CPEs normalmente é viável nos casos em que o
provedor gerencia remotamente o equipamento, sendo capaz de fazer upgrades em seu
firmware. O 6rd relay é um equipamento que vai encapsular e desencapsular pacotes para
trafegarem corretamente nas redes IPv4 e IPv6.

O CPE 6rd atribui ao usuário um endereço IPv4, como um CPE normal. Entretanto, um ende-
reço IPv6 também é atribuído ao usuário. Esse endereço IPv6 é um endereço IPv6 público
válido, mas é construído de maneira específica para que o relay 6rd identifique-o como um
endereço 6rd. O endereço IPv6 atribuído é constituído da seguinte forma:

0 n n+o n+o+m 128

n bits 0 bits m bits 128-(n+o+m) bits

6rd prefixo IPv4 endereço ID subrede ID interface

Prefixo delegado 6rd

Figura 10.5 No 6rd o tamanho do prefixo e o tamanho do endereço IPv4, que formam o prefixo dele-
Tradução de gado 6rd, são escolhas do provedor de acesso. Para permitir que a autoconfiguração de
endereço IPv4 para
IPv6 no 6rd. endereço stateless funcione, é necessário que o tamanho desse prefixo n + o seja menor
que 64 bits. O ID sub-rede de tamanho m pode ser definido pela operadora, mas é mais
provável que a operadora deixe a definição do valor e tamanho do campo para o usuário
final adequar às necessidade de sua rede.

Normalmente utiliza-se n=32, o=32 e m=0. Pode-se, contudo, aumentar o número de

bits utilizados por n para além de 32, forçando o endereço IPv4 a usar parte dos 64 bits
menos significativos, o que impede o funcionamento da autoconfiguração stateless. Para
evitar que isso ocorra, o endereço IPv4 pode ocupar menos de 32 bits. Tal configuração
é possível se os endereços IPv4 fizerem parte de uma mesma rede, pois pode-se omitir o
seu prefixo desta. Por exemplo, se todos os endereços IPv4 forem da rede 198.51.0.0/16,
os 16 bits que representam os números 198 e 51 podem ser omitidos e a representação do
endereço IPv4 necessitará somente de 16 bits, em vez dos 32 bits necessários para repre-
Capítulo 10 - Coexistência e transição – Parte 2

sentar o endereço completo.

O 6rd é uma técnica funcional cuja implementação em massa foi testada com sucesso no
provedor francês Free. Entretanto, a técnica não tem sido adotada por outros, principal-
mente pela necessidade de atualização do software ou de substituição dos CPEs.

Para configurar o CPE e o roteador de borda com Linux, é necessário pelo menos o kernel
mínimo 2.6.33 e as configurações para isso são:

171
 Roteador relay 6rd:

ip tunnel add paraDentro mode sit local 203.0.113.1 ttl 64

ip tunnel 6rd dev paraDentro 6rd-prefix 2001:db8::/32

ip link set paraDentro up

ip -6 route add 2001:db8:cb00:7101::/64 dev paraDentro

ip -6 route add 2001:db8::/32 dev paraDentro

ip -6 route add 2000::/3 dev eth1

Roteador CPE 6rd:

ip -6 addr add 2001:db8:cb00:7182::/64 dev eth0

ip tunnel add paraFora mode sit local 203.0.113.130 ttl 64

ip tunnel 6rd dev paraFora 6rdprefix 2001:db8::/32

ip link set paraFora up

ip -6 addr add 2001:db8:cb00:7182::1/128 dev paraFora

ip -6 route add ::/96 dev paraFora

ip -6 route add 2000::/3 via ::203.0.113.1

Configurando o 6rd com equipamentos Cisco os comandos seriam:

Roteador relay 6rd:

ipv6 general-prefix DELEGATED_PREFIX 6rd Tunnel0

interface Loopback0

ip address 203.0.113.1 255.255.255.0

interface Tunnel0

tunnel source Loopback0

tunnel mode ipv6ip 6rd

tunnel 6rd ipv4 prefix-len 8

tunnel 6rd prefix 2001:db8::/32

ipv6 address DELEGATED_PREFIX::/128 anycast

ipv6 route 2001:db8::/32 Tunnel0

ipv6 route 2001:db8:cb00:7101::/64 Null0

Roteador CPE 6rd:

IPv6 Básico

ipv6 general-prefix DELEGATED_PREFIX 6rd Tunnel0

interface Dialer0

172
 ip address dhcp ! (203.0.113.130)

interface Tunnel0

tunnel source Dialer0

tunnel mode ipv6ip 6rd

tunnel 6rd ipv4 prefix-len 8

tunnel 6rd prefix 2001:db8::/32

tunnel 6rd br 203.0.113.1

ipv6 address DELEGATED_PREFIX ::/128 anycast

interface Ethernet0

ipv6 address DELEGATED_PREFIX ::/64 eui-64

ipv6 route 2001:db8::/32 Tunnel0

ipv6 route ::/0 Tunnel0 2001:db8:cb00:7101::

ipv6 route 2001:db8:cb00:7182::/64 Null0

Já para fazer essa

w Éinternet,
importante deixar claro que o 6rd não é uma técnica para ser usada em novos usuários
mas sim para os usuários já existentes, de forma a conseguir uma implantação muito
configuração em rápida do IPv6. O 6rd funciona com base numa rede IPv4 e não resolve o problema da escassez
roteadores Juniper é
possível encontrar um de endereços. Técnicas escolhidas para novos usuários internet devem preferencialmente
exemplo em http:// basear-se em redes IPv6 e, quando necessário, preservar endereços IPv4, compartilhando-os.
www.juniper.net –
Junos OS Services Inter-
faces Configuration 6to4
Guide.
11 O prefixo 6to4 é sempre 2002. q
11 O próximo campo, IPv4 público do cliente, é criado com a conversão do endereço
para hexadecimal.

11 O ID da sub-rede pode ser usado para segmentar a rede IPv6 6to4 em até 216 sub-redes,
com 264 endereços cada, como por exemplo 0, 1, 2, 3, 4...
Capítulo 10 - Coexistência e transição – Parte 2

11 O ID da interface pode ser igual ao segundo campo (o Windows faz assim) ou qualquer
outro número no caso de configuração manual (no Linux, usa-se sequencial: 1, 2, 3, 4...).

Cenário 1 2 3 4 5 6 7 8 9 10

Suporta Não Não Não Não Não Não Não Não Sim Não

Tabela 10.4 O 6to4 (RFC 3056) é umas das técnicas de transição mais antigas em uso e é a técnica que
6to4 e os cenários. inspirou a criação do 6rd. Sua concepção era simples e muito interessante: com a ajuda de relays

173
 Pilha Dupla distribuídos na internet, abertos, instalados de forma colaborativa por diversas
redes, qualquer rede IPv4 poderia obter conectividade IPv6, através de túneis 6in4 automáticos.

Por meio do 6to4 qualquer computador com um IPv4 válido poderia funcionar como uma
extremidade de um conjunto de túneis automáticos e prover todo um bloco IPv6 /48 para
ser distribuído e usado em uma rede.

A técnica funcionou parcialmente e ainda é usada na internet, mas apresenta diversos pro-
blemas. De fato, talvez tenha trazido mais problemas para a implantação do IPv6, de forma
geral, do que ajudado. O 6to4 é composto pelos seguintes elementos:

11 Relay 6to4: roteador com suporte ao 6to4 e que possui conexão nativa IPv4 e IPv6.
Funciona como a extremidade dos túneis automáticos para os Roteadores 6to4 que
precisam se comunicar com a internet IPv6. Os relays 6to4 usam o endereço anycast IPv4
192.88.99.1 e anunciam rotas para 2002::/16 através deles, para a internet;

11 Roteador 6to4: roteador que suporta 6to4, que fica na extremidade de uma rede IPv4,
e é responsável por trazer conectividade IPv6 para essa rede, por meio dos túneis 6to4.
No caso dos acessos à internet IPv6, ele direcionará o tráfego até o Relay Router mais
próximo, que encaminhará o pacote ao seu destino. Para acesso a outras redes 6to4, os
túneis são fechados diretamente com outros Roteadores 6to4;

11 Cliente 6to4: equipamento de rede ou computador que usa endereços IPv6 fornecidos
pelo túnel 6to4. O cliente 6to4 é um cliente Pilha Dupla convencional, normalmente numa
rede doméstica ou corporativa, que pode usar IPv4 nativo ou compartilhado. O cliente
não diferencia um endereço IPv6 obtido via 6to4 de um endereço IPv6 nativo.

As funções de Roteador e Cliente 6to4 podem estar presentes no mesmo equipamento. Um

desktop convencional, por exemplo, usando Windows Vista, atua de forma automática como
Roteador 6to4, desde que tenha um endereço IPv4 válido disponível.

O endereçamento 6to4, conforme definição da IANA, usa o prefixo de endereço global

2002:wwxx:yyzz::/48, onde wwxx:yyzz é o endereço IPv4 público do cliente convertido para
hexadecimal. O exemplo a seguir mostra como fazer a conversão de endereços:

Endereço IPv4: 200.192.180.002.

200=C8

192=C0

180=B4

002=02

Com isso, o bloco IPv6 correspondente, via 6to4, é 2002:C8C0:B402::/48. A figura a seguir
mostra a estrutura do endereço 6to4. Figura 10.6
Estrutura do
endereço 6to4.
0
16 bits 32 bits 16 bits 64 bits

2002 C8CO:B402 ID subrede ID interface

q
IPv6 Básico

A figura e tabela a seguir demonstram o fluxo dos pacotes em uma rede 6to4. É impor-
tante notar que não existe a necessidade de uma rede e dos pacotes irem e voltarem
pelo mesmo relay 6to4. As etapas 1, 3, 4 e 6 usam pacotes IPv6, e as etapas 2 e 5 utilizam
pacotes IPv6 encapsulados em IPv4 através do protocolo 41.

174
 RL1
Relay 6to4
C2 Cliente 6to4 1.2.3.6
2002:0102:0304:1::2 192.88.99.1 2001.1111::1
R1
3
Roteador 6to4 2 R3
6 1

1.2.3.4 Internet Internet

Rede IPv6 IPv4 IPv6
5 S2
4
2002:0102:0304:1::1 Servidor IPv6
1.2.3.7 2001.2222::1 2001.2222::2
C1 Cliente 6to4
192.88.99.1
2002:0102:0304:1::3
RL2
Relay 6to4
Figura 10.7
Topologia e
funcionamento do
túnel 6to4.

Equipamento Rota

RL1 ::/0 rede IPv6 por meio da interface LAN / 2002::/16 através da interface virtual 6to4

RL2 ::/0 rede IPv6 através da interface LAN / 2002::/16 por meio da interface virtual 6to4

S2 Rota padrão através de R3

R3 2002::/16 através do Relay RL2 (rota descoberta por meio da divulgação via BGP)

R1 ::/0 através do Relay 6to4 RL1 ou RL2 utilizando a interface virtual 6to4
2002::/16 por meio da interface virtual 6to4
2002:0102:0304:1/64 para a rede local através da interface LAN

C1 ::/0 através de R1 / 2002:0102:0304:1::/64 por meio da interface LAN

C2 ::/0 através de R1 / 2002:0102:0304:1::/64 por meio da interface LAN

Tabela 10.5 Etapas:

Fluxo de pacotes
em uma rede 6to4. 11 1: de acordo com a tabela de roteamento, o pacote é enviado através da rede local IPv6
para o roteador R1 utilizando a rota ::/0;

11 2: o pacote IPv6 é recebido por R1 através da interface LAN, que verifica sua tabela de
roteamento e descobre que deve enviar o pacote para a interface virtual 6to4 (rota para a
Capítulo 10 - Coexistência e transição – Parte 2

rede 2002::/16). Nessa interface o pacote IPv6 é encapsulado em um pacote IPv4 (proto-
colo tipo 41) e enviado ao Relay RL1 ou RL2 (O Relay 6to4 pode ser definido manualmente
no roteador 6to4 ou então automaticamente através da utilização do endereço anycast
192.88.99.1). Vamos supor que o pacote foi enviado para o Relay RL1;

11 3: RL1 recebe o pacote 6to4 através de sua interface IPv4, vê que o pacote utiliza o proto-
colo 41 e o encaminha para a interface virtual. Esta desencapsula o pacote IPv6 e verifica
na sua tabela de roteamento que deve enviá-lo pela interface LAN através do roteador
R3, que simplesmente repassa o pacote IPv6 ao servidor S2;

11 4: S2 responde com o envio de outro pacote IPv6 com destino ao Cliente C2 utilizando a
sua rota padrão, que aponta para o roteador R3. Então R3 recebe o pacote e, através da
rota recebida via BGP, sabe que deve enviá-lo para o relay mais próximo, que é RL2;

175
 11 5: RL2 recebe o pacote IPv6 e verifica que o destino é a rede 6to4 (2002::/16). Desse
modo, de acordo com sua tabela de roteamento, ele encaminha o pacote para a interface
virtual 6to4, que o empacota em um pacote IPv4 (protocolo 41) e o envia ao endereço
IPv4 implícito no endereço IPv6 do destinatário do pacote;

11 6: o roteador R1 recebe o pacote através de seu endereço IPv4, verifica que o pacote está
utilizando o protocolo 41 e o encaminha à interface virtual 6to4. Esta o desencapsula e
verifica o endereço de destino. De acordo com sua tabela de roteamento e o endereço de
destino, o pacote IPv6 é enviado através da sua interface LAN para o Cliente 6to4 C2.

Entre os problemas que afetam o 6to4, podemos citar problemas de qualidade com relays
públicos e problemas de segurança. Alie-se a isso o fato de que diversos Sistemas Operacio-
nais suportam túneis 6to4 de forma automática, entre eles o Windows XP, o Windows Vista
e o Windows 7. O fato de os Sistemas Operacionais ativarem os túneis 6to4 sem intervenção
ou conhecimento dos usuários traz algumas consequências sérias. Uma delas é que firewalls
ou outras medidas de segurança em redes corporativas podem ser inadvertidamente con-
tornadas. Outra, é que, via túnel, os pacotes podem seguir caminhos mais longos, trazendo
uma experiência pior para o usuário, em comparação àquela que ele teria se estivesse sim-
plesmente usando IPv4. Um agravante é que não há relays públicos 6to4 no Brasil, ocasio-
nando a ida do pacote para localidades distantes como América do Norte ou Europa, mesmo
que a origem e o destino estejam no país.

Provedores de conteúdos e serviços na internet podem sofrer com a questão, pois ao

implantar o IPv6 em um servidor web, por exemplo, usuários que antes o acessavam bem via
IPv4 podem passar a fazê-lo de forma lenta e instável, via IPv6 obtido automaticamente por
meio de um túnel automático 6to4. Isso já foi motivo para adiamento da implantação do IPv6,
mas atualizações dos Sistemas Operacionais têm mudado seu comportamento e o número de
usuários potencialmente afetados diminuiu para patamares muito pequenos e aceitáveis.

Ainda assim, é recomendável agir para mitigar esse problema, principalmente porque existe
uma medida bastante simples e efetiva, que pode ser utilizada. Deve-se lembrar que o
caminho de ida do 6to4 pode ser diferente do caminho de volta. Isso permite que um relay
6to4 seja criado em um servidor web, ou em uma rede, com o objetivo de responder as
requisições recebidas via 6to4. O relay não deve ser público; apenas servirá para responder
às requisições dirigidas ao serviço advindas de clientes 6to4. A implementação desse relay
não reduzirá o tempo gasto para receber pacotes 6to4, mas garante que os pacotes 6to4 de
resposta saiam da rede com destino ao originador da requisição, já encapsulados em IPv4, e
isso dará a vantagem do tempo de resposta ser consideravelmente reduzido, já que não será
necessário o pacote ir até o relay localizado no exterior. Essa redução pode melhorar bastante
a experiência de acesso de um usuário que use 6to4 para acessar um serviço qualquer.

Para implementar esse relay é necessário que os roteadores de borda da rede permitam a
saída de pacotes com IP de origem 192.88.99.1. Provavelmente isso estará bloqueado por
padrão na rede, já que esse IP não faz parte do bloco a ela designado. É preciso verificar
também se o provedor de upstream não está filtrando também esse endereço. Normal-
mente, se a rede em questão for um AS, com bloco próprio, o upstream não terá filtros
antispoofing. Caso contrário, terá. Com a liberação do endereço, basta configurar o próprio
servidor web, ou um outro elemento na rede, para fazer o encapsulamento das respostas
usando 6to4. No Linux a configuração é:
IPv6 Básico

ip tunnel add tunel6to4 mode sit ttl 64 remote any local 192.88.99.1

ip link set dev tunel6to4 up

176
 ip addr add 192.88.99.1/24 dev lo

ip -6 addr add 2002:c058:6301::/16 dev tunel6to4

ip link set lo up

Para redes corporativas, é recomendável bloquear o protocolo 41 para evitar a utilização

de túneis automáticos IPv4 pelos usuários. É possível também desabilitar essa função no
Windows. Para isso, deve ser criada e configurada uma chave de registro, do tipo DWORD:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\
Parameters\DisabledComponents

Ao fazer isso, a chave será criada com o valor 0x00. O bit 1 (do menos significativo para o
mais significativo) deve ser mudado para 1, para desabilitar o 6to4. Ou seja, o valor da chave
deve passar a ser 0x01. A função de todos os bits é descrita a seguir. Note que 0 é o valor
padrão e significa que a função está ativa, 1 desativa a função:

bit 0: todos os túneis IPv6, incluindo ISATAP, 6to4 e Teredo;

bit 1: 6to4

bit 2: ISATAP

bit 3: Teredo

bit 4: interfaces IPv6 reais

bit 5: preferência por IPv4 e não IPv6

O 6to4 é, então, um protocolo com histórico importante, mas cujo uso deve ser evitado
atualmente. Deve-se desativá-lo em redes corporativas e bloqueá-lo nos firewalls. Contudo,
para redes Pilha Dupla que têm serviços IPv6 públicos na internet, principalmente servi-
dores web, é recomendada a instalação de um relay 6to4 para responder a solicitações de
usuários externos usando essa tecnologia, mitigando parte dos problemas trazidos por esta.

Teredo
11 Encapsula o pacote IPv6 em pacotes UDP. q
11 Funciona através de NAT tipo Cone e Cone Restrito.

11 Envia pacotes bubles periodicamente ao servidor para manter as configurações

iniciais da conexão UDP.

11 Seu funcionamento é complexo e apresenta overhead.

Capítulo 10 - Coexistência e transição – Parte 2

Cenário 1 2 3 4 5 6 7 8 9 10

Suporta Não Não Não Não Não Não Não Não Sim Não

Tabela 10.6 A técnica de tunelamento automática Teredo, criada pela Microsoft e definida na RFC 4380,
Teredo e os permite que nós localizados atrás de Network Address Translations (NAT), obtenham
cenários.
conectividade IPv6 utilizando tunelamento em IPv4, usando o protocolo UDP.

Sua utilização não é recomendada, uma vez que não é muito eficiente, tem alta taxa de falhas
e algumas considerações de segurança. Contudo, é importante conhecê-la bem, já que está
implementada e é utilizada de forma automática em algumas versões do Windows. Com o
uso de túneis automáticos, mesmo que a rede não tenha o IPv6 implantado, usuários podem

177
 ter endereços IPv6 em seus dispositivos, inclusive com capacidade para receber conexões
entrantes, contornando mecanismos e regras de segurança existentes no ambiente.

Existem dois elementos importantes no Teredo, o Servidor Teredo e o Relay Teredo. A conexão
é realizada através de um Servidor Teredo, que a inicia após determinar o tipo de NAT usado
na rede do cliente. Em seguida, caso o nó destino possua IPv6 nativo, um Relay Teredo é usado
para criar uma interface entre o cliente e o nó destino. O Relay utilizado será sempre o que
estiver mais próximo do nó destino e não o mais próximo do cliente.

Os Servidores Teredo utilizam a porta UDP 3544 para comunicar-se com os dispositivos.
Bloquear pacotes IPv4 enviados de uma rede para a internet nessa porta e na direção
inversa é uma forma efetiva para evitar a utilização indesejada, muitas vezes involuntária,
desse tipo de túneis.

Por padrão, os Windows 7 e Vista já trazem o Teredo instalado e ativado por padrão,
enquanto que no Windows XP, 2003 e 2008, ele vem apenas instalado. Quanto ao FreeBSD
e ao Linux, ele não vem instalado. Caso seu uso seja desejado, é possível usar um software
chamado miredo.

Para iniciar o túnel, existe uma comunicação entre o cliente e o Servidor Teredo com a fina-
lidade de identificar o tipo de NAT usado na rede. Para isso são usados dois IPs versão 4 no
servidor. O Teredo é capaz de funcionar com NAT do tipo Cone, também chamado de
NAT Estático e NAT Cone Restrito, também conhecido como NAT Dinâmico, mas não fun-
ciona com NAT Simétrico.

Para facilitar a compreensão do funcionamento desse tipo de túnel, apresentaremos no

quadro a seguir um resumo dos quatro tipos de NAT existentes:

11 NAT Cone: todas as requisições originadas de um mesmo endereço e porta internos são
mapeadas para uma mesma porta do NAT. Com isso, é preciso apenas conhecer o ende-
reço público do NAT e a porta associada a um nó interno para que um nó externo esta-
beleça uma comunicação, não importando seu endereço ou porta, podendo assim enviar
arbitrariamente pacotes para o nó interno. É também conhecido como NAT Estático;

11 NAT Cone Restrito: todas as requisições originadas de um mesmo endereço e porta

internos são mapeadas para uma mesma porta do NAT. No entanto, o acesso externo é
permitido apenas em respostas a requisições feitas previamente, sendo que o endereço
do nó externo, que está respondendo a requisição, deve ser o mesmo utilizado como
endereço de destino da requisição. É também conhecido como NAT Dinâmico;

11 NAT Cone Restrito por Porta: possui as mesmas características de mapeamento do

NAT Cone Restrito, embora a restrição para a comunicação considere também a porta
do nó externo. Com isso, um nó externo só poderá estabelecer uma comunicação
com um nó interno se este último tiver lhe enviado previamente um pacote através da
mesma porta e endereço;

11 NAT Simétrico: além de possuir as mesmas restrições do NAT tipo Cone Restrito por
Porta, cada requisição realizada, a partir de um endereço e porta internos, para um ende-
reço e porta externos, é mapeada unicamente no NAT. Ou seja, se o mesmo endereço
interno envia uma requisição com a mesma porta, porém para um endereço de destino
diferente, um mapeamento diferente será criado no NAT. Esse tipo de NAT é também
IPv6 Básico

conhecido como NAT Masquerade ou NAT Stateful.

178
 Se o pacote passar
pelo NAT, ele é do Responde utilizando
Cliente Teredo tipo Cone restrito NAT IP diferente Servidor Teredo

Flag Cone=1 IPv4-1

1 Porta-1
IPv4-2

Flag Cone=0 IPv4-1

2 Porta-2
IPv4-1

Flag Cone=0 IPv4-2

3 Porta-3
IPv4-2

Rede IPv4 Internet IPv4

Simétrico se Se o pacote passar Responde utilizando
porta-2 != porta-3 pelo NAT, ele é do o mesmo IP
tipo Cone full

Figura 10.8 Uma vez identificado o tipo de NAT, o cliente constrói seu endereço IPv6, conforme a
Definição do tipo de figura a seguir:
túnel Teredo.

0
32 bits 32 bits 16 bits 16 bits 32 bits

Porta ext. Endereço externo

Prefixo Teredo IPv4 do servidor Teredo Flags mascarada mascarado

Figura 10.9 O prefixo é sempre 2001:0000::/32. As Flags servem para identificar o tipo de NAT.

q
Tradução de
endereço IPv4 para 11 Teredo utiliza o prefixo 2001:0000::/32
IPv6 no Teredo.
11 Os 32 bits seguintes contêm o endereço IPv4 do servidor Teredo.

11 Os 16 bits seguintes são utilizados para definir flags que indicam o tipo de NAT utili-
zado e introduzem uma proteção adicional ao nó contra ataques de scan.

11 Os próximos 16 bits indicam a porta UDP de saída do NAT.

11 Os últimos 32 bits representam o endereço IPv4 público do servidor NAT.

A figura a seguir representa o estabelecimento do túnel Teredo na situação mais complexa

Capítulo 10 - Coexistência e transição – Parte 2

possível, quando o cliente está numa rede com NAT Cone Restrito. Note que, no estabeleci-
mento do túnel, os primeiros pacotes fluem através do Servidor Teredo. Uma vez estabele-
cido o túnel, toda a comunicação é feita através do Relay, bidirecionalmente.

179
 Servidor Teredo

Cliente
Teredo
1 5
Rede IPv4 2 Servidor IPv6

Internet IPv4 Internet IPv6

4
3
7 6

8 9

Relay Teredo

Além de bloquear a porta UDP 3544, para evitar a criação de túneis Teredo, estes podem ser Figura 10.10
desabilitados no próprio Windows. Para isso, deve ser criada e configurada uma chave de Estabelecimento de
túnel Teredo.
registro, do tipo DWORD:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\
Parameters\DisabledComponents

Ao fazer isso, a chave será criada com o valor 0x00. O bit 2 (do menos significativo para o
mais significativo) deve ser mudado para 1, para desabilitar o Teredo. Ou seja, o valor da
chave deve passar a ser 0x02. A função de todos os bits é descrita a seguir. Note que 0 é o
valor padrão e significa que a função está ativa, 1 desativa a função:

bit 0: todos os túneis IPv6, incluindo ISATAP, 6to4 e Teredo;

bit 1: 6to4

bit 2: ISATAP

bit 3: Teredo

bit 4: interfaces IPv6 reais

bit 5: preferência por IPv4 e não IPv6

Baseado nas mensagens RA recebidas dos servidores, o cliente constrói seu endereço IPv6,
usando o seguinte padrão:

11 Os bits 0 a 31 são o prefixo do Teredo recebido do servidor através das mensagens RA;
o padrão é 2001:0000;

11 Os bits 32 a 63 são o endereço IPv4 primário do servidor Teredo que enviou a primeira
mensagem RA;

11 Os bits 64 a 79 são utilizados para definir algumas flags. Normalmente, somente o bit
mais significativo é usado, e ele é marcado como 1 se o cliente está atrás de NAT do tipo
Cone. Caso contrário, é marcado como 0. Apenas o Windows Vista e Windows Server
2008 usam todos os 16 bits, que seguem o formado “CRAAAAUG AAAAAAAA”, onde
“C” continua sendo a flag Cone; o bit R é reservado para uso futuro; o bit U define a flag
Universal/Local (o padrão é 0); o bit G define a flag Individual/Group (o padrão é 0); e os
IPv6 Básico

12 bits “A” são randomicamente determinados pelo cliente para introduzir uma proteção
adicional ao nó contra ataques de scan;

180
 11 Os bits 80 a 95 são a porta UDP de saída do NAT, recebida nas mensagens RA e masca-
rada através da inversão de todos os seus bits. Esse mascaramento é necessário porque
alguns NATs procuram portas locais dentro dos pacotes e os substituem pela porta
pública ou vice-versa;

11 Os bits 96 a 127 são o endereço IPv4 público do servidor NAT, mascarado através da
inversão de todos os seus bits. Esse mascaramento é necessário porque alguns NATs
procuram endereços IPs locais dentro dos pacotes e os substituem pelo endereço público
ou vice-versa.

Se o pacote passar Se o pacote passar Responde

pelo NAT, ele é do pelo NAT, ele é do utilizando
tipo Cone restrito tipo Cone full IP diferente

Rede local Internet

IPv4 IPv4
Cliente
Teredo Flag Cone=1 IPv4-1
1 Porta-1 Servidor Teredo
IPv4-2
Flag Cone=0 IPv4-1
IPv4-1
2 Porta-2
IPv4-1
IPv4-1
Flag Cone=0 IPv4-2
IPv4-2
3 Porta-3
IPv4-2
IPv4-2
NAT
Simétrico se Responde
porta-2=porta-3 utilizando
o mesmo IP
Figura 10.11
Inicialização do
Teredo. Passos de inicialização do Teredo:

11 1: uma mensagem Router Solicitation (RS) é enviada ao servidor Teredo 1 (servidor

primário) com a flag de NAT tipo Cone ativado. O servidor Teredo 1 então responde com
uma mensagem de Router Advertisement (RA). Como a mensagem RS estava com o Cone
flag ativado, o servidor Teredo 1 envia a mensagem RA utilizando um endereço IPv4 alter-
nativo. Com isso, o cliente conseguirá determinar se o NAT que está utilizando é do tipo
Cone, se ele receber a mensagem de RA;

11 2: se a mensagem RA do passo anterior não for recebida, o cliente Teredo envia outra
mensagem RS, mas agora com o Cone flag desativado. O servidor Teredo 1 responde
novamente com uma mensagem RA, mas como o Cone flag da mensagem RS estava
desativado, ele responde usando o mesmo endereço IPv4 em que recebeu a mensagem
RS. Se agora o cliente receber a mensagem de RA, então ele conclui que está utilizando
Capítulo 10 - Coexistência e transição – Parte 2

NAT do tipo restrita;

11 3: para ter certeza de que o cliente Teredo não está usando um NAT do tipo simétrico,
ele envia mais uma mensagem RS, mas agora para o servidor secundário Teredo 2, que
responde com uma mensagem do tipo RA. Quando o cliente recebe a mensagem RA do
servidor Teredo 2, ele compara o endereço e a porta UDP de origem contidos na men-
sagem RA recebida dos dois servidores; se forem diferentes, o cliente conclui que está
usando NAT do tipo simétrico, que não é compatível com o Teredo.

181
 Servidor IPv6

Servidor Teredo 2
6
3
Internet
IPv6

Internet Relay Teredo

1 IPv4

4 5

NAT

Rede Local
IPv4 Figura 10.12
Comunicação
por meio de NAT
Cliente Teredo tipo Cone.

Passos para a comunicação através de NAT tipo Cone:

11 1: para iniciar a comunicação, primeiro o cliente Teredo tem de determinar o endereço

IPv4 e a porta UDP do relay Teredo que estiver mais próximo do host IPv6. Para isso, ele
envia uma mensagem ICMPv6 Echo Request para o host IPv6 via o seu servidor Teredo;

11 2: o servidor Teredo recebe a mensagem ICMPv6 Echo Request e a encaminha para o

host IPv6 através da rede IPv6;

11 3: o host IPv6 responde ao cliente Teredo com uma mensagem ICMPv6 Echo Reply, que é
roteada através do relay Teredo mais próximo dele;

11 4: o relay Teredo então encapsula a mensagem ICMPv6 Echo Reply e envia diretamente
ao cliente Teredo. Como o NAT utilizado pelo cliente é do tipo Cone, o pacote enviado pelo
relay Teredo é encaminhado para o cliente Teredo;

11 5: como o pacote retornado pelo relay Teredo contém o endereço IPv4 e a porta UDP
utilizada por ele, o cliente Teredo extrai essas informações do pacote. Depois disso, um
pacote inicial é encapsulado e enviado diretamente pelo cliente Teredo para o endereço
IPv4 e porta UDP do relay Teredo;

11 6: o relay Teredo recebe esse pacote, remove o cabeçalho IPv4 e UDP e o encaminha para
o host IPv6. Depois disso, toda a comunicação entre o cliente Teredo e o host IPv6 é feita
via o relay Teredo através desse mesmo método.
IPv6 Básico

182
 Servidor IPv6

Tráfego IPv6
Servidor Teredo 2
9
3
Internet
IPv6
4

Pacotes IPv6 encapsulados em UDP/IPv4

Internet Relay Teredo
5 IPv4 6
1
7
8

NAT

Rede Local
IPv4
Figura 10.13
Comunicação
por meio de NAT
restrito. Cliente Teredo

Passos para a comunicação através de NAT restrito:

11 1: para iniciar a comunicação, primeiro o cliente Teredo tem de determinar o endereço

IPv4 e a porta UDP do relay Teredo que estiver mais próximo do host IPv6; para isso, ele
envia uma mensagem ICMPv6 Echo Request para o host IPv6 via o seu servidor Teredo;

11 2: o servidor Teredo recebe a mensagem ICMPv6 Echo Request e a encaminha para o

host IPv6 através da rede IPv6;

11 3: o host IPv6 responde ao cliente Teredo com uma mensagem ICMPv6 Echo Reply que é
roteada através do relay Teredo mais próximo dele;

11 4: através do pacote recebido, o relay Teredo descobre que o cliente Teredo está utili-
zando um NAT do tipo restrito; sendo assim, se o relay Teredo enviar o pacote ICMPv6 dire-
tamente para o cliente Teredo, ele será descartado pelo NAT porque não há mapeamento
pré-definido para tráfego entre o cliente e o relay Teredo. Com isso, o relay Teredo envia
um pacote Bubble para o cliente Teredo através do servidor Teredo, usando a rede IPv4;

11 5: o servidor Teredo recebe o pacote Bubble do relay Teredo e o encaminha para o cliente
Teredo, mas coloca no indicador de origem o IPv4 e a porta UDP do relay Teredo. Como
Capítulo 10 - Coexistência e transição – Parte 2

já havia um mapeamento de tráfego entre o servidor Teredo e o cliente Teredo, o pacote

passa pelo NAT e é entregue ao cliente Teredo;

11 6: o cliente Teredo extrai do pacote Bubble recebido o IPv4 e a porta UDP do relay Teredo
mais próximo do host IPv6; com isso, o cliente Teredo envia um pacote Bubble para o
relay Teredo, para que seja criado um mapeamento de conexão entre eles no NAT;

11 7: baseado no conteúdo do pacote Bubble recebido, o relay Teredo consegue determinar

que corresponde ao pacote ICMPv6 Echo Reply, que está na fila para a transmissão.
Também determina que a passagem através do NAT restrito já está aberta e, sendo
assim, encaminha o pacote ICMPv6 Echo Reply para o cliente Teredo;

11 8: depois de recebido o pacote ICMPv6, um pacote inicial é então enviado do cliente

Teredo para o host IPv6 através do relay Teredo mais próximo dele;

183
 11 9: o relay Teredo remove os cabeçalhos IPv4 e UDP do pacote e o encaminha através da
rede IPv6 para o host IPv6. Após isso, os pacotes subsequentes são enviados através do
relay Teredo.

O principal problema de segurança quando se utiliza o Teredo é que seu tráfego pode passar
despercebido pelos filtros e firewalls se estes não estiverem preparados para interpretá-lo.

Sendo assim, os computadores e a rede interna ficam expostos a ataques vindos da internet
IPv6. Para resolver esse problema, antes de implementar o Teredo, deve-se fazer uma
revisão nos filtros e firewalls da rede ou pelo menos dos computadores que utilizarão essa
técnica. Além desse problema, ainda temos os seguintes:

11 O cliente Teredo divulga na rede a porta aberta por ele no NAT e o tipo de NAT que está
utilizando, possibilitando assim um ataque através dela;

11 A quantidade de endereços Teredo é bem menor que os endereços IPv6 nativos, facili-
tando a localização de computadores vulneráveis;

11 Um ataque por negação de serviço é fácil de ser aplicado, tanto no cliente quanto no relay;

11 Devido ao método de escolha do relay pelo host de destino, pode-se criar um relay falso
e utilizá-lo para coletar a comunicação deste host com os seus clientes.

Assim como o 6to4, o Teredo possui questões de segurança. Através do encapsula-

mento, pode permitir que tráfego que seria bloqueado em IPv4 consiga chegar ao
destino. Ele vem instalado e habilitado por padrão no Windows. Recomenda-se que
seja desabilitado em redes corporativas.

ISATAP
11 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) é uma técnica de tunelamento q
que liga hosts a roteadores.

11 Não há um serviço público de ISATAP; é uma técnica usada dentro das organizações.

11 Sua utilização faz sentido, por exemplo, quando a organização já tem numeração IPv6
válida e conectada na borda, mas sua infraestrutura interna não suporta IPv6.

Cenário 1 2 3 4 5 6 7 8 9 10

Suporta Não Não Não Não Não Não Não Não Sim Não

IntraSite Automatic Tunnel Addressing Protocol (ISATAP) é uma técnica de tunelamento que Tabela 10.7
liga dispositivos a roteadores. Sua utilização ocorre dentro das organizações, pois não há um ISATAP e os
cenários.
serviço público de ISATAP. É possível usar a técnica quando a organização tem IPv6 na
extremidade de sua rede, fornecido por seu provedor, mas sua infraestrutura interna, ou
parte dela, não suporta o protocolo.

A figura a seguir demonstra o conceito do ISATAP.

IPv6 Básico

184
 Roteador
ISATAP

Rede Rede
IPv4 IPv6

Cliente ISATAP
Figura 10.14 fe80::0:5fee:192.168.0.1
Topologia da rede 192.168.0.1
Túnel ISATAP
ISATAP.

Essa técnica, definida na RFC 5214, é baseada em túneis IPv6 criados automaticamente
dentro da rede IPv4 e em endereços IPv6 associados aos clientes de acordo com o prefixo
especificado no roteador ISATAP e no IPv4 do cliente. Para a criação desses túneis, são
usadas as especificações da seção 3 da RFC 4213, que trata do tunelamento através do
protocolo IPv4 tipo 41 ou 6in4.

Os endereços IPv4 dos clientes e roteadores são usados como parte dos endereços q
ISATAP, permitindo a um nó determinar facilmente os pontos de entrada e saída dos
túneis IPv6, sem usar nenhum protocolo ou recurso auxiliar. O formato do endereço
ISATAP segue o seguinte padrão:

11 Prefixo unicast: é qualquer prefixo unicast válido em IPv6, que pode ser link-local
(FE80::/64) ou global. Normalmente utiliza-se uma rede /64 obtida a partir do prefixo
global fornecido pelo provedor internet para uso na rede;

11 ID IPv4 público ou privado: se o endereço IPv4 for público, esse campo deve ter o valor
«200». Se for privado (192.168.0.0/16, 172.16.0.0/12 e 10.0.0.0/8), o valor do campo será zero;
Figura 10.15
Tradução de 11 ID ISATAP: sempre tem o valor 5EFE;
endereço IPv4 para
IPv6 no ISATAP. 11 Endereço IPv4: é o IPv4 do cliente ou roteador em formato IPv4;

0 64 80 96 128
64 bits 16 bits 16 bits 32 bits

ID IPv4 Púb: 200 ID ISATAP Endereço IPv4:w.x.y.z

Prefixo Unicast
ID IPv4 Priv: 0 5 EFE

O ISATAP é suportado pela maior parte dos Sistemas Operacionais e roteadores e é de q

fácil implantação.

Inicialização do ISATAP
q
Capítulo 10 - Coexistência e transição – Parte 2

11 1. Consulta ao DNS (no caso do Windows, procura por ISATAP.domínio-local).

11 2. O servidor DNS retorna o IPv4 do roteador ISATAP.

11 3. Router Solicitation (encapsulada em v4).

11 4. Router Advertisement (encapsulada em IPv4).

185
 Rede
IPv6
Servidor DNS

1 2
Roteador ISATAP
Tráfego IPv4
3 4
nativo
Rede
IPv4
Figura 10.16
Exemplo da
Tráfego IPv6 em túneis ISATAP
inicialização do
Cliente ISATAP utilizando protocolo 41
ISATAP.

Passos de inicialização do ISATAP:

11 1: nesse passo, o cliente tenta determinar o endereço IPv4 do roteador, se o endereço IPv4
já não estiver determinado na sua configuração. No caso do Windows, ele tenta por padrão
resolver os nomes ISATAP e ISATAP.domínio-local via resolução local ou servidor DNS;

11 2: o servidor DNS retorna o IPv4 do roteador ISATAP (se for o caso);

11 3: então, o cliente envia uma mensagem de solicitação de roteador (RS) encapsulada em

IPv4 ao roteador ISATAP;

11 4: o roteador ISATAP responde com uma mensagem de Anúncio de Roteador (RA) encap-
sulada em IPv4, e com isso o cliente já pode configurar os seus endereços IPv6/ISATAP.

Comunicação entre clientes ISATAP na mesma rede

11 A comunicação entre os clientes ISATAP numa mesma rede é feita diretamente, sem a q
interferência do roteador ISATAP (após autoconfiguração inicial).

11 O tráfego na rede é sempre IPv4. O IPv6 é encapsulado ou desencapsulado local-

mente nos clientes.

Servidor DNS
Rede
IPv6

Tráfego IPv4
nativo Rede
IPv4
Roteador ISATAP
2 3 4
5 1
Tráfego IPv6 em túneis ISATAP
C1 6
utilizando protocolo 41
Cliente
ISATAP Figura 10.17
Em uma mesma
Tráfego IPv6 em túneis ISATAP C2 rede: comunicação
utilizando protocolo 41 Cliente
IPv6 Básico

entre clientes
ISATAP ISATAP.

186
 Passos para a comunicação entre clientes ISATAP na mesma rede:

11 1: C2 solicita a resolução DNS do nome do roteador ISATAP (se necessário);

11 2: C2 recebe o IPv4 do roteador ISATAP (se necessário);

11 3: cliente envia uma mensagem de solicitação de roteador (RS) encapsulada em IPv4 ao

roteador ISATAP;

11 4: o roteador ISATAP responde com uma mensagem de Anúncio de Roteador (RA) encap-
sulada em IPv4, e com isso o cliente já pode configurar os seus endereços IPv6/ISATAP;

11 5: os processos de 1 a 4 são executados também por C1;

11 6: o cliente ISATAP C2 envia um pacote IPv6 encapsulado em IPv4 usando o protocolo 41

através da rede IPv4 com destino ao endereço IPv4 de C1;

11 7: o cliente ISATAP C1 recebe o pacote IPv4 e desencapsula o pacote IPv6 dele; depois
responde com outro pacote IPv6 encapsulado em IPv4, utilizando o protocolo 41 através
da rede IPv4 com destino ao endereço IPv4 do cliente C2.

Comunicação entre clientes ISATAP em redes diferentes

11 O tráfego ISATAP entre clientes de redes IPv4 diferentes depende dos q
roteadores ISATAP.

11 Na rede IPv4, o tráfego v6 está sempre encapsulado dentro de pacotes v4.

11 Entre os roteadores ISATAP diferentes, o tráfego é v6 nativo.

Tráfego IPv6
Rede Nativo
IPv6
Rede Rede
IPv4 IPv4
2
1 5 3
6 4
R1 R2
Roteador Roteador
ISATAP ISATAP

C1 C2
Cliente ISATAP Cliente ISATAP
Tráfego IPv6 em túneis ISATAP
utilizando protocolo 41

Figura 10.18 Passos para a comunicação entre clientes ISATAP em diferentes redes:
Capítulo 10 - Coexistência e transição – Parte 2

Em redes
diferentes: 11 1: o cliente ISATAP C1 quer enviar um pacote IPv6 para o cliente C2. Através de sua
comunicação entre tabela de roteamento, ele descobre que tem de enviá-lo utilizando a interface virtual
clientes ISATAP.
ISATAP; com isso, o pacote é encapsulado em IPv4 (protocolo 41) e enviado ao endereço
IPv4 do roteador R1;

11 2: o roteador R1 recebe o pacote através de sua interface IPv4, mas, como o pacote IPv6
está encapsulado utilizando o protocolo 41, ele o desencapsula (utilizando a interface
virtual ISATAP) e verifica o endereço IPv6 do destino. Depois disso, ele descobre que
a rota para o destino é através da rede IPv6; sendo assim, o pacote desencapsulado
(IPv6 nativo) é encaminhado para o roteador R2;

187
 11 3: o roteador R2 recebe o pacote IPv6 em sua interface IPv6, mas verificando o endereço
de destino, descobre que ele é destinado ao cliente C2 que está na sua sub-rede ISATAP.
Sendo assim, ele envia o pacote através dessa interface, que encapsula novamente o
pacote IPv6 em um pacote IPv4 e o envia a C2 (baseado no IPv4 que está implícito no
IPv6). O cliente ISATAP C1 recebe o pacote IPv4 e desencapsula o pacote IPv6 (através da
interface virtual ISATAP);

11 4: cliente ISATAP C2 quer responder ao cliente C1; sendo assim, ele verifica a sua tabela de
rotas e conclui que tem de enviar o pacote através da interface virtual ISATAP. Com isso, o
pacote IPv6 é encapsulado em IPv4 e encaminhado ao roteador R2;

11 5: roteador R2 recebe o pacote através de sua interface IPv4, mas como o pacote está
utilizando o protocolo 41, ele desencapsula o pacote IPv6 dele e o encaminha através da
sua interface IPv6, verificando na sua tabela de roteamento;

11 6: roteador R1 recebe o pacote IPv6, mas verificando em sua tabela de roteamento,

descobre que o pacote tem de ser enviado através de sua interface virtual ISATAP, a qual
encapsula o pacote IPv6 em IPv4 usando o protocolo 41 e encaminha o IPv4 de C1;

11 7: C1 recebe o pacote, mas como está encapsulado com o protocolo 41, ele extrai o
pacote IPv6 enviado por C2, e o recebe.

Comunicação entre clientes ISATAP e computadores IPv6

Rede
IPv6

Rede Servidor
IPv4 2 3 IPv6

1
4
Tráfego IPv6
Roteador Nativo
ISATAP

Cliente ISATAP Tráfego IPv6 em túneis ISATAP

utilizando protocolo 41

Passos para a comunicação entre clientes ISATAP e computadores IPv6: Figura 10.19
Comunicação entre
11 1: o cliente ISATAP quer enviar um pacote IPv6 para o servidor IPv6. Através de sua tabela clientes ISATAP e
de roteamento, ele descobre que tem de enviá-lo utilizando a interface virtual ISATAP; computadores IPv6.

com isso, o pacote é encapsulado em IPv4 (protocolo 41) e enviado ao endereço IPv4 do
roteador ISATAP;

11 2: o roteador ISATAP recebe o pacote através de sua interface IPv4, mas como o pacote
IPv6 está encapsulado utilizando o protocolo 41, ele o desencapsula (utilizando a interface
virtual ISATAP) e verifica o endereço IPv6 do destino. Depois disso, ele descobre que a rota
IPv6 Básico

para o destino é através da rede IPv6, e sendo assim o pacote desencapsulado (IPv6 nativo)
é encaminhado para o servidor IPv6. O servidor recebe o pacote IPv6 destinado a ele;

11 3: o servidor IPv6 quer responder ao cliente ISATAP; sendo assim, verificando sua tabela de
roteamento, ele descobre que tem de enviar através de sua rota padrão, via a rede IPv6;

188
 11 4: como a rota para a rede do cliente ISATAP é através do roteador ISATAP, o pacote é
encaminhado a ele via sua interface IPv6. Verificando em sua tabela de roteamento,
o roteador descobre que deve enviar o pacote através de sua interface virtual ISATAP;
sendo assim, o pacote é encapsulado em IPv4 e encaminhado ao cliente ISATAP através
da rede IPv4. O cliente recebe o pacote IPv4, mas como está utilizando o protocolo 41,
desencapsula e recebe o pacote IPv6.

A+P
Cenário 1 2 3 4 5 6 7 8 9 10

Suporta Não Não Não Não Não Não Não Não Não Não

Tabela 10.8 Os mecanismos A+P e NAT444, que serão explicados a seguir, não ajudam diretamente na
A+P e os cenários. transição de IPv4 para IPv6, mas têm sido usados na tentativa de prolongar a vida útil do IPv4.

Esses mecanismos podem ser usados, contudo, em conjunto com a implantação nativa do
IPv6, a fim de garantir conectividade IPv4 para os usuários, numa internet em transição,
onde muitos dos serviços disponíveis ainda são somente IPv4.

A técnica Address Plus Port (A+P), que significa “endereço mais porta”, está definida na q
RFC 6346 e compartilha o mesmo endereço público com mais de um usuário, simulta-
neamente. Para isso ser possível é necessária uma limitação das portas que estarão
disponíveis para cada um. É possível fazer a atribuição dos endereços e portas para os
diferentes usuários de forma stateless.

O mesmo IPv4 válido é compartilhado entre diversos usuários diferentes. A CPE é respon-
sável por fazer um NAT na rede do usuário, de forma a atender os dispositivos nela pre-
sentes com IPs privados, da RFC 1918, e obedecer a restrição de portas ao fazer a tradução.
No caso da implantação em redes com dispositivos móveis, como smartphones, estes
devem ser atualizados e estar cientes da restrição de portas.

Essa técnica provavelmente não seria notada por usuários domésticos comuns, pois estes
continuariam com IPs válidos e técnicas atuais como STUN ou uPnP para permitir conectivi-
dade fim a fim, em conjunto com o NAT na rede do usuário, continuariam funcionando.
A figura a seguir demonstra o funcionamento do A+P.

A restrição de portas não é, contudo, adequada para serviços corporativos, pois não
permitiria o uso de servidores em portas padronizadas. O problema pode ser agra-
vado se as portas forem atribuídas de forma dinâmica.
Capítulo 10 - Coexistência e transição – Parte 2

189
 Cliente A+P CPE A+P
192.168.0.1 203.0.113.1:3072~4095

Cliente A+P
192.168.0.2
Rede
IPv4 Internet
Provedor IPv4
Cliente A+P
192.168.0.1

CPE A+P
Figura 10.20
Cliente A+P 203.0.113.1:4096~5119
Topologia de
192.168.0.2 rede A+P.

Exemplos práticos da utilização do A+P já foram dados, nos itens que trataram do DS-Lite
com A+P, dIVI e dIVI-pd.A utilização de A+P, se possível, geralmente é preferível à utilização
do NAT444, estudado no item seguinte. É importante lembrar que a utilização dessas técnicas
deve ser sempre acompanhada da implantação do IPv6.

NAT444
Cenário 1 2 3 4 5 6 7 8 9 10

Suporta Não Não Não Não Não Não Não Não Não Não

Assim como o A+P, o NAT444 tem sido usado na tentativa de prolongar a vida útil do IPv4 na Tabela 10.9
internet. Esse mecanismo fere o princípio de comunicação fim a fim da internet e seu uso NAT444 e os
cenários.
deve ser evitado ao máximo. Alternativas que levem as redes na direção de redes somente
IPv6 são preferíveis, assim como alternativas que usem métodos stateless e que mantenham
a complexidade nas extremidades da rede.

O NAT444 é descrito no draft-shirasaki-nat444-05 e também é conhecido como Large q

Scale NAT (LSN) ou Carrier Grade NAT (CGN). Esse mecanismo atribui um IPv4 privado
para cada um dos usuários de um ISP, de forma semelhante ao que já é normalmente
feito em redes domésticas e em diversas redes corporativas. Ou seja, os usuários convi-
verão, nesse caso, com duas camadas de NAT.

l
A utilização dessa técnica resolveria, de forma provisória, o problema da falta de endereços
IPv4, já que eles seriam largamente reutilizados, mas o custo seria comprometer as conexões
fim a fim e possivelmente a “quebra” de diversas aplicações hoje existentes. Se usado, o NAT444
deve acompanhar a
Pode-se argumentar que o NAT já é usado normalmente e que não há prejuízo na utilização implantação do IPv6
nativo para os usuários.
da internet por conta disso. Isso não é verdade. O NAT, na rede dos usuários, por si só, já
Não deve ser usado
é prejudicial, embora tenha desempenhado um importante papel nos últimos anos para a isoladamente.
conservação dos endereços IPv4 na internet. Técnicas como servidores STUN, uPnP e outras
foram desenvolvidas para restaurar, parcialmente, a comunicação fim a fim perdida com
uma camada apenas de NAT. Com o uso de NAT444 elas deixarão de funcionar.

Outro ponto a considerar é que essa técnica é cara, exigindo equipamentos com grande
IPv6 Básico

poder de processamento. Investimentos altos tendem a ser politicamente conservados

dentro de grandes corporações, o que pode levar ao atraso na adoção do IPv6.

190
 Um ponto a considerar, do ponto de vista estritamente técnico, é a escolha do bloco de IPs
a ser usado no NAT. Como o uso dos blocos da RFC1918 é comum nas redes dos usuários,
qualquer bloco escolhido dentre os disponíveis pelo provedor fatalmente colidirá com
o bloco de algum de seus clientes. Existe uma proposta em estudo para a reserva de
um novo bloco, exclusivo para a utilização em situações onde houver duplo NAT. O ARIN
prontificou-se a ceder o bloco em questão e a proposta está sendo analisada pelo IETF:
draft-weil-shared-transition-space-request-15.

Devido ao rápido esgotamento do IPv4, podem existir situações em que essa técnica terá de
ser utilizada. Seu uso muitas vezes é incentivado por fabricantes de equipamentos, talvez
devido ao alto custo dos equipamentos necessários para sua implementação.

A figura a seguir exemplifica o funcionamento das redes hoje e como ficará o funcionamento
da rede com a utilização do NAT444.

Internet
IPv4

192.168.0.2 IPv4 Público

CPE 200.0.113.1
2001:db8::2 NAT44
10.0.0.2
2001:db8::2 LSN/CGN
192.168.0.1 10.0.0.1
NAT444
2001:db8::1
Rede Pilha Dupla
IPv4 e IPv6 Provedor
192.168.0.3
2001:db8::3
Internet
Figura 10.21
IPv6
Topologia de rede
NAT444.

Técnicas de tradução
11 Possibilitam um roteamento transparente na comunicação entre nós de uma rede q
IPv6 com nós em uma rede IPv4, e vice-versa.

11 Podem atuar de diversas formas e em camadas distintas:

22 Traduzindo cabeçalhos IPv4 em cabeçalhos IPv6 e vice-versa.

22 Realizando conversões de endereços.

22 Conversões de APIs de programação.

22 Atuando na troca de tráfego TCP ou UDP.

Capítulo 10 - Coexistência e transição – Parte 2

As técnicas de tradução possibilitam um roteamento transparente na comunicação entre

nós que apresentem suporte apenas a uma versão do protocolo IP ou usem Pilha Dupla.
Esses mecanismos podem atuar de diversas formas e em camadas distintas, traduzindo
cabeçalhos IPv4 em cabeçalhos IPv6 e vice-versa, realizando conversões de endereços, de
API APIs de programação, ou atuando na troca de tráfego TCP ou UDP.
Conjunto de instruções
e padrões de progra- SIIT
q
mação para acesso a
um aplicativo de sof- 11 Stateless IP/ICMP Translation (SIIT) permite a comunicação entre nós com suporte
tware baseado na web.
apenas ao IPv6 com nós que apresentam suporte apenas ao IPv4.

11 Utiliza um tradutor localizado na camada de rede da pilha, que converte campos espe-
cíficos dos cabeçalhos de pacotes IPv6 em cabeçalhos de pacotes IPv4 e vice-versa.

191
 11 Cabeçalhos TCP e UDP geralmente não são traduzidos. q
11 Usa um endereço IPv4-mapeado em IPv6, no formato 0::FFFF:a.b.c.d, que identifica o
destino IPv4, e um endereço IPv4-traduzido, no formato 0::FFFF:0:a.b.c.d, para identi-
Mais informações: RFC
ficar o nó IPv6. 4966 Reasons to Move
the Network Address
11 Utiliza faixas de endereços IPv4 para identificar nós IPv6.
Translator – Protocol
11 Traduz mensagens ICMPv4 em ICMPv6 e vice-versa. Translator (NAT-PT) to
Historic Status.
Stateless IP/ICMP Translation Algorithm (SIIT), definido na RFC 2765, é um mecanismo de tra-
dução stateless de cabeçalhos IP/ICMP, que permite a comunicação entre nós com suporte
apenas ao IPv6 com nós que apresentam suporte apenas ao IPv4.

Usa um tradutor localizado na camada de rede da pilha, que converte campos específicos
dos cabeçalhos de pacotes IPv6 em cabeçalhos de pacotes IPv4 e vice-versa. Para realizar
Mais informações:
esse processo, o tradutor necessita de um endereço IPv4-mapeado em IPv6, no formato RFC 2765 Stateless IP/
0::FFFF:a.b.c.d, que identifica o destino IPv4, e um endereço IPv4-traduzido, no formato ICMP Translation
Algorithm (SIIT).
0::FFFF:0:a.b.c.d, para identificar o nó IPv6. Quando o pacote chega ao SIIT, o cabeçalho é
traduzido, convertendo o endereço para IPv4 e encaminhando ao nó de destino.

BIS
11 Bump in Stack (BIS) funciona entre a camada de aplicação e a de rede. q
11 Uso para suportar aplicações IPv4 em redes IPv6.

11 Adiciona três módulos à pilha IPv4:

22 Translator: traduz cabeçalhos IPv4 em cabeçalhos IPv6 e vice-versa.

22 Address mapper: possui uma faixa de endereços IPv4 que são associados a ende-
reços IPv6, quando o translator receber um pacote IPv6.

22 Extension name resolver: atua nas consultas DNS realizadas pela aplicação IPv4.

22 Não funciona em comunicações multicast.

Aplicação IPv4

UDP / TCP / IPv4

Resolvedor Mapeador
de nome de de endereço
extensão

Tradutor

IPv6

Figura 10.22
IPv6 Básico

Driver de identificação de rede Estrutura proposta

para dual
stack host.

192
 Bump in the Stack (BIS) é um método que possibilita a comunicação de aplicações IPv4 com
nós IPv6. Definido na RFC 2767, funciona entre a camada de aplicação e a de rede, adicio-
nando à pilha IPv4 três módulos:

11 Translator: traduz os cabeçalhos IPv4 enviados em cabeçalhos IPv6 e os cabeçalhos IPv6

recebidos em cabeçalhos IPv4;

11 Extension name resolver: atua nas DNS queries realizadas pelo IPv4, de modo que, se o
servidor DNS retorna um registro AAAA, o resolver pede ao address mapper para atribuir
um endereço IPv4 correspondente ao endereço IPv6;

11 Address mapper: possui certa quantidade de endereços IPv4 para associar a endereços
Mais informações na IPv6 quando o translator receber um pacote IPv6. Como os endereços IPv4 não são
RFC 2767 – Dual Stack transmitidos na rede, eles podem ser endereços privados. Esse método permite apenas a
Hosts using the
“Bump-In-the-Stack” comunicação de aplicações IPv4 com hosts IPv6, e não o contrário, além de não funcionar
Technique (BIS). em comunicações multicast.

BIA
11 Bump in the API (BIA): similar ao BIS, traduz funções da API IPv4 em funções da API q
IPv6 e vice-versa.

11 Três módulos são adicionados:

22 Extension name resolver e Address mapper, que funcionam da mesma forma

que no BIS.

22 Function mapper, que detecta as chamadas das funções do socket IPv4 e invoca as
funções correspondentes do socket IPv6 (e vice-versa).

11 Também utiliza faixas de endereços IPv4.

11 Não suporta comunicações multicast.

Aplicação IPv4

Socket API (IPv4, IPv6)

Resolvedor Mapeador de Mapeador

de nome de função de endereço
Capítulo 10 - Coexistência e transição – Parte 2
extensão

TCP/UDP/IPv4 TCP/UDP/IPv6

Figura 10.23
Arquitetura de Driver de identificação de rede
dual stack host
usando BIA.

Bump in the API (BIA) é um mecanismo similar ao BIS, que adiciona uma API de tradução
entre o socket API e os módulos TPC/IP dos hosts de Pilha Dupla, permitindo a comunicação
de aplicações IPv4 com hosts IPv6, traduzindo as funções do socket IPv4 em funções do
socket IPv6 e vice-versa. Conforme descrito na RFC 3338, três módulos são adicionados:

193
 extension name resolver e address mapper, que funcionam da mesma forma que no BIS, e o
function mapper, que detecta as chamadas das funções do socket IPv4 e invoca as funções Interface socket
correspondentes do socket IPv6 e vice-versa. Interface de interação
entre os processos
BIA apresenta duas vantagens em relação ao BIS: não depende do driver da interface de de aplicação e as
implementações dos
rede e não introduz overhead na tradução dos cabeçalhos dos pacotes. No entanto, também
protocolos da arquite-
não suporta comunicações multicast. tura TCP/IP no Sistema
Operacional.
TRT
11 Transport Relay Translator (TRT): atua como tradutor de camada de transporte, possi- q
bilitando a comunicação entre hosts IPv6 e IPv4 através de tráfego TCP/UDP.

11 Atua em máquinas com Pilha Dupla que devem ser inseridas em um ponto intermedi-
ário dentro da rede.
Mais informações: RFC
11 Na comunicação de um host IPv6 com um host IPv4, adiciona um prefixo IPv6 falso ao 3338 – Dual Stack
endereço IPv4 do destino. Hosts Using Bump in
the API (BIA).
11 Quando um pacote com esse prefixo falso passa pelo TRT, o pacote é interceptado e
enviado ao host IPv4 de destino em um pacote TCP ou UDP.

11 Para funcionar de forma bidirecional, deve-se adicionar um bloco de endereços IPv4

públicos e usar um servidor DNS-ALG para mapear os endereços IPv4 para IPv6.

Transport Relay Translator (TRT): atuando como um tradutor de camada de transporte, esse
mecanismo possibilita a comunicação entre hosts apenas IPv6 e hosts apenas IPv4, através
de tráfego TCP/UDP. Sem a necessidade de instalação de qualquer tipo de software, o TRT
roda em máquinas com Pilha Dupla que devem ser inseridas em um ponto intermediário
dentro da rede. Na comunicação de um host IPv6 com um host IPv4, conforme definição
na RFC 3142, é adicionado um prefixo IPv6 falso ao endereço IPv4 do destino. Quando um
pacote com esse prefixo falso passa pelo TRT, é interceptado e enviado ao host IPv4 de
destino em um pacote TCP ou UDP. Na tradução TCP e UDP, o checksum deve ser recalcu-
Mais informações na
lado. Apenas no caso de conexões TCP o estado do socket sobre o qual o host está conec- RFC 3142 – An
tado deve ser mantido, sendo removido quando a comunicação for finalizada. Para que o IPv6-to-IPv4 Transport
Relay Translator.
mecanismo funcione de forma bidirecional, é necessária a adição de um bloco de endereços
IPv4 públicos e o uso de um servidor DNS-ALG para mapear os endereços IPv4 para IPv6.

ALG e DNS-ALG
Application Layer Gateway (ALG). q
11 Trabalha como um proxy HTTP.

11 O cliente inicia a conexão com o ALG, que estabelece uma conexão com o servidor,
retransmitindo as requisições de saída e os dados de entrada.

11 Em redes que somente usam IPv6, o ALG habilita a comunicação dos hosts com ser-
viços em redes que apenas usam IPv4, configurando o ALG em nós com Pilha Dupla.

11 Utilizado quando o host que deseja acessar a aplicação no servidor IPv4 está atrás de
NAT ou de um firewall.

DNS-ALG:
IPv6 Básico

11 Traduz consultas DNS do tipo AAAA de um host IPv6, para uma consulta do tipo A,
caso o servidor de nomes consultado se encontre no ambiente IPv4, e vice-versa.

194
Segurança na transição
11 Com a utilização de Pilha Dupla, as aplicações ficam expostas aos ataques a ambos os q
protocolos, IPv6 e IPv4, o que pode ser resolvido configurando firewalls específicos
para cada protocolo.

11 As técnicas de túneis e tradução causam maior impacto do ponto de vista de segurança.

11 Mecanismos de tunelamento são suscetíveis a ataques de DoS, falsificação de pacotes e

de endereços de roteadores e relays utilizados por essas técnicas, como 6to4 e Teredo.

11 As técnicas de tradução implicam em problemas relacionados à incompatibilidade

dessas técnicas com alguns mecanismos de segurança existentes.

11 Similar ao que ocorre com o NAT no IPv4.

11 Como se proteger:

22 Usar Pilha Dupla na migração, protegendo as duas pilhas com firewall.

22 Dar preferência aos túneis estáticos, no lugar dos automáticos.

22 Permitir a entrada de tráfego apenas de túneis autorizados.

Considerações finais
A utilização de Pilha Dupla IPv4 e IPv6 na internet foi imaginada com a técnica padrão para
uma transição sem solução de continuidade na migração para o IPv6. A Pilha Dupla parece
ser, ainda hoje, a melhor escolha para provedores e redes corporativas, desde que não haja
falta de endereços IPv4 válidos e, consequentemente, for possível utilizá-la.

O rápido esgotamento dos endereços IPv4, a existência de equipamentos legados onde não
é possível usar IPv6 e a presença de equipamentos somente IPv6, por falta de IPs v4 livres,
criaram a demanda por outras técnicas de transição. As principais foram apresentadas ao
longo deste texto.

Deve-se considerar, ao escolher a técnica a ser usada em uma rede específica, que a internet
caminha para usar o IPv6. Não há dúvida de que no futuro a internet utilizará majorita-
riamente IPv6 e, possivelmente, somente IPv6. Aqueles que trabalham com redes há pelo
menos pouco mais de uma década viveram outras transições similares, como por exemplo,
quando, em redes corporativas, era comum o uso de IPX/SPX, Netbios, Appletalk e IP con-
comitantemente. A convergência tecnológica é um processo natural. Ela facilita o gerencia-
mento das redes, a interoperabilidade, o desenvolvimento de novas aplicações e serviços,
reduzindo custos, de forma geral. Capítulo 10 - Coexistência e transição – Parte 2

Com isso em mente, os provedores devem planejar-se para atender, daqui a pouco tempo,
seus novos usuários exclusivamente com redes IPv6, de forma nativa. Devem oferecer
paliativamente a eles um IPv4 válido, se houver disponível, ou compartilhado, se necessário.
Isso deve ser feito enquanto houver uma quantidade relevante de dispositivos na internet
que não tenham implantado IPv6. Pode-se fazer isso com auxílio de técnicas de transição
baseadas em túneis, ou tradução, usando a rede que será exclusivamente IPv6.

Há muitas técnicas disponíveis. Algumas delas já relativamente maduras e outras em processo

de desenvolvimento e padronização. A IETF é uma organização aberta, na qual colaboram
provedores internet, fabricantes de equipamentos, universidades e outros interessados. Ela tem
sido muito ágil nesse processo, dada a urgência criada pela necessidade. É importante avaliar
cuidadosamente, então, se é preciso investir agora em equipamentos que suportam uma deter-
minada técnica, para serem usados daqui a um ou dois anos, ou se é melhor esperar algum

195
 tempo até que tecnologias melhores e mais baratas, do ponto de vista financeiro e computa-
cional, estejam mais maduras. Não é um problema para o qual se possa recomendar soluções
em uma direção, ou outra, genericamente. Cada operador ou usuário na internet deve analisar
sua situação específica e escolher dentre as várias opções possíveis, a melhor para seu caso.

Um dos pontos a considerar na escolha das técnicas de transição a serem utilizadas é se elas
são stateless ou stateful. Técnicas stateless são preferíveis, dado que escalam melhor e são
mais baratas. Se necessário usar técnicas stateful, é preferível que estejam implantadas nos
equipamentos dos usuários e não no provedor.

De forma geral, tanto as técnicas de tradução quanto as de túneis forçam a redução do

MTU no escopo em que são usados na rede. Embora o este Capítulo não tenha abordado
essa questão, todas elas apresentam mecanismos para contornar esse problema. Contudo,
as técnicas baseadas em tradução aparentemente oferecem alguma vantagem, pois não
encapsulam o pacote novamente: apenas traduzem e trocam os cabeçalhos na camada IP, o
que poderia ser interpretado, grosso modo, como um túnel com compactação do cabeçalho.

O NAT444 é uma técnica a ser evitada. Seu uso não leva a rede do provedor em direção ao
IPv6, acarreta altos custos financeiros e dificuldades técnicas para os usuários da internet.
O NAT444 fere o princípio da conexão fim a fim, que foi essencial para o desenvolvimento da
internet nos moldes em que a conhecemos atualmente e é uma das bases que a fazem ser
um ambiente propício à inovação, novas ideias, aplicações, serviços e negócios. O compar-
tilhamento de IPs com restrição de portas (A+P) e NAT44 são soluções preferíveis, adotadas
em conjunto com túneis ou dupla tradução sobre redes nativas IPv6. NAT 64 em conjunto
com DNS 64 e possivelmente ALGs também é uma solução preferível ao NAT444.

Para redes corporativas já existentes, o caminho mais indicado hoje é a implantação do

IPv6 de forma gradual, em Pilha Dupla. Isso deve ser feito de forma urgente nos servidores
expostos na internet, como os servidores web e de e-mails e de forma paulatina para os
usuários e outros serviços. Ainda há problemas com aplicações utilizadas no dia a dia em
relação ao suporte ao IPv6, por isso redes somente IPv6 ainda não podem ser recomen-
dadas de forma genérica. Essa situação, no entanto, vem avançando rapidamente. É possível
vislumbrar, já hoje, situações em que os benefícios trazidos pela facilidade de gerenciar uma
rede com apenas um protocolo e endereços suficientes para todos os dispositivos, sem a
necessidade de traduções, suplantem os problemas advindos da falta de suporte ao IPv6 em
algumas aplicações. Pode ser que o futuro em que será vantajoso para as redes corporativas
trabalhar apenas com IPv6, com auxílio de técnicas de transição para a comunicação com a
internet IPv4, não esteja muito distante.

Finalmente, deve-se considerar que todas as formas de compartilhamento do IPv4 para

usuários geram dificuldades no processo de sua identificação a partir de ações executadas
na internet, caso isso seja necessário. Hoje os provedores internet normalmente guardam
registros, logs, que associam, univocamente, um usuário a um IPv4, dentro de um determi-
nado período de tempo. É comum que em investigações criminais esses logs sejam requisi-
tados, por meio de ordens judiciais, que trazem como dados o IP do usuário e o momento de
acesso a um determinado site ou serviço na rede.

Com o compartilhamento de IPs não haverá apenas um usuário associado a um IP num dado
momento, mas sim diversos. Podem ser alguns poucos, dezenas, ou mesmo centenas.
IPv6 Básico

Esse será um problema temporário, resolvido facilmente com a migração dos principais ser-
viços na internet, como portais de conteúdo, de comércio eletrônico, serviços bancários ou
de governo, para IPv6. Paliativamente, no contexto do compartilhamento do IPv4, pode-se

196
propiciar uma possibilidade melhor de identificação, dependendo da técnica utilizada, se
como informação for obtido não apenas o IP, mas também a porta de origem, a partir da
qual a conexão foi realizada. Dessa forma, para aqueles serviços na internet que hoje já
guardam logs dos IPs de origem dos usuários, como bancos e serviços de comércio eletrô-
nico, é recomendado que passem também a guardar as portas de origem, além de implan-
tarem de forma urgente o IPv6.

Capítulo 10 - Coexistência e transição – Parte 2

197
 IPv6 Básico

198
 11
Planejamento
objetivos

Discutir todos os aspectos que envolvem a implantação do IPv6, incluindo a

descrição dos diversos cenários de implantação e como fazer a implantação.

conceitos
Treinamento em IPv6 e análise do impacto do IPv6 na rede.

O planejamento
Após conhecermos um pouco sobre o funcionamento e os novos recursos do protocolo IPv6,
discutiremos neste capítulo alguns conceitos importantes que precisam ser estudados na
hora de implantar IPv6 nas grandes redes de computadores. Devemos compreender todos
os aspectos que envolvem a implantação do IPv6, como análise de custos, troca de material
e treinamento, principalmente em redes corporativas.

A decisão pela adoção do protocolo IPv6 gera muitas questões: q

11 O IPv6 é realmente necessário?

11 Quando o IPv6 será necessário?

11 Há alternativas viáveis ao IPv6?

11 A transição deve ser feita de uma única vez ou gradualmente?

11 Como tornar as aplicações e serviços compatíveis com o novo protocolo?

11 Como tirar vantagem das novas funcionalidades do IPv6?

11 Quais aspectos devem ser avaliados além da segurança?

11 Como se planejar para essa transição?

11 Qual será o custo da implantação?

Pontos importantes:
Capítulo 11 - Planejamento

11 A troca de protocolo tem caráter estrutural;

11 Essa mudança não ocorrerá apenas porque o protocolo IPv6 apresenta melhorias em
relação ao seu antecessor;

11 A implantação do IPv6 é necessária e inevitável;

11 O esgotamento dos endereços IPv4 não fará a internet acabar, nem mesmo que deixe
de funcionar;

199
 11 Mas deve haver diminuição na taxa de crescimento da rede e dificuldades no desenvolvi-
mento de novas aplicações;

11 Todos esses problemas podem ser evitados com a adoção do IPv6 antes do término do IPv4;

11 A implantação do IPv6 não será rápida;

11 Não haverá uma “data da virada” para a troca de protocolo;

11 A migração do IPv4 para IPv6 acontecerá de forma gradual, com o IPv4 ainda em funcionamento.

É importante que as redes estejam preparadas para o novo protocolo desde já. Quanto mais cedo a
questão for entendida – e a implantação planejada –, menores serão os gastos no processo.

Primeiro passo: treinamento

É importante que técnicos e administradores de redes busquem adquirir conhecimento q
sobre a nova tecnologia em:

11 Cursos.

11 Livros.

11 Sites.

11 Documentos técnicos.

11 Fóruns.

11 Eventos.

Esse primeiro passo será essencial para as próximas fases.

O RIPE NCC oferece alguns vídeos sobre “cases IPv6” que podem servir como fonte RIPE NCC
de conhecimento. Registro Regional
da Internet RIR para
Esses vídeos estão no YouTube, no endereço www.youtube.com/ripencc, alguns com legendas em Europa, Oriente Médio e
português:Randy Bush (Internet Initiative Japan Inc.); Lorenzo Colitti (Google); Marco Hogewoning partes da Ásia Central.

(Dutch ISP XS4ALL); Andy Davidson (NetSumo ISP Consultancy); David Freedman (Claranet).

O impacto do IPv6
11 Como o IPv6 pode afetar os negócios: q
22 Novas aplicações.

22 Novas oportunidades.

22 Novos serviços.

11 Como obter conexão.

11 Que tipo de conexão oferecer aos clientes:

22 IPv6 nativo.

22 Túneis.

11 Quais serviços internos serão migrados inicialmente.

11 Entender esses aspectos é essencial para otimizar o retorno dos investimentos.

11 Minimizar os custos da implantação.

22 Custo relativo em um ISP (Fonte: U.S. Department of Commerce):

IPv6 Básico

33 Com equipamentos (15%):

33 Roteadores: médio.

33 Firewalls: médio.

200
 33 Com softwares (15%): ‫‏‬ q
33 Softwares de gerenciamento e monitoramento de redes: alto.

33 SOs: médio.

33 Mão de obra (70%) ‫ ‏‬:

33 Pesquisa e desenvolvimento: baixo.

33 Treinamento: alto.

33 Implementação: alto.

33 Manutenção: médio/alto.

33 Problemas de interoperabilidade: médio/alto.

Exercício de fixação: engenheiros x gerentes

Gerentes/gestores/diretores x técnicos/engenheiros. q
11 Você pode convencer os gestores de sua empresa?

11 Vamos trabalhar em grupos:

33 10 min.: preparação.

33 10 min.: apresentação e discussão.

11 Gerentes:

33 Não querem investir agora em IPv6.

11 Técnicos:

33 Querem convencer os gerentes a agir agora.

11 Pontos para pensar:

33 Capacidade do hardware.

33 Prioridades de negócio.

33 Conhecimento existente/treinamento.

33 Clientes.

33 Legislação.

33 Custo.

33 Timing.

33 Troca de tráfego.

Este exercício foi aplicado no treinamento IPv6 oferecido pelo RIPE a provedores europeus. Algumas
respostas apresentadas pelos técnicos à pergunta “por que investir no protocolo IPv6?” foram:

11 Pedido dos clientes;

11 Dispositivos móveis;

11 Nosso equipamento já suporta;

Capítulo 11 - Planejamento

11 Se fizermos agora, podemos investir gradualmente;

11 Obter a alocação agora é um investimento, porque possui muito espaço e nenhum custo;

11 Há várias oportunidades de treinamento;

11 v6 é a única opção para o crescimento;

11 v6 é fácil, não são necessários muitos recursos;

11 Compare o preço de fazer agora com o de deixar para depois.

201
 Já a resposta negativa dos gerentes à mesma questão tinha os seguintes argumentos:

11 Vai custar muito, vamos precisar de 20% a mais no orçamento;

11 Não teremos clientes para isso;

11 Antes precisamos auditar o equipamento;

11 Precisamos de um plano, em fases;

11 Os equipamentos podem ter v6, mas não há paridade nas funcionalidades;

11 Temos equipamentos e softwares obsoletos;

11 Empresas que se preocupam com segurança não querem v6 agora, porque hardware e
software não estão maduros;

11 Por que temos de mudar?

11 Como é possível garantir que o v4 vai acabar mesmo?

Cenário 1: não fazer nada

11 Nenhum problema nos próximos anos. q
11 Com o passar do tempo, algumas pessoas não poderão fazer uso de seus serviços.

11 Nenhum custo extra.

33 Até batermos no muro!

11 Custos altos para uma implantação rápida.

11 Períodos curtos de planejamento implicam em mais erros.

Cenário 2: fazer tudo agora

11 Talvez o hardware tenha de ser trocado. q
11 Investimento alto em tempo e outros recursos.

11 Sem retorno imediato.

11 Altos custos para uma implantação rápida.

11 Planejamento rápido significa maior possibilidade de erros.

Cenário 3: comece agora, faça em etapas

11 Defina metas e prazos a serem cumpridos. q
11 Identifique as áreas e serviços que serão afetados.

11 Procedimento de compra.

22 Paridade de funcionalidades.

11 Verifique hardware e software.

22 Aplicações ou sistemas que não serão atualizados.

22 Serviços críticos.

11 Faça testes.

11 Um serviço de cada vez:

22 Implementar na rede de núcleo.

IPv6 Básico

22 Implementar na rede de clientes.

11 Prepare-se para desligar o IPv4.

202
Comece fazendo
11 Desenvolva um plano de endereçamento. q
11 Obtenha os endereços.

11 Anuncie-os:

22 Web.

22 DNS autoritativo.

22 Servidores de e-mail.

Obtenha um prefixo IPv6

11 Todos os RIRs já distribuem endereços IPv6 em suas regiões q
11 Preencha o formulário em:

22 http://registro.br/info/pedido-form.txt

11 Enviar por e-mail: [email protected]

11 Receberá um ticket ou mensagem indicando erros de preenchimento.

11 Quem tem IPv4 certamente justifica IPv6.

11 Gratuito, por enquanto.

11 Duas semanas entre análise e aprovação.

11 Dúvidas: [email protected]

Não faça
11 Não separe as funcionalidades v6 do v4. q
11 Não faça tudo de uma vez.

11 Não indique um “guru IPv6” para sua organização.

22 Você tem um especialista v4?

11 Não veja o IPv6 como um produto.

22 O produto é a internet, ou o acesso a conteúdos da internet.

Considerações
11 IPv4 já não é mais sinônimo de internet. q
11 Evitar o problema não o fará desaparecer.

11 Quanto você está disposto a gastar agora, para economizar dinheiro depois?

11 Somente o IPv6 permitirá o crescimento contínuo da rede.

Capítulo 11 - Planejamento

203
 IPv6 Básico

204
 12
O IPv6 na RNP
objetivos

Conhecer a implantação do IPv6 na RNP.

conceitos
Backbone IPv6; troca de tráfego IPv6; distribuição de blocos IPv6; regras de
alocação de endereços IPv6

IPv6 na RNP
11 O projeto entrou em operação em novembro de 2001. q
11 A partir de 2005, o IPv6 tornou-se nativo na rede e trânsito global.

11 Meta: prover conectividade IPv6 nativa aos clientes da RNP.

11 Utiliza a mesma infraestrutura utilizada no serviço IPv4.

11 Endereço IPv6 de produção, alocado pelo LACNIC (prefixo 2001:12F0::/32).

11 Atualmente conecta todos os estados brasileiros, além do Distrito Federal.

O projeto de IPv6 foi iniciado na RNP em fevereiro de 2001. Entretanto, desde 1998 a RNP
possuía um bloco de endereços de teste, alocado pelo 6Bone. Em setembro de 2001, a RNP
obteve a alocação de um bloco de endereços IPv6 de produção, junto à American Registry
for Internet Numbers (ARIN).

A alocação de endereços IPv6 de produção segue uma política restritiva. A RNP era a única
rede no país que, naquela época, atendia às condições exigidas pela ARIN, tanto pelas suas
características técnicas quanto pelo histórico acumulado de projetos de desenvolvimento
desse protocolo. Na época, a RNP já contava com o apoio do Comitê Gestor da Internet no
Brasil, que considerava a iniciativa relevante para o progresso dos serviços de internet no país.

Inicialmente, esses endereços foram usados numa rede piloto instalada entre os Pontos de
Presença da RNP em São Paulo, Rio de Janeiro, Rio Grande do Norte e Rio Grande do Sul.
Capítulo 12 - O IPv6 na RNP

Posteriormente, a RNP ativou conexões entre essa rede piloto IPv6 e as redes acadêmicas
Internet2 e Renater. Ambas as conexões foram feitas através de túneis IPv6.

O primeiro túnel IPv6 foi estabelecido com a francesa Renater, em 9 de novembro. O túnel
com a Internet2, dos Estados Unidos, foi implementado em 30 de novembro. Essas duas
conexões, constituídas entre redes IPv6 nativas no Brasil e no exterior, permitiram acesso
direto às redes IPv6 norte-americanas e europeias.

205
 A partir de 2005, a RNP passou a contar com IPv6 nativo em todos os PoPs do backbone e
também com trânsito global. Dessa forma, a RNP cumpre a meta de prover conectividade O bloco de endereço
IPv6 nativa para seus clientes, conectando todos os estados brasileiros e o Distrito Federal. IPv6 de produção
usado pela RNP
corresponde ao prefixo
Backbone IPv6 na RNP 2001:12F0::/32.

11 Roteadores com pilha dupla: IPv6 rodando nos mesmos equipamentos da q

rede de produção.

11 IPv6 rodando nativamente sobre links do backbone (IPv6/IPv4).

11 Túneis são utilizados em algumas localidades para acesso local.

11 OSPFv3 é o protocolo de roteamento interno.

11 BGP4+ para roteamento externo.

A rede IPv6 nativa utiliza a mesma infraestrutura física usada pela rede IPv4. Todos q
os roteadores funcionam com pilha dupla, ou seja, IPv6 rodando nos mesmos equipa-
mentos da rede de produção IPv4 e rodando nativamente sobre os links de backbone.

Os PoPs, por sua vez, são providos de equipamentos de distribuição que também
possuem recurso de IPv6 nativo para acesso dos clientes. Entretanto, no caso de haver
clientes que não possuam uma conexão nativa IPv6 até o equipamento de distribuição
do PoP, túneis são utilizados para o acesso local IPv6 desses clientes.

O backbone da RNP utiliza o protocolo OSPFv3 para roteamento IPv6 interno, e o BGP4+
(BGP4 com extensão para multiprotocolo), para roteamento IPv6 externo.

A topologia atual do backbone da RNP, chamada rede Ipê, pode ser vista na figura a seguir.
IPv6 Básico

206
 Figura 12.1
Backbone RNP.

Backbone IPv6 RNP – Peerings

CGI.BR: q
11 Comitê Gestor da Internet no Brasil.

AMPATH:

11 American PATH (trânsito para a internet).

Rede Clara:

11 Cooperación Latino Americana de Redes Avanzadas.

A Internet2.

RIS:

11 Routing Information Service.

Dualtec.

CTBC.

Durand do Brasil.

Terremark.

DENIC eG.

PTT-Metro de São Paulo.

ANSP:

11 Academic Network at São Paulo.

Capítulo 12 - O IPv6 na RNP

A rede Ipê possui diversos peerings para a troca de tráfego IPv6 nativo.

207
 Backbone IPv6 RNP – Clientes
Alguns clientes IPv6 da rede Ipê. q
Rio Grande do Sul:

11 Universidade Federal do Rio Grande do Sul (UFRGS).

11 Universidade Federal de Santa Maria (UFSM).

11 Faculdades de Taquara.

Santa Catarina:

11 Universidade Federal de Santa Catarina (UFSC).

11 Centro Universitário de Brusque (Unifebe).

Paraná:

11 Pontifícia Universidade Católica do Paraná (PUC-PR).

11 Universidade Tecnológica Federal do Paraná (UTFPR).

Rio de Janeiro:

11 Centro Brasileiro de Pesquisas Físicas (CBPF).

11 Universidade Federal do Rio de Janeiro (UFRJ).

11 Escritório da RNP.

São Paulo:

11 Instituto de Pesquisas Tecnológicas (IPT).

11 Instituto Federal de Educação, Ciência e Tecnologia de São Paulo (IFSP).

11 Universidade Federal de São Carlos (UFSCar).

11 Centro de Pesquisa e Desenvolvimento em Telecomunicações (CPqD).

11 Escritório da RNP em Campinas.

Rio Grande do Norte:

11 Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte (IFRN).

11 Universidade Federal do Rio Grande do Norte (UFRN).

Bahia:

11 Universidade Federal da Bahia (UFBA).

11 Universidade de Salvador (UNIFACS).

11 Instituto Federal de Educação, Ciência e Tecnologia da Bahia (IFBA).

11 Faculdade Ruy Barbosa (FRB).

Pará:

11 Universidade Federal do Pará (UFPA).

Distrito Federal:

11 Escritório da RNP em Brasília.

IPv6 Básico

208
Distribuição de blocos IPv6 na RNP
11 Foi alocada uma rede /47 para a infraestrutura IPv6. q
11 Interfaces LAN do PoP utilizam endereços pré-alocados para cada PoP, segundo um
plano de endereçamento.

11 Para cada roteador do backbone, foi pré-alocado um conjunto de 16 redes /64.

A RNP possui quatro blocos /24 para uso na rede de infraestrutura IPv4. De forma equi-
valente, a RNP alocou um bloco /47 para a rede de infraestrutura IPv6. Desse bloco /47,
uma sub-rede /48 é destinada para interfaces nativas e a outra sub-rede /48 é destinada
para interfaces de túnel.

Os endereços IPv6 para as interfaces da rede local de cada PoP também fazem parte do /47
de infraestrutura da RNP. Esses endereços estão contidos em blocos /64 pré-alocados para
cada PoP, conforme plano de endereçamento da RNP. Para cada PoP, foi pré-alocado um
conjunto de 16 redes /64.

Regras para a alocação de endereços IPv6 na RNP

11 Todas as solicitações de endereços devem ser realizadas através do e-mail q
[email protected].

11 Só serão atendidas solicitações providas de instituições usuárias qualificadas pela

RNP cujo solicitante seja o contato técnico cadastrado para a instituição.

11 As solicitações também podem ser realizadas pelo coordenador técnico do PoP da

RNP, que atende à instituição.

11 Cada instituição recebe apenas um bloco IPv6 /48, mas alocações maiores podem
ser estudadas.

As instituições clientes que desejarem ter conectividade IPv6 devem solicitar à RNP uma
faixa de endereçamento IPv6. Caso aprovada, a faixa concedida será colocada em operação
mediante a configuração dos roteadores dos PoPs que as atendem.

Capítulo 12 - O IPv6 na RNP

209
 IPv6 Básico

210
Os autores e colaboradores trabalham no CEPTRO.br, área
do Núcleo de Informação e Coordenação do Ponto BR - NIC.
br, responsável por serviços e projetos relacionados prin-
cipalmente à infraestrutura da Internet no Brasil e ao seu
desenvolvimento. A equipe desenvolve soluções em infra-
estrutura de redes, software e hardware, além de geren-
ciar projetos executados por parceiros externos. Dentre os
projetos coordenados pelo CEPTRO.br, destaca-se o IPv6.br.
Projeto que engloba uma série de iniciativas do NIC.br para
disseminar o uso do protocolo IPv6 no Brasil, oferecendo
cursos presenciais e a distância, desenvolvendo materiais
didáticos, ministrando palestras e mantendo o site web
http://ipv6.br, o blog http://ipv6.br/blog, o validador de
sites web para IPv6 http://ipv6.br/validador e o curso
e-learning http://ipv6.br/curso.
LIVRO DE APOIO AO CURSO

DOMINE A NOVA GERAÇÃO DO PROTOCOLO IP Curso

voltado para capacitar administradores de redes LAN e
WAN na implantação de suporte ao protocolo IPv6 nas
redes de suas organizações. O conteúdo teórico e atividades
em laboratório cobrem desde o endereçamento IPv6
até o roteamento entre provedores de acesso. O curso
inclui também questões de gerenciamento, segurança e
a transição do IPv4 tradicional para o IPv6, assim como o
convívio destes protocolos na mesma rede.

ISBN 978-85-63630-40-7

9 788563 630407