IPv6: principais mudanças em relação a IPv4

Já ouvi muito sobre isso nos últimos dias, e Hoje com o lançamento oficial do IPV6 eu vou tentar te explicar o que muda, prepara o cafezinho que o texto é comprido e sem ilustrações hehe

1. IPv6: principais mudanças em relação a IPv4

As mudanças descritas neste capítulo estão baseadas nos trabalhos de HINDEN & DEERING (1998), MILLER (2000) e HAGEN (2002).

1.1. Espaço de endereçamento

O espaço de endereçamento do IPv6 é de 128 bits, contra os 32 bits do IPv4. Esta é a mudança mais visível do IPv6 em relação ao IPv4. Algumas das primeiras propostas de evolução do IPv4 – vide CALLON (1992), PISTICELLO (1993) e BRADNER & MANKIN (1993) – propunham espaços de endereçamento de 64 ou 96 bits, perfeitamente suficientes para um prazo razoavelmente longo.

A proposta mais interessante, denominada TUBA (TCP and UDP with Bigger Addresses) propunha a substituição do IP pelo CNLP da pilha OSI. O CNLP é bem documentado e tem um espaço de endereçamento de até 20 octetos (160 bits). A indisposição generalizada da comunidade Internet com o protocolo OSI, constatada no trabalho de DIXON (1993), acabou sepultando a idéia. Textos a favor e contra o TUBA e o OSI podem ser encontrados facilmente na Internet.

O endereçamento finalmente adotado visa, principalmente:

a) abrir espaço à criação de tantas classes de endereços quantas forem necessárias, e ainda ter espaço de sobra para um número virtualmente inesgotável de endereços dentro de cada classe; 

b) utilização massiva de roteamento por agregação, onde todas as sub-redes de uma mesma rede apresentam o mesmo prefixo de rede. Isto diminui drasticamente o número de rotas que cada roteador tem de conhecer, em todos os níveis.

Embora o roteamento por agregação seja padrão para IPv4 desde 1995 com a implementação da CIDR (FULLER, 1993), nem todas as redes classe A, B ou C podem ser renumeradas, e os roteadores da espinha dorsal da Internet têm de conhecer rotas específicas para inúmeras redes não agregadas.

O tamanho do endereço IPv6 comporta tanto profundas hierarquias de endereçamento por agregação bem como um grande número de nós por sub-rede. Isso permite:

a) liberal distribuição de faixas de endereçamento a usuários finais, tornando desnecessários, por exemplo, os complexos roteadores NAT (Network Address Translation – tradução de endereço de rede) para compartilhamento de um IP por váriosusuários. O IPv6 acaba com os cidadãos de segunda classe da Internet; 

b) Com o desuso do NAT, ocorre uma grande simplificação na configuração de servidores e dispositivos de rede, o que contribui para o barateamento do acesso à Internet. Evita todos os problemas citados por PEÑA (2001) e permite floresçam protocolos mais sofisticados e.g. voz sobre IP.

Nada impede de um sistema operacional ou dispositivo de rede implementar NAT para IPv6, e de fato é implementado no Linux. Alguns administradores de rede têm a sensação subjetiva de que NAT aumenta a segurança, embora isso seja muito discutível.

1.1.1. Notação de endereços IPv6

Devido a seu tamanho, os endereços IPv6 são textualizados em hexadecimal, 8 palavras de 16 bits cada. Exemplo:

2002:0000:0000:0015:0000:0000:0000:0001

Algumas simplificações são permitidas, de modo a encurtar graficamente o endereço IPv6:

a) Seqüências de palavras 0000 podem ser omitidas; a posição da seqüência é marcada pela cadeia “::”. Exemplos equivalentes: 

2002::0015:0000:0000:0000:0001 

2002:0000:0000:0015::0001 

b) Apenas uma seqüência de zeros pode ser contraída, pois se contraíssemos mais de uma, o endereço tornar-se-ia ambíguo: 

2002::0015::0001 (inválido, qual a posição da palavra 0015 dentro do endereço?) 

