BRPI0512807B1

BRPI0512807B1 - Atribuição dinâmica de agente nativo e endereço nativo em comunicações sem fio

Info

Publication number: BRPI0512807B1
Application number: BRPI0512807-2A
Authority: BR
Inventors: Peter Anthony Barany; Paul E. Bender; Jun Wang; Sivaramakrishna Veerepalli; Ramin Rezaiifar
Original assignee: Qualcomm Incorporated
Priority date: 2004-07-01
Filing date: 2005-06-30
Publication date: 2019-04-02
Also published as: CN101010925B; JP5335850B2; JP4787250B2; EP1766930B1; JP2011193495A; US20060002356A1; CN101010925A; EP2512094B1; BRPI0512807A; EP1766930A1; MX2007000281A; ES2409346T3; CN101827100B; HK1110448A1; CN101827100A; KR20080083013A; KR100956043B1; EP2512094A1; KR20070033455A; KR101095333B1

Abstract

designação dinâmica de agente nativo e endereço nativo em comunicação sem fio. as modalidades aqui descritas estão relacionadas ao provimento de designação dinâmica de agente nativo e endereço nativo em comunicação sem fio, de tal forma que um nó móvel afastado do sistema nativo possa receber serviços de acesso local a partir de uma rede visitada. em uma modalidade, um nó móvel acessa urna rede visitada. a rede visitada autentica o nó móvel junto à sua rede nativa. a rede visitada a seguir designa um agente nativo visitado e um endereço nativo para o nó móvel. o nó móvel a seguir efetua a ligação segura com o agente nativo visitante. o nó móvel prossegue com as comunicações utilizando o agente nativo e o endereço nativo do visitante.

Description

ATRIBUIÇÃO DINÂMICA DE AGENTE NATIVO E ENDEREÇO NATIVO EM

COMUNICAÇÕES SEM FIO

FUNDAMENTOS

Campo relacionada presente invenção está de um modo geral especificamente, relacionadas ao comunicação sem fio as modalidades agui provimento de atribuição nativo e endereço nativo para um

IP móvel.

descritas dinâmica de nó móvel.

Mais estão agente

Fundamentos

O protocolo Internet (IP) móvel consiste de um protocolo Internet recomendado, projetado para dar suporte à mobilidade de um usuário.

Tal mobilidade se tornou importante devido à proliferação de computadores laptop e, portanto, à demanda por conectividade continua à rede, em gualguer local em gue o usuário se encontre.

O avanço nas comunicações sem fio propiciou também uma diversidade de dispositivos de comunicação sem fio (por exemplo, assistentes de dados pessoais (PDAs), portáteis, telefones móveis, etc.), capazes de acessar a

Internet e prover serviços IP, acarretando dessa forma uma maior demanda sobre a infraestrutura atual da Internet para o provimento aos usuários móveis de conectividade sem interrupções e suporte robusto.

BREVE DESCRIÇÃO DOS DESENHOS

A Figura 1 ilustra um sistema de comunicação· configurado para dar suporte a MIPv6;

A Figura 2 ilustra um sistema de comunicação no qual as modalidades descritas podem ser implementadas;

A Figura 3 ilustra uma modalidade de procedimentos envolvidos na atribuição dinâmica de HA e

HoA;

2/25

Ά Figura 4 ilustra um diagrama de fluxo de chamada que pode ser usado em uma modalidade para a implementação de atribuição dinâmica de HA e HoA;

A Figura 5 ilustra um fluxograma de chamada que pode ser usado em uma modalidade para a implementação de atribuição dinâmica de HA e HoA;

A Figura 6 ilustra um fluxograma de chamada que pode ser usado em uma modalidade para a implementação de atribuição dinâmica de HA e HoA;

A Figura 7 ilustra um fluxograma de processo que pode ser usado em uma modalidade para a implementação de atribuição dinâmica de HA e HoA;

A Figura 8 ilustra um fluxograma de processo que pode ser usado em uma modalidade para a implementação de atribuição dinâmica de HA e HoA;

A Figura 9 ilustra um diagrama de blocos de um equipamento em que podem ser implementadas algumas modalidades descritas; e

A Figura 10 ilustra um diagrama de blocos de um equipamento em que podem ser implementadas algumas modalidades descritas.

DESCRIÇÃO DETALHADA

As modalidades aqui descritas estão relacionadas ao provimento de atribuição dinâmica de agente nativo e endereço nativo para um nó móvel em comunicação sem fio.

Para referência e maior clareza, os vários acrônimos e abreviações aqui utilizados são definidos como se segue:

ΆΆΑ Autenticação, Autorização e Contabilidade

BA Confirmação (acknowledgement) de Vinculação

BU Atualização de Vinculação

CHAP Protocolo de Autenticação de Handshake de Desafio CoA Endereço Dinâmico (Care-of Address)

DAD Detecção de Endereço Duplicado

3/25

DHCPv6	Protocolo de Configuração Dinâmica de Hospedeiro Versão 6
ΕΑΡ	Protocolo de Autenticação Extensível
HA	Agente Nativo
ΗΑΆΆ	ΆΆΑ Nativo
HMAC	Código de Autenticação de Mensagem que Sofreu Hash
HoA	Endereço Nativo
HoT	Teste Nativo
HoTI	Iniciação de Teste Nativo
IKE	Troca de Chave Internet
IPsec	Segurança de Protocolo Internet
IPv6	Protocolo Internet Versão 6
IPv6CP	Protocolo de Controle IPv6
ISAKMP	Associação de Segurança de Internet e Protocolo de Gerenciamento de Chave
LCP	Protocolo de Controle de Link
ΜΙΡνβ	IP Móvel Versão 6
MN	Nó Móvel
MS-MPPE	Criptografia Ponto-a-ponto Microsoft
ΝΆΙ	Identificador de Acesso à Rede
NAS	Servidor de Acesso à Rede
NCP	Protocolo de Controle de Rede
PANA	Protocolo para Portar Autenticação para Acesso à Rede
PEAPv2	Protocolo EAP Protegido Versão 2
PDSN	Nó de Serviços de Dados em Pacote
PPP	Protocolo Ponto-a-ponto
PRF	Função Pseudo-aleatória
RADIUS	Serviço de Autenticação Remota de Usuários Discados
SA	Associação de Segurança
SPD	Base de Dados de Política de Segurança
TLS	Segurança de Camada de Transporte
TTLS	TLS em Túnel

4/25

