A utilização de dispositivos móveis ligados em rede tem vindo a aumentar, resultando principalmente da explosão de adesões à Internet. Novas tecnologias (redes sem fios, ligação através de micro-ondas) estão a se tornar comuns rapidamente. O IPv4 não previu a utilização crescente deste tipo de dispositivos.
Na medida em que um host se movimente de uma rede para outra, seu endereço IP irá sendo alterado. Isto, a princípio, geraria o problema de nunca se saber o endereço atual deste host, inviabilizando a comunicação com o mesmo. No entanto, o IPv6 implementa um método que permite esta mobilidade.
Este método consiste basicamente em todo host móvel possuir um endereço fixo em sua rede local original, conhecido como home address. Ao se autoconfigurar em uma rede qualquer, o host móvel envia uma mensagem a sua rede local "avisando" seu novo endereço na rede na qual é visitante. Deste modo, todos os pacotes destinados ao seu endereço original serão roteados para o seu endereço visitante, permitindo assim a recepção de pacotes de forma transparente.
6.1 - Mobile IPv4
A versão original do IP não previa suporte a mobilidade de hosts, e o assim como diversos entre outros protocolos, o Mobile IP foi desenvolvido ad hoc. Muitos usuários da Internet possuem computadores portáteis, e necessitam acesso à rede fora de sua base, ou mesmo em movimentação. Infelizmente, o sistema de endereçamento do IP não facilita a tarefa de manter um host móvel conectado. O modo como pacotes são entregues ao host de destino não permite que o mesmo saia de sua rede sem que seja necessário alterar o endereço do mesmo, ou, alternativamente, avisar a todos roteadores a nova localização do host móvel. Esta última alternativa é impraticável, portanto a solução oferecida não deve contar com esta possibilidade.
Em 1996 foi publicada a RFC 2002 (IP Mobility Support), o primeiro documento tratando da implementação do suporte a mobilidade no IP. Vários documentos se seguiram a este, aprimorando o protocolo que será descrito brevemente neste tópico.
Conforme RFC 2002 (PERKINS, 1996), os usuários com MH (Host Móvel) possuem uma rede local base, e podem se locomover entre diferentes áreas, onde uma área é tipicamente uma rede remota em que o usuário ou uma célula wireless se conecta. Cada uma dessas áreas possui um ou mais FA (Foreing Agent ou agente remoto), que são responsáveis por gerenciar a permanência de MHs na sua respectiva área. Além disso, cada área tem um HA (Home Agent ou agente local), responsável pelos MHs de suas bases originais, mas que estão visitando outras áreas.
Sempre que um MH adentra uma área, ele deve se registrar com o FA responsável por esta área. O FA periodicamente faz um broadcast de seu endereço, anunciando sua presença para os novos MHs, que, caso não queriam esperar pelo broadcast do FA, também podem fazer um broadcast perguntando quem é o FA responsável.
O host móvel se registra com o FA, dando o endereço do seu home agent e informações de segurança. O FA, por sua vez, entra em contato com o HA, fornecendo as informações de segurança recebidas do MH, e anunciando a presença do mesmo na área. Satisfeito com as informações, o HA diz ao FA para prosseguir com o registro, e este último avisa então ao MH que ele está registrado.
A partir deste ponto, sempre que um host tentar contatar o MH, o pacote direcionado ao mesmo será interceptado pelo HA, na rede local base do MH, pois a princípio o remetente não sabe se o MH está na sua área permanente ou em uma outra área. Após interceptar o pacote, o HA faz o seguinte:
Encapsula este pacote no campo de dados de um novo pacote, e direciona este novo pacote para o FA responsável pela área onde o MH se encontra. Este procedimento é chamado de tunneling, ou, tunelamento.
Avisa ao remetente do pacote original para enviar os próximos pacotes destinados ao MH diretamente para o FA, usando a mesma técnica de tunneling. Desta forma, os pacotes subseqüentes não precisam passar pelo HA.
Envio de pacotes pelo Mobile IPv4.
Na figura acima, tem-se:
a. Um host deseja contactar o MH, e envia um pacote para seu endereço.
b. O HA sabe que o MH não está na área, e então intercepta o pacote, encapsula o mesmo em um novo pacote e envia para o FA.
c. O FA recebe o pacote, desencapsula o pacote original e envia este para o MH.
d. Pacotes subseqüentes são enviados diretamente para o FA.
6.2 - Mobile IPv6
O MIPv6 (Mobile IPv6) é um protocolo que foi desenvolvido como um subconjunto do Internet Protocol version 6 (IPv6) para dar suporte a conexões móveis. O MIPv6 facilita o movimento do nó de uma rede do tipo Ethernet para outra do mesmo tipo assim como o movimento de uma rede Ethernet para uma célula de Wireless LAN.
MIPv6 é uma atualização do padrão Mobile IP (RFC 2002), criado pela IETF, e foi desenvolvido para autenticar dispositivos móveis (conhecidos como nós móveis) usando endereços IPv6.
6.2.1 – Funcionalidade IPv6 Mobile
O Mobile IPv6, assim como o MIP, permite que um nó móvel se mova de uma rede a outra sem quebrar uma conexão. Isto significa que o endereço original (home address) nunca se modifica. O nó móvel (MN) pode estar em qualquer lugar, que os pacotes serão roteados corretamente para ele através de mecanismos apropriados. O movimento é, desta forma, transparente para a camada de transporte e para aplicações que usam o protocolo TCP/IP e Mobile IPv6.
O home address é constituído de um prefixo válido no link de sua rede original (home network). É através deste endereço que um nó correspondente irá se comunicar com o nó móvel, independente de onde este estiver. Quando o nó móvel muda de rede, ele mantém o home address e recebe outro endereço, o care-of address (COA), constituído de um prefixo válido em uma rede estrangeira. Este endereço é conseguido de forma stateless ou stateful, (sem ou com servidor de endereços, respectivamente). Desta forma, o MN terá um home address e um ou mais care-of address quando está se movendo entre redes.
Para que seja possível saber onde o nó móvel se encontra, uma associação entre home address e care-of address deve ser realizada (binding). Esta associação do care-of address é feita pelo nó móvel, no home agent (HA). Esta associação é realizada através de um binding registration, onde o MN envia mensagens chamadas Binding Updates (BU) para o HA, que responde com uma mensagem Binding Acknowledgement (BA).
Os nós correspondentes (CNs) no MIPv6 possuem "inteligência" para a otimização de rota, ou seja, eles podem armazenar bindings entre home address e care-of address de nós móveis. Sendo assim, um nó móvel pode fornecer informações sobre sua localização para CNs, através do correspondent binding procedure. Neste procedimento, um mecanismo de autorização de estabelecimento de binding é realizado, chamado de return routability procedure. A figura abaixo mostra um cenário de mobilidade IPv6 com elementos básicos:
Visão Geral Ipv6. (Fonte: Rede Nacional de Ensino e Pesquisa)
Nota-se que o Foreign agent (FA), presente no MIPv4, não existe mais. A comunicação entre MN e CN pode acontecer de dois modos:
Tunelamento bidirecional: não requer que o CN tenha suporte ao MIPv6 e que o MN tenha se registrado com o CN. Os pacotes são roteados do CN para o HA e do HA é tunelado para o MN. Depois, o MN responde para o HA por túnel que, por sua vez, responde para o CN. Cada pacote interceptado é tunelado para o care-of address do MN;
Otimização de rota: o CN deve ter suporte ao MIPv6 ("inteligência" para binding) e o MN deve se registrar com o CN. Neste caso, o CN, antes de enviar o pacote, busca em uma cache uma associação entre home address e care-of address do MN. Se existir associação, o pacote será roteado para o care-of address do nó móvel diretamente. Isto elimina congestionamento no home link e no HA. A figura a seguir ilustra os dois modos:
Modos de comunicação entre CNe MN. (Fonte: Rede Nacional de Ensino e Pesquisa)
6.3 - Operação do Host Móvel
Quando em uma rede remota, o host móvel continua utilizando seu home-address, em adição aos COAs, podendo escolher entre estes endereços para utilizar como endereço de origem. Do ponto de vista das camadas de protocolo acima do Mobile IP, o host móvel geralmente vai utilizar seu home-address a fim de manter a transparência para estes aplicativos. Isso implica em transparência também para os hosts com os quais ele se comunica, como se o host móvel nunca tivesse saído de sua rede local.
Ao enviar tais pacotes, eles serão modificados de forma a mover o home-address do campo origem para a opção de home-address e utilizar um dos COAs como endereço de origem do pacote. Estas alterações serão revertidas no receptor do pacote, inserindo o home-address de volta no campo de origem, assim alcançando a desejada transparência para camadas superiores.
Para alguns tipos curtos de comunicação, particularmente as operações em que novas tentativas podem ser efetuadas com facilidade (ex.: DNS), o host móvel pode utilizar diretamente um de seus care-of-address no campo de origem do pacote, eliminando assim o processamento extra de utilizar a opção home-address. Para isso, no entanto, é necessário que a aplicação saiba tratar este tipo de comunicação, caso contrário recomenda-se utilizar o método mencionado anteriormente.
É importante reafirmar que pacotes enviados quando o host móvel está na sua rede local não precisam sofrer nenhuma alteração, sendo processados da mesma forma que pacotes gerados em hosts estacionários. Da mesma forma, pacotes enviados pelo host móvel de uma rede remota utilizando um IP da rede remota não são alterados. Um problema visto nesta forma de trabalhar é que hosts correspondentes que fazem algum tipo de verificação baseada no home-address do host móvel não irão reconhecê-lo, uma ver que o endereço de origem não é o home-address, e sim o endereço utilizado na rede remota.
Um host móvel, quando em rede remota, vai receber pacotes destinados ao seu home-address de uma das seguintes três maneiras:
Pacotes enviados por um correspondente que não tem uma entrada para o host móvel em seu binding-cache serão interceptados pelo HA na rede local do host móvel e tunelados para o COA do host móvel.
Pacotes enviados por um correspondente que tem uma entrada para o host móvel em seu binding-cache farão uso do cabeçalho de roteamento, e enviados diretamente para o COA do host móvel, recuperado do cache.
Pacotes enviados por um correspondente que tem uma entrada inválida para o host móvel em seu binding-cache serão enviados como no item 2. O pacote, ao chegar na rede onde o COA utilizado reside, será descartado, pois o host móvel não se encontra mais nesta rede. Porém, se o host móvel tiver enviado um binding-update para o FA desta rede, o pacote será interceptado por este último, sendo tunelado para o novo COA do host móvel, que receberá o pacote com sucesso.
Para os casos 1 e 3 descritos acima, é recomendado que o host móvel envie um binding-update para o remetente do pacote, a fim de criar ou atualizar a sua entrada no binding-cache do correspondente.
O host móvel, visando descobrir a rede em que está, utiliza as facilidades implementadas pelo IPv6 Neighbor Discovery, além de ouvir os anúncios feitos pelos FA's locais. Baseado nestes métodos, o host móvel mantém uma lista com FA's e redes considerados ativos, além dos COA's disponíveis para seu uso, escolhendo uma das opções para ser o padrão, ou ainda, COA primário. Ao detectar que o FA em uso não está ativo, o host móvel deve escolher um novo de sua lista, e, devido à alteração do COA, fazer um binding-update com seu HA.
Esta lista também é utilizada quando o host móvel passa a utlizar outro COA; todos os FA's recebem um binding-update, para que possam tunelar pacotes enviados para o COA antigo. Ao selecionar um novo COA primário, o host móvel é obrigado a enviar um binding-update para seu HA com os seguintes requisitos:
bit H (home registration) deve estar ligado;
bit A (acknowledge) deve estar ligado;
pacote tem que ter a opção de home-address preenchida;
endereço de origem do pacote deve ser o COA a ser registrado, a menos que a sub-opção de COA alternativo esteja sendo utilizada;
é recomendado que o tempo de vida informado para este binding seja menor ou igual ao tempo de vida do COA.
Caso o host móvel tenha mais de um home-address, um binding-update deverá ser feito para cada um deles, obviamente em pacotes separados. Em algumas situações o host móvel pode não saber o endereço de um host em sua rede local que pode servir de home-agent para ele. Neste caso o host móvel pode tentar descobrir o endereço de um host, como foi mencionado no tópico " Operação do Home Agent ". É obrigatório que o host móvel tente o binding-update antes com o HA que ele já vinha utilizando, caso exista.
O host móvel pode mandar binding-updates também para correspondentes, para que estes atualizem seu cache, evitando assim o overhead de tunelamento por parte do FA. O COA utilizado nesta operação pode ser escolhido livremente dentre os disponíveis para o host móvel; se o endereço utilizado for o home-address, o correspondente deve remover do cache a entrada correspondente ao host móvel.
É interessante notar que caso o host móvel não queira divulgar sua localização atual para um correspondente, basta não enviar binding-updates para este correspondente. Neste caso os pacotes serão tunelados pelo HA.
Para ativar o encaminhamento de pacotes por parte do FA, mencionado anteriormente, o host móvel deve mandar um binding-update para qualquer FA da rede remota onde ele estava anteriormente, utilizando como endereço de origem o COA utilizado nesta rede remota anterior e passando seu novo COA como o endereço a ser inserido no cache. É importante que o bit H (home registration) esteja ligado nesta mensagem, significando que o FA deve atuar temporariamente como HA do host móvel naquela rede. Um aspecto interessante é que este FA não sabe necessariamente o home-address do host móvel, e nem precisa saber, pois tudo que ele tem que fazer é tunelar pacotes destinados ao COA antigo para o novo COA.
Correspondentes desejando saber o COA do host móvel podem enviar um binding-request para o mesmo. Ao receber este pedido o host móvel pode escolher entre responder ou não o pedido. Como mencionado anteriormente, o host móvel pode responder com um COA que é o seu próprio home-address, indicando que ele recebeu o pedido mas não quer divulgar sua localização. O host móvel pode também, é claro, processar o pedido normalmente, enviando um binding-update com seu COA atual.
A multiplicidade de COAs no host móvel auxilia o processo de smooth handovers, no sentido que ao se deslocar por células sobrepostas, o host móvel pode receber pacotes destinados a qualquer um dos COAs disponíveis. Assim, mesmo trocando de COA primário, o host móvel pode manter o COA primário anterior na lista de COAs disponíveis para uso. Outro benefício na disponibilidade de vários COA é a possibilidade do host móvel escolher como COA primário o que pertence à rede com melhor nível de comunicação, aumentando assim a eficiência de transmissão.
Ao retornar para sua rede local, o host móvel deve enviar um binding-update para seu HA, pedindo para que este deixe de interceptar e tunelar os pacotes destinados a ele. Uma situação que requer cuidado pode ocorrer neste ponto: caso o host móvel não saiba o endereço de camada link do home-agent, ele deve solicitar este endereço utilizando unicast e endereço de origem não especificado para evitar problemas com o algoritmo de detecção de endereços duplicados.
6.4 - Considerações de Segurança
O uso de binding-updates não autenticados é tido como problema de segurança conhecido pela comunidade. Como este recurso permite que pacotes destinados a um host móvel sejam enviados para um endereço remoto (COA), o uso não autenticado do mesmo poderia acarretar em updates maliciosos que levariam um correspondente a enviar pacotes destinados ao host móvel para um terceiro host.
Assim como o binding-update, as confirmações destes updates também devem ser autenticados. Alguém mal-intencionado poderia enganar o host móvel, fazendo este acreditar em um resultado falso de um update com seu HA, por exemplo. Ao contrário do binding-update e sua confirmação, o binding-request não oferece nenhum risco de segurança, pois seu uso não implica em mudança de estados no host móvel ou no correspondente.
Os números de seqüência utilizados nos binding-updates e suas confirmações também devem ser renegociados para evitar ataques de repetição de pacotes. A autenticação dos pacotes de binding-update é feita através da verificação do campo BSA (binding security association), existente conceitualmente em um campo do binding-cache. O processo para estabelecer tal associação não está definido no " Draft IETF Mobile IPv6 ", e portanto está em aberto.
Um assunto já pendente no IPv4 que não foi resolvido no IPv6 é a questão do ARP gratuito, ou Neighbor Advertisement no IPv6, que tem como efeito associar um endereço IP a um determinado endereço de camada link. Um usuário malicioso conectado à rede local pode emitir um destes pacotes, anulando assim a proteção que o uso de hubs chaveados traz. A técnica é um pouco mais complicada do que o explicado aqui, e está amplamente coberta em outros textos.
Além dessas questões, devemos considerar que o ambiente de computação móvel é bastante diferente do ordinário, estando as estações muitas vezes conectadas através de dispositivos sem fio (wireless). Tais conexões são muito vulneráveis a interceptação passiva dos dados, além de outros ataques ativos, como enviar pacotes especialmente preparados para causar algum tipo de confusão. Alguns deste problemas podem ser evitados utilizando-se criptografia. Estações móveis são ainda mais fáceis de serem roubadas, e neste caso, as chaves de autenticação ou de criptografia, bem como outras informações serão comprometidas.
Usuários preocupados em manter secreta a localidade do host móvel, podem usar uma técnica que consiste em tunelar para o HA os pacotes a serem enviados. Desta forma, os pacotes vão parecer estar saindo da rede onde o home-agent reside, mantendo assim o local verdadeiro de transmissão secreto.
6.5- Futuro do MIPv6
O HMIPv6 (Hierarchical Mobile IPv6) foi proposto como uma melhoria o MIPv6. Ele foi desenhado com o propósito de reduzir a quantidade de sinalização requerida e para melhorar a velocidade de handoff para conexões moveis. O HMIPv6 foi proposto pelo IETF (Internet Engineering Task Force).
O MIPv6 define meios de gerenciar mobilidade global, mas não enfoca o gerenciamento de mobilidade local separadamente. Ele utiliza-se do mesmo mecanismo em ambos os casos, o que causa uma ineficiência na utilização de recursos no caso de mobilidade local.
O HMIPv6 adiciona um novo nível, baseado em MIPv6, que separa mobilidade local de global. No HMIPv6, a mobilidade global é gerenciada pelos protocolos do MIPv6, enquanto handoffs locais são gerenciados localmente.
O novo nó em HMIPv6 é chamado de MAP (Mobility Anchor Point). O MAP, que substitui o foreign agent do MIPv4, ao contrário do mesmo, não exige estar presente em cada subnet. O MAP também ajuda a diminuir a latência referente aos handoffs devido ao fato de ele poder se atualizar mais rapidamente que o remoto home agent.
6.6 - Mobile IPv6 x Mobile IPv4
O Mobile IPv6 é uma combinação natural das experiências adquiridas com o desenvolvimento do suporte para hosts móveis no IPv4 com as oportunidades oferecidas pelo desenvolvimento de uma nova versão do IP e suas propriedades. Neste tópico é apresentado um resumo das maiores diferenças entre o Mobile IPv4 e o Mobile IPv6.
A otimização conhecida no Mobile IPv4 como " Route Optimization " (otimização de rota) foi incorporada ao IPv6, ao invés de fazer parte de um conjunto de extensões opcionais. Esta otimização consiste em armazenar em um cache o COA do host móvel, permitindo ao correspondente enviar pacotes sem precisar do tunelamento feito pelo HA.
O problema das regras de firewall que impediam o MH de usar o seu home-address como source dos pacotes foi resolvido permitindo que os MH's usem o COA para enviar os pacotes. O home address é enviado opcionalmente no pacote, e a habilidade de processar este campo é quesito obrigatório em qualquer implementação do IPv6.
Enquanto que no IPv4 pacotes UDP eram utilizados para enviar mensagens de controle, no IPv6 estas mensagens podem ir nos pacotes já existentes, fazendo o que é conhecido como " piggybacking ".
A possibilidade de utilizar o COA para enviar pacotes permite simplificar o roteamento de pacotes multicast. No IPv4, estes pacotes tinham que ser enviados ao HA através de tunneling, para que o MH pudesse utilizar seu home address.
Não é mais necessário o uso de roteadores especiais para atuar como FA; todos os roteadores IPv6 vão ter esta funcionalidade. O mecanismo de detecção de movimento no IPv6 permite que, ao perder o link com o antigo FA, o mobile host passe a utilizar um novo FA e um novo COA.
O novo formato do pacote do IP permite que os pacotes para o MH não precisem ser encapsulados. Ao invés disso, é utilizado o cabeçalho de roteamento, reduzindo assim o overhead da transmissão. A implementação do Neighbor Discovery permite também que o processo de interceptação dos pacotes destinados ao MH por parte do HA não dependa da camada inferior (data link), simplificando o protocolo e aumentando sua robustez.
Limitações na definição do ICMP no IPv4 exigiam processamento especial para mensagens ICMP, através do tunnel soft state. Esta limitação for eliminada na nova definição do ICMP.
A busca automática do HA por parte do MH agora é feita utilizando o anycast. Desta forma, o MH só receberá a reposta de um HA, ao invés de respostas de todos os HA da sua área permanente. Os binding updates, no IPv4 feitos pelo HA e FA, agora são feitos pelo próprio host móvel, permitindo que ele decida se vai ou não divulgar seu COA.
É permitido ao MH ter mais de um COA, ajudando assim a implementar o que é chamado de Smooth Handover, onde o MH não perde as conexões estabelecidas ao trocar de área.