c) Os zeros não significantes dentro de cada palavra podem ser omitidos: 

2002::15:0:0:0:1

Os endereços IPv6 compatíveis com IPv4, que serão explanados mais adiante, admitem uma sintaxe parcialmente compatível com IPv4:

xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:a.b.c.d

onde (a.b.c.d) é o endereço IPv4 expresso na tradicional notação decimal pontuada, que ocupa 32 bits. Os demais 96 bits de tais endereços são expressos em hexadecimal, da forma usual IPv6, com as mesmas possibilidades de simplificação.

1.1.2. Máscara de rede

Não existem classes como A, B e C. O IPv6 utiliza o conceito de CIDR (FULLER, 1993), onde um determinado número de bits corresponde ao prefixo da rede, e os bits restantes identificam o nó. Exemplo:

FFFF:FFFF:FFFF:FFFF:0000:0000:0000:0000 

ou 

FFFF:FFFF:FFFF:FFFF::

expressa uma máscara de rede de 64 bits.

As máscaras de rede IP na notação acima são pouco práticas, e aparecem apenas em textos didáticos. A notação usual é a “notação de barra”, com o número de bits 1 da máscara sufixando o endereço IP. Exemplo:

2002:1/64

1.2. Simplificações do protocolo

O aumento do tamanho do endereço IP faz o cabeçalho do pacote crescer, o que aumenta o consumo de largura de banda, dado o mesmo payload (conteúdo útil do pacote). Também o processamento desses pacotes seria, em princípio, um pouco mais pesado para os roteadores.

Para mitigar o aumento de overhead, a camada de rede IPv6 e o respectivo cabeçalho foram simplificados:

a) Pacotes IPv6 não podem ser fragmentados por roteadores intermediários. Fragmentação é um grande complicador da pilha IPv4, bem como fonte abundante de problemas de implementação e brechas de segurança. 

Ao receber um pacote IPv6 grande demais para ser repassado, o roteador deve descartá-lo e notificar o remetente via ICMPv6. É o mecanismo de Path MTU discovery, opcional em IPv4 emandatório em IPv6. 

O nó pode remeter pacotes fragmentados, valendo-se do cabeçalho opcional de fragmentação, mas normalmente não o fará pois já conhece o MTU correto, via Path MTU discovery. 

b) IPv6 exige um protocolo de enlace com MTU mínimo de 1280 bytes; é recomendado um MTU mínimo de 1500 bytes, padrão da Ethernet e da maioria das redes ligadas à Internet. Isso também ajuda a diminuir o uso de pacotes fragmentados. 

c) Não há checksum no cabeçalho IPv6, por dois motivos: 

c.1) praticamente todos os protocolos de enlace em uso corrente são muito confiáveis e implementam por conta própria checagem mais robusta (e.g. CRC da Ethernet); 

c.2) A maioria dos protocolos de quarta camada (TCP, UDP, ICMPv6) têm um campo de checksum. Em IPv6, esse checksum inclui e protege também os endereços do cabeçalho de terceira camada, bem como os números de porta presentes no cabeçalho de quarta camada. 

Esta mudança é extremamente bem-vinda por diminuir o tempo de processamento nos roteadores bem como a latência. Além disso, isenta o roteador de recalcular o checksum ao alterar algum campo variável do cabeçalho IP. 

d) O cabeçalho IPv6 tem tamanho fixo, o mínimo necessário de campos para o uso regular; 

e) Dados adicionais de camada de rede, quando necessários, são alocados em cabeçalhos opcionais, cada um com o tamanho necessário à sua tarefa; 

f) Cada cabeçalho opcional tem um flag hop-by-hop, que sinaliza se os roteadores intermediários devem analisar o cabeçalho. Também colabora para diminuir a latência, pois a maioria dos cabeçalhos opcionais interessa apenas ao destinatário; 

g) Os dados de todos os cabeçalhos são alinhados em 64 bits, que agiliza o processamento em computadores de 32 e 64 bits.

