IPv6: Internet Protocol – Versão 6
e Mecanismos de Transição
Edgard Jamhour
2008, Edgard Jamhour
Neste módulo será visto a versão 6 do protocolo IP denominada IPv6. A versão do
protocolo IP atualmente usada na Internet e na maioria das redes é o IPv4. Contudo, a
idéia de "evoluir" o protocolo IP para uma nova versão data dos anos 90.
O protocolo IP foi criado nos anos 70 (e formalizado em 1981) tendo em vista as
limitações de hardware disponíveis na época. Os primeiros roteadores IP eram muito
limitados em termos de capacidade de processamento e memória, por isso, necessitavam
de um protocolo bastante simples.
Nos anos 80, a visão da rede IP era menos ambiciosa. Não se imaginava a criação de
uma rede tão grande baseada no IPv4 (a Internet), nem os problemas de segurança ou
transporte de tantos tipos de serviço pelas redes IP.
Nos anos 90 teve início a elaboração da nova versão do protocolo IP, denominada IPv6. A
discussão de quando essa nova versão será adotada ainda está em aberto. O IETF não
acredita que seja possível uma migração completa do IPv4 para o IPv6 de forma abrupta.
Ao contrário, ela imagina que haverá um grande período onde ambas as redes irão existir.
Dessa forma, até aproximadamente 2001, o IETF criou uma série de "mecanismos de
transição", que permitem a comunicação entre redes IPv4 e IPv6. Esse mecanismos
definem novas formas de tunelamento, roteamento e serviços de rede para suportar a
integração das duas versões do protocolo IP que são, a princípio, incompatíveis.
Nesse módulo será estudado o IPv6 e os principais mecanismos de transição propostos
pelo IETF.
Problemas do IP Versão 4
• Crescimento do IPv4
– 07/2007 490 milhões de hosts
01/2008 542 milhões de hosts
PREVISÃO DE
ESGOTAMENTO
= 1994
Edgard Jamhour
A idéia da criação de uma nova versão do IP data do início dos anos 90. Conforme
observado na figura, a quantidade de hosts (computadores com endereço IP público
registrados no DNS) na Internet vem crescendo exponencialmente a partir dessa data. A
pergunta que precisamos responder é: qual o limite para o crescimento da Internet? Para
responder essa pergunta, temos que analisar as limitações do IPv4 sobre alguns aspectos
estruturais: Endereçamento e Arquitetura de Roteamento.
O espaço de endereçamento do IPv4 é um forte limitante de crescimento. É curioso
lembrar que a previsão inicial de esgotamento de endereços IPv4 foi 1994. A reação do
IETF para essa previsão foi o desenvolvimento de duas propostas que tiveram o efeito de
prolongar a vida do IPv4: O CIDR e os IPs privados.
O CIDR (Classless Inter Domain Routing) possibilitou a alocação de blocos de endereços
de qualquer tamanho, reduzindo o desperdício causado pelo uso de classes, que
permitiam alocar apenas blocos de tamanho múltiplos de oito na base 2, isto é (2^8, 2^16
e 2^24). Com o CIDR, pode-se alocar blocos 2^n, onde n pode ser qualquer número
entre 0 e 32.
Os IPs privados permitiram que vários computadores passassem a ter acesso a Interent
sem necessidade de ter identificadores únicos (IPs públicos). Contudo, deve-se lembrar
que um computador com IP privado não tem todas as funcionalidades que outro com IP
público (pois ele não pode receber conexões). Então um usuário com IP privado tem
conectividade limitada. O uso de IPs privados é uma prática aceitável para permitir o
acesso a Internet a partir de um ambiente controlado (como funcionários de uma
empresa), mas geralmente pouco aceito por usuários residenciais.
Problemas de Arquitetura
Internet Exchange Point
IXP
AS
AS
AS
AS
A criação do CIDR, provocou
grande incremento no número de
rotas dos roteadores de borda
(entradas BGP)
AS
Edgard Jamhour
O IPv4 usa endereços de 32 bits, o que permite endereçar até 4 bilhões de hosts. A
quantidade de entradas no DNS já atingiu 1/8 dessa quantidade. Contudo, devido as
perdas inerentes resultantes da divisão de endereços em classes (e mesmo depois, com
o CIDR), e o fato de que muitos clientes usam endereço IP público, podemos estimar que
estejamos bem mais próximos do esgotamento (mais de 50%).
Deve-se observar que as estatísticas de esgotamento não se referem a quantidade total
de computadores que tem acesso a rede, mas sim apenas aqueles que possuem um
endereço público (e possuem um nome de DNS). Existe uma certa quantidade de
usuários que acessam a Internet com endereços privados através de NAT ou Proxy.
Esses computadores não são contabilizados nas estatísticas e podem continuar a
aumentar mesmo após o esgotamento dos endereços IPv4.
Outro limitante para o crescimento IPv4 é que a arquitetura de roteamento do IPv4 não
prevê uma hierarquia entre sistemas autônomos. Por essa razão, o roteador de borda de
um sistema autônomo precisa conhecer as rotas de todas as redes da Internet. Se por um
lado o CIDR permitiu a criação de redes menores para evitar o desperdício de endereços,
ele também provocou um aumento exponencial do número de rotas na Internet. Isso
significa maiores tabelas nos roteadores de borda e também uma maior quantidade de
mensagens anunciadas pelo BGP.
Devemos lembrar que, inicialmente, a idéia era usar apenas as classes A e B na Internet.
Mesmo as classes C eram consideradas muito pequenas para serem anunciadas, e só
foram liberadas no início dos anos 90.
Crescimento das Entradas BGP
Edgard Jamhour
A figura mostra o crescimento exponencial do número de entradas BGP anunciadas
pelos roteadores de Borda na Internet. Atualmente, o número de rotas anunciadas supera
a 300.000. Deve-se ressaltar que não é apenas a quantidade de rotas anunciadas que é
prejudicial ao crescimento da Internet. Também, a falta de hierarquia entre sistemas
autônomos faz com que essas rotas precisem ser conhecidas por todos os AS.
A quantidade de prefixos anunciados não é igual a quantidade de prefixos alocados para
um AS. Um AS pode ter em estoque uma grande quantidade de endereços recebidos de
uma autoridade de registro, mas apenas os endereços em uso, isto é aqueles que foram
alocados para usuários finais em uma rede pertencente ao AS, é que são efetivamente
anunciados pelos seus roteadores BGP. Dessa forma, o conceito de esgotamento de
endereços IPv4 costuma ser analisado por dois pontos de vista:
Primeiro: quantos endereços os órgãos de registro ainda possuem para serem alocados.
Segundo: quantos endereços alocados a um AS ainda estão disponíveis para serem
atribuídos para usuários finais.
Vale destacar ainda que a quantidade de prefixos anunciados é dinâmica. Prefixos
podem ser criados, apagados ou reagrupados conforme as criação ou encerramento de
contratos com usuários finais, mudanças de topologia e políticas de uso de endereços
adotadas por cada AS.
Quantidade de Endereços IPv4 Disponíveis
Edgard Jamhour
Para auxiliar a análise do uso dos endereços IPv4, todo o espaço de endereçamento foi
dividido em 256 blocos de tamanho /8. Convém destacar que essa divisão é puramente
conceitual. É simplesmente mais fácil discutir como os endereços IPv4 estão alocados na
forma de 256 blocos do que na forma de 4 bilhões de endereços individuais. Seguindo
essa divisão, os endereços IPv4 podem ser classificados em três grandes categorias:
a) IETF Reserved (Reservados pelo IETF): correspondem a um bloco de endereços que
não pode ser usado como unicast. Nesse bloco estão os endereços multicast, os
endereços de loopback, os endereços privados, os endereços "site local de autoconfiguração" (169.254/16), entre outros. Atualmente, 35 blocos estão nessa categoria
(aproximadamente 13.6% do total).
b) IANA Pool (Bloco IANA): correspondem a endereços pertencentes a IANA, e que
podem ser disponibilizados para autoridades de registro regionais (ARIN, RIP, APNIC e
LACNIC) para futura alocação. Atualmente, 32 blocos estão nessa categoria (12.5 % do
total).
c) Allocated (Alocados): correspondem a endereços que foram atribuídos para
autoridades de registro locais (ARIN, RIP, APNIC e LACNIC). Atualmente, 190 blocos
estão nessa categoria (74.2 % do total).
Distribuição da Alocação
Edgard Jamhour
Por análise feita anteriormente, observamos que a quantidade de endereços IPv4
disponíveis corresponde apenas ao bloco da IANA que representa 12.5 % do total.
Contudo, para uma análise mais precisa, precisamos considerar que nem todos os
endereços alocados estão efetivamente em uso. O termo alocado neste gráfico significa
que os endereços foram designados para distribuição por uma autoridade de registro
regional, mas esses endereços podem estar ainda disponíveis para criação de novas
redes.
A figura apresenta uma divisão mais precisa de como os endereços IPv4 estão sendo
utilizados, pois considera uma diferença entre endereços "alocados", "atribuídos" e
"anunciados", conforme descrito a seguir:
a) Allocated (Alocados): correspondem a endereços que foram atribuídos para
autoridades de registro locais (ARIN, RIP, APNIC e LACNIC) mas que ainda não foram
atribuídos para nenhuma entidade ou instituição. Atualmente, 19.7 blocos estão nessa
categoria (7.7% do total).
b) Assigned (Atribuídos): correspondem a blocos que já foram atribuídos para entidades
ou instituições, mas que não estão em uso. Atualmente, 49.2 blocos estão nessa
categoria (19.2% do total).
c) Advertised (Anunciados): correspondem a blocos que estão sendo anunciados pelos
roteadores BGP e que estão, supostamente, em uso. Atualmente, 120 blocos estão
nessa categoria (46.9% do total).
Distribuição da Alocação IPv4
Edgard Jamhour
Das análises anteriores, concluímos que a quantidade de endereços IPv4 disponíveis é
de 110 blocos (aproximadamente 39.4% do total):
a) 32 blocos do bloco IANA (12.5% do total)
b) 19.7 blocos alocados, mas não atribuídos (7.7% do total)
c) 49.2 blocos atribuídos, mas não anunciados (19.2% do total)
Dessa forma, podemos afirmar que a Internet já ultrapassou a metade de seu tamanho
máximo teórico. A figura mostra como os endereços atribuídos pela IANA estão
distribuídos pelas diferentes autoridades de registro regionais (RIR: ARIN, APNIC,
RIPENCC, LACNIC e AFRINIC). Conforme mostra a figura, observa-se um esgotamento
de endereços em quase todas as regiões do mundo. A quantidade de endereços
disponíveis para novos usuários finais (marcados como Pool, em amarelo, na figura) é
pequena em todas as RIR do mundo.
No início, a América do Norte recebeu um grande quantidade de blocos, mesmo antes da
política de alocação estar consolidada. Nos últimos anos observou-se um esforço da
IANA para alocar mais blocos para regiões menos favorecidas como a Ásia (APNIC) e
mesmo a Europa (RIPENCC), em detrimento da América do Norte (ARIN).
Na figura, observamos que nem todos os endereços IP foram atribuídos pelas RIR. De
fato, a própria IANA fez uma grande parte das atribuições para usuários finais (indicado
pela classe IANA Registry). A classe VARIOUS pool indica que vários blocos foram
alocados antes da criação das RIRs. Atualmente a gerência dos blocos dessa classe está
distribuída entre várias entidades relacionadas a Internet.
Previsão de Esgotamento
Edgard Jamhour
A próxima questão é saber quanto tempo irá levar para que os 39.4% dos endereços
restantes sejam exauridos.
O primeiro bloco de endereços que deverá se esgotar é o que pertence a própria IANA.
Como no geral, a quantidade de alocações vem crescendo a cada ano, deve-se esperar
que o esgotamento do bloco IANA aconteça muito em breve (as últimas estimativas são
de 2011).
Quando o bloco IANA estiver totalmente exaurido, não haverá possibilidade de novas
alocações para as autoridades de registro regionais. Isto significa que a IANA não terá
mais a possibilidade de suprir as necessidades de crescimentos de áreas emergentes
representadas pelo LACNIC (América Latina) e AfriNIC (Africa).
A seguir, deverão ser esgotados os blocos de endereços ainda disponíveis nas RIR, em
torno de 2012. Quando isso acontecer, não será mais possível para os ISP (provedores
de acesso a Internet) obterem mais endereços para suprir a demanda de seus usuários.
O esgotamento definitivo dos endereços IP só acontecerá quando não houverem mais
endereços disponíveis pelos ISP. A data prevista para isso é 2018. Quando os endereços
obtidos pelos ISP se esgotarem, poderemos dizer que o tamanho da Internet estará
estagnado, pois não será possível a entrada de novos usuários finais na rede, a menos
que seja feito com conectividade limitada (isto é, com endereços privados).
IPv6: Internet Protocol versão 6
Aplicação
5. Aplicação
HTTP, FTP, TELNET,
SSH, POP3, SNMP,SMTP, ...
4. Transporte
TCP, UDP,
SCTP, DCCP ...
3. Rede
IP (IPv4, IPv6) , ARP,
RARP, ICMP, IPSec ...
2. Enlace
Ethernet, 802.11 WiFi, IEEE 802.1Q, 802.11g,
HDLC, Token ring, FDDI, PPP, Frame Relay, ...
1. Física
Modem, RDIS, RS-232,
EIA-422, RS-449, Bluetooth, USB, ...
Sistema
Operacional
Interface
Física
Edgard Jamhour
O desenvolvimento da versão 6 do protocolo IP (denominada IPv6) teve início em 1991.
Por razões históricas, devemos ressaltar que não houve versão 5, pois o termo era usado
para um outro projeto experimental do IETF, que acabou não se concretizando.
Conforme mostra a figura, o IPv6 é um protocolo de rede que atua na mesma camada do
IPv4. O suporte ao IPv6 é feito pela inclusão de um novo protocolo de rede nos sistemas
operacionais de equipamentos hosts e roteadores. Deve-se observar que a maioria dos
sistemas operacionais modernos já é implementada segundo o conceito de multiprotocolo.
Por exemplo, é comum que o S.O. de computadores e roteadores tenham suporte
simultâneo a protocolos como IPx, IPv4 e NetBEUI (este último, apenas em
computadores Windows). Dessa forma, acrescentar mais um protocolo de rede é uma
tarefa relativamente fácil para esses sistemas, uma vez que nenhuma alteração de
hardware, ou alteração profunda na arquitetura do S.O., é necessária.
De fato, atualmente, o IPv6 é suportado pela maioria dos sistemas operacionais
comerciais e equipamentos de rede. Deve-se destacar também que o IPv6 não implica
em nenhuma alteração dos protocolos de transporte (TCP e UDP), nem dos protocolos de
aplicação.
Infelizmente, contudo, a aplicação propriamente dita precisa ser reescrita para suportar o
IPv6 devido a necessidade de passagem de novos parâmetros através da interface
sockets.
Melhorias IPv6
Endereçamento
Endereços de 128 bits
Protocolo
Cabeçalhos especializados
Eliminação de campos pouco usados
Identificação do tipo de tráfego
Roteamento
Endereçamento Hierárquico
Rotas Explícitas
Melhor suporte ao multicast
Segurança
Autenticação e Criptografia Mandatórios
Mais classes de endereçamento privado
Gerenciamento
Mecanismo de auto-configuração
Suporte a mobilidade
Eliminação do Broadcast
Edgard Jamhour
Conforme mostrado na figura, as melhorias do IPv6 podem ser agrupadas em cinco
grandes categorias.
a) Endereçamento. Os endereços IPv6 foram ampliados para um número supostamente
inesgotável (2^128).
b) Cabeçalho do protocolo. O IPv6 permite criar cabeçalhos de tamanho variável, de
acordo com as necessidades específicas do pacote que está sendo enviado. Essa
melhoria foi implementada pela introdução de cabeçalhos opcionais especializados
denominados cabeçalhos de expansão (extension headers). Além disso, alguns campos
pouco usados do IPv4 foram eliminados. O IPv6 introduziu também a possibilidade de
identificar aplicações ao nível do protocolo de rede, eliminando a necessidade de vascular
as portas dos protocolos de transporte, como é feito no IPv4. O IPv6 também define a
possibilidade de tunelamento sem necessidade de protocolos adicionais.
c) Roteamento. O IPv6 introduziu o conceito de endereçamento hierárquico que permite
um grande agrupamento de rotas nas tabelas de roteamento dos roteadores BGP. Foi
introduzido também a possibilidade de escolher a rota por onde o pacote vai passar e um
melhor suporte ao multicast.
d) Segurança. As extensões definidas no IPsec foram tornadas mandatórias para o IPv6.
O IPv6 cria também mais classes de endereçamento privado, oferecendo maior
segurança e opções de gerenciamento para estruturação da rede do usuário.
e) Gerenciamento. O IPv6 define um mecanismo de auto-configuração (atribuição
automática de endereço sem DHCP) e um melhor suporte a mobilidade, através de um
mecanismo que dispara a troca automática do endereço IP quando o usuário muda de
rede.
Datagrama IPv6 X IPv4
IPv6
CABEÇALHO DE BASE
(NEXT HEADER TIPO 1)
IPv4
CABEÇALHO ÚNICO
CABEÇALHO TIPO 1
(NEXT HEADER TIPO 5)
CABEÇALHO TIPO 5
(NEXT HEADER TIPO 2)
CABEÇALHO TIPO 2
(NEXT HEADER TCP)
CABEÇALHO
TRANSPORTE
CABEÇALHO
APLICAÇÃO/DADOS
CABEÇALHO
TRANSPORTE
CABEÇALHO
APLICAÇÃO/DADOS
Edgard Jamhour
O IPv6 introduziu várias alterações em relação ao IPv4. A alteração mais conhecida foi o
aumento significativo do espaço de endereçamento de 2^32 (IPv4) para 2^128 (IPv6).
Contudo, muitas outras alterações foram feitas, a começar pela forma como o cabeçalho
IPv6 está estruturado.
A estratégia usada pelo cabeçalho IPv4 é considerada obsoleta. O IPv4 tem um conjunto
fixo de campos, que estão presentes mesmo quando eles não são usados. Por exemplo,
atualmente sabemos que a maioria dos pacotes IP é fragmentada na origem (pelo
sistema operacional do transmissor), de maneira que os campos de fragmentação
presentes no pacote IPv4 raramente são usados. Contudo, não é possível criar pacotes
IPv4 sem esses campos quando eles não são necessários. No IPv6 isso é possível.
O cabeçalho IPv6 usa uma estratégia de composição de cabeçalho similar a todos os
novos protocolos definidos pelo IETF: um cabeçalho de base, seguido por zero ou mais
cabeçalhos de extensão. O cabeçalho de base IPv6 é bastante simples. Ele inclui apenas
funções que são necessárias para qualquer aplicação IP, como os endereços de origem e
destino. Já os cabeçalhos de extensão contém campos adicionais que são inseridos
apenas quando necessário.
A figura ilustra esse conceito. Todos os cabeçalhos IPv6 (base e extensão) trazem um
campo denominado NEXT HEADER. Esse campo indica o que virá após o cabeçalho: um
cabeçalho de extensão IPv6 ou os protocolos de transporte (TCP/UDP), ou simplesmente
nada. O IPv6 define vários tipos de cabeçalho de extensão. Esses cabeçalhos contém
campos especializados para controlar funções como segurança, roteamento e
fragmentação.
Cabeçalho de Base IPv6
byte 1
Version
byte 2
byte 3
Byte DS
byte 4
Flow Label
Payload length
Next Header
Hop Limit
Source Address
(16 bytes)
IPv6
Destination Address
(16 bytes)
Version
H.Len.
Byte DS
Fragment ID
IPv4
TTL
Total Length
flags
Protocol
Fragment Offset
Header Checksum
Source Address
Destination Address
Options ...
Edgard Jamhour
A figura mostra uma comparação entre os campos IPv4 e o cabeçalho de base IPv6. Os
seguintes campos IPv4 foram eliminados do cabeçalho de base:
a) Campos de Fragmentação: (Fragment ID, flags e Fragment Offset). Como o IPv6
considera que a fragmentação é um evento de pequena probabilidade, esses campos
foram deslocados para um cabeçalho de extensão. O IETF define que todas as redes com
suporte a IPv6 devem garantir um MTU mínimo de 1280 bytes. Caso seja necessário
fragmentar um pacote até esse tamanho, essas redes devem garantir que a fragmentação
e remontagem seja feita pelas camadas inferiores, de forma transparente para o IPv6.
b) Campo de Checksum: (Header Checksum). A operação de verificação desse campo
foi considerada muito custosa em termos de CPU para os roteadores, principalmente
quando grandes velocidades de enlace estão envolvidas. Adicionalmente, sabe-se que
redes guiadas apresentam pequena probabilidade de erros nas transmissão de pacotes, e
redes sem fio apresentam recursos de verificação de erros nas camadas inferiores.
c) Campos de opção: (Header Length, Options). Como o cabeçalho IPv4 era de tamanho
variável (devido ao campo Options), eram necessários dois campos para descrever o
tamanho do pacote: Header Length e Total Length. Como o cabeçalho de base IPv6 tem
tamanho fixo (40 bytes), utiliza-se agora apenas o campo "Payload Length".
Além de eliminar vários campos, o IPv6 renomeou alguns e introduziu um novo campo. O
TTL do IPv4 foi renomeado para Hop Limit, mantendo o mesmo significado. O TOS do
IPv4 está presente com sua nova denominação: byte DS. O novo campo "Flow Label" foi
introduzido.
Versão e Flow Label
Pilha
IPv4
Pilha
IPv6
IP version=4
IPv6 version=6
Fila
Alta
Prioridade
Fila
Baixa
Prioridade
IP flow label =1
IPv6 flow label=2
Edgard Jamhour
Os campos do cabeçalho de base IPv6 são os seguintes:
a) Version (4 bits). Contém o número fixo 6. É utilizado pelos roteadores e demais hosts
para redirecionar os pacotes IP recebidos para a pilha de protocolos adequada.
Equipamentos sem suporte a IPv6 simplesmente descartam os pacotes recebidos, como
sendo pertencentes a um protocolo desconhecido.
b) Flow Label (20 bits): Esse novo campo cria a possibilidade de identificar o tipo de
tráfego transportado ao nível da camada de rede. Devemos lembrar que, no IPv4, a única
maneira de identificar o tipo de tráfego era através de informações de portas das camadas
de transporte. Pelo conceito de isolamento de camadas, os roteadores deveriam poder
operar sem necessidade de verificar as camadas superiores. O IPv6 corrige essa falha
pois possibilita identificar 1 milhão de conexões distintas entre 2 pares de IP. A principal
aplicação do flow label é o tratamento diferenciado de tráfego para implementação de
políticas de qualidade de serviço.
c) Payload Length (16 bits): Esse campo indica quantos bytes seguem o cabeçalho de
base de 40 bytes. De forma similar ao IPv4, o tamanho máximo de um pacote IPv6 é
64Kbytes. Contudo, no IPv6 é possível enviar pacotes de tamanho superior, se for
utilizado o cabeçalho de extensão denominado "jumbograma".
d) Next Header (8bits): Esse campo tem significado similar ao "Protocol Type" (tipo de
protocolo) do IPv4. Ele é utilizados para identificar qual cabeçalho irá seguir ao cabeçalho
de base. Esse campo pode utilizar os códigos da IANA para protocolos conhecidos (como
o TCP, UDP, ICMP, etc), mas também os novos códigos criados para os cabeçalhos de
extensão IPv6.
e) Hop Limit (8 bits): Equivalente ao Time to Live (TTL) do IPv4. O novo termo é mais
adequado, uma vez que o TTL nunca foi medido em tempo, mas sim em número de
saltos. O número máximo de saltos em uma rede IPv6 está limitado a 256, da mesma
forma que ocorria na rede IPv4.
Cabeçalhos de Extensão
CABEÇALHO DE BASE
(NEXT HEADER 0)
CABEÇALHO 0
(HOP-BY-HOP OPTIONS)
cria opções que influenciam
a ação de roteadores
CABEÇALHO DE BASE
(NEXT HEADER 60)
CABEÇALHO 60
(DESTINATION OPTIONS)
cria opções que influenciam
apenas o destino final
CABEÇALHO DE BASE
(NEXT HEADER 44)
CABEÇALHO 44
(FRAGMENTATION)
inclui os campos opcionais
de fragmentação
CABEÇALHO DE BASE
(NEXT HEADER 51)
CABEÇALHO 51
(AUTHENTICATION)
inclui campos de
autenticação (AH do IPsec)
CABEÇALHO DE BASE
(NEXT HEADER 50)
CABEÇALHO 50
(ENCRYPTED SECURITY PAYLOAD)
inclui campos de criptografia
(ESP do IPsec)
CABEÇALHO DE BASE
(NEXT HEADER 43)
CABEÇALHO 43
(ROUTING)
CABEÇALHO DE BASE
(NEXT HEADER 59)
inclui campos para rotas
explícitas
Sem cabeçalho de extensão
Edgard Jamhour
Atualmente, 6 tipos de cabeçalhos de extensão estão definidos:
a) Hop-by-hop options (código de protocolo 0): permite incluir campos adicionais com
informações que serão analisadas pelos roteadores ao longo do caminho do pacote
b) Destination options (código de protocolo 60): permite incluir campos adicionais que
são interpretados pelo destino final, sendo ignorados pelos roteadores ao longo do
caminho.
c) Fragmentation (código de protocolo 44): inclui os campos de fragmentação que foram
removidos do IPv4.
d) Authentication (código de protocolo 51): inclui campos para autenticação dos pacotes
IPv6. Corresponde ao protocolo AH do IPsec.
e) Encrypted security payload (código de protocolo 50): inclui campos para criptografia
do pacote IPv6. Corresponde ao protocolo ESP do IPsec.
f) Routing (código de protocolo 43): inclui campos que permitem definir de forma total ou
parcial a seqüência de roteadores que o pacote deverá percorrer para chegar ao seu
destino.
Um pacote apenas com o cabeçalho IPv6 de base (sem protocolo de transporte ou
mesmo aplicação) é definido pelo tipo de protocolo 59.
Deve-se observar que os exemplos mostrados na figura são compostos apenas do
cabeçalho de base seguido por um único cabeçalho de extensão. Contudo, é possível ter
múltiplos cabeçalhos de extensão no mesmo pacote. Por exemplo, poderíamos ter um
pacote com 4 cabeçalhos de extensão em seqüência: rota explícita, seguido da
autenticação com AH, criptografia com ESP e, se necessário, fragmentação. Apenas os
cabeçalhos de extensão do tipo Hop-by-Hop e Destination options podem aparecem mais
de uma vez no pacote (no máximo duas) .
Hop-by-Hop Options
próximo cabeçalho de extensão
tamanho do cabeçalho de extensão
(menos 8 bytes que são mandatários)
código que identifica o tipo do campo
Next
Header
header
length
Type
Length
tamanho do campo em bytes
Value (Valor do Campo)
8 bytes de cabeçalho
tipo jumbograma
Next
Header
0
194
4
tamanho do pacote
(até 4Gbytes)
Jumbo payload length
1 byte
1 byte
1 byte
o campo tem 4 bytes
1 byte
Edgard Jamhour
O cabeçalho hop-by-hop permite criar campos adicionais que serão analisados por todos
os roteadores ao longo do trajeto do pacote, incluindo o nó de destino.
Cada cabeçalho de extensão permite adicionar vários campos no cabeçalho, segundo o
formato T-L-V, isto é, Type (tipo), Length (tamanho) e Value (valor). A estrutura do
cabeçalho está ilustrada pela figura (a figura mostra apenas 1 TLV, mas vários são
possíveis). O tipo do cabeçalho é definido como um valor de 8 bits, e segue o seguinte
formato: XX–Y–ZZZZZ, onde:
XX: 2 bits que indicam como um nó IPv6 que não reconhece a opção deve proceder. As
opções são: "ignorar a opção e continuar a processar o pacote" (00), "descartar o pacote
em silêncio" (01), "descartar o pacote enviando um ICMP" (10), "descartar enviando ICMP
apenas se não for multicast" (11).
Y: 1 bit que indica se a opção pode ser modificadas pelos roteadores ao longo do trajeto
(como acontece com o TTL, por exemplo). Se houver mudança (1), esse campo não pode
ser incluído em nenhum checksum.
ZZZZZ: 5 bits que definem a opção, isto é, o significado do campo que está sendo
estendido.
Por exemplo, o campo de tamanho do cabeçalho de base IPv6 possui apenas 16 bits, o
que permite definir somente pacotes de 64Kbytes. Existe uma opção denominada
"jumbograma" (tipo 194), que adiciona um campo de tamanho de 32 bits que permite criar
pacotes de até 4Gbytes.
O valor 194 corresponde a 11000010 em binário, e indica:
a) XX=11: Descartar enviando ICMP caso não seja multicast
b) Y=0: O valor não muda ao longo do caminho
c) Z=00010: Opção jumbograma
Destination Options
1 byte
Next Header
seqüência de
opções
individuais.
1 byte
Header Length
1 byte
1 byte
Type
Length
Value
Type
Length
Value
Type
Length
....
Edgard Jamhour
Um outro tipo de cabeçalho de extensão que permite incluir campos ao cabeçalho IPv6 é
o "Destination Options". Esse campo tem uma estrutura similar ao cabeçalho de extensão
"Hop-by-Hop Options", contudo, os cabeçalhos diferem na forma como são processados.
O cabeçalho de opções "Hop-by-Hop" é interpretado pelos roteadores ao longo do trajeto
do pacote e o de opções "Destination" apenas pelo elemento de rede que é identificado
pelo endereço IP de destino do pacote. Opcionalmente, o cabeçalho de opções
"Destination" pode também ser interpretado por rotadores apontados pelo cabeçalho de
rotas explícitas que será discutido na seqüência.
Esse cabeçalho é formado por um conjunto de opções no formato "TLV" (Tipo, Tamanho
e Valor). De acordo com o IETF todas as opções precisam ser processadas na mesma
ordem em que aparecem no cabeçalho. O comportamento que o destinatário deve ter ao
encontrar uma opção desconhecida (isto é, que ele não sabe processar) é definido de
pelo tipo da opção (Type), de forma idêntica a descrita para o cabeçalho de opções "Hopby-Hop".
Os cabeçalhos de opções podem ocorrer no máximo duas vezes em cada pacote IPv6.
Routing Header
Next Header
Header Size
Type
Seg. Left
Routing Data ....
o formato depende do
campo tipo
tipo de cabeçalho de rotas
Next Header
Reserved
Header Size
Type=0
Strict/Loose Bitmat
Seg. Left
número máximo de saltos
restantes (máximo 23)
Address Router 1 (16 bytes)
Address Router 2 (16 bytes)
....
Address Router 24 (16 bytes)
Edgard Jamhour
O cabeçalho de roteamento ("Routing") define a rota por onde um pacote IPv6 irá passar
de forma estrita (strict) ou parcial (loose). O cabeçalho de roteamento segue a estrutura
mostrada na parte superior da figura. Os campos "Next Header" e "Header Size" tem a
mesma função que nos cabeçalhos de extensão discutidos anteriormente. O campo Type
refere-se a maneira como as rotas serão descritas no campo "Routing Data" do
cabeçalho. Uma rota é definida como uma seqüência de saltos, isto é, uma seqüência de
endereços de roteadores por onde o pacote deverá passar até chegar ao seu destino. O
campo "Segments Left" define a quantidade de saltos restantes que o pacote deverá
executar a fim de completar toda a seqüência definida.
No presente momento, só foi definido um tipo de descrição de rotas para o IPv6
denominado "0". O formato de um cabeçalho do tipo zero é mostrado na parte inferior da
figura. Esse formato de rotas permite definir até 24 saltos, descritos como a lista de
endereços IPv6 das interfaces dos roteadores por onde o pacote deverá passar. Observe
que os endereços são precedidos de um campo denominado "Strict/Loose Bitmat". Esse
campo é formado por 24 bits que definem como cada um dos saltos deverá ser
interpretado.
Se o valor no bitmap correspondente a um salto for "1", o salto é considerado estrito
(strict) e ser for "0", o salto e considerado parcial (loose). Um salto estrito significa que o
próximo roteador precisa ser um vizinho imediato, e não pode haver roteadores
intermediários entre o salto corrente e o próximo salto. Se salto for especificado como
loose, o pacote poderá passar por roteadores intermediários antes de chegar ao próximo
roteador especificado no cabeçalho. A cada vez que um pacote passa por um roteador
especificado na lista de saltos, o campo "Segments Left" é decrementado.
Recentemente iniciou-se uma discussão sobre a suscetibilidade desse cabeçalho a
ataques do tipo DOS (Deny Of Service), de forma que a RFC 5095 tornou as rotas do tipo
"0" obsoletas. Ainda não foi definida outro tipo de rota para substituí-la.
Roteamento
strict routing
4-11111
ABCDE
5-11111
ABCDE
B
D
3-11111
ABCDE
A
loose routing
2-000
ACE
C
2-11111
ABCDE
2-000
ACE
E
0-11111
ABCDE
1-000
ACE
3-000
ACE
A
1-11111
ABCDE
C
1-000
ACE
E
0-000
ACE
Edgard Jamhour
A figura ilustra como um cabeçalho de roteamento funciona. A parte superior da figura
ilustra um cenário onde a rota foi especificada de forma estrita e a parte inferior um
cenário onde a rota foi definida apenas parcialmente.
No cenário estrito, o roteador A recebe um pacote que especifica que ele deverá passar
por 5 roteadores, e que todos eles devem ser vizinhos. Cada vez que o pacote passar por
um roteador, o campo "segments left" (segmentos remanescentes) é decrementado, de
maneira que, quando o pacote é transmitido pelo último roteador da lista de saltos, o valor
desse campo é zero.
No cenário parcial, o roteador A recebe um pacote que especifica que ele deverá passar
por 3 roteadores, mas que eles não precisam ser vizinhos. Observe que o campo
"segments left" não é decrementado quando o pacote passa por um roteador que não
pertence a lista de saltos. É possível ter cenários onde saltos estritos e parciais estão
presentes. Para isto basta criar um bit map mesclando saltos do tipo "1" e "0".
Esse método de especificação de rotas é muito semelhante ao adotado pelos protocolos
de sinalização do MPLS. A diferença, contudo, é que no MPLS os pacotes não carregam
a informação da seqüência de saltos, mas sim um LABEL que identifica o caminho. Então
a seqüência de saltos precisa ser configurada anteriormente nos roteadores utilizando
tabelas especiais para encaminhamento de pacotes por saltos.
O método do IPv6 é mais simples, mas aumenta significativamente o overhead dos
pacotes, uma vez que o cabeçalho de saltos é muito grande devido ao tamanho dos
endereços IPv6.
Fragmentation Header
indica se é o último fragmento ou não.
indica a posição do fragmento
(múltiplo de 8 bytes).
1 byte
Next
Header
1 byte
Reservado
13 bits
Fragment Offset
1 bit
1 bit
res
MF
Identification
Edgard Jamhour
Em uma rede IPv6, toda a fragmentação deve ser feita pelo nó de origem. Esse
procedimento é distinto da estratégia do IPv4, onde o próprio roteador tinha a
possibilidade de re-fragmentar o pacote para adequá-lo ao MTU de seu enlace de saída.
Conforme discutido anteriormente, o IETF define que todas as redes com suporte a IPv6
devem garantir um MTU mínimo de 1280 bytes. Caso seja necessário fragmentar um
pacote até esse tamanho, essas redes devem garantir que a fragmentação e remontagem
seja feita pelas camadas inferiores, de forma transparente para o IPv6.
Se um host enviar um pacote que exceda o MTU mínimo, poderá ocorrer que, ao longo do
caminho, algum roteador não consiga colocar o pacote no seu enlace de saída. Nesse
caso, o roteador envia uma mensagem ICMP para origem, informando que o MTU foi
excedido. Cabe ao transmissor fragmentar o pacote para adequá-lo ao enlace de menor
MTU ao longo do caminho.
O cabeçalho contém basicamente os mesmos campos que haviam no IPv4 para essa
finalidade. Todos os fragmentos de um mesmo pacote original são identificados por um
número aleatório de 32 bits denominado "Identification" (ou Fragment Identification). Para
permitir que o destino seja capaz de reordenar os pacotes recebidos, cada fragmento é
identificado por um offset, que indica sua posição em relação ao pacote original.
Finalmente, o flag MF indica se o fragmento recebido é o último (MF=1), ou se haverá
mais fragmentos (MF=0).
Em relação ao IPv4, apenas o flag DF (Do Not Fragment), que informa a opção de não refragmentar o pacote pelo roteador foi eliminado, pois, no IPv6, essa opção é sempre
verdadeira.
Extensões de Segurança: IPsec AH e ESP
Aplicação
Transporte
IP
X
Descarte antes de
atingir as camadas
superiores
IPsec
Enlace
Verificações de
Segurança
ipsec
ipsec
ipsec
Edgard Jamhour
Nos anos 90, o IETF publicou uma extensão de segurança para o protocolo IP
denominada IPsec. O IPsec definiu campos adicionais para o protocolo IP, de maneira a
dar suporte as funções de autenticação, assinatura digital e criptografia ao nível dos
pacotes. Existem duas versões de IPsec, o AH (Authentication Header) e o ESP
(Encrypted Security Payload). O primeiro dota os pacotes apenas de informações de
autenticação. O segundo, dota os pacotes de informações de autenticação e criptografia.
Essas funções básicas de segurança sempre estiveram disponíveis em aplicações.
Contudo, proteger apenas as aplicações não inibe que ataques sejam feitos as camadas
inferiores do sistema operacional de roteadores e computadores. Por exemplo, um
usuário pode fazer um acesso seguro via SSH até um computador remoto, protegido por
um firewall que libera apenas algumas aplicações selecionadas. O serviço SSH desse
usuário está protegido pela própria aplicação. Contudo, o sistema operacional do
computador pode ser atacado através de inúmeras estratégias, que criam pacotes falsos
com números de porta, informações de fragmentação, números de seqüência e flags TCP
alterados de modo a enganar o firewall e fazer roubos das conexão do usuário.
O IPsec resolveu esse problema definindo um cabeçalho denominado AH (Authentication
Header), que permite incluir no pacote informações que evitam a falsificação do pacote.
Quando o IPsec AH é usado, pacotes falsos são descartados pelas camadas inferiores do
sistema operacional, antes que possam causar algum dano nas camadas superiores. O
cabeçalho ESP (Encrypted Securty Payload) é mais completo, pois além de incluir
informações que dão suporte a autenticação, ele inclui também informações que
permitem efetuar a criptografia do campo de dados do pacote. Quando combinado com
opções de tunelamento, o IPsec ESP permite esconder inclusive os endereços IP dos
usuários envolvidos na comunicação.
Cabeçalhos IPsec: AH e ESP
1 byte
1 byte
Next Header
Length
1 byte
1 byte
reserved
reserved
AH
SPI: Security Parameter Index
Sequence Number
Authentication Data
(ICV: Integrity Check Value)
Campo de Tamanho Variável, depende do protocolo de autenticação
utilizado
Security Parameter Index
HEADER
ESP
Sequence Number
Encrypted Payload
(dados criptografados)
Pad (0 – 255 bytes)
Authentication Data
(tamanho variável)
Pad Length
Next Header
TRAILER
AUTH
Edgard Jamhour
A especificação do IPsec para IPv4 e para IPv6 é praticamente idêntica. Contudo, no IPv4
o suporte ao IPsec é considerado facultativo. Já no IPv6, seu suporte é mandatário. Isto
significa que qualquer dispositivo de rede que suporte IPv6 também suporta IPsec. O
cabeçalho de extensão AH é ilustrado na parte superior da figura, e o cabeçalho de
extensão ESP é ilustrado na parte inferior da figura. Convém lembrar que uma
comunicação IPsec necessita que seja estabelecido previamente uma associação de
segurança (SA – security association) entre os pares envolvidos na comunicação. Uma
SA é estabelecido de forma manual ou através do protocolo IKE (Internet Key Exchange),
e define o algoritmo e a chave de assinatura ou criptografia que devem ser utilizados para
validar o pacote.
O cabeçalho AH é formado pelos seguintes campos:
Next Header: protocolo encapsulado pelo IPsec, de acordo com os códigos definidos pela
IANA (UDP, TCP, etc ...)
Length: comprimento do cabeçalho em múltiplos de 32 bytes.
Security Parameter Index: identificador de 32 bits da SA que deve ser usada para testar
o pacote.
Sequence Number: número seqüência para evitar a duplicação de pacotes.
Authentication Data: dados da verificação de integridade (ICV), cujo tamanho variável
depende do algoritmo utilizado. Os algoritmos suportados são MD5, SHA, SHA1 e as
opções de segurança do AES.
O cabeçalho ESP é formado pelos seguintes campos:
Header: SPI e Sequence Number: Mesmas funções do AH.
Trailler: Torna os dados múltiplos de um número inteiro, conforme requerido pelo
algoritmo de criptografia. O trailler também é criptografado. Os algoritmos de criptografias
suportados são o 3DES e o AES.
Auth: ICV (Integrity Check Value) calculado de forma idêntica ao cabeçalho AH. Este
campo é opcional.
Endereços IPv6
• Definido pela RFC 2373
– IPv6 Addressing Architecture
• Exemplo de Endereço IPv6:
– FE80:0000:0000:0000:68DA:8909:3A22:FECA
• endereço normal
– FE80:0:0:0:68DA:8909:3A22:FECA
• simplificação de zeros
– FE80::68DA:8909:3A22:FECA
• omissão de 0’s por :: (apenas um :: por endereço)
– ::1
• endereço LOOPBACK
Edgard Jamhour
Os endereços IPv6 são números de 128 bits (16 bytes). Ao invés de adotar a notação
decimal pontuada do IPv4, onde o endereços é formado por quadro bytes separados por
".", o IPv6 representa seu endereço na forma de 8 palavras de 16 bits, separadas por ":".
Cada uma das palavras que forma o endereços IPv6 é representada em hexadecimal.
Dessa forma, um endereço IPv6 tem o seguinte formato:
FE80:0000:0000:0000:68DA:8909:3A22:FECA
As palavras que forem formadas unicamente por quatro zeros em hexadecimal podem ser
substituídas por um único zero, conforme o exemplo a seguir:
FE80:0:0:0:68DA:8909:3A22:FECA
Para tornar os endereços ainda mais compactos, uma seqüência de zeros pode ser
substituídas pelo símbolo "::", conforme o exemplo abaixo. Contudo, essa simplificação
pode ocorrer uma única vez no endereço, ou não será possível determinar quantos zeros
correspondem a cada símbolo "::".
FE80::68DA:8909:3A22:FECA
O símbolo "::" pode estar também no início do endereço. Por exemplo, o endereço
loopback IPv6 é representado como:
::1, que é equivalente a 0000:0000:0000:0000:0000:0000:0000:0001
Os endereços IPv6 são seguidos de uma máscara de subrede na forma compacta
(/"tamanho do prefixo"), de maneira similar aos endereços IPv4:
FE80::68DA:8909:3A22:FECA/80
Categorias de Endereço
O pacote anycast é enviado
para o destinatário que tiver a
rota de menor custo até a
origem.
A
C
unicast
B
anycast
OU
O pacote unicast é
enviado apenas para C.
Uma cópia do pacote é entregue
para cada um dos membros do
grupo multicast, formado por B e C.
multicast
B
Edgard Jamhour
O IPv6 define três categorias de endereço: o unicast, o anycast e o multicast. O broadcast
foi extinto no IPv6.
Os endereços de unicast são associados a uma única interface de um computador ou
roteador. Por exemplo, suponha que o computador A enviou um pacote para rede,
utilizando o endereço de unicast do computador C com destino. O pacote será entregue
unicamente para o computador C.
Os endereços de multicast podem estar associados a interfaces de múltiplos
computadores ou roteadores. Exemplos de endereços multicast são aqueles que
representam roteadores ou servidores DHCP, isto é, um roteador além do endereço
multicast, também responde a um endereço multicast que é comum a todos os
roteadores. O mesmo raciocínio se aplica a servidores DHCP e muitos outros serviços
que precisam ser localizados automaticamente. Suponha na figura que o computador A
enviou um pacote para o endereço multicast do qual os computadores B e C são
membros. Assim que pacote encontra uma bifurcação no caminho, o pacote é duplicado
para que uma cópia siga cada um dos caminhos disponíveis para cada um dos membros
do grupo multicast.
O anycast é um endereço compartilhado por mais de um elemento da rede. Os endereços
anycast tiram proveito do fato das rotas IP sempre utilizarem o caminho mais curto.
Dessa forma, um pacote para um endereço anycast será sempre enviado para o elemento
de rede que esteja mais próximo da origem. Suponha, na figura, que o computador A
enviou um pacote para um endereço anycast compartilhado pelos computadores B. No
caso, o pacote será enviado para apenas um deles, aquele que tiver a rota com menos
custo até o computador A.
Classes de Endereço IPv6
Prefix (hexa)
Fraction of
Address Space
Reserved
0::/8
1/256
Unassigned
…
…
NSAP Allocation
200::/7
1/128
IPX Allocation
400::/7
1/128
Unassigned
…
…
Aggregatable Global Unicast
2000::/3
1/8
Addresses
Unassigned
…
…
Link Local Unicast
. Addresses
FE80::/10
1/1024
Site Local Unicast Addresses
FEC0::/10
1/1024
Allocation
Multicast Addresses
Total Alocado
FF00::/8 1
1/256
15%
Edgard Jamhour
O espaço de endereçamento IPv6 foi dividido em diversas classes, conforme indica a
tabela acima. Algumas dessas classes foram criadas para efetuar mapeamentos com
outras redes, como IPX e OSI. Outras classes representam endereços unicast públicos,
endereços unicast privados e endereços multicast. A tabela mostra as classes mais
importantes e o prefixo associada a cada uma delas.
a) A classe 0::/8 foi reservada para fazer mapeamentos com outras redes, incluindo o
IPv4. Uma classe "/8" representa 288 mais endereços do que todo o endereçamento IPv4
existente. Por exemplo, qualquer endereço IPv4 podem ser representados no formato
IPv6 usando o formato: "::FFFF:<IPv4>". Esse formato permite que hosts IPv6 enviem
pacotes para computadores IPv4 através de roteadores com suporte aos mecanismos de
transição, conforme discutidos na seqüência desse módulo.
b) A classe 200::/7 foi reservada para efetuar mapeamentos com redes baseadas em
endereçamento OSI.
c) A classe 400::/7 foi reservada para efetuar mapeamentos com redes IPx
d) A classe 2000::/3, chamada AGGR, corresponde aos endereços unicast públicos
e) A classe FE80::/10 representa endereços unicast privados de acesso restrito a um
enlace. Computadores com endereços dessa classe só conseguem se comunicar com
outros computadores no mesmo HUB ou Switch, uma vez que esses endereços não são
roteáveis nem mesmo por roteadores privados.
f) A classe FEC0::/10 representa endereços unicast privados de acesso restrito a uma
WAN privada. Computadores que tenham endereços nessa classe podem se comunicar
com outros computadores da mesma organização, independente de onde estejam, mas
não tem acesso a Internet. Esses endereços são os equivalentes aos endereços IPv4
privados.
Aggregatable Global Unicast
3
13
13
19
16
64
FP
TLA ID
Sub-TLA
NLA ID
SLA ID
Interface ID
AGGR
FP: Format Prefix (AGGR=001)
TLA/Sub TLA
GLOBAL ROUTING PREFIX
NLA
TLA ID: Top Level Aggregation Identifier
SLA
SITE 1
Organização 1
SLA ID: Site Level Aggregation Identifier
ISP 1
SITE 2
SITE 1
Organização 2
SITE 2
ISP 2
NLA ID: Next Level Aggregation Identifier
Internet IPv6
Sub TLA ID: Sub Top Level Identifier
Interface ID: Link Level Host Identifier
Edgard Jamhour
Os endereços IPv6 unicast público (AGGR) adotam uma estrutura hierárquica que
permitirá que a Internet IPv6 cresça sem os mesmos problemas causados para os
roteadores BGP no IPv4. Em uma rede IPv6, não será necessário que cada roteador de
borda conheça as rotas para as redes de todos os demais sistemas autônomos.
O formato hierárquico de um endereço AGGR é mostrado na figura. Os três primeiros bits
do endereço são fixos (001, que corresponde ao prefixo 2000/3). A seguir é definido um
prefixo denominado TLA. Um TLA representará uma entidade de agregação de auto-nível,
mantida provavelmente por uma autoridade de registro regional (RIR) como a ARIN,
RIPENCC, LACNIC ou APNIC, ou a outras entidades de grande porte, responsáveis pela
distribuição de endereços IP. Um Sub-TLA será um prefixo atribuído a um ISP (Internet
Service Provider). Atualmente, muitas empresas de telecomunicações já receberam um
Sub-TLA que corresponde a um bloco de 299 endereços. Um ISP pode atribuir NLAs
inteiros ou pedaços de NLA para seus clientes. Cada cliente pode organizar sua rede em
diversos sites, cada um deles representado um prefixo SLA.
Considerado o tamanho dos prefixos, observe que poderemos ter até 213=8192 TLAs.
Cada TLA pode alocar blocos para até 213=8192 Sub-TLAs. Cada sub-TLA pode controlar
até 219 organizações (524288 organizações), caso decida adotar o NLA como unidade
mínima de alocação. Uma empresa que receba um NLA pode ter até 216 sites (64K subredes). Cada sub-rede pode ter até 264 computadores.
A maneira como irá funcionar o BGPv6 e a estrutura dos sistemas autônomos IPv6 ainda
está em discussão. Contudo, é possível imaginar que essa hierarquia permitirá reduzir
bastante o tamanho das tabelas de roteamento. Por exemplo, todas as rotas para as
redes de um mesmo ISP podem ser representadas por uma única rota para o seu SubTLA.
Endereços de Multicast IPv6
8
PF = FF
4
Flags
4
Escopo
112
ID de Grupo
RFC 2375
FF01::1: todas as interfaces do nó (host)
FF02::1: todos os nós do enlace (rede local)
FF01::2 todos os roteadores locais ao nó
FF05::2 todos os roteadores do site
FF02::B agentes móveis locais ao enlace
FF02::1:2 agentes DHCP do enlace
FF05::1:3 servidores DHCP do site
Edgard Jamhour
O IPv6 baniu os endereços do tipo broadcast. Muitos das aplicações que usavam
broadcast no IPv4, como o ARP e o DHCP, forma reformuladas para usar apenas
multicast.
A estrutura de um endereço multicast é mostrada na figura. O prefixo do endereço é
FF00/8, isto é, todos os endereços multicast começam com 0xFF.
O campo Flags define como é a adesão do nó ao grupo em questão. A adesão do
endereço pode ser dinâmica (o nó pode entrar e sair do grupo multicast) ou permanente
(o nó sempre possui o endereço multicast). Os valores definidos para Flags são os
seguintes:
0000 endereço de grupo dinâmico
1111 endereço de grupo permanente
O escopo define se o endereço multicast é público ou privado. Os diferentes níveis de
escopo para endereços IPv6 são definidos a seguir:
1: nó local (o multicast é usado internamente no host)
2: enlace local (o multicast está confinado a uma LAN)
5: site local (o multicast está confinado a um site de uma organização)
8: organização (o multicast está confinado aos sites de uma mesma organização)
14: global (o multicast pode ser propagado pela Internet)
A figura ilustra alguns dos endereços multicast mais comuns. Observe, em particular, que
o IPv6 oferece um controle aprimorado para que um computador localize um roteador ou
servidor DHCP mais próximo.
Mensagens ICMP
8
Tipo
8
Código
16
Checksum
Corpo da Mensagem
Mensagens de Erro: 0 a 127
Destino inalcançável,
MTU excedido,
TTL excedido,
etc
Mensagens Informativas: 128 a 362
Echo Request/ Response,
Consulta/Relatório/Redução de Adesão ao Grupo,
Solicitação/Anúncio de Roteador,
Solicitação/Anúncio de Vizinho
etc
Edgard Jamhour
Dois protocolos muito utilizados no IPv4 foram eliminados no IPv6: o ARP e o IGRP. A
função do ARP é bem conhecida, ele permite descobrir o endereço MAC a partir de
endereços IP. O IGRP gerencia a entrada ou saída de membros de um grupo multicast.
Todas as vezes que um nó entra ou deixa um grupo multicast, ele anuncia essa mudança
de estado enviando uma mensagem IGRP.
Ambos os protocolos foram substituídos pelo ICMP. Como sabemos, o ICMP é um
protocolo muito genérico, que pode conter diversos tipos de mensagens, usadas tanto por
aplicativos, como o ping e o traceroute, como para informar erros no encaminhamento de
pacotes por roteadores. Então, nada mais natural do que estender as mensagens ICMP
para incorporar as funções do ARP e do IGMP. O ICMPv6 (definida pela RFC 1885 e
RFC 2461) é identificado pelo Next Header = 58.
Os tipos mensagens ICMP são definidos de acordo com os valores do campo Tipo, da
seguinte forma:
Mensagens de tipo 0 a 127: Erros.
Por exemplo, erros de roteamento: destino inalcançável, pacote muito grande, TTL
excedido, problema de parâmetro.
Mensagens do tipo 128 a 362: Informativas.
Por exemplo: mensagens do ping (echo request, echo response), mensagens de
substitutas dos IGMP (consulta de adesão ao Grupo, Relatório de Adesão a Grupo,
Redução de Adesão ao Grupo), mensagens de localização de roteadores e anúncio de
prefixos (Solicitação de Roteador, Anúncio de Roteador), mensagens substitutas do ARP
(Solicitação de Vizinho, Anúncio de Vizinho), etc.
Mensagens ICMP substitutas do ARP
Solicita MAC
HOST
Neighbor Solicitation
HOST
Neighbor Advertisement
Fornece MAC
Edgard Jamhour
No IPv6, o ARP foi eliminado, e substituído por duas novas mensagens ICMPv6,
denominadas "Neighbor Solicitation" e "Neighbor Advertisement".
Lembremos, primeiramente, que o ARP é um protocolo muito ineficiente, e um dos
principais responsáveis por problemas de desempenho em grandes redes não
segmentadas, formadas pelo cascateamento de switches sem o uso de VLANs. Além
disso o ARP não possui o cabeçalho de rede, o que lhe torna um espécie de intruso na
família de protocolos IP. O ARP é baseado em duas mensagens: "ARP Request", enviada
em broadcast e "ARP Reply", enviada em unicast.
No IPv6, o "ARP Request" foi substituído pela mensagem ICMP enviada em multicast,
denominada "Neighbor Solicitation". O endereço de multicast dessa mensagem é formado
conforme o desenho da figura, e é denominado "endereço de multicast do nó solicitado).
Esse endereço é formado pelo prefixo de multicast FF02::1:FF/96 e os últimos 24 bits são
extraídos do endereço de unicast do nó de destino.
Todo computador IPv6 ao ser inicializado torna-se membro de seu endereço de multicast
de "nó solicitado". Como o prefixo FF02 está limitado apenas a computadores na mesma
rede local, é muito provável que não existam dois computadores com o mesmo endereço
solicitado em uma mesma rede, de forma que esse endereço funciona quase como um
unicast.
O "ARP Reply" foi substituído pela mensagem "Neighbor Advertisement" enviada em
unicast.
A estratégia baseada no ICMPv6 não terá os mesmos problemas de desempenho do
ARP, podendo ser facilmente filtrada por switches, de maneira que pacotes multicast
podem ser enviados apenas para as portas que tiverem computadores com o endereço
solicitado.
Autoconfiguração de Endereços IP
HOST
DHCP
Server
HOST
Solicita Prefixo
Router Advertisement
Anuncia PREFIXO
Informa MTU
Indica como configura o endereço IP
Router Solicitation
HOST
MAC:
03:04:05:06:07:08
IP LINK LOCAL:
FE80::0203:04FF:FE0506:07/10
IP GLOBAL:
PREFIXO::0203:04FF:FE05:0607/80
Edgard Jamhour
A atribuição automática de um endereço IPv6 para uma interface pode ser feita de duas
formas: Stateful: via DHCPv6 ou Stateless: via ICMPv6 enviada pelo roteador (RFC
1971). Quando uma interface é inicializada, o host IPv6 executa um procedimento
denominado auto-configuração, que é definido pelas seguintes etapas:
1. O host cria um endereço de enlace local ("link local") formado pelo prefixo FE80::/10
combinado com seu endereço MAC. O processo é indicado na figura. Observe que os
bytes FFFE são intercalados com o endereços MAC de 48 bits de forma a criar um
identificador de 64 bits. O endereço MAC precisa ser global (byte mais significativo
XXXXXX1X).
2. O host verifica se o endereço de enlace local já existe com uma mensagem de
"Neighbor Advertisement". Se já existir, a auto-configuração falhou, e não há
comunicação em rede.
3. O host envia mensagens de solicitação de roteador (Neighbor Solicitation) para o
endereço de multicast que identifica todos os roteadores acessíveis na sua rede local. Se
nenhum roteador responder, o host tenta solicitar um endereço enviado uma mensagem
multicast para todos os servidores DHCP acessíveis em sua rede local. Se nenhum
servidor DCHP responder, ele fica apenas como o endereço "link local", que limita sua
comunicação apenas no interior da LAN.
4. Se o host receber uma mensagem de "router advertisement":
Se o flag M da mensagem estiver setado: o nó deve solicitar seu endereço via DHCP
Se o flag O da mensagem estiver setado: o nó deve obter também as demais informações
de configuração de rede (como gateway default) via DHCP.
Se o flag A da mensagem estiver setado: o host configura seu endereço sem DHCP,
adicionando o prefixo recebido ao seu endereço MAC, conforme indicado na figura.
Mecanismos de Transição
Host
puramente IPv4
Host
Dual Stack
Host
puramente IPv6
Aplicação
Aplicação
Aplicação
Aplicação
TCP
TCP
TCP
TCP
IPv4
IPv4
IPv6
IPv6
Enlace
Enlace
Enlace
Edgard Jamhour
Os protocolos IPv4 e IPv6 são incompatíveis, pois um nó de rede (roteador ou
computador) que não tenha a pilha IPv4 implementada não encaminhará pacotes IPv4, e
aquele que não tiver a pilha IPv6 implementada não encaminhará pacotes IPv6. Isto
significa que você não conseguirá acessar um servidor IPv6 a partir de um navegador
Web IPv4, nem vice versa. Além disso, se você instalar um host IPv6 em uma rede que o
roteador entende apenas IPv4, ele ficará isolado, sem conectividade com o mundo
exterior.
Uma das limitações ao uso do protocolo IPv6 certamente será a falta de aplicações
compatíveis com o protocolo. Observe que mesmo que os protocolos de transporte UDP e
TCP sejam compatíveis com ambos as versões do IP, o mesmo não acontece com as
aplicações. Para entender a razão disso, considere o desenho da figura que ilustra a
comunicação entre três hosts, um puramente IPv4, um puramente IPv6 e outro que
possui as duas pilhas implementadas. Quando uma aplicação é executada, ela escolhe
qual a pilha que irá utilizar através do parâmetro "família de endereços" passado pela
interface de SOCKETS. Se o parâmetro for INET, a pilha IPv4 é utilizada, se o parâmetro
for INET6, a pilha IPv6 é utilizada. Um host dual stack pode falar com hosts puramente
IPv4 e hosts puramente IPv6, mas ele precisa de uma aplicação distinta para cada uma
das pilhas.
Atualmente, existem poucas aplicações compatíveis com o IPv6. Uma delas é o
navegador Web. As últimas versões dos navegadores já são dual-stack, isto é, elas são
capazes de criar sockets para as pilhas de ambas as versões do protocolo IP. O
navegador seleciona qual pilha utilizará de acordo com o endereço que você digitar na
URL do navegador. Se a resposta do DNS for um endereço IPv6 ele cria um socket com o
parâmetro INET6, se for um endereço IPv4, ele cria um socket com o parâmetro INET.
Os mecanismos de transição foram criados para permitir a conectividade entre hosts IPv4
e IPv6, conforme veremos na seqüência desse módulo.
Técnicas de Tunelamento
Tunnel Endpoints
SRC IPv4
DST IPv4
PROT
SRC IPv6
payload
DST IPv6
DST
IPv6
rede IPv6
payload
SRC
IPv6
DST
IPv4
SRC
IPv4
rede IPv6
IPv4
Edgard Jamhour
De acordo com a estratégia do IETF, a rede Internet baseada em IPv6 deverá crescer
lentamente, devendo coexistir com a rede IPv4 durante muitos anos, antes que a
tecnologia IPv4 se torne obsoleta e venha a ser desativada. Atualmente, não existe
suporte de conectividade IPv6 em grande escala. Contudo, utilizando mecanismos de
tunelamento, é possível fazer com que redes IPv6 isoladas utilizem a Internet IPv4 para
se comunicarem.
O tunelamento é uma técnica genérica que consiste em colocar um pacote dentro de
outro. Por exemplo, um pacote IPv6 pode ser colocado inteiramente no campo de carga
de um pacote IPv4, a fim de ser transmitido pela Internet. Esse princípio é ilustrado na
figura. Na parte superior da figura vemos o formato de um pacote com tunelamento. O
campo "protocolo type" é utilizado para indicar que o pacote IPv4 está transportando um
pacote IPv6 tunelado.
Geralmente, os endereços de origem e destino do pacote IPv6 refletem a comunicação
entre as origens e destinos finais (por exemplo, os endereços do cliente e do servidor). Já
os endereços IPv4 definem as extremidades dos túneis, isto é, os endereços dos
roteadores que terão a função de criar o pacote tunelado para envio, e destunelar os
pacotes recebidos.
Os principais mecanismos de transição propostos pelo IETF para integrar redes IPv4 e
IPv6 são baseados em tunelamento. Como veremos, existe mais de uma estratégia
possível de tunelamento. As estratégias diferem quanto a forma como o túnel é criado e
sua finalidade. As técnicas propostas pelo IETF adotam endereços especiais para
pacotes IPv6 que precisam ser tunelados, de maneira que os túneis sejam criados de
forma automática e dinâmica, numa abordagem conhecida como "sem estado" (stateless).
ISATAP (Intra-Site Automatic Tunnel Addressing Protocol)
200.1.2.3
60.1.2.3
PROT
FE80::5EFE:200.1.2.3
payload
FE80::5EFE:60.1.2.3
payload
B
A
IPv4
if ISATAP
FE80::5EFE:200.1.2.3
if IPv4
200.1.2.3
if: interface de rede
if ISATAP
FE80::5EFE:60.1.2.3
if IPv4
60.1.2.3
Edgard Jamhour
ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) é um mecanismo para
atribuição automática de endereço e configuração automática de túneis que permite que
hosts IPv6 isolados se comuniquem através da Internet. Para utilizar esse mecanismo, o
sistema operacional do host precisa ter as duas pilhas instaladas IPv4 e IPv6.
Quando o mecanismos ISATAP é habilitado em um host que já tenha um endereço IPv4
previamente atribuído, uma interface virtual ISATAP é criada, com um endereço IPv6
automático, formatado da seguinte maneira:
FE80::5EFE:<IPv4>
O prefixo FE80::5EFE/96 é denominado "prefixo do ISATAP". Observe na figura que um
host com suporte a ISATAP possui pelo menos duas interfaces. Uma interface IPv4 e
outra ISATAP com endereço IPv6. Todas os pacotes direcionados para o prefixo
FE80::5EFE/96 são enviados através da interface de ISATAP, que efetua o tunelamento
para a interface IPv4 do host de destino de forma automática.
Observe que quando o host A envia um pacote para o host B, sua interface ISATAP sabe
como criar o túnel, pois o endereço IPv4 do destinatário está embutido no próprio
endereço IPv6.
Esse mecanismo permite que hosts com aplicações puramente IPv6 (por exemplo, um
cliente e um servidor Web) se comuniquem de forma transparente através da Internet
IPv4. A desvantagem desse método é que ele não provê nenhuma economia de
endereços IPv4, pois todos os hosts envolvidos na comunicação precisam de um
endereço IPv4 público.
Tunelamento 6to4
Allocation
Prefix (binary)
Fraction of
Address Space
Reserved
0000 0000
1/256
Unassigned
…
…
NSAP Allocation
0000 001
1/128
IPX Allocation
0000 010
1/128
Unassigned
…
…
Aggregatable Global Unicast
Addresses
Unassigned
001
1/8
…
…
Link-Local Unicast Addresses
.
Site-Local Unicast
Addresses
1111 1110 10
1/1024
1111 1110 11
1/1024
1111 1111
1/256
Multicast Addresses
AGGR (1/8)
6to4
scheme
1/65535
Edgard Jamhour
O tunelamento 6to4 é outro mecanismo de transição baseado em tunelamento proposto
pelo IETF. De forma diferente do ISATAP, o mecanismo 6to4 é utilizado para conectar
redes IPv6 inteiras através da Internet IPv4, ao invés de hosts isolados.
A fim de suportar esse esquema, o IETF selecionou um bloco de endereços para criação
automática dos túneis 6to4. Esse bloco, denominado "esquema 6to4", é definido pelo
prefixo 2002::/16. Ele corresponde a 1/8 de um bloco TLA (que tem prefixo /13), extraído
do espaço de endereços unicast públicos (AGGR). Isto significa que nenhum endereço
com esse prefixo poderá ser atribuído a um ISP, nem poderá ser usado como endereço
público unicast de um host.
O motivo para reservar endereços de tunelamento para o mecanismo "6to4" é o mesmo
do mecanismo ISATAP. Quando um host envia um pacote para outro endereço IPv6, seu
sistema operacional precisa determinar se o pacote deve ser tunelado ou não. Como o
prefixo 2002::/16 é reservado para tunelamento, todas as vezes que se enviar um pacote
para um endereço com esse prefixo, ele será tunelado.
Um prefixo "/16" corresponde a 2112 endereços, o que é uma quantidade 280 vezes maior
do que todos os endereços da Internet atual. Essa quantidade de endereços gigantesca
corresponde a apenas 1/65535 do espaço de endereços públicos disponíveis para o IPv6.
Como veremos, um bloco de 280 endereços IPv6 do esquema "6to4" foi atribuído
automaticamente para cada usuário que possua um endereço IPv4 público registrado, de
forma que qualquer usuário hoje está livre para participar da Internet IPv6, sem
necessidade de solicitar endereços para uma autoridade de registro.
Endereços 6to4
prefixo da rede ::/48
escolhido pelo usuário 80 bits
16
32
16
2002
V4ADDR
SLAID
64
Interface
Interface externa do
roteador que se conecta
com a Internet.
redes IPv6 "6to4"
IPv4
2002:V4ADDR::/48
V4ADDR
(endereço IPv4 público)
Edgard Jamhour
Os endereços IPv6 do tipo "6to4" devem ser construídos conforme a figura (definido pela
RFC 2529). Para ter direito a utilizar essa classe de endereços, um usuário precisa ter
pelo menos um endereço IPv4 público, que é denominado V4ADDR.
Idealmente, o V4ADDR corresponde ao endereço IPv4 da interface externa do roteador,
isto é, o endereço da interface que tem conexão direta com a rede IPv4. Esse conceito é
ilustrado pela parte inferior da figura.
Todo o usuário detentor de um endereço IPv4 (o V4ADDR), ganha automaticamente 280
endereços públicos da classe "6to4" para serem atribuídos aos computadores de sua rede
IPv6 interna. O bloco de 280 endereços é definido pelo prefixo construído da seguinte
forma:
2002:V4ADDR::/48.
Por exemplo, suponha que o endereço V4ADDR corresponde ao IP 64.1.2.3. A
representação em hexadecimal desse endereço é: 4001:0203
O prefixo deve, então, ser construído da seguinte forma:
2002:4001:0203::/48
A rede do usuário pode ser criada adicionando-se livremente os 80 bits restantes ao
prefixo. Como os 80 bits incluem o identificador do site (SLAID), a rede pode ser inclusive
segmentada em múltiplos sites.
Observe que não há necessidade de entrar em contato com uma autoridade de registro
da Internet para obter esse endereços, uma vez que sua própria construção garante que
os endereços serão únicos.
Exemplo
2002:4001:0203::2/48
2002:4001:0203::2
2002:C803:0201::5
REDE A
64.1.2.3
1
redes IPv6 "6to4"
2002:4001:0203::/48
200.3.2.1
2002:4001:0203::2
2002:C803:0201::5
1
2
V4ADDR
64.1.2.3 = 4001:0203
IPv4
2002:4001:0203::2
2002:C803:0201::5
3
V4ADDR
200.3.2.1 = C803:0201
2
redes IPv6 "6to4"
2002:C803:0201::/48
REDE B
2002:C803:0201::5/48
Edgard Jamhour
A figura ilustra como acontece uma comunicação entre duas redes IPv6, conectadas
através da rede IPv4, utilizando o mecanismo de transição "6to4".
Observe que cada uma das redes foi estruturada utilizando o bloco "6to4" definido com o
endereço V4ADDR do seu roteador. Como o roteador 1 da rede A possui o endereço
V4ADDR=64.1.2.3 (4001:0203), a rede A possui o seguinte prefixo: 2002:4001:0203::/48.
Similarmente, como o roteador 2 da rede B possui o endereço V4ADDR=200.3.2.1
(C803:0201), o prefixo da rede B é 2002:C803:0201::/48. Tanto o roteador 1 quanto o
roteador 2 precisarão ter o mecanismo de transição "6to4" implementado em seu sistema
operacional, para que eles sejam capazes de identificar esse tipo de endereço e efetuar
as operações de tunelamento e de-tunelamento.
Os computadores A e B possuem, respectivamente, os seguintes endereços pertencentes
ao prefixo "6to4" de suas redes: Computador A: 2002:4001:0203::2 e Computador B:
2002:C803:0201::5.
Quando o computador A envia uma mensagem para o computador B (indicado como
passo 1 na figura), o pacote é processo primeiramente pelo seu roteador 1 (que pode ser
o gateway default da rede). Ao identificar que o endereço de destino possui o prefixo
2002::/16, o roteador 1 efetua o tunelamento do pacote recebido, utilizando o endereço
V4ADDR do roteador 2, extraído do endereço IPv6 de destino. O pacote tunelado é
enviado diretamente ao roteador 2 (passo 2 da figura). Quando o pacote chega ao
roteador 2, ele é de-tunelado e enviado para o computador B (passo 3 na figura).
Se uma rede tiver endereços "6to4" ela pode se comunicar apenas com outra rede que
também tenha prefixos "6to4", mas não pode se comunicar com as demais redes IPv6
"puras". Para resolver esse problema, o IETF definiu a figura de roteadores "relay" que
executam a função de ponte entre as redes "6to4" e as demais redes IPv6.
O endereço Anycast mágico
roteadores relay
roteador 6to4
Rede 6to4
2002::/16
BACKBONE IPv6
(Prefixos diferentes
de 2002::/16)
roteadores relay
BACKBONE
IPv4
Rede 6to4
2002::/16
roteador 6to4
tunel
Edgard Jamhour
Conforme mostra a figura, podem haver diversos roteadores relay na fronteira entre a
rede IPv4 (a Internet atual) e backbones puramente IPv6. Os roteadores relay são vistos
como verdadeiros “gateways default” para acessar redes puramente IPv6. A fim de utilizar
esses roteadores, uma rede 6to4 isolada precisa encontrar o roteador relay mais próximo,
e criar um "túnel 6to4" associada a sua rota default. Muitas instituições que participam dos
projetos de backbones IPv6, como Microsoft e Cisco, oferecem roteadores relay de
acesso gratuito.
A RFC 3068 definiu que o prefixo 192.88.99.0/24 é utilizado para anunciar o roteador
relay mais próximo de uma rede utilizando o BGP. Esse prefixo corresponde a endereços
de "anycast IPv4", ou seja, muitos roteadores relay podem compartilhar endereços com
esse mesmo prefixo. Como o BGP trabalha com rotas de menor custo, os pacotes
enviados para esse endereço de destino serão encaminhados naturalmente para o
roteador relay mais próximo. Os endereços de anycast são representados em IPv6 da
seguinte forma: 2002:c058:6301::". Alguns sistemas operacionais, como o Windows XP e
o Vista, criam automaticamente endereços IPv6 6to4 para computadores que tenham
endereços IPv4 públicos. Esses sistemas também incluem uma rota default para o
roteador relay da Microsoft. A tabela abaixo ilustra as rotas criadas automaticamente pelo
Windows XP para acessar redes IPv6.
2002::/16 -> 3 pref 1
::/0 -> 3/2002:c058:6301::1741 pref 2
A primeira linha indica que todos os endereços que começam com 2002::/16 são
acessíveis via interface 3 (a interface virtual que faz tunelamento 6to4) sem necessidade
de gateway. A segunda linha, indica que todos os demais endereços IPv6 (::/0 representa
a Internet em IPv6) são acessíveis também via interface 3, mas que o túnel será criado
para o roteador relay 2002:c058:6301::1741, que pertence a Microsoft.
6over4 Tunneling (Virtual Ethernet)
Tunnel Endpoints
SRC IPv4
DST IPv4
41
SRC IPv6
multicast
IPv6
payload
DST IPv6
payload
IPv6
Host
if 6over4
if IPv4
IPv4 Network
if: interface de rede
Host
IPv6
multicast
tunelado em IPv4
6over4
Router
multicast
IPv6
if IPv6
IPv6 Net
Edgard Jamhour
Um terceiro tipo de mecanismo de transição também baseado em tunelamento é o
6over4, também conhecido como Virtual Ethernet. O objetivo desse mecanismo é permitir
que hosts IPv6 isolados consigam enviar e receber mensagens multicast de roteadores e
servidores IPv6 através de uma rede IPv4. É importante lembrar, que vários serviços do
IPv6 são baseados em mensagens multicast: Neighbor Discovering, Router
Advertisement, DHCP Discover, etc. Dessa forma, é necessário redirecionar as
mensagens de multicast para os hosts isolados a fim de que eles possam operar
normalmente na rede IPv6. Esse mecanismo é definido pela RFC 2529 (Transmission of
IPv6 over IPv4 Domains without Explicit Tunnels).
Nesse método, pacotes IPv6 são encapsulados no interior de pacotes IPv4 utilizando o
tipo de protocolo 41. O host e pelo menos um roteador da rede que faça fronteira entre as
redes IPv4 e IPv6 deve suportar o mecanismo IPv6over4. O mecanismo IPv6over4 define
um mapeamento entre mensagens multicast IPv4 e IPv6:
O bloco de endereços multicast IPv4 usados para o mapeamento usa o seguinte prefixo:
239.192.0.0/16
Um endereço multicast IPv6 é mapeado em um endereço de multicast IPv4
correspondente usando a seguinte estratégia: 239 .192.< 2 bytes menos significativos do
endereço multicast IPv6>
A seguir são mostradas uma lista de mensagens multicast IPv6, e como elas são
tuneladas em mensagens multicast IPv4:
FF02::1 (all nodes of the link): tuneladas com o endereço de multicast 239.192.0.1
FF01::2 (all link local routers): tuneladas com o endereço de multicast 239.192.0.2
FF02::1::FFxx:yyyy (solicited node multicast addres): tunelados como 239.192.yy.yy
NAT/NAPT-PT (PT- Protocol Translation)
2
IPv6
IPv6A
::FFFF:<IPv4B>
PortaS
3
IPv4
PortaD
IPv4R
IPv4
PortaN
PortaD
PortaD
PortaS
Host B
Host A
IPv4R
1
IPv6A
IPv6 Network
endereços
IPv4 mapeados
com o prefixo
::FFFF::/96
IPv4B
NAPTPT
Router
IPv4
IPv4 Network
Mapeamento
IPv6A:PortaS - IPv4R:PortaN
DNS
Edgard Jamhour
De forma similar ao mecanismo de NAT/NAPT que permitem que computadores com
endereço IP privado tenham acesso a recursos na Internet pública através de um
processo de mapeamento de endereços privados em públicos, o NAT/NAPT-PT permite o
mapeamento de endereços IPv6 e IPv4.
A denominação PT (Protocol Translation) usada ao final das siglas tradicionais
NAT/NAPT, indica que além das traduções de endereços e números de porta, também
são feitas traduções entre os protocolos IPv4 e IPv6. O NAT-PT efetua mapeamentos do
tipo um-para-um entre endereços IPv4 e IPv6, pois não usa as portas do protocolo de
transporte. O NAPT-PT permite fazer mapeamentos de um-para-muitos, pois utiliza os
números de porta para diferenciar múltiplas requisições feitas com o mesmo endereço.
Dessa forma, utilizando-se o NAPT-PT, é possível dar acesso a Internet a uma grande
quantidade de computadores IPv6 (cerca de 63k), utilizando um único endereço IPv4
público. Esse conceito é ilustrado pela figura. No cenário, uma rede puramente IPv6 está
conectada a Internet através de um roteador NAPT-PT. Quando um cliente IPv6 precisa
enviar um pacote para um host na Internet, ele primeiramente faz uma consulta ao DNS
para resolver um FQDN (e.g. www.google.com). Um servidor DNS com suporte a IPv6,
sempre responde endereços IPv4 mapeados para hosts IPv6. Um endereço mapeado é
uma representação IPv6 de um endereço IPv4, de acordo com a sintaxe: ::FFF:<IPv4).
Os pacotes com endereço de destino mapeados são enviados para o roteador com
suporte ao NAPT-PT, que faz dois tipos de conversão no pacote:
a) Substitui o endereço IPv6 do host que enviou o pacote pelo seu próprio endereço IPv4.
b) Substitui o número de porta do protocolo de transporte por um número de porta que
ainda esteja disponível em sua tabela de mapeamento.
Proxy Socks6to4
IPv6A
1
::FFFF:<IPv4B>
IPv6A
PortaS
IPv6P
PortaD
PortaS PortaF
IPv6
PortaS
2
Host A
3
PortaF
Socks LIB
IPv4R
PortaP
PortaD
IPv4
PortaP
Host B
PortaD
Proxy
6to4
IPv6A
IPv4B
IPv6 Network
DNS
IPv4B
IPv6P
IPv4P
IPv4
IPv4 Network
Mapeamento
IPv6A:PortaS:IPv6P:PortaF - IPv4P:PortaP:IPv4B:PortaD
Edgard Jamhour
O proxy SOCKS é definido com um mecanismo de redirecionamento ao nível da camada
de transporte, que permite que hosts com endereços privados ou com acesso limitado por
firewalls consigam ter livre acesso a recursos da Internet.
Um proxy SOCKS para IPv4 está hospedado, normalmente, em um dual-homed host com
um endereço privado e outro público. Ele recebe conexões de hosts internos pela sua
interface de IP privado e cria conexões com hosts na Internet através de sua interface
pública. De maneira similar, um proxy SOCKS64 está hospedado em um dual-homed host
com um endereço IPv6 e outro endereço IPv4 público. Ele pode receber conexões pela
sua interface IPv6 e redirecioná-las pela sua interface IPv4 e vice-versa.
A figura ilustra o cenário onde um proxy SOCKS64 é usado para permitir que usuários de
uma rede puramente IPv6 tenham acesso a recursos na Internet IPv4. Para ter acesso ao
proxy SOCKS64 um host precisa ter uma aplicação com suporte ao SOCKS ou,
preferencialmente, instalar uma versão alterada da SOCKS LIB que intercepta as as APIs
enviadas pelas aplicações, e formata pacotes de acordo com o protocolo SOCKS. Existe
uma diferença no funcionamento do proxy SOCKS quando operando em TCP ou UDP.
Consulte a apostila sobre o proxy SOCKS do módulo de redes TCP/IP para relembrar
esse assunto. Nesse exemplo, suponha que se trata de uma aplicação TCP.
Quando a SOCKS LIB do host A recebe o pedido de abertura de conexão para um
endereço mapeado (::FFFF:<IPv4B>), ela cria uma conexão com o proxy SOCKS64, e
envia uma mensagem solicitando que os pacotes enviados por essa conexão sejam
redirecionados para o endereço IPv4B na porta D. Em seguida, a LIB envia o pacote de
dados diretamente para o Proxy. Como proxy possui um mapeamento entre a conexão
IPv6 com o host A e uma conexão IPv4 com o host B, os pacotes recebidos são
automaticamente convertidos para IPv4 e enviados para Internet.
Conclusão
• O IPv6 é necessidade real para permitir a continuidade do
crescimento dos serviços Internet devido:
– Ao esgotamento de endereços IPv4 públicos
– Ao grande número de rotas dos roteadores de borda.
• A transição para IPv6 ocorrerá gradualmente.
– Redes IPv4 e IPv6 podem e irão coexistir.
– Atualmente, já é possível utilizar endereços IPv6 e mecanismos de
transição.
Edgard Jamhour
Nesse módulo, nós vimos que o IPv6 é uma necessidade real para permitir a continuidade
do crescimento da Internet, que está limitada devido a dois fatores principais: o
esgotamento de endereços IPv4 públicos e o grande número de rotas dos roteadores de
borda BGPv4.
Além de trazer um espaço de endereçamento muito mais amplo, o IPv6 trouxe diversas
melhorias em relação ao IPv4. Essas melhorias partiram de uma mudança estrutural no
formato do cabeçalho IP, que abandonou a estratégia baseada em um número fixo de
campos, para uma estratégia mais flexível, formada por um cabeçalho de base
simplificado, seguindo de zero ou mais cabeçalhos de extensão opcionais. Esses
cabeçalhos de extensão dotaram o IPv6 de funções indisponíveis no IPv4, como o uso de
rotas explícitas, e também simplificaram várias funcionalidades que no IPv4 necessitavam
de protocolos externos, como o tunelamento e os recursos de segurança oferecidos pelo
IPsec.
Os protocolos IPv4 e IPv6 são incompatíveis. Contudo, espera-se que haja uma transição
suave do uso do IPv4 para o IPv6 na Internet. Durante a fase de transição que deve durar
muitos anos, espera-se que ambas as redes coexistam, e que hosts IPv4 e IPv6 se
comuniquem através da rede. Para dar suporte a essa comunicação vários mecanismos
de transição foram propostos. Muitos desses mecanismos são baseados na criação de
túneis automáticos, disparados pelo uso de espaços de endereçamento especiais. Outros
são adaptações de soluções para conectividade entre endereços privados e públicos,
adaptados para a integração entre o IPv4 e o IPv6, como o caso do NAT/NAPT-PT e o
proxy SOCKS64.