Tal como é aqui utilizado, um nó pode se referir a um dispositivo configurado para implementar o IP. Um link pode se referir a um recurso ou meio de comunicação através do qual nós podem se comunicar na camada de link. Uma interface pode se referir a um anexo de um nó a um link. Um prefixo de sub-rede pode se referir a uma string de bits incluindo um certo número de bits iniciais de um endereço IP. Um roteador pode incluir um nó configurado para encaminhar pacotes IP não explicitamente endereçados para ele próprio. Um endereço IP unicast roteável pode se referir a um identificador mapeado para uma única interface de tal forma que um pacote enviado para ele a partir de outra sub-rede seja entregue à interface tal como mapeado.

Um nó móvel (MN) pode se referir a um nó que pode modificar seu ponto de anexação de um link para outro, podendo, porém ainda ser alcançado ou contatado através de seu endereço nativo. Um MN pode incluir vários tipos de dispositivos, incluindo, porém não estando limitados a, um telefone cabeado, um telefone sem fio, um telefone celular, um computador laptop, uma placa de computador pessoal (PC) para comunicação sem fio, um assistente de dados pessoal (PDA), um modem interno ou externo, etc. Em quaisquer aplicações, um MN pode possuir diferentes atribuições, tais como uma unidade de acesso, um terminal de acesso, uma unidade de assinante, uma estação móvel, um dispositivo móvel, uma unidade móvel, um telefone móvel, um móvel, uma estação remota, um terminal remoto, uma unidade remota, um dispositivo de usuário, um equipamento de usuário, um dispositivo portátil, etc.

Um endereço nativo (HoA) pode se referir a um endereço IP unicast direcionável atribuído a um MN por um período prolongado de tempo. Um prefixo de sub-rede nativa pode se referir ao prefixo de sub-rede IP correspondente ao HoA de um MN. Uma rede nativa pode se

5/25 referir a uma rede IP em que o prefixo de sub-rede nativa de um MN está configurado.

O termo movimento pode se referir a uma mudança no ponto de anexação de um MN à Internet de tal forma que ele não mais esteja conectado à mesma rede a que estava anteriormente. Caso um MN não esteja atualmente anexado à sua rede nativa, o MN é descrito como estando afastado de casa.

Um endereço dinâmico (CoA) pode se referir a um endereço IP unicast direcionável atribuído a um MN enquanto está afastado de caso e em uma rede visitada (ou estrangeira); o prefixo de sub-rede do CoA é um prefixo de sub-rede estrangeira. Um prefixo de sub-rede estrangeira pode se referir a qualquer prefixo de sub-rede IP que não o prefixo de sub-rede nativa do MN.