Estas simplificações permitem tornar a implementação do IPv6 no mínimo tão rápida quanto IPv4, e também facilitam sua implementação em hardware Pilha de rede em hardware ou assistida por hardware é comum em roteadores de alto desempenho, já é oferecida em algumas placas de rede e deve ser algo comum no futuro mesmo em computadores de uso geral.

1.3. Mudanças estruturais

O IPv6, além da mudança do tamanho de endereço, possui algumas mudanças estruturais em relação ao IPv4.

1.3.1. Sem broadcast

Não existe broadcast em IPv6. As tarefas antes exercidas pelo broadcast são despachadas via multicast.

1.3.2. Uso extensivo de multicast

A implementação de multicast é obrigatória nas pilhas IPv6, e é utilizado em diversas tarefas de sistema, em particular aquelas onde o IPv4 emprega broadcast.

O multicast é inerentemente mais poderoso que o broadcast, mas boa parte desse poder depende de que os roteadores da Internet implementem os protocolos de roteamento de multicast. Especificamente em substituição ao broadcast na rede local, as vantagens do multicast são:

a) Filtragem por hardware na própria placa de rede. Apenas as máquinas interessadas em um grupo multicast arcam com os custos de processamento; 

A rigor, esta filtragem é imperfeita, pois apenas os 24 bits finais do grupo multicast são mapeados no endereço de enlace. Além disso, cada placa de rede pode filtrar um número máximo de grupos multicast; ultrapassado esse limite, a filtragem é inteiramente delegada ao software. (Felizmente, as boas placas de rede costumam suportar um número de grupos muito superior à demanda atual.) 

b) Possibilidade de criar inúmeros grupos de multicast, enquanto broadcast é apenas um.

Em hubs e switches de baixo custo, pacotes multicast são efetivamente transmitidos via broadcast, portanto substituir broadcast por multicast pode não trazer vantagens na primeira camada. Algunsswitches mais elaborados monitoram as mensagens IGMP e transmitem pacotes multicast apenas a quem interessa.

1.3.3. Autoconfiguração extensiva

Toda interface IPv6 tem um endereço definido de forma automática, mesmo que o nó esteja completamente isolado, ou ligado a uma rede local isolada.

O endereço automático, denominado stateless, sempre possui o prefixo FE80::/10. Devido a isto, ele é válido apenas na rede local, e não é roteável. Nesse último aspecto, ele é análogo a um endereço 10.0.0.0/8 do IPv4.

A garantia da existência deste endereço simplifica consideravelmente protocolos como o DHCPv6 e evita o uso de broadcast. Lembrar que, em IPv4, uma máquina em processo de configuração via DHCP ainda não tem endereço IP e toda a comunicação tem de ser feita por broadcast.

Uma interface IPv6 pode responder por múltiplos endereços – as implementações são obrigadas a suportar essa multiplicidade. O endereço stateless tipicamente será acumulado com outros definidos pelo administrador da rede ou atribuídos via DHCPv6.

Em IPv4, uma interface de rede pode ter mais de um IP (artifício conhecido como IP alias) porém o suporte a IP alias é opcional, e em algumas implementações seu uso causa problemas com a resolução ARP.

1.3.3.1 Autoconfiguração de prefixo de rede

Todo roteador IPv6 deve juntar-se a determinados grupos multicast e noticiar o prefixo de rede.

Assim, os nós IPv6 podem obter o prefixo de rede e realizar a auto-configuração de endereços roteáveis na Internet. Se o prefixo de rede for mudado, apenas o roteador precisa ser reconfigurado; os demais nós vão conhecer a mudança dinamicamente.

1.3.4. Uso de endereço de segunda camada como sufixo de endereço IPv6

O tópico 1.3.3 não esclareceu de onde vem o sufixo dos endereços IPv6 automáticos. Esse sufixo está no padrão EUI-64, descrito por CRAWFORD (1998) e por HINDEN & DEERING (1998), e que contém várias informações importantes sobre o endereço:

a) fabricante do equipamento de rede (bits 0 a 5 MSB), tipicamente baseado no endereço de enlace; 

