Mobilidade IP

Mobilidade IP
Luísa Marina Araújo Lima – 010316023
João Paulo Vilela – 000316016
Mobile IP - I
Índice
Introdução
–
O que é a Mobilidade IP? ............................................................................ 3
–
Aplicações Possíveis ...................................................................................... 3
–
Alternativas .................................................................................................... 3
–
Descrição ........................................................................................................ 4
–
Conceitos/Terminologia ................................................................................ 7
–
Mensagens de controlo ................................................................................ 8
–
Segurança em Mobile IP ............................................................................. 11
–
Mobile IP em IPv6 ....................................................................................... 12
Objectivos .................................................................................................................. 13
Lista de Equipamento necessário .............................................................................. 13
Trabalho desenvolvido ................................................................................................ 14
–
Cenários de demonstração ........................................................................... 16
–
Dificuldades ................................................................................................ 28
Conclusão e Análise Crítica ....................................................................................... 30
Bibliografia .................................................................................................................... 31
Anexos
–
Configuração geral ...................................................................................... 32
–
Scripts de configuração de rede .................................................................. 36
–
Configuração específica de cada cenário .................................................... 32
Mobile IP - II
Introdução Teórica
O que é a mobilidade IP?
O Mobile IP foi criado de forma a permitir maior flexibilidade e mobilidade às
redes e aplicações associadas. O seu maior potencial relaciona- se com as
redes wireless, hoje em dia em constante desenvolvimento. Sem o Mobile IP, a
mudança de rede sem perder conectividade é impossível.
O mobile IP foi, assim, pensado para permitir a manutenção da ligação de
internet quando se move o computa dor de um ponto de acesso para outro.
O termo “mobilidade ” significa que, quando um utilizador está ligado a uma ou
mais aplicações na Internet, se o ponto de acesso do utilizador muda
dinamicamente, todas as ligações são automaticamente mantidas apesar da
mudanç a. Assim, todas as sessões de aplicações abertas continuam.
Aplicações possíveis
Computadores Desktop
Com o Mobile IP podemos estar ligados a uma rede, e ligar o cabo de rede a
uma rede nova sem ter de reconfigurar a ligação nem perder as sessões das
aplicações que estamos a usar.
Ligações Wireless
Apesar de o Mobile IP funcionar com ligações de rede fixas – no caso de um
cabo de rede de um computa dor ser desligado e ligado noutra rede – é
particularmente apropriado para ligações wireless. Uma das possíveis
aplicações (e possivelmente a mais pertinente no futuro) será os telemóveis de
3ª geração, dado que esta não é baseada apenas num standard, mas sim num
conjunto deles.
Alternativas
As alternativas mais comuns para implementaç ã o de mobilidade utilizadas hoje
em dia são o PPP dial-up 1 simples, assim como soluções de mobilidade internas
às empresas, implementad as através da renovação do endereço IP em cada
ponto de acesso. Neste cenário utiliza-se as funções de DHCP get e release: é,
assim, atribuído um novo endereço “topologicam ente correcto” em cada
ponto de acesso.
Apesar de estas soluções funcionarem bastante bem dentro das limitações
inerentes a cada tecnologia, ambas falham no que toca a suportar utilizadores
“em roaming ” que querem aceder a recursos na sua home network em
qualquer altura e sítio, independentemente da tecnologia de acesso de rede.
Outra limitação bastante incómoda destas alternativas é o facto de não haver
continuidade na sessão: esta está relacionad a com a possibilidade de um
utilizador poder estar ligado a recursos remotos sem interrupção prolongad a,
por exemplo, quando se muda de rede ou até de tecnologia de acesso. Neste
caso os utilizadores não deveriam ser forçados a reiniciar aplicações ou até o
seu computa dor portátil.
1
Abreviatura de Point-to-Point Protocol.
Mobile IP - III
Descrição
Na generalidade, na Internet, os pacotes IP são transportados da sua origem
para o destino através do reencaminhamento de pacotes nos routers: a
informação de roteamento é mantida em tabelas de routing , nas quais se
mantem o próximo salto para cada rede IP de destino. O endereço IP de um
pacote especifica normalmente o ponto de acesso à rede.
O endereço IP tem de mudar num novo ponto de acesso. De forma a alterar a
rota dos pacotes IP com destino a um novo ponto de acesso necessita-se de
um novo endereço IP associado à nova rede. No entanto, para manter as
ligações do protocolo de transporte enquanto o cliente se move, o endereço IP
do cliente deve permanecer o mesmo.
O Mobile IP resolve este problema introduzindo duas novas entidades nas redes
IP: o foreign agent e o home agent . Em conjunto com o mobile node (o cliente
que se move de uma rede para a outra), estas entidades constituem o básico
para se poder construir uma rede com suporte para Mobile IP. O correspondent
node é um terminal com o qual o mobile node comunica – este não precisa de
ter nenhum conhecimento Mobile IP!
O endereço visível para os correspondent nodes é sempre o Home Address,
independentemente da rede visitada no momento.
O Mobile IP funciona associando ao mobile node dois endereços IP: o Home
Address e um care- of address dinâmico. Este muda em cada novo ponto de
acesso à rede.
Um home agent localizado numa home network recebe tráfego destinado ao
endereço IP do mobile node , mesmo quando este não está fisicamente ligado
à home network. Quando o mobile node está ligado a uma foreign network, o
home agent reencaminha esse tráfego para um foreign agent utilizando o
care- of address corrente do mobile node . Se o mobile node não estiver ligado a
uma foreign network, o home agent simplesmente envia o tráfego de pacotes
de dados ao mobile node na home network. Cada vez que o mobile node
muda de rede, regista um novo care- of address no seu home agent .
A entrega de pacotes feita pelo home agent ao foreign agent requer, assim,
que cada pacote destinado ao mobile node seja modificado / extendido de
forma a que o care- of address apareça no pacote como sendo o endereço IP
de destino.
O home agent redirecciona pacotes da home network para o care- of address
construindo um novo cabeç alho IP que contem o care- of address do mobile
node como o endereço de destino do pacote. Este novo cabe ç alho
“enca psula” os dados do pacote original; desta forma o Home Address do
mobile node não tem efeito no roteamento do pacote encapsulado até
chegar ao care- of address. Esta encapsulação é geralmente designada por
tunneling 2. Quando o pacote chega ao foreign agent o novo cabeç alho de
routing é removido e o pacote original é enviado ao mobile node .
2 Encapsulação IP em IP – Na enca psulaçã o IP em IP, coloca- se um novo cabe ç alho no pacote IP – este
“enc a psula” o pacote de dados original, que é “escondido ” pelo novo cabe ç alho de routing, enquanto
que o cabe ç alho IP encapsulado é com pletam ente ignorado na Internet.
Mobile IP - IV
Triangular Routing
A operação básica do Mobile IP utiliza uma técnica chamad a triangular
routing : os pacotes são reencaminhados por diferentes rotas dependendo se os
pacotes são direccionados para o mobile node ou do mobile node . Os pacotes
de um correspondent node para um mobile node numa rede visitada são
encaminhados do corresponding node para o home agent . O home agent
encapsula os pacotes num túnel IP. Este túnel termina no foreign agent , que
reenvia o pacote para o mobile node . Na outra direcção, do mobile node para
o corresponding node , não há necessidade de túneis: os pacotes do
corresponding node são enviados do mobile node para o foreign agent .
Esta solução, no entanto, tem alguns problemas: muitos routers filtram pacotes
que não são originários de uma sub-rede topologicamente correcta. Para além
disso, não suporta endereçam ento privado de forma eficaz dado que esta
solução requer IP's únicos em cada interface. A solução para este problema é
uma técnica designada reverse tunneling .
Mobile IP - V
Reverse Tunnelling
Com o reverse tunelling , em adição ao forward tunnel (do home agent para o
foreign agent ), o foreign agent também manda os pacotes destinados ao
mobile node por um túnel para o home agent , em vez de os mandar
directamente para o correspondent node .
Esta técnica permite superar as dificuldades relacionadas com os filtros dos
routers na Internet, e também a incapa cid ad e de suportar multicast.
Co- located care- of address e Network Based foreign agents
Em cada rede acedida é normalmente necessário um foreign agent . No
entanto, se a rede em questão não providenciar serviços de Mobile IP, é
possível incluir um co- located care- of address no software do mobile node . O
care- of address é o endereço temporário na rede de acesso visitada para o
qual o home agent reenvia os pacotes que são destinados ao mobile node e
vice- versa.
Existem algumas diferenças entre estes dois modos de operação:
– No caso de um network-based foreign agent , o túnel Mobile IP termina no
foreign agent . Quando se usa co- located care- of address, o túnel termina no
Mobile IP - VI
mobile node . Nas redes wireless, regra geral o uso de network-based foreign
agents é mais eficiente.
– Um network-based foreign agent care- of address é partilhado entre vários
mobile nodes a visitar esta rede. Os pacotes destinados ao mobile node que
chegam à home network são interceptados pelo home agent e enviados
pelo túnel para o foreign agent na rede visitada. O foreign agent
desencapsula os pacotes e reenvia- os para o mobile node . Os networkbased foreign agents facilitam o reparticionamento dos endereços IP
disponíveis, dado que permitem ter vários mobile nodes com apenas um
care- of address. Logo, este modo de operação é preferível para redes Ipv4.
– Quando se usa o co- located care- of address, é atribuído um care- of address
único ao mobile node . O túnel do home agent é extendido e termina no
próprio mobile node . Neste caso não é necessário existir um foreign agent na
rede visitada – uma vantagem deste modo de operação é que a rede
visitada não precisa de ter suporte para mobile ip! O modo de co- located
care- of address requer um care- of address por mobile node na rede visitada,
sendo assim mais adequado para redes IPv6.
Conceitos / Terminologia
Mobile Node – Um terminal ou router que muda o seu ponto de acesso de uma
rede ou subrede para outra.
Home Address – Um endereço IP que é atribuído por um período de tempo
bastante longo a um mobile node . Este não é alterado,
independentemente de estar na rede original ou na rede visitada.
care- of address – Um endereço que é atribuído a um mobile node , na rede
visitada. Corresponde ao extremo final do túnel que liga o home agent
ao mobile node .
Home Agent – Um router numa home network de um mobile node que reenvia
através de um túnel os pacotes destinados ao home address para o
care- of address.
home network – A rede a que o mobile node está ligado inicialmente, e onde
se encontra o home agent .
Foreign Agent - Recebe os pacotes do home agent , desencapsula- os e
entrega- os ao mobile node (pode ser um computad or na rede
estrangeira ou o próprio mobile node )
foreign network – Rede para o qual o mobile node transita, diferente da home
network.
Correspondent Node – Nó com o qual o mobile node comunica. Não tem
qualquer conhecimento do protocolo de Mobile IP.
Mobile IP - VII
Mensagens de controlo
As mensagens de controlo do Mobile IP são definidas numa extensão às
mensagens ICMP.
1) Mensagens de divulgação - Advertisements
As mensagens Agent Discovery funcionam com o objectivo de saber em que
rede se encontra o mobile node (home network ou foreign network). Existem
dois tipos de mensagens deste género: Agent Advertisement e Agent
Solicitation .
A primeira é uma extensão à mensagem ICMP Router Discovery, anunciando
assim o home agent ou foreign agent e as respectivas características.
Analogamente à mensagem ICMP Router Discovery, esta mensagem é
difundida periodicamente para os endereços broadcast ou multicast.
Formato da mensagem Router Discovery
A mensagem Agent Solicitation pode ou não ser enviada periodicamente pelo
mobile node – podendo, assim, ser enviada apenas quando o mobile node
detecta que não está ligado a nenhum agente. Esta é em tudo idêntica à
mensagem ICMP Router Solicitation , diferindo no valor do campo TTL – que é
obrigatoriamente igual a 1. Através destas mensagens o mobile node pode
requerer mensagens Agent Advertisement aos agentes que se encontrem no
seu perímetro. Desta forma o agente móvel não precisa de esperar pelo tempo
do ciclo das mensagens Agent Advertisement , podendo registar-se mais
rapidamente.
Formato da mensagem Router Solicitation
Formato da mensagem Agent Advertisement
Mobile IP - VIII
2) Mensagens de registo - Registration
As mensagens de registo permitem as seguintes acções:
– requerer o serviço de forwarding quando o mobile node está numa
foreign network
– Informar o home agent do seu endereço care- of address c orrente
– renovar o registo quando este está a expirar
– cancelar o registo quando o mobile node regressa à sua home
network.
Existem dois tipos de mensagens de registo: Registration Request e Registration
Reply.
Formato da mensagem Registration Request
Formato da mensagem Registration Reply
O mobile node efectua o pedido de registo através de uma mensagem
Registration Request para o seu home agent , através do foreign agent do seu
perímetro. Este efectua o reencaminhamento das mensagens Registration
Request e Registration Reply para o home agent – que recebe os registos dos
seus mobile nodes que estão nas foreign networks. Ao receber o pedido, o
home agent actualiza a entrada na tabela de binding que corresponde ao
mobile node correcto. Esta tabela efectua uma correspondência entre o
endereço do mobile node e o endereço c are- of address. Ao terminar este
Mobile IP - IX
processo, envia uma mensagem Registration Reply indicando se o registo
sucedeu.
Troca de mensagens: Registo num foreign agent externo
Troca de mensagens: Registo com foreign agent interno (co- located care- of address)
Mobile IP - X
Segurança em Mobile IP
A segurança no mobile IP é assegurada através da identificaç ão e
autenticaç ã o dos pedidos e respostas de registo. Apesar de apenas a
autenticaç ã o do mobile node ser requerida pelo RFC2002, este permite
adicionalmente a autentica ç ã o Mobile- Foreign e Foreign-Home . A extensão de
autenticaç ã o protege o corpo da mensagem e todas as extensões
precedentes de modificações não pretendidas.
Identificação
O campo de identificaç ão nos pedidos e respostas de registo é requerido pelo
RFC2002. Existem duas alternativas para o valor de identificação: timestamps e
nonces. Os timestamps são obrigatórios, enquanto que os nonces são opcionais.
O mobile node e o home agent devem ser configurados previamente com o
método que irá ser utilizado. Este método é mapead o para uma SPI3.
Independentemente do método utilizado, é importante que os 32 bits mais
baixos do campo de identificaçã o não sejam modificados pelo home agent ,
dado que o foreign agent os usa, em conjunto com o endereço original do
mobile node , para associar um pedido de registo a uma resposta.
Nos timestamps a identificaç ão é a hora do dia, formatada como especificado
pelo NTP (Network Time Protocol). O RFC2002 anuncia que os relógios dos
mobile nodes e home agents devem estar suficientemente próximos um do
outro, apesar de não o especificar em concreto. O mobile node deve sempre
incrementar este tempo.
Com os nonces ambos o mobile node e o home agent produzem números
aleatórios de 32 bits, colocando- os no campo de identificaçã o. O mobile node
utiliza os 32 bits mais baixos, enquanto que o home agent utiliza os 32 bits mais
altos. Quando o mobile node manda um pedido de registo, põe um novo
número aleatório no campo de identificaç ão. O home agent copia este
número para o campo de identificaç ão das respostas de registo e gera outro
número aleatório para a parte mais baixa, e assim por diante. Estes números
aleatórios estão no corpo da mensagem de registo; a extensão de
autenticaç ã o protege- o assim de uma possível modificaç ão.
Extensão de autenticaç ã o
O RFC2002 especifica três extensões de autenticaç ão diferentes: Mobile- Home ,
Mobile- Foreign e Foreign-Home . As três extensões têm o mesmo formato,
diferindo apenas no valor do campo do tipo. A extensão de autenticaç ã o
contem um parâmetro de segurança de 32 bits e um “autenticador”de
tamanho variável.
O SPI mapeia um conjunto de parâmetros de configuração (como, por
exemplo, os métodos utilizados para calcular o valor de identificaçã o e o
“autenticador” e uma chave partilhada) que são especificados nos ficheiros de
configuração dos mobile nodes e mobile agents. O “autenticador” é uma string
de tamanho variável calculada a partir de uma chave partilhada, que apenas
o mobile node e o mobile agent conhecem – obtêm- no a partir da mensagem
de registo e das extensões que precedem a extensão de autenticaç ã o e os
3SPI - Index do Parâmetro de Segurança (Security Parameter Index – SPI)
Mobile IP - XI
campos Type e Length da extensão de autenticaç ã o. Assim, todos os pedidos
de registo e respostas são protegidos de modificações indesejadas.
O RFC2002 especifica a utilização de MD5 em modo de prefixo e sufixo, com
um tamanho de chave de 128 bits, como o algoritmo por defeito para calcular
o “autenticador”. Outros algoritmos poderão ser também suportados.
Extensão de autenticaç ã o
Ameaç as de segurança
Os ataques possíveis ao Mobile IP são replay attacks e ataques que levem a
uma falsa autenticaç ã o. Como o Mobile IP é frequentemente usado em
ambientes Wireless, o eavesdropping é também uma séria ameaç a.
Os replay attacks são protegidos pelo campo de identificaçã o, sendo a
mensagem completa protegida pela extensão de autenticaç ã o. Hoje em dia o
algoritmo utilizado, “ keyd MD5”, é considerado um bom algoritmo, portanto a
segurança das mensagens de registo do Mobile IP depende completamente
do facto de se manter a chave partilhada em segredo.
Apesar de o protocolo ARP introduzir algumas amea ç as de segurança no
Mobile IP, estas estão também presentes no protocolo IP normal.
Mobile IP em IPV6
Na próxima geração de redes IP haverá suporte intrínseco para Mobile IP, sendo
algumas das vantagens sobre o IPv4 as seguintes:
– Não há necessidade de utilizar foreign agents específicos, dado que a
amplitude de IPs é suficientemente vasta para se poder atribuir um ip a cada
co- located care- of address.
– O suporte para a optimização de rotas é uma parte fundamental do
protocolo, em vez de um conjunto de extensões que não estão incluídas no
standard.
– A maioria dos pacotes enviados para um mobile node quando este está
numa rede estrangeira são enviados utilizando um cabe ç alho de routing
IPv6, reduzindo o overhead associado à encapsulação IP-IP utilizada no IPv4.
– O Mobile IPv6 é independente de qualquer cama d a de ligação, dado que
usa o IPv6 Neighbor Discovery em vez do ARP.
– O mecanismo de descoberta de home agents dinâmica retorna uma única
resposta ao mobile node . O broadc ast direccionado usado no IPv4 retorna
respostas separadas de cada home agent .
Mobile IP - XII
Objectivos
Aprofundar os conhecimentos sobre mobilidade IP; demonstrar a troca de
mensagens que ocorre na mobilidade IP; analisar o modo de operação, tanto
em redes fixas como redes wireless.
Lista de equipamento necessário
Cenário de demonstração com rede fixa:
Computadores:
- mobile node:
Mandrake Linux 9.1
Linux version 2.4.21-0.13mdk; gcc version 3.2.2
1 placa de rede
- home agent:
Mandrake Linux 9.2
Linux version 2.4.22-28mdk; gcc version 3.3.1
3 placas de rede
- foreign agent:
Mandrake Linux 9.2
Linux version 2.4.22-28mdk; gcc version 3.3.1
3 placas de rede
Outro hardware:
3 hubs
Cenário de demonstração com rede wireless:
Apesar de ter sido considerado o cenário de demonstração com rede wireless,
tal hipótese foi abandonad a por falta de tempo.
Mobile IP - XIII
Trabalho desenvolvido
Software Utilizado
- Ettercap / ethereal
- Implementaç ã o de Mobile IP – dynamics HUT mobile ip
– dhcp server e dhcpc d , dhclient
– comandos de rede do linux: route , ifconfig
Implementações de Mobile IP em Ipv4
Mosquito – mosquitonet.stanford.edu
Esta implementaç ã o não foi utilizada por ter sido abandonad a há
algum tempo; o último kernel suportado é o 2.2.x.
Dynamics
Esta implementaç ã o do protocolo foi a escolhida, pelas seguintes
características que apresenta:
– Corre em espaço utilizador
– Disponibiliza daemons para o mobile node , home agent
e foreign agent
– Utiliza IPv4
Implementações de Mobile IP em IPV6
Apesar de ter sido considerado fazer um cenário de Mobile IP com
IPV6, tal hipótese foi abandona d a por falta de tempo. No
entanto, há boas descrições disponíveis no TLDP (The Linux
Documentation Project – http://www.tldp.org/)
Cisco
Esta implementaç ã o não foi utilizada pois não estava incluída
nos routers que nos foram disponibilizados.
Mobile IP - XIV
Acções realizadas
1) Configuração da rede necessária
Configurámos os routers com os comandos ifconfig e iproute . Os scripts utilizados
para tal encontram- se em anexo.
2) Instalação do Dynamics
Em todas as máquinas:
–
Instalação da biblioteca gmp , necessária para o funcionamento do
Dynamics.
–
Instalação do Dynamics
Dificuldades ocorridas neste ponto do trabalho:
No mobile node , tivemos erros de compilação; foi necessário
acrescentar as seguintes linhas ao ficheiro /usr/include/linux/ethtool.h :
typedef
typedef
typedef
typedef
unsigned
unsigned
unsigned
unsigned
long long u64;
int u32;
short u16;
char u8;
(que já era suposto terem sido incluídas do ficheiro /usr/include/asm/types.h )
–
Configuração do Dynamics
Em anexo apresentamos as opções que mudámos em cada cenário, e as
opções gerais mais importantes. Os restantes valores foram deixados com o
default value, que já vinha com o programa, com o objectivo de ser um sistema
de testes mínimo para uma pessoa começ ar a implementar o Mobile IP.
Medições a efectuar
Correndo os daemons do Dynamics com as opções “--fg –debug ” podemos
observar com bastante detalhe as trocas de mensagens entre o home agent, o
mobile node e o foreign agent.
Para ter uma ideia mais concreta da informação trocad a e do formato dos
pacotes enviados, usámos o software “ethereal”.
Os passos efectuados na utilização destes dois programas está descrito na
secção “Cenários de demonstração”.
Mobile IP - XV
Cenários de demonstração
Cenário Geral
mobile node – 192.168.10.100
home agent – Router 1
foreign agent 1 – Router 2
foreign agent 2 – Router 3
correspondent node – 192.168.40.40
Depois de configurado um sistema de teste mínimo fizemos os seguintes testes:
–
Pings para 192.168.40.40, 192.168.20.20 e 192.168.10.10, alternando
entre as duas redes, para testar se a conectividade se mantinha
correctamente e sem problemas. Verificámos que tudo correu bem.
–
Ssh para 192.168.40.40; corremos o comando “ls -R /”; verificámos que
ao alternar entre as duas redes a sessão se mantinha e os dados não
se perdiam. Repetimos o teste para correspondent nodes nas redes 20
e 10.
Mobile IP - XVI
–
Corremos o tomcat na máquina 192.168.10.10; ao alternar entre as
duas redes verificámos que a sessão se mantinha num javabean (que
utiliza sessões) a correr no servidor tomcat .
Nos testes seguintes utilizámos um ping para o correspondent node
(192.168.40.40), de forma a analisar os pacotes que passam na rede de forma
mais simples.
Em todos os cenários utilizamos os seguintes métodos de medição:
–
–
–
–
–
–
Análise dos pacotes no ethereal
Análise dos pacotes no ethereal
Utilização do modo “debug ” do
Utilização do modo “debug ” do
Utilização do modo “debug ” do
Utilização do comando “ping
pacotes
em todas as interfaces do home agent
em todas as interfaces do foreign agent
dynhad
dynmnd
dynfad
-R” para analisar a rota percorrida pelos
Mobile IP - XVII
Cenário 1: network-based foreign agent care- of address – 1 FA externo
Neste cenário o care- of address é o endereço do foreign agent .
Teste utilizado neste cenário : ping para 192.168.40.40, alternando o cabo de
rede entre as redes 10 e 20.
–
Cenário 1-a) Sem reverse tunelling (Com triangular routing)
Sem reverse tunneling, o foreign agent manda directamente os pacotes
destinados ao mobile node .
Análise:
1 – Ligando o mobile node à home network:
a) Quando se liga o mobile node sem haver nenhum FA ou HA a receber
pedidos, o MN manda a extensão dos pacotes ICMP Router Solicitation - Agent
Solicitation em broadcast para a rede, solicitando um agente (observado no
ethereal no mobile node ).
b) Ao ligar o HA, este envia pacotes ICMP Mobile IP advertisement ao mobile
node (observado no ethereal no mobile node ).
c) O mobile node manda o pedido de registo (Registration Request) para o seu
home agent (verificado no output do daemon dynmnd no mobile node ).
d) O home agent verifica e manda um pacote Registration Reply (verificado no
output do daemon dynhad no home agent ).
e) O mobile node pode agora comunicar em rede.
2 – Fazendo um ping para o terminal 192.168.40.40 (correspondent node ):
Comando: ping -R 192.168.40.40
RR: 192.168.10.100
192.168.40.254
192.168.40.40
192.168.40.40
192.168.10.254
192.168.10.100
Mobile IP - XVIII
Observámos que a rota utilizada foi a esperada.
3 – Ligámos o mobile node à foreign network.
Captura no mobile node (ethereal )
a) (Linhas 27-28) Ao ligar o mobile node à foreign network, este envia pacotes
Agent Solicitation para requerer mensagens Agent Advertisement . Ao mesmo
tempo o foreign agent está a enviar mensagens Agent Advertisement , pois está
definido na nossa configuração do foreign agent que este mande estas
mensagens de 15 em 15 segundos, mesmo que não receba nenhuma
solicitação (observado nos daemons do foreign agent e mobile agent ).
b) (Linha 29) O mobile node efectua o pedido de registo através de uma
mensagem Registration Request: este contem, como se pode ver na figura, o
endereço do mobile node na home network e o care- of address pretendido –
que neste caso é o do foreign agent .
c) (Linha 30) O foreign agent responde ao mobile node , com um pacote
Registration Reply.
d) (Linhas 31-34) O mobile node continua a mandar solicitações de agentes
continuamente; isto é utilizado para ele poder mudar no caso de haver um
foreign agent mais perto no seu perímetro. O foreign agent também se anuncia
para outros possíveis mobile nodes.
Mobile IP - XIX
Captura no home agent (ethereal )
a) (Linha 10) O foreign agent reencaminha o Registration Request do mobile
node para o home agent ; aqui podemos visualizar o pedido do mobile node
que está na foreign network. Localmente no home agent , se fizermos ifconfig
visualizamos uma interface extra – o túnel criado entre o home agent e o
foreign agent .
b) (Linha 12) O home agent envia uma mensagem Registration Reply ao
foreign agent , indicando que o registo sucedeu.
4 – Fazendo um ping para o terminal 192.168.40.40 (correspondent node ):
Comando: ping -R 192.168.40.40
RR: 192.168.10.100
192.168.40.253
192.168.40.40
192.168.40.40
192.168.10.254
192.168.20.254
192.168.10.100
64 bytes from 192.168.40.40: icmp_seq=2 ttl=62 time=1.56 ms (same route)
Podemos observar que a rota é a pretendida:
A rota até ao terminal 192.168.40.40 é feita normalmente, através da default
gateway que é o foreign agent .
No sentido inverso, o pacote é enviado para o home agent , onde é feita a
encapsulação IP-IP (com um cabeç alho IP com o care- of address como IP de
destino) e o reenvio pelo túnel para o foreign agent , que o desencapsula e
entrega ao mobile node . O túnel é estabelecido entre as interfaces
192.168.30.253 e 192.168.30.254. Este pormenor não é visível com as rotas do
ping, no entanto, podemos observar isto na seguinte ilustração, obtida com o
ethereal :
Mobile IP - XX
No mobile node – Ping Request:
No home agent – Ping Reply do correspondent node :
No home agent – Encapsulação e envio do pacote acima para o foreign
agent :
No foreign agent , é recebido o pacote acima – este é desencapsulado e
enviado para o mobile node .
No mobile node – Ping Reply:
Como se pode constatar, nesta fase o mobile node recebe o pacote tal como
foi enviado originalmente do correspondent node para o home agent .
Mobile IP - XXI
–
Cenário 1-b) Com reverse tunelling (Sem triangular routing)
Com reverse tunneling , o foreign agent manda os pacotes destinados ao
mobile node através do túnel IP-IP entre o home agent e o foreign agent .
1 – Ligação do mobile node à home network
2 – Fazendo um ping para o terminal 192.168.40.40 (correspondent node ):
mantém- se o resultado do cenário anterior, como seria de esperar, pois o
Reverse Tuneling não afecta o percurso dos pacotes quando o mobile node
está na sua rede natural.
3 – Ligação do mobile node à foreign network
4 – Fazendo um ping para o terminal 192.168.40.40 (correspondent node ):
Comando: ping -R 192.168.40.40
RR: 192.168.10.100
192.168.30.254
192.168.40.254
192.168.40.40
192.168.40.40
192.168.10.254
192.168.20.254
192.168.10.100
Podemos observar que neste caso a rota para o correspondent node se
modificou relativamente ao cenário anterior, como seria de esperar devido à
activação do Reverse Tunelling.
Para ilustrar melhor o tunelling no sentido directo, não visível na rota do ping tal
como anteriormente, capturámos os pacotes no ethereal :
No foreign agent – o ping request é recebido e encapsulado, sendo enviado
através do túnel para o home agent :
No home agent – o ping request é desencapsulado e enviado para o
correspondent node :
No mobile node não existe diferença relativamente
relativamente à forma de enviar ou receber os pacotes.
ao cenário anterior
Mobile IP - XXII
Rota do ping reply com reverse tunneling
Mobile IP - XXIII
Cenário 2: Rede com co- located address – 1 FA interno, com reverse
tunelling
Neste caso, o foreign agent é, por assim dizer, o próprio mobile node – o
tunelling estabelece- se entre o home agent e o mobile node .
Neste modelo, a comunica ç ã o é feita directamente entre o mobile node que
obtém um co- located care- of address na rede estrangeira (por exemplo, por
DHCP) e o home agent . As extremidades do túnel utilizado para redireccionar
os pacotes da rede natural para a rede são o co- located care- of address
obtido pelo mobile node e a interface visível do home agent .
Assim sendo, o túnel utiliza na mesma como intermediário o router 2 (na rede
estrangeira); no entanto, este não tem que ter qualquer conhecimento do
protocolo.
Neste cenário, apesar de termos efectuado os passos de configuração descritos
em anexo, não conseguimos que ele funcionasse.
Mobile IP - XXIV
Cenário 3: 2 FA (network-based foreign agent care- of address) – modo
hierárquico
Os foreign agents, neste caso, estão organizados hierarquicamente numa
topologia por regiões. Os advertisements destas máquinas contêm a hierarquia
completa dos foreign agents acessíveis.
Cada foreign agent utiliza como próximo passo na ligação ao home agent o
care- of address do foreign agent imediatamente inferior na hierarquia. Sendo
assim, um pacote vai ser desencapsulado e reencapsulado várias vezes no
caminho, sendo reenviado por um novo túnel cuja extremidade é o nível
imediatamente inferior.
Mobile IP - XXV
Processo de registo entre os internevientes no protocolo, no modo de foreign agents Hierárquicos
Como se pode
próximo foreign
mensagem de
próximo agente
ver na imagem, cada agente guarda o care- of address do
agent inferior na hierarquia – este endereço está disponível na
pedido de registo; cada agente delega o pedido para o
superior a ele na hierarquia.
Apesar de termos começ a d o esta demonstração, não conseguimos acabá- la
pois eram necessários mais recursos, que não estavam disponíveis (ver
“Dificuldades”).
Esta demonstração tinha o objectivo de ilustrar o roaming entre mais do que
uma foreign network no modo hierárquico, e as mensagens trocadas.
Mobile IP - XXVI
Teste à “fiabilidade” do Mobile IP – Análise do fluxo de pacotes TCP no
upload de um ficheiro por FTP
As duas seguintes figuras servem apenas para se ilustrar o contexto da figura de
análise TCP.
Quando se desliga o cabo de rede da home network e se liga à foreign
network:
Quando se regista na foreign network:
Análise do fluxo TCP:
Como se pode verificar nos registos retirados, após o período de handover a
ligação é reestabelecida.
Pudemos também verificar na prática que os ficheiros foram transferidos
correctamente para o destino, donde se conclui que o protocolo é fiável.
Mobile IP - XXVII
Dificuldades :
Superadas:
Inicialmente preparámos o cenário de demonstração com dois routers cisco
(um da série 2500 e outro da série 2600). No entanto, depois de uma
investigação mais aprofundada, chegám os à conclusão de que apesar de no
site da cisco ser anunciado o suporte para Mobile IP nestes routers, tal não
acontece.
Como tal tivemos de replanear o trabalho, preparando o cenário explicado
anteriormente, no qual tivemos de configurar os routers em computad ores com
três placas de rede cada.
Não Superadas:
–
Atraso no handover
Pudemos constatar que existe um atraso considerável no handover da home
network para a foreign network.
Na
64
64
64
home network, fazendo um ping para 192.168.40.40:
bytes from 192.168.40.40: icmp_seq=314 ttl=63 time=0.718 ms
bytes from 192.168.40.40: icmp_seq=315 ttl=63 time=0.697 ms
bytes from 192.168.40.40: icmp_seq=316 ttl=63 time=0.684 ms
Depois da
64 bytes
64 bytes
64 bytes
troca
from
from
from
para a foreign network, foram perdidos 36 pacotes:
192.168.40.40: icmp_seq=352 ttl=62 time=1.30 ms
192.168.40.40: icmp_seq=353 ttl=62 time=1.16 ms
192.168.40.40: icmp_seq=354 ttl=62 time=1.18 ms
Apesar de termos modificado e testado vários parâmetros, tais como os
intervalos entre as mensagens Agent Solicitation e Agent Advertisement , não
conseguimos eliminar este atraso.
Após alguma investigação, concluímos que a solução, não implementad a por
falta de tempo, seria instalar um servidor NTP, tendo clientes a correr no mobile
node , no foreign agent e no home agent . Com efeito, este atraso deve- se ao
facto de o Mobile IP utilizar timestamps para efectuar a “autentica ç ã o ” entre as
máquinas; quando as horas nestas não estão exactamente iguais, ele tem de
sincronizar o tempo nas mudanças de rede, o que demora ainda algum tempo.
–
Cenário 2 – com co- located care- of address
Tivemos bastantes problemas ao configurar o cenário previsto com co- located
care- of address: o dhcpc d automaticamente modificava o endereço de rede
da placa eth0, não permitindo manter as sessões na troca de rede da home
para a foreign network.
–
Falta de equipamento
Houve alguma dificuldade em ter computad ores e routers livres para trabalhar.
Adicionalmente mesmo apenas para as pessoas da cadeira de TAR os
computad ores eram poucos, tendo sido necessário utilizar os portáteis de
algumas pessoas.
Mobile IP - XXVIII
–
Falta de tempo
Por falta de tempo, não pudemos testar os cenários com wireless, nem outros
que tínhamos planeado.
Mobile IP - XXIX
Conclusão e Análise Crítica
Apesar de não termos conseguido desenvolver o trabalho tanto como
desejaríamos, nomead a m ente na vertente prática, atingimos o objectivo de
perceber o protocolo em pormenor.
Depois de analisarmos o funcionamento do Mobile IP, concluímos que este
protocolo, apesar das dificuldades analisadas acima, funciona eficientemente
nas condições de rede testadas.
Estas são suficientemente genéricas para que se possa facilmente adaptar a
novos cenários, nomeada m ente a mudanç a entre redes com tecnologias
heterogéneas (como W-LAN4, GPRS5 e UMTS6) .
As características que concluímos serem adequa d as a este género de cenários
são:
–
Uma reduzida duração do handover entre diferentes redes (apesar
de não o termos conseguido implementar, como referido acima).
–
A possibilidade de utilizar parâmetros de segurança eficientes que
permitem proteger a comunicaç ã o com pouco impacto resultante.
–
Possibilidade
processo.
–
Uma grande escalabilidade, devido à possibilidade de definição de
uma hierarquia de foreign agents, que deverão comunicar
eficientemente.
–
É compatível com as tecnologias de ponta que estão a surgir, e é até
integrado no IPv6.
de autenticaç ã o
entre os vários intervenientes no
Em conclusão, o protocolo Mobile IP é, tal como o nome indica, adequado a
qualquer cenário que necessite de uma grande mobilidade e/ou
escalabilidade.
4
5
6
W-LAN – Wireless Local Area Network
GPRS - General Packet Radio Service – um standard para comunica ç ões wireless.
UMTS - Universal Mobile Telecommunications System – uma tecnologia 3G (3ª geraç ã o).
Mobile IP - XXX
Bibliografia
Implementações de Mobile IP:
* Linux Mobile IP – MosquitoNet - http:/ / mosquitonet.stanford.edu /mip /
* Dynamics – HUT Mobile IP - http:/ / w w w.cs.hut.fi/Research/Dynamics/
Mobile IP em IPv6:
* IETFMobile IP - http:/ /w w w.ietf.org/internet- drafts/draft- ietf-mobileip- ipv6-24.txt
Informação sobre Mobile IP:
* The Internet Engineering Task Force - http:/ / w w w.ietf.org/html.charters/mobileip- charter.html
* Mobile Networking Through Mobile IP - http:/ / w w w. c o m puter.org/internet/v2n1/perkins.htm
* Wireless Networking and Mobile IP References
http:/ / w w w. cis.ohio- state.edu/~jain/refs/wir_refs.htm
-
* Mobile IP. What is that? - http:/ / w w w.hpl.hp.co m / p ersonal/Jean_Tourrilhes/MobileIP/mip.html
* ACM Crossroads Student Magazine - http:/ / w w w.a c m.org / crossroads/xrds7-2/mobileip.html
* Mobile- IP Playground Archives - http:/ / playground.sun.com / m o bile- ip/
* White Paper da Unplugged – Mobility and Mobile IP, Introduction
* FAST-MIP – http:/ / w w w.ee cs.berkeley.edu/~ergen/ d o cs/FASTMIP-onecolumn.pdf
Configuração do DHCP:
* Linux Forum - http:/ /w w w.linuxforum.com /linux-dhcp- server/x369.html
Rpms:
* Rpmpbone - http:/ /rpm.pb one.net/
Segurança em Mobile IP:
* Mobile IP - http:/ / w w w.hut.fi/~sponkane /tlark/10/MIP.html#luku5
Performance :
* The effect of mobile IP handoffs on the performance of TCPhttp:/ / w w w- rp.lip6.fr/site_npa/site_rp/_publications/126-p131-fladenmuller.pdf
Publicações várias sobre Mobile IP:
* Dynamics Mobile IP Publications - http:/ / dyna mics.sourceforge.net/?p a g e=publications
* Mobility within WLAN - http:/ /user.it.uu.se/~joha0263/wlan/ Mo bilityWithinWLAN.pdf
* ACM Portal - http:/ / p ort al.acm.org/ citation.cfm?id=304749&dl=ACM&coll=GUIDE
Hierarchical foreign agents:
* Third-Generation Mobile IP Systems - http:/ / w w w.ee.iastate.edu /~russell/cpre537xf00/Projects/pengf an.pdf
* Mobile- IP Local Registration with Hierarquical Foreign Agents http:/ / p e o ple.nokia.net/~ch arliep/txt/hierfa/hierfa.txt
Mobile IP - XXXI
Anexo 1 – Configuração geral - Dynamics
Configuração do mobile node (/usr/local/etc/dynmnd.conf):
NOTA: Como este é um teste “minimalista”, não precisamos de considerar as
opções do AAA, necessárias se não se souber o endereço do home agent, ou se se
quiser manter os mobile nodes com endereços indeterminados.
(Endereço IP do mobile node na home network)
MNHomeIPAddress 192.168.10.100
(Endereço IP do home agent - se o home agent tiver várias interfaces
de rede – como é o caso do nosso que é um router – deve-se escolher o
endereço da interface “pública” - ou seja, deve ser atingível a partir
das foreign networks)
HAIPAddress 192.168.10.254
(Endereços IP Alternativos do home agent – estes endereços são
utilizados pelo mobile node para além do endereço “principal” do home
agent para saber quando um anúncio de agente é da sua home network)
AlternativeHAIPAddress 192.168.30.253
AlternativeHAIPAddress 192.168.40.254
(Home net default gateway – usada para forçar a utilização de uma
gateway que o mobile node usa quando está na home network)
HomeNetGateway 192.168.10.254
(ChaveSecreta – é utilizada juntamente com o algoritmo de autenticação
abaixo para obter o checksum das mensagens trocadas)
SharedSecret “bananasNaRepublicaCheca”
(Algoritmo de autenticação – HMAC-MD5: algoritmo de autenticação
utilizado para garantir que não há um ataque no processo de registo
dos intervenientes)
AuthenticationAlgorithm 4
(Método de prevenção de ataque por repetição – Nonces: números
aleatórios que são gerados para cada mensagem de registo e colocados
no campo de identificação)
ReplayMethod 2
(Autenticação com o Foreign Agent – para garantir que o FA a que o
Mobile Node se está a ligar é o correcto)
FA_SECURITY_BEGIN
# SPI
FA IP
Alg.
Shared Secret
1000
192.168.20.254
4
"bananasNaRepublicaChecaFA"
FA_SECURITY_END
(Solicitações de novos foreign agents – Normalmente, o mobile node
envia solicitações de agentes quando não tem um advertisement de uma
gente válido. As solicitações periódicas são enviadas mesmo quando a
ligação está activa.
NOTA: Este setting provoca o envio de mais mensagens broadcast, mas
pode aumentar a velocidade do handover em alguns ambientes – que é o
nosso caso!)
SolicitationInterval -1
Mobile IP - XXXII
Configuração do home agent (/usr/local/etc/dynhad.conf):
(Interfaces a serem usadas para serviços Mobile IP – as interfaces
para as quais se manda, ou recebe, mensagens de registo)
INTERFACES_BEGIN
# interface ha_disc agentadv interval force_IP_addr
eth0
1
1
10
192.168.10.254
INTERFACES_END
(Default Tunnel Lifetime)
HADefaultTunnelLifetime 600
(AuthorizedList – Lista de mobile nodes que estão
estabelecer comunicação com o Home Agent)
AUTHORIZEDLIST_BEGIN
# < SPI | SPI-range
IP | network/netmask >
# SPI
IP
1000
192.168.10.100
AUTHORIZEDLIST_END
autorizados
a
(Security Begin – define os parâmetros de segurança existentes entre
os Mobile Nodes e o Home Agent:
– Security parameter index (SPI): uma chave que identifica uma
interacção de segurança entre o HA e o MN
– Algoritmo de autenticação (auth. alg.): algoritmo utilizado para
garantir um registo seguro
– Método de prevenção de ataque de repetição (replay method): identico
ao visto acima para o HA...
– Tempo máximo de diferença nos timestamps (timestamp tolerance)
– Tempo máximo associado a uma associação de segurança (max lifetime)
– Chave secreta (shared secret): tem a mesma funcão da chave secreta
no mobile node e é partilhada com ele))
SECURITY_BEGIN
#
auth.
replay timestamp
max
shared
# SPI
alg.
meth.
tolerance
lifetime
secret
1000
4
1
120
600
"test"
SECURITY_END
(Foreign Agent Security – Associação de segurança entre o HA e o FA;
tem os parâmetros de segurança normalmente adoptados por este
software, já descritos acima)
FA_SECURITY_BEGIN
# SPI
FA IP
Alg.
Shared Secret
2001
192.168.30.254
4
“bananasNaIrlanda”
FA_SECURITY_END
(PublicKeyHashMethod – Utilizado para prevenir ataques man-in-themiddle entre o FA e o HA. Neste caso, se o checksum for recebido,
verifica a chave pública com ele.)
PublicKeyHashMethod 1
Mobile IP - XXXIII
Configuração do foreign agent 1 (Highest Foreign Agent)
(/usr/local/etc /dynfad.conf):
(Interfaces a serem usadas para serviços Mobile IP – Interfaces a
serem usadas para serviços Mobile IP)
INTERFACES_BEGIN
# interface type agentadv interval force_IP_addr
eth0
3
1
30
192.168.20.254
eth1
2
1
30
192.168.30.254
INTERFACES_END
(Network Acess Identifier do foreign agent – aqui podemos pôr, por
exemplo, o mac adress, através de uma macro chamada “identifier”.)
NetworkAccessIdentifier "test"
(Endereço do maior foreign agent – Usado na comunicação com o home
agent, e anunciado nas mensagens de advertisement dos agente – é o
endereço da interface “pública” do foreign agent, ou seja, o endereço
visível do home agent)
HighestFAIPAddress 192.168.30.254
(Highest FA – opção que indica que este foreign agent é o foreign
agent mais “alto” - isto é, não tem nenhum foreign agent mais alto e
comunica directamente com os home agents)
HighestFA TRUE
(Segurança – endereços de rede autorizados:
Esta lista é usada para limitar os endereços IP dos quais os pedidos
de registo podem ser enviados (foreign agents mais baixos, ou mobile
nodes).)
AUTHORIZEDNETWORKS_BEGIN
# [ networkaddress ]/[ netmask ]
0.0.0.0/0.0.0.0
AUTHORIZEDNETWORKS_END
(AllowMobileNodes – Este parâmetro estabelece se este FA permite
ligações directas dos Mobile Nodes – isto é, se pode ser o lowest FA
ou não.)
AllowMobileNodes TRUE
(FASecurity – define os parametros de segurança adoptados pelo FA.
Neste caso temos autenticação quer com o MN (SPI 1000) quer com o HA
(SPI 2001))
FA_SECURITY_BEGIN
# SPI
Node IP
Node
Alg.
Shared Secret
1000
192.168.10.100
3
4
"bananasNaRepublicaChecaFA"
2001
192.168.10.254
2
4
"bananasNaIrlanda"
FA_SECURITY_END
(FAkeyfile – a chave RSA utilizada para cifrar a comunicação com o MN)
FAKeyFile "/etc/dynfad.key"
Mobile IP - XXXIV
Configuração do foreign agent 2 (/usr/local/etc /dynfad.conf) – apenas usada nos
cenários com 2 foreign agents:
(HighestFAIPAddress – deixa de ser ele próprio e passa a indicar o IP da
interface pública do FA anterior (o Highest Foreign Agent), que é o Foreign
Agent que se encontra mais próximo e é aquele através do qual este
comunicará com o Home Agent)
HighestFAIPAddress 192.168.30.254
(UpperFAIPAddress – endereço IP do FA para o
direccionados com vista a chegarem ao Home Agent)
UpperFAIPAddress 192.168.30.254
qual
os
pedidos
são
(HighestFA – define se um FA é ou não o Highest Foreign Agent desta rede,
no caso não o é)
HighestFA FALSE
Mobile IP - XXXV
Anexo 2 – Configuração geral – Scripts de configuração da
rede
Configuração de rede do mobile node – script_mobile_node.sh:
ifdown eth0
ifconfig eth0:9 down
killall -9 ifplugd
killall -9 zcip
ifconfig eth0 192.168.10.100
route add default gw 192.168.10.254
dynmnd --fg --debug --no-wireless
Configuração de
# modulos
# eth2 ->
# eth0 ->
# eth1 ->
rede do home agent – script_router_10.sh:
tulip -> cima -> 192.168.30.253
8139too -> meio -> 192.168.10.254
ne2k-pci -> baixo -> 192.168.40.254
modprobe 8139too eth0
modprobe ne2k-pci eth1
modprobe tulip eth2
# enderecos ip
ifconfig eth0 192.168.10.254 netmask 255.255.255.0 up
ifconfig eth1 192.168.40.254 netmask 255.255.255.0 up
ifconfig eth2 192.168.30.253 netmask 255.255.255.0 up
killall -9 ifplugd
killall -9 zcip
# ip forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
# tabelas de routing
route add -net 192.168.20.0 netmask 255.255.255.0 gw 192.168.30.254
# IPIP Tunneling
insmod ipip
# fazer disable do rp_filter
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter
# ele tem de responder pelo mobile node aos pedidos de arp
echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/eth2/proxy_arp
################# começar o daemon para o home agent #############
dynhad --fg --debug
Configuração de rede do foreign agent – script_router_20.pl:
#!/usr/bin/perl;
# cima (liga os 2 routers)
print `modprobe ne2k-pci eth1`;
print `ifconfig eth1 192.168.30.254`;
# meio (liga a rede 20)
# 8139too
print `ifconfig eth0 192.168.20.254`;
#baixo
print `modprobe tulip eth2`;
print `ifconfig eth2 192.168.40.253`;
# activa forwarding
print `echo 1 > /proc/sys/net/ipv4/ip_forward`;
# adiciona a rota para a rede 10
print
`route
add
-net
192.168.10.0
netmask
255.255.255.0
192.168.30.253`;
# /usr/local/etc/dynfad.conf
print `killall -9 ifplugd`;
print `killall -9 zcip`;
gw
Mobile IP - XXXVI
Anexo 3 – Configuração específica de cada cenário Dynamics
Cenário 1 – network-based foreign-agent care- of address – 1 FA
(Nível de endereçamento: Home Adress)
–
Cenário 1-a) Sem reverse tunelling
No mobile node (computador portátil):
(EnableFADecapsulation:
– se for TRUE, o foreign agent desencapsula os pacotes
resultantes da encapsulação IP em IP; assim o mobile node
utiliza o seu Home Adress na interface de rede, mesmo na
foreign network.
– se for FALSE, o mobile node desencapsula os pacotes
resultantes da encapsulação IP em IP; assim o mobile node
necessita de adquirir o co-located care-of address na rede
visitada – para isto é preciso o dhcpcd.
EnableFADecapsulation TRUE
(Endereço de rede da home network – este é usado para a
desencapsulação feita pelo foreign agent e para a resolução dinâmica
do endereço do Home Adress)
HomeNetPrefix 192.168.10.0/24
(TunelingMode – Os pacotes trocados entre o mobile node e o
correspondent node podem ser encaminhados usando rotas diferentes.
Esta opção é usada para seleccionar que rota irá ser seleccionada.
Neste caso usamos o valor 4 - “Forçar o triangle routing”)
TunnelingMode 4
No home agent (192.168.10.254 – router 10)
(Triangle Tunelling – os pacotes para os mobile nodes são enviados
através do home agent, mas os pacotes vindos do mobile node são
enviados directamente – isto é, o foreign agent usa roteamento IP
normal).
EnableTriangleTunneling TRUE
(Reverse tunnel – tunneling bidireccional, no qual os pacotes para o
mobile node e os pacotes vindos do mobile node são enviados através
do home agent)
EnableReverseTunneling FALSE
No foreign agent (router 20)
(EnableFaDecapsulation – ver explicação para o mobile node)
EnableFADecapsulation TRUE
(Triangle Tuneling – ver explicação para o mobile node)
EnableTriangleTunneling TRUE
(Reverse Tunnel – ver explicação para o mobile node)
EnableReverseTunneling FALSE
(Force Reverse Tunneling – permite forçar o reverse tunneling, neste
caso não era pretendido)
ForceReverseTunneling FALSE
Mobile IP - XXXVII
–
Cenário 1-b) Com reverse tunelling
Alterações relativamente às configurações anteriores:
No mobile node:
TunnelingMode 3
# só aceita reverse tunneling
No home agent:
EnableTriangleTunneling FALSE
EnableReverseTunneling TRUE
# desactiva triangle tunneling
# activa reverse tunneling
No foreign agent:
EnableTriangleTunneling FALSE
EnableReverseTunneling TRUE
ForceReverseTunneling TRUE
tunneling
# desactiva triangle tunneling
# activa reverse tunneling
# força a utilização de reverse
Mobile IP - XXXVIII