Um agente nativo (HA) pode se referir a um roteador ou direcionador (ou entidade de roteamento) junto ao qual o MN tenha registrado seu HoA e seu CoA atual. Um HA pode ser configurado para interceptar pacotes destinados ao HoA do MN e encaminhá-los (por exemplo, por meio de encapsulamento e tunelamento para o CoA registrado do MN. Um agente nativo visitante (HA visitante) aqui descrito pode se referir a um HA em uma rede visitada à qual um MN está anexado.

Um nó correspondente (CN) pode incluir um nó par (peer) como qual um MN está se comunicando. O CN pode ser móvel ou estacionário.

O termo vinculação pode fazer referência à associação de um HoA e um CoA para um MN, ao longo da vida útil remanescente de tal associação. Uma atualização de vinculação (BU) pode ser utilizada por um MN para registrar a vinculação de seu CoA com seu HoA. Uma confirmação de vinculação (BA) pode ser usada para confirmar a recepção de uma BU.

-t

6/2

Os endereços IP tornam possível o direcionamento de pacotes de uma ponta fonte para um destino por permitir que roteadores encaminhem pacotes provenientes de interfaces de redes sendo recebidas para interfaces externas de acordo com tabelas de roteamento. As tabelas de roteamento mantêm tipicamente as informações do próximo salto (hop) (interface de outbound) para cada endereço IP de destino, que porta consigo informações especificando o ponto de anexação do nó IP (por exemplo, o prefixo da rede) . Para manter as conexões de camada de transporte existentes à medida que um MN se movimenta de um local para outro, ele deve manter sempre o mesmo endereço IP. No entanto, a entrega correta de pacotes para o ponto de anexação atual do MN depende do prefixo de rede contido no endereço IP do MN, o qual muda com os novos pontos de anexação. Dito de outra forma, para modificar o roteamento é necessário um novo endereço IP associado ao novo ponto de anexação.

O IP móvel (MIP) foi projetado para solucionar tal problema, permitindo que um MN utilize dois endereços IP: um HoA estático e um CoA (ver, por exemplo, o MIP versão 6 (MIPv6) ou o MIP versão 4 (MIPv4), promulgados pela Internet Engineering Task Force (IETF) na Request for Comments (RFC) 3775 ou na RFC 3344) . O HoA é estático e utilizado, por exemplo, para identificar uma rede nativa do MN e/ou outras informações de conexão (tais como conexões TCP) . 0 CoA se modifica a cada novo ponto de anexação e pode ser considerado como o endereço topoiogicamente significativo do MN. 0 CoA inclui o prefixo de rede e, portanto identifica o ponto de anexação do MN com referência à topologia da rede. 0 HoA faz parecer que o MN está continuamente habilitado a receber dados em sua rede nativa, em que um HA está atribuído ao MN. Quando o MN está afastado de casa e anexado a uma rede visitada, o HA obtém

7/25 todos os pacotes destinados ao HoA do MN e providencia sua entrega ao ponto de anexação atual do MN.

Quando está afastado de casa, um MN adquire um CoA (por exemplo, a partir de um roteador ou anúncio de agente) proveniente de uma rede visitada em conexão com seu ponto de anexação atual. O MN a seguir registra seu novo CoA junto ao seu HA efetuando uma BU. Para levar um pacote ao MN a partir de sua rede nativa, o HA entrega o pacote da rede nativa para o CoA. Isto envolve modificar o pacote de forma a que o CoA apareça como o endereço IP de destino. Quando o pacote chega ao CoA, é aplicada a transformação inversa, de forma a que o pacote aparente novamente ter o HoA do MN como o endereço IP de destino.

Assim sendo, o MIP permite a um MN se movimentar continuamente de uma rede para outra sem modificar seu HoA e receber dados continuamente utilizando tal endereço, independentemente do ponto de anexação atual do MN à Internet. Como resultado, o movimento do MN quando longe de sua rede nativa fica transparente para os protocolos de transporte, para os protocolos de camada superior e para os aplicativos.

No ΜΙΡνβ, a atribuição do HA e HoA é estática. Apesar de tal se destinar a evitar que um MN use seu IPsec SA para efetuar uma BU em nome de outro MN junto ao mesmo HA, isto pode levar a algumas consequências desejáveis, tal como descrito a seguir.

Como exemplo, a Figura 1 ilustra um sistema de comunicação 100, em que um MN 110, possuindo um HoA, está afastado de uma rede nativa 120 e está anexado a uma rede visitada 130. O MN 110 adquiriu um CoA em conexão com uma rede visitada 130 e registrou a vinculação de seu HoA e CoA junto a um HA 125 na rede nativa 120.

Em um exemplo, a rede nativa 120 pode estar localizada, por exemplo, em San Diego, Califórnia, EUA, enquanto a rede visitada 130 pode estar localizada, por

8/25 exemplo, em Tóquio, Japão. Em outros exemplos, a rede nativa 120 e a rede visitada 130 podem estar no mesmo pais, porém em cidades diferentes, ou em outras configurações. O MN 110 pode estar em comunicação com um CN 140 (por exemplo, um provedor local de serviço Internet, ou um dispositivo móvel) através da rede visitada 130. Neste caso, pacotes provenientes do CN 140 para o MN 110 (por ser primeiramente exemplo, ambos em Tóquio) pode necessitar direcionado para o HA 125 (por exemplo, qual a seguir encaminha os pacotes cabos submarinos) em San Diego) , o (por de satélites e/ou para exemplo, por meio o MN 110 através de seu CoA.

Dito de outra forma, afastado de caso, remoto através de

110 está quando o MN o MIP atual provê serviço nativa, o que pode serem ineficientes de acesso sua rede levar as transmissões de pacotes a e/ou não confiáveis em alguns casos,

Seria desejável que o MN 110 recebesse serviço local a partir da rede visitada 130, sem passar a cada vez pela rede nativa 120.

tal como foi acima descrito.

de acesso

As modalidades aqui descritas estão relacionadas ao provimento de atribuição dinâmica de HA e HoA para um MN em relação a seu ponto de anexação atual de tal forma que o MN possa receber serviço de acesso local.

A Figura 2 ilustra um sistema de comunicação 200 no qual várias modalidades descritas podem ser implementadas. Como exemplo, um MN 210 está longe de uma rede nativa 220 e anexado a uma rede visitada 230. Um HA visitante 235 na rede visitada 230 e um HoA são atribuídos ao MN 210. O MN 210 pode também adquirir um CoA associado à rede visitada 230 e registrar a vinculação de seu HoA e CoA junto ao HA visitante 235 efetuando uma BU. Dessa forma, o MN 210 se beneficia do recebimento de serviço de acesso local a partir da rede visitada 230. Como exemplo, os pacotes transmitidos entre o MN 210 e um CN 240 podem ser roteados através do HA visitante 235, o qual é local (ou

9/25 próximo) tanto para o MN 210 como para o CN 240, portanto tornando as transmissões de pacotes mais eficientes e confiáveis. Em algumas modalidades, o uso ou seleção da rede visitada pelo MN 210 e CN 240 podem estar baseados, por exemplo, nas localizações do MN 210 e do CN 240, no estado de carga da rede, ou em outras condições ou critérios, etc.

A Figura 3 ilustra uma modalidade 300 de procedimentos envolvidos na atribuição dinâmica de HA e HoA 10 para um MN (por exemplo, no sistema de comunicação 200 da Figura 2) . Na etapa 310, um MN acessa uma rede visitada (o que pode implicar, por exemplo, em configurar o link de dados e negociar protocolos para autenticação junto à rede visitada). Na etapa 320, a rede visitada efetua a 15 autenticação junto à rede nativa do MN (por exemplo, um servidor AAA nativo na rede nativa) . Na etapa 330, a rede visitada atribui um HA visitado e um HoA (ou uma parte de um HoA) para o MN. Na etapa 340, o MN efetua a vinculação segura com o HA visitante (o que pode também incluir 20 negociar a associação de segurança com o HA visitante). Na etapa 350, o MN prossegue com as comunicações utilizando o HA visitante e HoA. As modalidades descritas a seguir propiciam alguns exemplos.

A Figura 4 ilustra um fluxograma de chamada 400 25 que pode ser usado em uma modalidade para implementar a atribuição dinâmica de HA e HoA para um MN (por exemplo, na modalidade da Figura 3) . Como exemplo, o fluxograma de chamada 400 ilustra as negociações que ocorrem entre um MN 410, um servidor de acesso a rede (NAS) 420 em uma rede 30 visitada (não é mostrada explicitamente) e um servidor AAA nativo 440 em uma rede nativa (não é mostrada explicitamente), de forma a atribuir um HA visitante 430 na rede visitada e um HoA para o MN 410. Em uma modalidade, o NAS 420 pode incluir um PDSN, trabalhando em conjunto com 35 um servidor de DHCP sem estado (stateless), tal como um

10/25 servidor DHCP-v6 sem estado (por exemplo, tal como especificado nas RFC 3315 e 3736 da

IETF) . Note-se que, para maior simplicidade e ilustração, o servidor DHCP sem estado é apresentado como estando co-localizado com o NAS

420. Em outras modalidades, eles podem estar localizados separadamente.

Na etapa 451, o MN 410 configura o link de dados, por exemplo, efetuando PPP LCP (tal como especificado na IETF RFC 1661) e negocia o uso de um protocolo para autenticação, tal como o PAP (por exemplo, tal como especificado na IETF RFC 1661) ou CHAP (por exemplo, tal como especificado na IETF RFC 1994) .

Na etapa 452, o MN 410 se autentica junto ao NAS 420 através de PAP ou CHAP. O NAS 420 pode autenticar o MN 410 junto ao servidor AAA nativo 440 através de uma mensagem de solicitação de acesso especificada pelo protocolo RADIUS (por exemplo, tal como especificado nas IETF RFCs 2865 e 3162). Em outras modalidades, também pode ser usado o protocolo Diameter (por exemplo, tal como especificado na IETF RFC 3588) .

Na etapa 453, o servidor AAA nativo 440 autentica o MN 410 e responde ao NAS 420 através de uma mensagem de aceitação de acesso especificada pelo protocolo RADIUS. A mensagem de aceitação de acesso pode incluir um atributo MS-MPPE-Recv-Key especifico de vendedor (por exemplo, tal como especificado na IETF RFC 2548), contendo a chave précompartilhada do MN 410. A chave pré-compartilhada pode ser utilizada pelo uso de IKE/ISAKMP (por exemplo, tal como especificado nas IETF RFC 2408 e 2409) pelo MN 410 e HA visitante 430 (por exemplo, ver a etapa 459 mais adiante) . Caso o MN 410 se autentique com CHAP (tal como descrito na etapa 451 acima), a chave pré-compartilhada do MN 410 pode ser calculada da seguinte forma: PRF (MNHAAA_Shared_Secret, CHAP_Challenge, NAI) . A função pseudoaleatória (PRF) pode ser HMAC. O NAI pode ser o

11/25 identificador de acesso a rede do MN 410. O MNHAAA_Shared_Secret pode ser provido no MN 410 e no servidor AAA nativo 440 antecipadamente.

Na etapa 454, o MN 410 efetua PPP IPv6CP (por exemplo, tal como especificado na IETF RFC 2472) para negociar uma ID de interface de 64 bits, que o MN 410 pode usar para configurar seu link IPv6 - endereço local (tal como especificado nas IETF RFC 2460-2462 e 3513) e CoA (por exemplo, tal como especificado na IETF RFC 3775) através de auto configuração de endereço sem estado (por exemplo, tal como especificado na IETF RFC 2462).

Na etapa 455, o NAS 420 envia uma mensagem de Anúncio de Roteador (por exemplo, tal como especificado na IETF RFC 2461) para o MN 410, contendo um prefixo /64, o qual o MN 410 pode usar para montar seu CoA anexando a ID de interface de 64 bits negociada na etapa 454 ao prefixo /64. Em uma modalidade, a mensagem de Anúncio de Roteador pode incluir M-flag = 0, O-flag = 1, Router Lifetime, Aflag = 1, L=flag = 0 (por exemplo, tal como especificado na IETF RFC 2461) . O M-flag pode ser ajustado para 0, indicando que o MN 410 pode utilizar auto configuração de endereço sem estado para configurar seu CoA. O O-flag pode ser ajustado para ”1, indicando que o MN 410 pode usar o servidor DHCPv6 sem estado para configurar outros parâmetros, incluindo (porém não limitado a) o endereço do HA visitante 430 e o HoA do MN 410, tal como adicionalmente descrito mais adiante.

Na etapa 456, o NAS 420 atribui um endereço para o HA visitante 430 e um HoA para o MN 410. O NAS 420 pode armazenar tais informações no servidor DHCPv6 sem estado.

Na etapa 457, o MN 410 usa o servidor DHCPv6 sem estado para obter o endereço para o HA visitante 430 e o HoA para o MN 410. Em algumas modalidades, o endereço para o HA visitante 430 e o HoA para o MN 410 podem ser armazenados no servidor DHCPv6 sem estado como opções de

12/25 informações especificadas de vendedor (tal como especificado na IETF RFC 3315).

Na etapa 458, o NAS 420 cria uma entrada SPD (tal como especificado na IETF RFC 2401) no HA visitante 430, por exemplo, para os propósitos de

BU, BA, HoTI, HoT e outras mensagens (por exemplo, tal como especificado na

IETF RFC 3775). Em algumas modalidades, o NAS 420 pode usar a interface provida pelo HA visitante 430 para efetuar isto (por exemplo, tal como especificado na IETF RFC 2570).

Na etapa 459, o MN 410 efetua IKE vl fase 1 usando o modo agressivo com chave pré-compartilhada (por exemplo, tal como especificado nas IETF RFC 2409 e 2460) com o HA visitante 430 para negociar ISAKMP SA e gerar chaves para mensagens IKE vl fase 2.

Na etapa 460, o MN 410 efetua IKE vl fase 2 usando o modo rápido (por exemplo, tal como especificado nas IETF RFC 2409 e 2460) com o HA visitante 430, para negociar IPsec (por exemplo, tal como especificado na IETF RFC 2401) SA e gerar' chaves para mensagens não ISAKMP para BU segura, BA, HoTI, HoT e outras mensagens (por exemplo, tal como especificado na IETF RFC 3775).

Na etapa 461, o MN 410 registra a vinculação de seu HoA e CoA junto ao HA visitante 430 efetuando uma BU. Tal pode ser protegido por IPsec (por exemplo, ver etapa 460 acima).

Na etapa 462, o HA visitante 430 efetua um DAD proxy (por exemplo, tal como especificado nas IETF RFC 2462 e 3775) em nome do MN 410, para assegurar que nenhum outro nó no link do HA 430 esteja usando o HoA do MN 410.

Na etapa 463, o MN 410 recebe um BA proveniente do HA visitante 430 em resposta a sua BU na etapa 461. Tal pode estar protegido por IPsec (por exemplo, ver etapa 460 acima).

A Figura 5 ilustra um fluxograma de chamada 500 que pode ser usado em uma modalidade para implementar a

J

13/25 atribuição dinâmica de HA e HoA para um MN. Para ilustração e maior clareza, elementos semelhantes são numerados com referências numéricas similares nas Figuras 4 e 5. O fluxograma de chamada 500 pode também compartilhar alguns dos recursos usados no fluxograma de chamada 400 da Figura 4, como será adicionalmente descrito mais adiante.

Na etapa 551, o MN 410 efetua PPP LCP (tal como especificado na IETF RFC 1661) para configurar o link de dados e negociar o uso de EAP (por exemplo, tal como especificado na IETF RFC 3487) para autenticação.

Na etapa 552, o MN 410 se autentica junto ao servidor ΑΆΆ nativo 440 através ou de EAP TTLS (por exemplo, tal como especificado em EAP Tunneled TLS Authentication Protocol (EAP-TTLS), IETF draft, julho de 2004), ou PEAPv2 (por exemplo, tal como especificado em Protected EAP Protocol (peap) Version 2, IETF draft, outubro de 2004) . A comunicação EAP entre o MN 410 e o servidor AAA nativo 440 pode ocorrer através de PPP entre o MN 410 e o NAS 420 e através do protocolo RADIUS (tal como especificado na IETF RFC 2865) entre o NAS 420 e o servidor AAA nativo 440. Em outras modalidades, o protocolo Diameter (tal como especificado na IETF RFC 3588) pode ser usado entre o NAS 420 e o servidor AAA nativo 440. Como parte de tal procedimento geral, o NAS 420 envia uma mensagem de solicitação de acesso (por exemplo, especificada pelo protocolo RADIUS) para o servidor AAA nativo 440, de forma a obter a chave pré-compartilhada do MN 410 (por exemplo, a ser usada durante IKE/ISAKMP SA pelo MN 410 e pelo HA visitante 430 a seguir) e o material de chaveamento para criptografia e autenticação de dados entre o MN 410 e o NAS 420 (como parte de EAP TTLS ou da funcionalidade PEAPv2). O servidor AAA nativo 440 responde ao NAS 420 com uma mensagem de aceitação de acesso (por exemplo, especificada pelo protocolo RADIUS). A mensagem de aceitação de acesso inclui um atributo MS-MPPE-Recv-Key especifico de vendedor

14/25 (por exemplo, tal como especificado na IETF RFC 2548), que contém a chave pré-compartilhada do MN 410.

	Na	etapa	553, o MN 410 efetua	PPP IPv6CP	(por
exemplo,	tal	como	especificado na IETF	RFC 2472)	para
negociar	uma	ID de	interface de 64 bits,	a qual o MN	410

pode usar para configurar seu link IPv6 - endereço local (por exemplo, tal como especificado na IETF RFC 2460) e CoA (tal como especificado na IETF RFC 3775) através de auto configuração de endereço sem estado (tal como especificado na IETF RFC 2462).

Na etapa 554, o NAS 420 envia um Anúncio de Roteador (por exemplo, tal como especificado na IETF RFC 2461) para o MN 410 contendo um prefixo /64, o qual o MN 410 pode usar para montar seu CoA por anexação da ID de interface de 64 bits negociada na etapa 553 acima ao prefixo /64. Em uma modalidade, o Anúncio de Roteador pode incluir M-flag = 0, O-flag = 1, Router Lifetime, A-flag = 1, L=flag = 0 (por exemplo, tal como especificado na IETF RFC 2461). O M-flag pode ser ajustado para 0, indicando que o MN 410 pode utilizar auto configuração de endereço sem estado para configurar seu CoA. O O-flag pode ser ajustado para 1, indicando que o MN 410 pode usar o servidor DHCPv6 sem estado para configurar outros parâmetros, incluindo (porém não limitado a) o endereço do HA visitante 430 e o HoA do MN 410, tal como adicionalmente descrito mais adiante.

Na etapa 555, o NAS 420 atribui um endereço para o HA visitante 430 e um HoA para o MN 410. O NAS 420 pode armazenar tais informações no servidor DHCPv6 sem estado.

Na etapa 556, o MN 410 usa o servidor DHCPv6 sem estado para obter o endereço para o HA visitante 430 e o HoA para o MN 410. Em algumas modalidades, o endereço para o HA visitante 430 e o HoA para o MN 410 podem ser armazenados no servidor DHCPv6 sem estado como opções de

15/25 informações especificadas de vendedor (tal como especificado na IETF RFC 3315).

Na etapa 557, o NAS 420 cria uma entrada SPD no HA visitante 430, por exemplo, para os propósitos de BU, BA, HoTI, HoT e outras mensagens (por exemplo, tal como especificado na IETF RFC 3775) . Em algumas modalidades, o NAS 420 pode usar a interface provida pelo HA visitante 430 para efetuar isto (por exemplo, tal como especificado na IETF RFC 2570).

Na etapa 558, o MN 410 efetua IKE vl fase 1 usando o modo agressivo com chave pré-compartilhada (por exemplo, tal como especificado nas IETF RFC 2409 e 2460) com o HA visitante 430 para negociar ISAKMP SA e gerar chaves para mensagens IKE vl fase 2 ISAKMP.

Na etapa 559, o MN 410 efetua IKE vl fase 2 usando o modo rápido (por exemplo, tal como especificado nas IETF RFC 2409 e 2460) com o HA visitante 430, para negociar IPsec SA e gerar chaves para mensagens não ISAKMP para BU segura, BA, HoTI, HoT e outras mensagens (por exemplo, tal como especificado na IETF RFC 3775).

Na etapa 560, o MN 410 registra a vinculação de seu HoA e CoA junto ao HA visitante 430 efetuando uma BU. Tal pode ser protegido por IPsec (por exemplo, ver etapa 559 acima).

Na etapa 561, o HA visitante 430 efetua um DAD proxy (por exemplo, tal como especificado nas IETF RFC 2462 e 3775) em nome do MN 410, para assegurar que nenhum outro nó no link do HA 430 esteja usando o HoA do MN 410.

Na etapa 562, o MN 410 recebe um BA proveniente do HA visitante 430 em resposta a sua BU na etapa 560. tal pode também estar protegido por IPsec (por exemplo, ver etapa 560 acima).

A Figura 6 ilustra um fluxograma de chamada 600 que pode ser usado em uma modalidade para implementar a atribuição dinâmica de HA e HoA para um MN. Para ilustração

16/25 e maior clareza, elementos semelhantes são numerados com referências numéricas similares nas Figuras 4, 5 e 6. O fluxograma de chamada 600 pode também compartilhar alguns dos recursos usados nos fluxogramas de chamada 400 e 500,

5. como será adicionalmente descrito mais adiante.

Na etapa 651, o MN 410 efetua PPP LCP (tal como especificado na IETF RFC 1661) para configurar o link de dados e negociar o uso de PAP (por exemplo, tal como especificado na IETF RFC 1661) ou CHAP (tal como 10 especificado na IETF RFC 1994) para autenticação.

Na etapa 652, o MN 410 se autentica junto ao NAS

420 através de PAP ou CHAP. O NAS 420 pode autenticar o MN

410 junto ao servidor AAA nativo 440 através de uma mensagem de solicitação de acesso especificada pelo 15 protocolo RADIUS (tal como especificado na IETF RFC 2865) ou pelo protocolo Diameter (tal como especificado na IETF RFC 3588), tal como foi acima descrito.

Na etapa 653, o servidor ΆΆΆ nativo 440 autentica o MN 410 e responde ao NAS 420 através de uma mensagem de 20 aceitação de acesso especificada pelo protocolo RADIUS. A mensagem de aceitação de acesso pode incluir um atributo MS-MPPE-Recv-Key especifico de vendedor (por exemplo, tal como especificado na IETF RFC 2548), contendo a chave précompartilhada do MN 410. A chave pré-compartilhada pode ser 25 utilizada durante a BU e BA não protegidas por IPsec pelo

MN 410 e HA visitante 430, tal como adicionalmente descrito mais adiante. Caso o MN 410 se autentique com CHAP (tal como descrito na etapa 651 acima), a chave précompartilhada do MN 410 pode ser calculada da seguinte forma: PRF (MN-HAAA_Shared_Secret, CHAP_Challenge, NAI) . A função pseudo-aleatória (PRF) pode ser HMAC. O NAI pode ser o identificador de acesso a rede do MN 410. O MNHAAA_Shared_Secret pode ser provido no MN 410 e no servidor ΆΆΆ nativo 440 antecipadamente.

/25

Em modalidades alternativas, a etapa 552 no fluxograma de chamada 500 da Figura 5 pode ser efetuada, por exemplo, em lugar das etapas 652 e 653 acima.

Na etapa 654, o MN 410 efetua PPP IPv6CP (tal como especificado na IETF RFC 2472) para negociar uma ID de interface de 64 bits, a qual o MN 410 pode utilizar para configurar seu link IPv6 - endereço local (tal como especificado na IETF RFC 2460) e CoA (tal como especificado na IETF RFC 3775) através de auto configuração de endereço sem estado (tal como especificado na IETF RFC 2462).

Na etapa 655, o NAS 420 envia um Anúncio de Roteador (por exemplo, tal como especificado na IETF RFC 2461) para o MN 410 contendo um prefixo/64, o qual o MN 410 pode usar para montar seu CoA por anexação da ID de interface de 64 bits negociada na etapa 654 ao prefixo /64. Em uma modalidade, o Anúncio de Roteador pode incluir Mflag = 0, O-fiag = 1, Router Lifetime, A-flag = 1, L=flag = 0 (por exemplo, tal como especificado na IETF RFC 2461). O M-flag pode ser ajustado para 0, indicando que o MN 410 pode utilizar auto configuração de endereço sem estado para configurar seu CoA. O O-flag pode ser ajustado para 1, indicando que o MN 410 pode usar o servidor DHCPv6 sem estado para configurar outros parâmetros, incluindo (porém não limitado a) o endereço do HA visitante 430 e o HoA do MN 410, tal como adicionalmente descrito mais adiante.

Na etapa 656, o NAS 420 seleciona um endereço para o HA visitante 430 e um prefixo/64 HoA para o MN 410 (por exemplo, tal como especificado na IETF RFC 3775) . O NAS 420 pode armazenar tais informações no servidor DHCPv6 sem estado.

Na etapa 657, o MN 410 usa o servidor DHCPv6 sem estado para obter o endereço para o HA visitante 430 e o prefixo/64 HoA. Em algumas modalidades, o endereço para o HA visitante 430 e o prefixo/64 HoA podem ser armazenados no servidor DHCPv6 sem estado como opções de informações

18/25 especificadas de vendedor (tal como especificado na IETF RFC 3315) . Subsequentemente, o MN 410 cria dinamicamente seu HoA usando o prefixo/64 HoA e sua ID de interface de 64 bits (negociada na etapa 655 acima). Note-se gue, ao contrário de receber um HoA como na modalidade das Figuras 4 ou 5 acima, o MN 410 neste caso monta dinamicamente seu HoA.

Na etapa 658, o NAS 420 cria uma entrada, que pode incluir o NAI do MN 410 (tal como especificado no IETF RFC 2486) e a chave pré-compartilhada, no HA visitante 430 para mensagens BU e BA não IPsec (por exemplo, tal como especificado em Authentication for Mobile IPv6, IETF draft, janeiro de 2005, e em Mobile Node Identifier Option for Mobile IPv6, IETF draft, dezembro de 2004). O NAS 420 pode usar a interface provida pelo vendedor HA visitante 430 para efetuar isto (por exemplo, tal como especificado na IETF RFC 2570) .

Na etapa 659, o MN 410 registra a vinculação de seu HoA e CoA junto ao HA visitante 430 efetuando uma BU. Como foi acima mencionado, tal BU pode não ser protegida por IPsec. Ela pode ser, entretanto protegida pela opção de autenticação de mobilidade MN - HA (tal como especificado em Authentication for Mobile IPv6, IETF draft, janeiro de 2005) e a opção de mobilidade NAI (tal como especificado em Mobile Node Identifier Option for Mobile IPv6, IETF draft, dezembro de 2004) . O HA visitante 430 pode conferir seu cache (por exemplo, populado pelo NAS 420) para assegurar que o HoA sendo registrado pelo MN 410 já não está em uso (por exemplo, por outro MN) . Ao se confirmar isto, pode ser permitido o registro do MN.

Na etapa 660, o HA visitante 430 efetua um DAD proxy (por exemplo, tal como especificado nas IETF RFC 2462 e 3775) em nome do MN 410 para assegurar que nenhum outro nó no link do HA visitante 330 está utilizando o HoA do MN 410.

19/25

Na etapa 661, o MN 410 recebe um BA proveniente do HA visitante 430 em resposta a sua BU na etapa 659. Como foi acima mencionado, tal BA pode não estar protegido por IPsec. Ele pode estar protegido pela opção de mobilidade de autenticação MN - HA (tal como especificado em Authentication for Mobile IPv6, IETF draft, janeiro de 2005) e a opção de mobilidade NAI (tal como especificado em Mobile Node Identifier Option for Mobile IPv6, IETF draft, dezembro de 2004).

As modalidades aqui descritas (tal como acima descrito nas Figuras 2 a 5) propiciam algumas modalidades de atribuição dinâmica de HA e HoA para um MN. Existem outras modalidades e implementações. Em modalidades alternativas, por exemplo, vários procedimentos (por exemplo, configuração de link de dados, autenticação, configuração de HoA e CoA, negociação de associação de segurança, etc.) acima descritos podem ser efetuados de acordo com outros protocolos adequados. Além disso, para a auto configuração de endereço sem estado especificada nas IETF RFC 2462 e 2461, o prefixo da sub-rede para HoA é /64, tal como acima descrito. Em outras modalidades, o prefixo de sub-rede para HoA pode possuir diferentes comprimentos (ou formas).

A Figura 7 ilustra um fluxograma de um processo 7 00 que pode ser usado em uma modalidade para prover atribuição dinâmica de HA e HoA para um MN. A etapa 710 atribui um endereço para um HA visitante e pelo menos uma parte de um HoA para um MN, o HA visitante estando associado a uma rede visitada à qual o MN está anexado. Ά expressão pelo menos uma parte de um HoA pode incluir um HoA (tal como nas modalidades das Figuras 4 e 5 acima) , um prefixo HoA (tal como na modalidade da Figura 6 acima) , ou outras informações associadas a um HoA para o MN. A etapa 720 armazena o endereço para o HA visitante e pelo menos uma parte do HoA para o MN em um servidor (por exemplo, um

20/25 servidor DHCPvô sem estado) associado à rede visitada. A etapa 730 cria uma entrada no HA visitante em relação ao MN. Em uma modalidade, a entrada pode estar associada a uma entrada SPD para armazenamento de BU, BA e outras mensagens. Em outras modalidades, a entrada pode incluir um NAI e uma chave pré-compartilhada associada ao MN.

O processo 700 pode também incluir o efetuar a autenticação junto à rede nativa do MN (por exemplo, um servidor AAA nativo), por exemplo, para obter uma chave pré-compartilhada associada ao MN. O processo 700 pode também incluir a transmissão de um Anúncio de Roteador para o MN, com base na qual o MN pode configurar um CoA.

A Figura 8 ilustra um fluxograma de um processo 800, que pode ser usado em uma modalidade para prover atribuição dinâmica de HA e HoA para um MN. A etapa 810 obtém um endereço para um HA visitante e pelo menos uma parte de um HoA para um MN a partir de uma rede visitada, o HA visitante estando associado à rede visitada à qual o MN está anexado. A etapa 820 envia uma BU para o HA visitante, a BU incluindo o HoA e um CoA associado ao MN. A etapa 830 recebe um BA proveniente do HA visitante em resposta à BU.

O processo 800 pode também incluir o configurar o CoA, por exemplo, com base, em parte, em um Anúncio de Roteador recebido a partir da rede visitada. O processo 800 pode também incluir a configuração do HoA com base, em parte, na parte do HoA (por exemplo, um prefixo HoA) obtido a partir da rede visitada. O processo 800 pode também incluir a negociação de associação de segurança (por exemplo, IPsec) com o HA visitante.

A Figura 9 ilustra um diagrama de blocos de um equipamento 900 que pode ser usado para implementar algumas modalidades descritas (tal como acima descrito). Como exemplo, o equipamento 900 pode incluir uma unidade (ou módulo) de atribuição de HA 910 configurada para atribuir um endereço para um HA visitante e pelo menos uma parte de

21/25 um HoA para um MN, em que o HA visitante está associado a uma rede visitada à qual o MN está anexado, bem como uma unidade de armazenamento de endereço 920 configurada para armazenar o endereço para o HA visitante e pelo menos uma parte do HoA para o MN. Em algumas modalidades, a unidade de armazenamento de endereços 920 pode estar associada a um servidor (por exemplo, um servidor DHCPv6 sem estado) na rede visitada. O equipamento 900 pode incluir também uma unidade de autenticação 930 configurada para efetuar a autenticação junto à rede nativa do MN (por exemplo, um ΆΆΆ nativo). O equipamento 900 pode também incluir uma unidade de transmissão 940 configurada para transmitir um Anúncio de Roteador.

No equipamento 900, a unidade de atribuição de HA 910, a unidade de armazenamento de endereços 920, a unidade de autenticação 930 e a unidade de transmissão 940 podem estar acopladas a um barramento de comunicação 950. Uma unidade de processamento 960 e uma unidade de memória 970 podem também estar acopladas ao barramento de comunicação 950. A unidade de processamento 960 pode estar configurada para controlar e/ou coordenar as operações de várias unidades. A unidade de memória 970 pode incorporar instruções para serem executadas, por exemplo, pela unidade de processamento 960.

Em algumas modalidades, o equipamento 900 pode ser implementado em um NAS, ou outros dispositivos de infraestrutura de rede.

A Figura 10 ilustra um diagrama de blocos de um equipamento 1000 que pode ser usado para implementar algumas modalidades descritas (tal como acima descrito). Como exemplo, o equipamento 1000 pode incluir uma unidade (ou módulo) de recepção de endereço 1010 configurada para a obtenção de um endereço para um HA visitante e pelo menos uma parte de um HoA para um MN a partir de uma rede visitada, em que o HA visitante está associado à rede

22/25 visitada à qual o MN está anexado, bem como uma unidade de vinculação de HA 1020 configurada para enviar uma BU para o HA visitante, a BU incluindo o HoA e um CoA associado ao

MN. O equipamento 1000 pode também incluir uma unidade de configuração de endereço 1030 que opera para configurar o CoA, por exemplo com base, em parte, em um Anúncio de Roteador recebido a partir da rede visitante. Em algumas modalidades, a unidade de configuração de endereços 1030 pode também operar para configurar o HoA com base, em parte, na parte do HoA (por exemplo, um prefixo HoA) obtida a partir da rede visitada. O equipamento 1000 pode também incluir uma unidade de autenticação 1040 configurada para efetuar a autenticação junto à rede visitada.

No equipamento 1000, a unidade endereços 1010, a unidade de vinculação unidade de configuração de endereço 1030 autenticação 1040 podem estar acopladas a de de recepção

HA 1020, unidade um barramento de de de comunicação 1050. A unidade de processamento 1060 e uma unidade de memória 1070 podem também estar acopladas ao barramento de comunicação 1050. A unidade de processamento 1060 pode ser configurada para controlar e/ou coordenar as operações de várias unidades. A unidade de memória 1070 pode incorporar instruções, por exemplo, para serem executadas pela unidade de processamento 1060.

Em algumas modalidades, o equipamento 1000 pode ser implementado em um MN, ou outros dispositivos para recepção de dados.

Várias unidades/módulos nas Figuras 9 e 10 e outras modalidades podem ser implementadas em hardware, software, firmware, ou em uma combinação de tais. Em uma implementação em hardware, várias unidades podem ser implementadas dentro de um ou mais circuitos integrados específicos para aplicação (ASICs), processadores de sinais digitais (DSPs), dispositivos processadores de sinais digitais (DSPDs), dispositivos lógicos programáveis (PLDs),

23/25 arranjos de porta programáveis em campo (FPGAs), processadores, controladores, microcontroladores, microprocessadores, dispositivos lógicos programáveis (PLD), outras unidades eletrônicas, ou quaisquer combinações de tais. Em uma implementação em software, várias unidades podem ser implementadas por meio de módulos (por exemplo, procedimentos, funções e assim por diante) que efetuam as funções aqui descritas. Os códigos de software podem ser armazenados em uma unidade de memória e executados por um processador (por exemplo, uma unidade processadora). Ά unidade de memória pode ser implementada no interior do processador ou externamente ao processador, caso este em que ela pode estar acoplada em comunicação com o processador através de vários dispositivos como é do conhecimento dos técnicos na área.

Os técnicos na área notarão que as sinais podem ser representados usando-se dentre uma diversidade diferentes.

informações, sido mencionados

Como exemplo, sinais, bits, informações e de tecnologias dados, instruções, qualquer uma técnicas comandos, símbolos e chips que por toda a descrição acima representados eletromagnéticas, quaisquer combinações de

Os técnicos na por campos tensões, possam ter podem ser ondas ou partículas tais.

área notarão correntes, eletromagnéticos, ou também que os vários exemplos de blocos lógicos, módulos, circuitos e etapas de algoritmos descritos em conexão às modalidades aqui descritas podem ser implementados na forma de hardware eletrônico, software de computador, ou combinações de tais. Para ilustrar claramente tal intercambialidade de hardware e software, os vários exemplos de componentes, blocos, módulos, circuitos e etapas foram descritos de um modo geral em termos de sua funcionalidade. Se tal funcionalidade é implementada na forma de hardware ou software depende da aplicação específica e restrições de .1

« projeto impostas sobre o sistema como um todo. Os técnicos na área podem implementar a funcionalidade descrita de várias formas para cada aplicação especifica, porém tais decisões de implementação não devem ser interpretadas como levando a circuitos um afastamento do escopo da presente invenção. Os vários exemplos de blocos descritos em conexão às lógicos, módulos e modalidades aqui descritas podem ser implementados ou efetuados com um processador de uso geral, processadores (DSP), um circuito integrado especifico (ASIC), arranjos de porta programáveis em lógicos programáveis, transistores, componentes de combinação de tais de sinais digitais aplicação para campo (FPGA) ou outros dispositivos individuais, ou lógica hardware individuais, portas projetada para efetuar processador porém como processador, de ou as qualquer funções aqui descritas. Um de uso geral alternativa, o pode ser um microprocessador, controlador, processador pode ser qualquer microcontrolador ou máquina de estado convencionais. Um processador pode também ser implementado na forma de uma combinação de dispositivos de computação, por exemplo, uma combinação de um DSP e um microprocessador, uma pluralidade de microprocessadores, um ou mais microprocessadores em conjunto com um núcleo DSP, ou qualquer outra configuração similar.

As etapas de um método ou algoritmo descritas em conexão com as modalidades aqui descritas podem ser incorporadas diretamente em hardware, em um módulo de software executado por um processador, ou em uma combinação de ambos. O módulo de software podería residir em uma memória de acesso aleatório (RAM), uma memória flash, memória ROM (memória apenas para leitura), memória EPROM (memória apenas para leitura eletricamente programável), memória EEPROM (memória apenas para leitura eletricamente apagável programável), registradores, um disco rígido, um disco removível, um CD-ROM, ou qualquer outra forma de meio

25/25 de armazenamento conhecido pelos técnicos na área. Um exemplo de um meio de armazenamento pode estar acoplado ao processador de tal forma que o processador possa ler informações a partir do, e gravar informações no, meio de armazenamento. Como alternativa, o meio de armazenamento pode estar integrado ao processador. O processador e o meio de armazenamento podem residir em um ASIC. O ASIC pode residir em um MN. Como alternativa, o processador e o meio de armazenamento podem residir na forma de componentes individuais em um MN.

A descrição acima das modalidades preferidas é provida para permitir que os técnicos na área efetivem ou façam uso da presente invenção. As diferentes modificações dessas modalidades ficarão prontamente claras para os técnicos na área e os princípios genéricos aqui definidos podem ser aplicados a outras modalidades sem o uso das faculdades inventivas. Dessa forma, a presente invenção não deve ser limitada às modalidades aqui apresentadas, devendo receber o escopo mais amplo, consistente com os princípios e características novas aqui descritos.

Claims

REIVINDICAÇÕES

1. Método (700) para comunicações sem fio, caracterizado pelo fato de que compreende as etapas de:

atribuir (710) um endereço a um agente nativo visitante (430), o agente nativo visitante sendo associado a uma rede visitada (230) a qual um nó móvel (410) está anexado;

atribuir pelo menos uma parte de um endereço nativo ao nó móvel;

criar um endereço nativo para o nó móvel pela combinação da parte de prefixo do endereço nativo com um identificador de interface negociado com a rede visitada (230); e seguir com a comunicação utilizando o agente nativo visitante (430) e o endereço nativo criado.
2. Método (700), de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente armazenar (720) o endereço para o agente nativo visitante e a pelo menos uma parte de prefixo do endereço nativo para o nó móvel em um servidor (440) associado à rede visitada (230) .
3. Método (700), de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente efetuar autenticação junto a uma rede nativa associada ao nó móvel (410).
4. Método (700), de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente transmitir um Anúncio de Roteador, o Anúncio de Roteador provendo informações para que o nó móvel (410) configure um endereço dinâmico.
5. Método (700), de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente criar (730) uma entrada no agente nativo visitante em relação ao nó móvel.

Petição 870180156587, de 29/11/2018, pág. 6/9

2/3
6. Equipamento (900) próprio para comunicações sem fio, caracterizado pelo fato de que compreende:

um processador configurado para:

atribuir (960) um endereço a um agente nativo visitante (430), o agente nativo visitante sendo associado a uma rede visitada a qual um nó móvel está anexado;

atribuir pelo menos uma parte de prefixo de um endereço nativo ao nó móvel (410);

criar um endereço nativo para o nó móvel (410) pela combinação da parte de prefixo do endereço nativo com um identificador de interface negociado com a rede visitada (230); e seguir com a comunicação utilizando o agente nativo visitante (430) e o endereço nativo criado.
7. Equipamento (900), de acordo com a reivindicação 6, caracterizado pelo fato de que o processador (960) é adicionalmente configurado para armazenar o endereço para o agente nativo visitante (430) e a pelo menos uma parte de prefixo do endereço nativo para o nó móvel em um servidor associado à rede visitada.
8. Equipamento (900), de acordo com a reivindicação 7, caracterizado pelo fato de que o servidor inclui um servidor de protocolo de configuração dinâmica de hospedeiro (DHCP) sem estado.
9. Equipamento (900), de acordo com a reivindicação 6, caracterizado pelo fato de que o processador (960) é adicionalmente configurado para efetuar autenticação junto a uma rede nativa associada ao nó móvel (410).
10. Equipamento (900), de acordo com a reivindicação 6, caracterizado pelo fato de que o processador (960) é adicionalmente configurado para transmitir um Anúncio de Roteador, o Anúncio de Roteador

Petição 870180156587, de 29/11/2018, pág. 7/9

3/3 provendo informações para o nó móvel para configurar um endereço dinâmico.
11. Equipamento (900), de acordo com a reivindicação 6, caracterizado pelo fato de que o processador (960) é adicionalmente configurado para criar uma entrada no agente nativo visitante (430) em relação ao nó móvel (410).