b) se o código EUI-64 foi gerado localmente ou é baseado no endereço de enlace (bit 6 MSB); 

c) se o endereço representa um endereço unicast ou multicast (bit 7 MSB); 

d) identificador unívoco (demais bits), tipicamente baseado no endereço de enlace. O mapeamento do endereço de enlace para este identificador é ligeiramente diferente para cada arquitetura de enlace. 

Por exemplo, o endereço stateless é calculado assim: 

– prefixo FE80::/10 

– sufixo de 64 bits EUI-64 baseado no endereço de enlace 

Esta solução já foi adotada com sucesso por outros protocolos de rede, notoriamente o IPX. Ela funciona porque o endereço de enlace é tipicamente unívoco.

Em Ethernet e FDDI, a unicidade do endereço de enlace é garantida pelo instituto IEEE que fornece faixas de endereçamento aos diversos fabricantes, que por sua vez atribuem um endereço não reaproveitável a cada placa de rede.

Algumas arquiteturas de enlace não garantem unicidade. Em particular o ARCNet tem um endereço de 8 bits, fixado pelo administrador, suficiente apenas para distinguir o nó num segmento de rede. Nelas, a parte final do código EUI-64 é gerada aleatoriamente.

Outras arquiteturas, como ATM e Frame Relay, além de possuirem endereços de segunda camada pequenos, não suportam broadcast nem multicast. Para estes, deve haver um servidor ARP responsável pela tradução de endereços.

Algumas placas de rede permitem que seja mudado o endereço de enlace, e nada impede que alguém atribua o mesmo endereço a duas ou mais placas. Isto abre a possibilidade de coincidência ou “colisão” de endereços IPv6. A palavra “colisão” transmite melhor a idéia de que endereços coincidentes vão interferir e falhar ao comunicar-se com outros nós da rede.

Para evitar os dissabores de uma eventual colisão, o IPv6 realiza uma busca automática do endereço na rede local antes de adotá-lo. No improvável caso de outro nó estar usando o mesmo endereço, ocorre o fallback para a geração aleatória.

1.3.4.1 Sufixo de endereços IPv6 públicos

Também no caso dos endereços roteáveis, o sufixo do endereço pode ser preenchido com base no endereço de enlace.

Como vimos, os nós podem obter automaticamente o prefixo de rede do roteador, via multicast. (O roteador pode ele mesmo ter obtido o prefixo de forma automática junto ao provedor de acesso.) Portanto, os nós podem obter seu endereço completo (prefixo+sufixo) por meios dinâmicos.

Isso traz quatro problemas, todos solucionáveis:

a) O registro DNS referente ao nó teria de ser atualizado se/quando sua placa de rede fosse substituída, o que não é nada prático; 

b) Um nó que ofereça serviços à Internet pública tornar-se-ia inacessível quando tiver a placa de rede substituída, mesmo que o registro DNS fosse consertado, pois essa mudança demoraria a propagar-se pelos servidores DNS; 

c) Os endereços assim criados são difíceis de memorizar e administrar, e isso acabaria encorajando os administradores a modificar endereços de enlace, o que é totalmente indesejável; 

d) Como os endereços de enlace são únicos em todo o mundo e rotulam o hardware, os endereços IPv6 baseados neles trazem um problema de privacidade – seria possível rastrear a localização e os hábitos de computadores e dispositivos portáteis.

As respectivas soluções são:

a) Em IPv6, a utilização de DNS dinâmico é, na prática, indispensável; 

b) Nós acessíveis a partir da Internet pública (e.g. servidores Web) podem ter endereços IP adicionais, estáveis, não atrelados à placa de rede, atribuídos manualmente pelo administrador; 

c) Tais endereços criados manualmente podem usar sufixos simples com 0, 1, 2… o que torna-os tão simples de memorizar e administrar quanto endereços IPv4; 

d) Nós e aplicações que exijam precaução redobrada com privacidade podem gerar um sufixo de 64 bits aleatório ao invés de utilizar o endereço de enlace. Tal geração tem baixa probabilidade de colisão e de qualquer forma o protocolo IPv6 fiscaliza a ocorrência de colisões, conforme descrito em 1.3.4.

