Embed Size (px)
Citation preview
2008, Edgard Jamhour
IPv6: Internet Protocol – Versão 6e Mecanismos de Transição
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.
Edgard Jamhour
Problemas do IP Versão 4
• Crescimento do IPv4– 07/2007 490 milhões de hosts01/2008 542 milhões de hosts
PREVISÃO DE ESGOTAMENTO
= 1994
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 Interentsem 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.
Edgard Jamhour
Problemas de Arquitetura
IXP
Internet Exchange Point
AS
AS
ASAS
AS
A criação do CIDR, provocou grande incremento no número de rotas dos roteadores de borda
(entradas BGP)
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 deusuá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.
Edgard Jamhour
Crescimento das Entradas BGP
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.
Edgard Jamhour
Quantidade de Endereços IPv4 Disponíveis
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 auto-configuraçã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).
Edgard Jamhour
Distribuição da Alocação
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).
Edgard Jamhour
Distribuição da Alocação IPv4
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.
Edgard Jamhour
Previsão de Esgotamento
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).
Edgard Jamhour
IPv6: Internet Protocol versão 6
5. Aplicação
4. Transporte
HTTP, FTP, TELNET, SSH, POP3, SNMP,SMTP, ...
3. Rede
2. Enlace
1. Física Modem, RDIS, RS-232, EIA-422, RS-449, Bluetooth, USB, ...
Ethernet, 802.11 WiFi, IEEE 802.1Q, 802.11g, HDLC, Token ring, FDDI, PPP, Frame Relay, ...
IP (IPv4, IPv6) , ARP, RARP, ICMP, IPSec ...
TCP, UDP, SCTP, DCCP ...
Aplicação
SistemaOperacional
Interface Física
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.
Edgard Jamhour
Melhorias IPv6
RoteamentoEndereçamento HierárquicoRotas ExplícitasMelhor suporte ao multicast
Endereçamento Endereços de 128 bits
Segurança Autenticação e Criptografia MandatóriosMais classes de endereçamento privado
Protocolo Cabeçalhos especializadosEliminação de campos pouco usadosIdentificação do tipo de tráfego
Gerenciamento Mecanismo de auto-configuraçãoSuporte a mobilidadeEliminação do Broadcast
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.
Edgard Jamhour
Datagrama IPv6 X IPv4
CABEÇALHO ÚNICOCABEÇALHO DE BASE(NEXT HEADER TIPO 1)
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
IPv6 IPv4
CABEÇALHO TRANSPORTE
CABEÇALHO APLICAÇÃO/DADOS
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.
Edgard Jamhour
Cabeçalho de Base IPv6
Version Byte DS Flow Label
Payload length Next Header Hop Limit
Source Address
(16 bytes)
Destination Address
(16 bytes)
byte 1 byte 2 byte 3 byte 4
Version H.Len. Byte DS Total Length
Fragment ID flags Fragment Offset
TTL Protocol Header Checksum
Source Address
Destination Address
Options ...
IPv6
IPv4
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.
Edgard Jamhour
Versão e Flow Label
IP version=4
IPv6 version=6
Pilha IPv4
Pilha IPv6
IP flow label =1
IPv6 flow label=2
Fila Alta
Prioridade
Fila Baixa
Prioridade
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.
Edgard Jamhour
Cabeçalhos de Extensão
CABEÇALHO DE BASE(NEXT HEADER 0)
CABEÇALHO 0(HOP-BY-HOP OPTIONS)
CABEÇALHO DE BASE(NEXT HEADER 43)
CABEÇALHO 43(ROUTING)
CABEÇALHO DE BASE(NEXT HEADER 44)
CABEÇALHO 44(FRAGMENTATION)
CABEÇALHO DE BASE(NEXT HEADER 51)
CABEÇALHO 51(AUTHENTICATION)
CABEÇALHO DE BASE(NEXT HEADER 50)
CABEÇALHO 50(ENCRYPTED SECURITY PAYLOAD)
CABEÇALHO DE BASE(NEXT HEADER 60)
CABEÇALHO 60(DESTINATION OPTIONS)
CABEÇALHO DE BASE(NEXT HEADER 59)
cria opções que influenciam a ação de roteadores
cria opções que influenciam apenas o destino final
inclui os campos opcionais de fragmentação
inclui campos de autenticação (AH do IPsec)
inclui campos de criptografia (ESP do IPsec)
inclui campos para rotas explícitas
Sem cabeçalho de extensão
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) .
Edgard Jamhour
Hop-by-Hop Options
Next Header
Type
Value (Valor do Campo)
headerlength
Length
Next Header
194
Jumbo payload length
0 4
tipo jumbograma
8 bytes de cabeçalho
o campo tem 4 bytes
tamanho do pacote (até 4Gbytes)
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
tamanho do campo em bytes
1 byte1 byte 1 byte 1 byte
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 multicastb) Y=0: O valor não muda ao longo do caminhoc) Z=00010: Opção jumbograma
Edgard Jamhour
Destination Options
Next Header Type
Value
Header Length Length
Type Length
Value Type Length
....
1 byte 1 byte 1 byte 1 byte
seqüência de opções individuais.
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 "Hop-by-Hop".
Os cabeçalhos de opções podem ocorrer no máximo duas vezes em cada pacote IPv6.
Edgard Jamhour
Routing Header
Next Header Type=0
Reserved
Header Size Seg. Left
Address Router 1 (16 bytes)
Address Router 24 (16 bytes)
Address Router 2 (16 bytes)
....
número máximo de saltos restantes (máximo 23)
tipo de cabeçalho de rotas
Strict/Loose Bitmat
Next Header TypeHeader Size Seg. Left
Routing Data .... o formato depende do campo tipo
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 Typerefere-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.
Edgard Jamhour
Roteamento
A C
D
E
5-11111ABCDE
strict routing
loose routing
B
A C E
4-11111ABCDE
3-11111ABCDE
1-11111ABCDE
0-11111ABCDE
2-11111ABCDE
3-000ACE
2-000ACE
2-000ACE
1-000ACE
1-000ACE
0-000ACE
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.
Edgard Jamhour
Fragmentation Header
Next Header
Fragment Offset
1 byte 1 byte
Reservado res
Identification
13 bits 1 bit
MF
1 bit
indica a posição do fragmento(múltiplo de 8 bytes).
indica se é o último fragmento ou não.
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 re-fragmentar o pacote pelo roteador foi eliminado, pois, no IPv6, essa opção é sempre verdadeira.
Edgard Jamhour
Extensões de Segurança: IPsec AH e ESP
Aplicação
Transporte
IP
IPsec
EnlaceVerificações de Segurança
ipsecipsecipsec
XDescarte antes de atingir as camadas
superiores
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.
Edgard Jamhour
Cabeçalhos IPsec: AH e ESP
Next HeaderPad (0 – 255 bytes) Pad Length
Security Parameter Index
Encrypted Payload(dados criptografados)
Sequence Number
Authentication Data(tamanho variável)
HEADER
TRAILER
AUTH
Next Header reservedLength reserved
SPI: Security Parameter Index
Authentication Data(ICV: Integrity Check Value)
Campo de Tamanho Variável, depende do protocolo de autenticaçãoutilizado
Sequence Number
1 byte 1 byte 1 byte 1 byteAH
ESP
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.
Edgard Jamhour
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
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
Edgard Jamhour
Categorias de Endereço
AC B
B
unicast
multicast
anycast
OUO 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.
O pacote anycast é enviado para o destinatário que tiver a rota de menor custo até a origem.
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 menoscusto até o computador A.
Edgard Jamhour
Reserved
Allocation
0::/8 1/256
Prefix (hexa) Fraction of Address Space
Unassigned … …
NSAP Allocation 200::/7 1/128
IPX Allocation 400::/7 1/128
Unassigned … …
Aggregatable Global Unicast
Addresses
2000::/3 1/8
Unassigned … …
Link Local Unicast Addresses. FE80::/10 1/1024
Site Local Unicast Addresses FEC0::/10 1/1024
Multicast Addresses FF00::/8 1 1/256
Total Alocado 15%
Classes de Endereço IPv6
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.
Edgard Jamhour
TLA ID SLA ID Interface ID
3 13 19 16 6413
FP
Aggregatable Global Unicast
GLOBAL ROUTING PREFIX
Sub-TLA NLA ID
FP: Format Prefix (AGGR=001)
TLA ID: Top Level Aggregation Identifier
Sub TLA ID: Sub Top Level Identifier
NLA ID: Next Level Aggregation Identifier
SLA ID: Site Level Aggregation Identifier
Interface ID: Link Level Host Identifier
AGGR
Organização 1
ISP 2
SITE 1
SITE 2
TLA/Sub TLA
Internet IPv6
NLA
Organização 2
SLA
ISP 1
SITE 1
SITE 2
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 NLAsinteiros 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 sub-redes). 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 Sub-TLA.
Edgard Jamhour
Endereços de Multicast IPv6
Flags ID de Grupo
8 4 4
PF = FF Escopo
112
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 siteFF02::B agentes móveis locais ao enlaceFF02::1:2 agentes DHCP do enlaceFF05::1:3 servidores DHCP do site
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âmico1111 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.
Edgard Jamhour
Mensagens ICMP
Código
Corpo da Mensagem
8 8 16
Tipo Checksum
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 Vizinhoetc
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.
Edgard Jamhour
Mensagens ICMP substitutas do ARP
HOST HOSTNeighbor Solicitation
Neighbor Advertisement
Fornece MAC
Solicita MAC
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 multicastde "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 multicastpodem ser enviados apenas para as portas que tiverem computadores com o endereço solicitado.
Edgard Jamhour
Autoconfiguração de Endereços IP
HOST
DHCPServer
HOSTRouter AdvertisementRouter Solicitation
Anuncia PREFIXOInforma MTUIndica como configura o endereço IP
Solicita Prefixo
HOST
MAC: 03:04:05:06:07:08IP LINK LOCAL: FE80::0203:04FF:FE0506:07/10IP GLOBAL:PREFIXO::0203:04FF:FE05:0607/80
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.
Edgard Jamhour
Mecanismos de Transição
Aplicação Aplicação
TCP TCP
IPv4 IPv6
Enlace
Aplicação
TCP
IPv4
Enlace
Aplicação
TCP
IPv6
Enlace
Host puramente IPv4
Host Dual Stack
Host puramente IPv6
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.
Edgard Jamhour
Técnicas de Tunelamento
SRC IPv4 payloadDST IPv4
Tunnel Endpoints
payloadSRC IPv6 DST IPv6
PROT
rede IPv6 SRCIPv4
IPv4
rede IPv6DSTIPv4
DSTIPv6
SRCIPv6
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).
Edgard Jamhour
ISATAP (Intra-Site Automatic Tunnel Addressing Protocol)
FE80::5EFE:200.1.2.3 FE80::5EFE:60.1.2.3
IPv4
200.1.2.3 payload60.1.2.3
payloadFE80::5EFE:200.1.2.3 FE80::5EFE:60.1.2.3
PROT
if ISATAP if IPv4
200.1.2.3
if ISATAP if IPv4
60.1.2.3
AB
if: interface de rede
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.
Edgard Jamhour
6to4
scheme
Tunelamento 6to4
1/65535
AGGR (1/8)Reserved
Allocation
0000 0000 1/256
Prefix (binary)Fraction of
Address Space
Unassigned … …
NSAP Allocation 0000 001 1/128
IPX Allocation 0000 010 1/128
Unassigned … …
Aggregatable Global UnicastAddresses
001 1/8
Unassigned … …
.1111 1110 10 1/1024
1111 1110 11 1/1024
Multicast Addresses 1111 1111 1/256
Site-Local Unicast Addresses
Link-Local Unicast Addresses
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.
Edgard Jamhour
Endereços 6to4
V4ADDR2002
Interface externa do roteador que se conecta
com a Internet.
SLAID Interface
16 32 16 64
prefixo da rede ::/48 escolhido pelo usuário 80 bits
redes IPv6 "6to4"
2002:V4ADDR::/48IPv4
V4ADDR(endereço IPv4 público)
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 registroda Internet para obter esse endereços, uma vez que sua própria construção garante que os endereços serão únicos.
Edgard Jamhour
Exemplo
redes IPv6 "6to4"2002:4001:0203::/48
redes IPv6 "6to4"2002:C803:0201::/48
IPv4
2
REDE A
V4ADDR64.1.2.3 = 4001:0203
1
V4ADDR200.3.2.1 = C803:0201
REDE B
2002:4001:0203::2/48
2002:C803:0201::5/48
2002:4001:0203::2 2002:C803:0201::5
11
22
2002:4001:0203::2 2002:C803:0201::564.1.2.3 200.3.2.1
33
2002:4001:0203::2 2002:C803:0201::5
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.
Edgard Jamhour
O endereço Anycast mágico
BACKBONE IPv4
BACKBONE IPv6(Prefixos diferentes
de 2002::/16)
roteadores relay
roteador 6to4tunel
Rede 6to42002::/16
Rede 6to42002::/16
roteador 6to4
roteadores relay
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.
Edgard Jamhour
6over4 Tunneling (Virtual Ethernet)
IPv6
Host
Host
IPv6
IPv4 Network IPv6 Net6over4Router
SRC IPv4 payloadDST IPv4
Tunnel Endpoints
payloadSRC IPv6 DST IPv6
41
if 6over4 if IPv4 if IPv6
if: interface de rede
multicastIPv6
multicasttunelado em IPv4
multicastIPv6
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, RouterAdvertisement, 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 ofIPv6 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
Edgard Jamhour
NAT/NAPT-PT (PT- Protocol Translation)
Host B
Mapeamento
IPv6A:PortaS - IPv4R:PortaN
PortaS
IPv6A
Host A
IPv4IPv6 Network
NAPT-
PT
RouterIPv4 Network
IPv6A IPv4B
::FFFF:<IPv4B> PortaS PortaD
PortaD
IPv6
IPv4R IPv4 PortaN PortaD
IPv4
DNS
endereços
IPv4 mapeados
com o prefixo
::FFFF::/96
IPv4R
11
22 33
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.
Edgard Jamhour
Proxy Socks6to4
Host B
Mapeamento
IPv6A:PortaS:IPv6P:PortaF - IPv4P:PortaP:IPv4B:PortaD
IPv6A
Host A
IPv4IPv6 Network IPv4 Network
IPv6AIPv4B
IPv6P PortaS PortaF
PortaP
IPv6
IPv4R IPv4B PortaP PortaD IPv4
DNS
22 33
Proxy
6to4
IPv6P IPv4P
Socks LIB
PortaF
PortaD11
IPv6A ::FFFF:<IPv4B> PortaS
PortaS
PortaD
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 APIsenviadas 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.
Edgard Jamhour
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.
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.