A chance de colisão é em torno de 2^-0.5n, onde n é o número de bits do número aleatório. Para um número aleatório de 64 bits, a chance de colisão é 2^-32. Essa chance aparentemente alta de colisão é conhecida como Paradoxo do Aniversário: dadas 23 pessoas, existe uma chance de 50% de haver duas com a mesma data de aniversário. Referências em HOWSTUFFWORKS e BURTLE.

1.3.5 Faixas de endereçamento

Conforme foi dito em 1.1, o grande espaço de endereçamento visa a criação facilitada de classes de endereçamento. Tais classes, mais apropriadamente denominadas de faixas de endereçamento, são registradas junto à IETF. Segue uma lista das principais faixas e os respectivos prefixos IPv6.

Aproximadamente 15% do espaço de endereçamento IPv6 foi alocado. Restam ainda 85%.

A presença de faixas para IPX e NSAP é resultado de uma diretiva de design do IPv6: permitir que outros protocolos trafeguem na Internet sem necessidade de tunelamento explícito, bem como permitir que os aplicativos possam comunicar-se com nós não-IP de forma transparente (SKELTON, 1994; CLARK et al., 1994). Hoje, a utilização dos protocolos não-IP é tão restrita, e sem perspectiva de ressurgência, que essas faixas caíram em obsolescência.

Os endereços roteáveis na Internet têm mascara de rede de 64 bits, o que permite uma hierarquia de roteamento relativamente profunda (muito mais profunda que a proporcionada por qualquer classe IPv4) e um número virtualmente ilimitado de nós por rede.

Também existem alguns endereços especiais:

1.3.6. Multicast

Formato do endereço:

FFFF:xyee:eeee:eeee:eeee:eeee:eeee:eeee

x = flags 

y = escopo 

e = restante do endereço

Os endereços multicast funcionam de forma muito semelhante ao IPv4, com as seguintes diferenças:

a) O espaço de endereçamento é muitíssimo maior; 

b) Os octetos 5 e 6 têm propósito especial: flags e escopo, respectivamente; 

c) No IPv4, o valor do campo TTL é sobrecarregado com o escopo do multicast. No IPv6, essa sobrecarga não existe; o sexto octeto do endereço de multicast é que informa o escopo.

1.3.6.1 Campo de flags (4 bits)

1.3.6.2. Campo de escopo (4 bits)

Um roteador IPv6 ligado a uma rede local nunca aceitará rotear pacotes multicast com escopo menor que 5 (sítio local); um roteador ligado à espinha dorsal da Internet não aceita multicast com escopo menor que 14, e assim por diante.

1.3.6.3. Endereços multicast predefinidos

O IANA predefine a aplicação de alguns de endereços de multicast IPv6. Exemplos:

FF02::1 Todas as máquinas da rede local – propósito geral 

FF02::2 Todos os roteadores presentes na rede local – propósito geral

Esses dois grupos são mandatórios; todos os nós têm de se associar ao grupo FF02::1, e todos os roteadores têm de se associar ao grupo FF02::2. Por exemplo, para comunicar-se com todas as máquinas da rede local via multicast, basta usar o grupo predefinido FF02::1. Para procurar por um roteador, basta mandar pacotes para FF02::2.

Note que estes endereços têm o escopo igual a 2 (rede local). Outros exemplos de endereços predefinidos:

FF02::1:2 => Agentes DHCP 

FF02::1:FFxx:xxxx => Resolução de endereços (abordado em tópico próprio)

O fato de um nó estar no grupo FF02::1 não quer dizer que ele processe todo o tráfego multicast direcionado a esse grupo. Se não houver nenhuma aplicação interessada em multicast, o tráfego é desprezado.

Os grupos citados são mandatórios porque são freqüentemente demandados; sua predefinição evita que cada aplicação utilize um grupo multicast diferente para o mesmíssimo fim.

1.3.7. Anycast

Um endereço anycast, assim como um endereço multicast, representa um agrupamento de nós de rede. Porém, é diferente em três aspectos cruciais:

a) apenas um dos nós do grupo receberá cada pacote cujo destino é um endereço anycast; 

b) o prefixo de rede de um endereço anycast não é predefinido como no multicast; já o sufixo de rede é predefinido como zero; 

c) o pacote anycast é roteável, segundo seu prefixo de rede; pode portanto trafegar na Internet sem necessidade de um protocolo de registro como o IGMP, nem suporte especial nos roteadores intermediários. Apenas o destinatário tem de dar tratamento diferenciado ao pacote anycast. Nesse aspecto, anycast é algo semelhante ao broadcast remoto IPv4.

O anycast é em princípio uma novidade muito promissora, embora sua natureza orientada a pacotes impeça seu uso em protocolos de transporte orientados a conexão (a mesma limitação domulticast).

Um dos primeiros usos atribuídos ao anycast foi a autoconfiguração dos nós. Posteriormente, tais funções acabaram delegadas ao multicast. O uso prático do anycast é atualmente muito restrito. Uma possível aplicação futura é o Mobile IP.

1.3.8 ICMPv6

Uma das metas do IPv6 é não forçar alterações em protocolos de camadas superiores. De fato, o protocolo TCP roda sem qualquer modificação sobre IPv6. Porém, o protocolo ICMP foi alterado, por boas razões.

O ICMP continua exercendo as funções que tinha no IPv4 (ping, MTU discovery, notificações de erros etc.), mas foi estendido para absorver funções de outros protocolos. Isso é bom pois evita a multiplicidade de protocolos, o que aumenta a coerência e torna as implementações mais enxutas.

1.3.8.1 Resolução de endereços de enlace

O protocolo ARP não é utilizado em IPv6, pois não existe broadcast em IPv6 e o ARP baseia-se em broadcast. Em seu lugar, é utilizado o protocolo ICMPv6 e transmissão multicast.

Referimo-nos aqui ao protocolo ARP utilizado em arquiteturas de rede baseadas em difusão ou anel, nas quais é fácil e eficiente fazer a procura direta por um endereço de enlace mediantebroadcast ou multicast.

Em arquiteturas hierárquicas como Frame Relay ou ATM, a procura exaustiva por um nó é inviável, nem é suportado broadcast e/ou multicast. Em tais arquiteturas, existe um servidor ARP com endereço de enlace conhecido, onde o administrador da rede cadastra os pares endereço de enlace: endereço IP. O protocolo ARP utilizado na comunicação com esse servidor, que não é abordado neste trabalho, é bem diferente do ARP tradicional (BRAZDZIUNAS, 1994).

O multicast é utilizado na procura de endereços IPv6 da seguinte forma:

a) É calculado um endereço multicast a partir de cada endereço IPv6 do nó, da seguinte forma: 

– prefixo FF02:0:0:0:0:1:FF00::/104 (citado em 1.3.6.3) 

– sufixo: os últimos 24 bits do endereço IPv6 

b) Todo nó IPv6 é obrigado a permanecer na escuta de todos os endereços multicast calculados por esse método. 

Neste caso, não é necessário que haja uma aplicação interessada; a própria implementação (que tipicamente reside no kernel) deve interpretar o tráfego ICMP recebido por essa via. 

c) Quando outro nó quiser descobrir onde está um determinado IP, emite um pacote ICMP multicast formado pelo método descrito acima. 

Exemplo: se se deseja descobrir onde está o endereço 3FFF::DEAD::BEEF, o endereço de remessa do pacote ICMP será FF02::1:FFAD:BEEF. 

d) Os nós cujos endereços coincidam com o solicitado nos 24 bits finais receberão o pacote, e apenas o nó possuidor do endereço requisitado responderá.

Existe, é claro, a possibilidade de haver dois endereços IPv6 numa mesma rede que coincidam nos 24 bits finais. No entanto, esta chance é pequena – em torno de 2^-12 (BURTLE) – se os sufixos IPv6 forem obtidos dos endereços de enlace ou forem aleatórios. Portanto, este método é muito mais leve que o broadcast, pois pouquíssimos nós (geralmente um) efetivamente analisam e respondem a cada solicitação.

1.3.8.2. IGMP

O protocolo IGMP também foi absorvido pelo ICMPv6. A mecânica do IGMP continua a mesma, exceto pelo tamanho dos endereços.

1.3.8.3. Detecção de colisões de endereços IPv6

Através do mesmo mecanismo descrito em 1.3.8.1, o ICMPv6 detecta colisões de endereços auto-configurados. Antes de adotar um endereço, procura-se por ele na rede; se ninguém reclamar sua posse, então pode ser usado.

Todas as implementações IPv6 são obrigadas a fiscalizar colisões desse gênero.

1.3.9. IP móvel

Há duas situações principais onde o IP móvel é útil:

a) um nó numa uma rede wireless, que troca de ponto de acesso na medida em que se movimenta; 

b) um nó que é desligado de uma LAN e ligado à outra.

Nas duas situações, o nó móvel recebe um IP novo (via DHCP ou protocolo equivalente) e as conexões em andamento são perdidas. Para evitar isso, existe o IP móvel.

O funcionamento do IP móvel é relativamente simples. Ao contectar-se à uma LAN ou ponto de acesso, o nó móvel liga-se um agente de IP móvel. Toda a comunicação desse nó com a Internet é feita através do agente.

O endereço IP dos pacotes que trafegam na Internet será o do agente. O IP do nó móvel é anexado num cabeçalho opcional, denominado “ care of ” (“aos cuidados de”). Isso faculta aos nós remotos saber que estão comunicando-se com um nó IP móvel.

Em IPv4, devido à inexistência de cabeçalhos opcionais nos moldes do IPv6, o IP móvel é implementado como um túnel IP tradicional, o que torna problemáticos a instalação e o suporte. Em IPv6, a implementação é transparente aos aplicativos e à rede.

Segundo GAST(2002), é possível evitar a troca de IP numa rede wireless mesmo sem o uso de IP móvel. O padrão 802.12 prevê um endereço care of na camada de enlace, o que permite a um nó conservar o mesmo IP mesmo trocando de ponto de acesso (desde que é claro todos os pontos de acesso utilizados pertençam à mesma rede wireless). É uma solução interessante, complementar porém não substituta ao IP móvel.

1.3.10. Segurança

O protocolo padrão de segurança para IPv6 é o IPSEC, cuja implementação é mandatória em todos os nós IPv6.

Devido à complexidade do protocolo IPSEC, sua implementação tanto em IPv4 quanto em IPv6 ainda está em andamento ou em estado imaturo em muitas plataformas. Então, apesar da obrigatoriedade teórica, um aplicativo IPv6 deve testar a presença de IPSEC antes de contar com ele.

Características do protocolo IPSEC:

a) projetado para utilização em IPv4 e IPv6; 

b) permite garantir integridade, confidencialidade e origem dos pacotes. Soluciona praticamente todos os problemas de segurança pertinentes às camadas de rede e transporte. IPSEC não resolve, por exemplo, o problema da não repudiação de um e-mail. Tais problemas devem ser resolvidos pelos protocolos de aplicação, como o PGP; 

c) uso de certificados digitais, forma aceita como a mais adequada para identificação segura de uma entidade; 

d) previsão de um conjunto mínimo de algorítmos de criptografia, que todos os nós IPSEC têm de implementar. Os nós podem implementar outros algorítmos, e negociam entre si para determinar qual o melhor algorítmo em comum que vai ser usado na conexão. 

e) opera em dois modos: transporte e túnel; 

No modo transporte, os endereços IP de origem e destino do cabeçalho não são criptografados, muito embora sua integridade possa ser garantida. 

Este modo é mais prático, pois dois nós IPSEC quaisquer podem conectar-se sem previsão administrativa. Por outro lado, os hábitos de conexão dos nós ainda podem ser espionados. A utilização generalizada do modo transporte aumentará muito a segurança da Internet como um todo. 

Já no modo túnel, os endereços IP também são criptografados. O pacote original é inteiramente reempacotado num pacote IPSEC. Os endereços IP visíveis são os endereços das extremidades do túnel, e não dos nós que estão realmente se comunicando. 

Este modo exige providências administrativas nas duas extremidades, portanto apenas as conexões especialmente previstas serão seguras. Mas o túnel impede um espião de estudar os hábitos de conexão, o que aumenta a segurança. Também é possível, no modo túnel, interligar redes com endereçamento não roteável na Internet pública e/ou sem acesso direto à Internet. 

O modo transporte é utilizado primariamente na construção de VPNs. 

(O FreeS/WAN, implementação IPSEC para Linux, oferece um modo de “criptografia oportunista” para o modo túnel, sem configuração e sem comunicação prévia entre as duas extremidades; porém, é uma extensão própria do FreeS/WAN e implica em cadastrar a chave pública de pelo menos um dos sítios em um servidor DNS.) 

f) Por ser um padrão, o IPSEC é o único protocolo de segurança de rede disponível em todos os sistemas operacionais de mercado, e devido a isso também é o único protocolo interoperável.

Infelizmente, alguns fatores têm retardado a adoção generalizada do IPSEC:

a) protocolo um tanto complexo; 

b) as implementações existentes têm consideráveis desvios e apresentam problemas de interoperabilidade; 

c) o algorítmo de criptografia DES, que todo nó IPSEC deveria implementar mandatoriamente, é notoriamente fraco para os padrões atuais. Segundo referência em FREESWAN, algumas implementações recusam-se a utilizá-lo (o que viola o protocolo), enquanto outras oferecem apenas esta opção (devido às restrições de exportação de criptografia do governo americano), o que elimina de plano a interoperabilidade (discussão completa a respeito em FREESWAN (a)); 

d) O uso do protocolo exige algumas providências administrativas, como a obtenção de certificados digitais, cuja existência e funcionalidade são ignoradas por muitos administradores de rede; 

e) A existência de outros protocolos, que por incompletos e não interoperáveis são de utilização mais fácil, retarda a adoção generalizada do IPSEC.

Espera-se que com a pressão dos usuários, as diversas implementações IPSEC melhorem qualitativamente e uniformizem o conjunto mínimo de recursos oferecidos, bem como possibilitem criptografia automática sem qualquer intervenção administrativa.

1.3.11. Tráfego multimídia

O cabeçalho IPv6 possui campos de fluxo e prioridade, com uso potencial para aplicações que exijam fluxo com alguma garantia de qualidade (QoS). IPv4 possui apenas flags de prioridade.

A experiência com IPv4 revela, porém, que QoS na Internet é um problema por resolver, e a utilização desses campos é, hoje, quase nula. O principal problema é que implementar garantias numa Internet pública induziria todo fluxo a requisitar garantia, mesmo quando desnecessária, e como os recursos da Internet são limitados, a grande maioria das requisições seria rejeitada, invalidando completamente a idéia.

A saída é cobrar taxas extras dos requisitantes de fluxos com garantias de serviço, para o que seria necessário estabelecer acordos de cobrança inter-provedores (pois um fluxo pode percorrer diversos provedores, e a garantia de fluxo só é efetiva se todos os provedores intermediários honram a garantia solicitada), bem como preparar os equipamentos de rede para implementar as garantias bem como registrá-las e tarifar o solicitante. Essa infra-estrutura não existe hoje.

À época de projeto do IPv6, acreditava-se que todas estas questões logo estariam resolvidas, o que justificou a inclusão dos campos de fluxo cabeçalho principal. A visão atual é que esses campos deveriam ter sido previstos em um cabeçalho opcional.

Presumindo que o futuro resolva tais problemas, o candidato mais promissor a protocolo de reserva de qualidade é o RSVP.

Finalmente, é prudente lembrar que, embora a garantia de qualidade de serviço não exista na Internet atual, ele pode ser e de fato é utilizada numa rede ou inter-rede privada, e nesse caso os campos do cabeçalho IPv6 podem ser úteis.