MXPA02002828A - Interfase de paquetes de red. - Google Patents

Abstract

Un metodo para irterconectar y una interfase por un dominio IPv4. La interfase comprende un convertidor del protocolo un encapsulador/desencapsulador y un controlador. Cuando una fuente IPv6 desea enviar a un destino nombrado en el otro dominio IPv6, al fuente envia una direccion IPv6 normal solicitada al servidor DNS local, el cual lo releva a un servidor de nombre IPv6 en el otro dominio IPv6. El mensaje de respuesta que contiene la direccion IPv6 verdadera del destino, es recibido en la interfase remota, que se anexa al mensaje de respuesta DNS convertido del protocolo que resulta un primer registro adicional que contiene la direccion IPv6 verdadera y un segundo registro adicional que contiene la direccion IPv4 de esa interfase. Al recibirse en la otra interfase, los registros adicionales son eliminados y sus contenidos almacenados en una entrada de una tabla y la direccion IPv6 verdadera escrita en el registro de direccion del mensaje de respuesta DNS IPv6 que resulta. Cuando la interfase recibe un paquete de un huesped IPv6, checa si la direccion de destino acopla con la entrada de la tabla y si es asi envia el paquete al encapsulador junto con la direccion IPv4 de la interfase remota. La interfase remota extrae la direccion de la fuente y la direccion de la interfase de encapsulacion y las almacena en una entrada en su tabla correspondiente para emplearse en encapsular los paquetes que regresen a la fuente. Sin embargo, si se reconoce la direccion de destino como forma IPv4 mapeado, el paquete es enviado a un convertidor protocolo.

Description

-qr INTERFASE'DE PAQUETES DE RED DESCRIPCIÓN DE LA INVENCIÓN 5 Esta invención se relaciona con una interfaz entre una primera red que opera de acuerdo con primer protocolo de transmisión y que tiene direcciones de red de acuerdo con un primer convención de direccionamiento, denominado en la presente como dirección del primer tipo, y una segunda red que opera de 10 acuerdo con un segundo protocolo de transmisión y que tiene direcciones de red de acuerdo con una segundo convención de direccionamiento, denominado en la presente como direcciones del segundo tipo; y con el encapsulado (cambio temporal de destino) de paquetes a través de la segunda red desde un interfaz a otra 15 interfaz; y se relaciona de manera particular aunque no exclusiva, con la comunicación entre huéspedes en dominios de la versión 6 de protocolo de internet respectivo (IPv6) separados por un dominio de versión 4 de protocolo de internet (IPv4) . En la presente, los términos paquete y mensaje se < ) 20 utilizan intercambiablemente y tienen el mismo significado, y el término dominio de internet se utiliza como un ejemplo específico de una red. En tecnología de internet, se ha vuelto evidente que el protocolo de transporte inicial, IPv4, necesita mejorarse, debido 25 principalmente a incrementos en el espacio de dirección Por otra parte, un encapsulado automático no necesita configuración manual : los puntos finales del encapsulado se determinan automáticamente. Actualmente están en desarrollo varios mecanismos de encapsulado automáticos dentro del IETF, y estos se conocen en la técnica como 6 sobre 4, 6 a 4, encapsulado dinámico, gestionador de encapsulado. Para información más detallada respecto a 6 sobre 4, el lector puede obtener de IETF el documento conocido como RFC2829, o cualquier variante del mismo, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", por B. Carpenter y C. Jung, marzo de 1999. Para información más detallada de 6 a 4, el lector puede obtener de IETF el documento conocido como draft-ietf-ngtrans-6to4-0.2. txt o cualquier variante del mismo, "Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels", por B.

Carpenter y K. Moore . Para una información más detallada del encapsulado dinámico, el lector puede obtener información de IETF, el documento conocido como draft-ietf-ngtrans-dti-OO.txt. Para información más detallada del gestionador de encapsulado, el lector puede obtener de IETF, el documento conocido como draft-ietf-ngtrans-broker-OO.txt. Estos mecanismos de encapsulado automáticos conocidos utilizan diversas técnicas para permitir que se establezca automáticamente el encapsulado: disponible y resolver una estructura de dirección jerárquica. El resultado es IPv6, el cual tiene un formato encabezador simplificado comparado con IPv4, pero el cual utiliza direcciones de 128 bitios en comparación con las direcciones de 32 bitios utilizadas en IPv4. Los lectores que desean tener una revisión del área de transición general pueden tener acceso a una lista de diseños de internet, las cuales son documentos de trabajo de la fuerza de tarea de ingeniería de internet (IETF) en http://www.ietf.org/lid-abstracts.txt, y un documento particularmente importante es "A Guide to the introduction of IPv6 in the IPv4 World" <draft-ieft-ngtrans-introduction-to-ipv6-transition-01. txt>, también denominado como "guía a la transición IPv6". Como se ha mencionado, la presente invención se relaciona con el encapsulado. Las técnicas de encapsulado conocidas son de dos tipos: configurada y automática. Un encapsulado configurado se genera por configuración manual de una interfaz de encapsulado entre un dominio IPv6 y un dominio IPv4 de manera tal que todos los paquetes recibidos del dominio IPv6 se encapsulan en paquetes IPv4 y se direccionan a un punto final de encapsulado especifico, es decir, la interfaz de encapsulamiento entre el dominio IPv4 y el dominio IPv6 remoto que contiene el huésped IPv6 de destino. • 6 sobre 4 Difusión múltiple • 6 a 4 Dirección IPv6 especial en la cual el agregador de nivel superior (TLA) contiene un identificador para el mecanismo de encapsulamiento 6 a 5 4 y el agregador de siguiente nivel (NLA) contiene la dirección IPv4 del punto final de encapsulación • Encapsulación dinámica vía DNS • Gestionador de encapsulado www based tool La solicitud de patente Europea EP 840 482 describe un 10 método para comunicarse entre una terminal IPv4 y una terminal IPv6, en particular un método para realizar conversión de protocolo en paquetes IPv4 y paquetes IPv6 utilizando el aparato de conversión localizado entre las redes IPv4 e IPv6. EP 840 482 establece que existen varios métodos conocidos para comunicación 15 entre las terminales IPv4 e IPv6, y discute los métodos de encapsulado mencionados antes, entre otros. EP 480 482 afirma que existen varios problemas con los métodos existentes y en consecuencia proporciona un método nuevo para trabajo en internet con IPv4-IPv6. Su método se explica por medio de un ejemplo: i ) 20 considérese el caso de una terminal IPv4 que solicita comunicaciones con una terminal A IPv6. La terminal IPv4 envía una solicitud de búsqueda de nombre para un huésped A en la red IPv6. Esta solicitud se recibe por el aparato de conversión, el cual envía la solicitud a un servidor DNS. El servidor DNS 25 regresa una dirección de red IPv6 al aparato de conversión, el cual asigna una dirección IPv4 de un acumulado de direcciones (de un servidor de Dynamic Host Configuration Protocol (protocolo de configuración de huésped dinámico) (DHCP) ) para regresar la dirección IPv6. El aparato de conversión almacena el mapeo entre la dirección IPv4 asignada y la dirección IPv6 que se ha regresado, y dirige la dirección IPv4 asignada al huésped C solicitante. En comunicaciones subsecuentes entre los huéspedes C y E, el huésped C establece una dirección de destino para que sea asignado los paquetes que salen con dirección IPv4 y envía los paquetes a la dirección IPv4 asignada del huésped A; el direccionamiento IP convencional asegura que el paquete se dirige al aparato convertidor. El aparato convertidor después busca el mapeo entre las direcciones IPv4 asignadas y las direcciones IPv6 para recuperar la dirección IPv6 del huésped A y vuelve a esta la dirección de destino del paquete. EP 840 482, por lo tanto presenta un método nuevo de constitución de redes IPv4/IPv6. De acuerdo con un primer aspecto de la presente invencidn, se proporciona una interfaz para uso entre una primera red que opera de acuerdo con un primer protocolo de transmisión y que tiene direcciones de red de acuerdo con una primera convención de direccionamiento, denominada en la presente como direcciones del primer tipo, y una segunda red que opera de acuerdo con un segundo protocolo de transmisión y que tiene direcciones de red de acuerdo con un segundo convenio de direccionamiento, denominado en la presente como direcciones del segundo tipo, la interfaz tiene direcciones del primer tipo y direcciones del segundo tipo, y comprende: un convertidor de protocolo arreglado para convertir un mensaje que tiene un formato de acuerdo con un primer protocolo de transmisión, denominado en la presente como un mensaje del primer tipo, en un mensaje que tiene un formato de acuerdo con el segundo protocolo de transmisión, denominado en la presente como mensaje del segundo tipo; un medio para encapsulamiento arreglado para que responda a la recepción de una dirección del segundo tipo junto con un mensaje del primer tipo al encapsular el mensaje recibido del primer tipo como la información útil del mensaje de segundo tipo encapsulante resultante, utilizando la dirección de segundo tipo recibida como la dirección de destino del mensaje de segundo tipo encapsulante resultante y utilizando la dirección de segundo tipo de la interfaz como la fuente de dirección del mensaje de segundo tipo encapsulante resultante; y un controlador de interfaz arreglado para responder a la recepción por la interfaz de un mensaje del primer tipo de la primera red al : examinar la dirección de destino del mensaje de primer tipo recibida de la primera red para determinar si el mensaje de primer tipo es de un formato predeterminado, y de ser así, enviar el convertidor de protocolo de que el mensaje del primer tipo recibido de la primera red derivar, directa o indirectamente, de la dirección de destino del mensaje del primer tipo, una dirección del segundo tipo para uso por el medio de encapsulamiento, y enviar al medio de encapsulamiento la dirección de segundo tipo derivada, junto con el mensaje del primer tipo recibido de la primera red. Preferiblemente, el controlador se distribuye para recibir la dirección del segundo tipo directamente al recuperarla de un campo de subdirección determinado previamente de la dirección de destino. Alternativamente, el controlador se arregla para derivar la dirección de segundo tipo indirectamente al tener acceso, de acuerdo con la dirección de destino, a una tabla de búsqueda que tiene entrada en forma de una dirección de primer tipo asociada con una dirección del segundo tipo, y recuperar la dirección de segundo tipo de una entrada que tiene una dirección del primer tipo que coincide con la dirección de destino. Preferiblemente, cada entrada de la tabla de conversión de dirección comprende un campo que contiene un identificador para identificar si el controlador que se va a enviar es un mensaje del primer tipo recibido desde la primera red al convertidor de protocolo o al medio de encapsulamiento.

El medio de encapsulamiento puede comprender una pluralidad de encapsuladores diferentes, cada encapsulador se distribuye para que funcione de acuerdo con el tipo de encapsulador respectiva, y el controlador se arregla para determinar si la dirección de destino de este mensaje de primer tipo recibido de la primera red es uno de una pluralidad correspondiente respectiva de formatos determinados previamente, y de ser así, enviar el mensaje del primer tipo recibido de la primera red al medio encapsulante que corresponde a un formato determinado previamente. Preferiblemente, cada entrada de la tabla de conversión de dirección comprende un campo para contener un identificador para identificar un tipo de encapsulación ya sea que el controlador vaya a enviar un mensaje del primer tipo recibido de la primera red al convertidor de protocolo o al medio de encapsulación. De acuerdo con un segundo aspecto de la presente invención, se proporciona un método para operar una interfaz entre una primera red que opera de acuerdo con un primer protocolo de transmisión y que tiene direcciones de red, de acuerdo con una primera convención de direccionamiento, denominada en la presente como dirección del primer tipo, y una segunda red que opera de acuerdo con un segundo protocolo de transmisión y que tiene una dirección de red de acuerdo con un segundo convenio de direccionamiento, denominado en la presente como direcciones del segundo tipo, el método comprende las etapas de: examinar las direcciones de destino del mensaje del primer tipo recibido de la primera red; y si la dirección de destino del mensaje de primer tipo que se recibe es de un primer formato determinado previamente, el protocolo convierte el mensaje del primer tipo recibido; de otra manera, encapsula el mensaje recibido del primer tipo, de acuerdo con el segundo protocolo de transmisión utilizando, como la dirección de destino del mensaje de segundo tipo encapsulado resultante, una dirección de segundo tipo derivada directa o indirectamente de la dirección de destino del mensaje de primer tipo recibido. De acuerdo con un tercer aspecto de la presente invención, se proporciona un método para operar una interfaz entre una primera red que opera de acuerdo con un primer protocolo de transmisión y que tiene direcciones de red de acuerdo con un primer convención de direccionamiento, denominado en la presente como direcciones del primer tipo y una segunda red que opera de acuerdo con un segundo protocolo de transmisión y que tiene direcciones de red de acuerdo con el segundo convenio de direccionamiento, denominado en la presente como direcciones del segundo tipo, el método comprende las etapas de: examinar las direcciones de destino de un mensaje del primer tipo recibido desde la primera red; y si las direcciones de destino del mensaje del primer tipo recibidas son de un formato determinado previamente, convertir el protocolo que ha recibido el mensaje del primer tipo; y si la dirección de destino del mensaje de primer tipo recibida es de un segundo formato determinado previamente, encapsular el mensaje recibido del primer tipo de acuerdo con un segundo protocolo de transmisión, utilizando, como la dirección de destino del mensaje del segundo tipo encapsulado resultante, una dirección de segundo tipo derivada, directa o indirectamente, de la dirección de destino del mensaje del primer tipo recibido. Preferiblemente, el segundo formato de dirección predeterminado incluye un identificador que identifica un tipo de encapsulación. De acuerdo con un cuarto aspecto de la presente invención, se proporciona un aparato de interfaz para realizar el método del segundo aspecto de la presente invención, el aparato de interfaz comprende : un medio para examinar la dirección de destino del mensaje de primer tipo recibido en el aparato de interfaz desde la primera red para determinar si la dirección de destino del mensaje de primer tipo que se recibe es de un primer formato determinado previamente; un protocolo convertidor que responde a una determinación del medio de examen de que la dirección de destino del mensaje de primer tipo recibido es de un primer formato determinado previamente para convertir ese mensaje de primer tipo recibido; y un medio para encapsular, en respuesta a una determinación del medio de examen de que la dirección de destino del mensaje del primer tipo recibida es de un primer formato determinado previamente para encapsular el mensaje de primer tipo recibido, de acuerdo con el segundo protocolo de transmisión utilizando, como la dirección de destino del mensaje de segundo tipo encapsulante resultante, una dirección del segundo tipo derivada directa o indirectamente de la dirección de destino del mensaje de primer tipo recibido. El primer formato determinado previamente puede incluir una primera porción determinada previamente cuyo contenido identifica al mensaje de primer tipo recibido como adecuado para el protocolo de conversión. El primer formato determinado previamente también puede incluir una segunda porción determinada previamente cuyo contenido constituye la dirección del segundo tipo utilizada como la dirección de destino de un mensaje de segundo tipo encapsulado resultante. Preferiblemente, la dirección del segundo tipo se deriva directamente al recuperarla de un campo de subdirección determinado previamente de la dirección de destino.

Preferiblemente, la etapa de examen comprende las subetapas de recuperar la dirección de destino del mensaje de primer tipo recibida, y tener acceso a una tabla de búsqueda, de acuerdo con la dirección de destino recuperada. De manera más referible, en los métodos para uso cuando la tabla de búsqueda comprende entradas en forma de una dirección del primer tipo asociada con una dirección del segundo tipo, la recuperación de la dirección del segundo tipo de cualquier entrada que tenga su dirección de primer tipo coincidente con la dirección de destino constituye indirectamente derivar la dirección del segundo tipo de la dirección de destino de la recibida en el mensaje del primer tipo. En los métodos para uso cuando las entradas de la tabla de búsqueda incluyen un primer campo identificador que contiene un identificador que identifica si el mensaje del primer tipo va a ser convertido en cuanto a protocolo o encapsulado, se pueden incluir las etapas de recuperar el identificador del primer campo identificador de la entrada que tenga su coincidencia de dirección del primer tipo con el destino. El primer formato determinado previamente también puede incluir una segunda porción determinada previamente cuyo contenido constituya la dirección de segundo tipo utilizada como la dirección de destino de un mensaje del segundo tipo encapsulado resultante.

Preferiblemente, la dirección del segundo tipo se deriva directamente al recuperarla de un campo de subdirección determinado previamente de la dirección de destino. Preferiblemente, la etapa de examen comprende las subetapas de recuperar la dirección de destino del mensaje de primer tipo recibido, y tener acceso a una tabla de búsqueda de acuerdo con la dirección de destino recuperada. De manera más preferible, en los métodos para uso cuando la tabla de búsqueda comprende entradas en forma de una dirección del primer tipo asociada con una dirección del segundo tipo, la recuperación de la dirección del segundo tipo de una entrada que tiene su dirección del primer tipo que coincide con la dirección de destino constituye derivar indirectamente la dirección del segundo tipo de la dirección de destino del mensaje recibido del primer tipo. En los métodos para uso cuando las entradas de la tabla de búsqueda incluyen un primer campo identificador que contiene un identificador que identifica si el mensaje del primer tipo va a ser convertido por protocolo o encapsulado, se pueden incluir las etapas de recuperar el identificador del campo del primer identificador de la entrada que tenga su dirección del primer tipo coincidente con la dirección de destino, y verificar que el identificador recuperado es consistente con cualquiera del protocolo de conversión o encapsulación que se va a realizar sobre ese mensaje del primer tipo recibido. • En los métodos para uso cuando las entradas de la tabla de búsqueda incluyen un segundo campo identificador que contiene un identificador que identifica un tipo de encapsulación, y cuando existe una pluralidad de tipos de encapsulación disponibles, se pueden incluir las etapas de recuperar el identificador del segundo campo identificador de la entrada que tenga su dirección del primer tipo coincidente con la dirección de destino y verificar que el identificador recuperado es consistente con el tipo de encapsulación que se va a realizar ante ese mensaje del primer tipo que se recibe. Se conocen los convertidores de protocolo por habilitar a un huésped IPv6 para enviar mensajes a un huésped IPv4. Cuando se activa un huésped IPv6 nuevo en un dominio IPv6, utiliza la técnica conocida como Descubrimiento de Vecindario (ND) para encontrar la identidad de huéspedes con quienes se puede comunicar directamente. Difunde un mensaje ND que contiene su dirección de red IPv6, y cada huésped que la recibe envía un mensaje de respuesta que contiene la dirección de red IPv6 del huésped. Dado que el dominio utiliza un mecanismo de transporte subyacente, digamos direcciones de control de acceso de medio (MAC, por sus siglas en inglés, utilizando Ethernet, cada huésped que recibe un mensaje ND recuperará una dirección de red IPv6 del huésped nueva y también la dirección MAC del huésped nuevo, y el huésped nuevo recuperará de cada mensaje de respuesta la dirección de red IPv6 del huésped enviada y su dirección MAC.

El nuevo huésped ahora construye una tabla ND en la cual cada entrada corresponde a un huésped vecino y comprende una primera parte en forma de una dirección IPv6 de 128 bitios de ese huésped vecino, y una segunda parte en forma de la dirección MAC asociada. El dispositivo de interfaz (que contiene el convertidor de protocolo) entre el dominio IPv6 y un dominio IPv4 adyacente también habrá recibido el mensaje ND y enviado un mensaje de respuesta, y el nuevo huésped tendrá una entrada especial implícita en la tabla ND que tenga su primera parte formada por 128 ceros (en las variantes, estos pueden ser todos unos) , y su segunda parte formada por la dirección MAC del dispositivo de interfaz . Por lo tanto, cuando un huésped nuevo desea enviar un mensaje a uno de los otros huéspedes en su dominio, construye un mensaje IPv6 y accesa su tabla ND para recuperar la dirección MAC asociada dentro de la dirección de destino. Después el mensaje es encapsulado dentro de un paquete de Ethernet de una manera conocida y es enviado vía el mecanismo de transporte de Ethernet subyacente al huésped de destino. Por otra parte, si el huésped construye un mensaje IPv6 que tiene su dirección de destino en forma de una dirección compatible con IPv4 o mapeada en IPv4, es decir, un mensaje diseñado para un huésped IPv4 en el dominio IPv4 adyacente, esta dirección de destino no se encontrará en la tabla ND. En esta situación, el algoritmo de acceso regresará la dirección MAC a la entrada implícita y el mensaje se enviará al convertidor de protocolo. Los convertidores de protocolo únicamente pueden convertir (o traducir) entre campos correspondientes de los encabezados de los mensajes IPv6 o IPv . Cuando un campo en el encabezador, por ejemplo, de un mensaje IPv6 no tiene un campo correspondiente en el encabezador de un mensaje IPv4 o viceversa, la información en ese campo se perderá en el proceso de conversión de protocolo. Como se mencionó en lo anterior, se conocen técnicas de encapsulado para habilitar a los huéspedes IPv6 para comunicarse entre si mismos cuando están en dominios separados en el espacio. En este caso, el dispositivo de interfaz contiene un mecanismo de encapsulado en vez de un convertidor de protocolo. Se apreciará que antes de ahora, para que un huésped IPv6 sea capaz de comunicarse tanto con huéspedes IPv4 como con huéspedes Ipv6 remotos, era necesario que para el huésped IPv6 y la interfaz de dominio fueran de apilamiento doble, es decir, que tuviera capacidad de comunicación tanto IPv4 como IPv6. Si un huésped IPv6 no tiene un apilamiento doble, su algoritmo de acceso regresará únicamente una dirección MAC única para la entrada implícita. Esta sería la dirección MAC del puerto de entrada de un convertidor de protocolo, si la administración de red ha decidido que el huésped IPv6 es capaz de comunicarse con los huéspedes IPv4, sería la dirección MAC del puerto de entrada de un mecanismo de encapsulado, si la administración de la red ha decidido que el huésped IPv6 es capaz de comunicarse con los huéspedes IPv6. La dirección MAC de entrada implícita no puede ser una dirección de entrada común para el convertidor de protocolo y el mecanismo de encapsulado . Ahora se describirán modalidades específicas de la presente invención con referencia a los dibujos, en los cuales: la figura 1 es un diagrama esquemático de un dominio IPv4 interconectado con dos dominios IPv6 aislados; la figura 2 es un diagrama esquemático de un ruteador de limite; la figura 3 es un diagrama esquemático de un mensaje de respuesta DNS de IPv6; la figura 4 es un diagrama esquemático de un mensaje de respuesta DNS IPv4 para conversión del mensaje de respuesta DNS IPv6 de la figura 3 ; la figura 5 es un diagrama esquemático de un mensaje de respuesta DNS IPv6 que resulta de la conversión del mensaje de respuesta DNS IPv4 de la figura 4; y la figura 6 es un diagrama esquemático que muestra el formato de las direcciones IPv6 especiales utilizadas con la técnica de conversión 6 a 4. En la figura 1, un dominio 10 de IPv4 separa un primer dominio 12 de IPv6, que se constituye de acuerdo con la presente invención como una primera red que opera de acuerdo con un primer protocolo de transmisión y que tiene direcciones de red de acuerdo con una primera convención de direccionamiento, desde un segundo dominio 14 IPv6, que se constituye de acuerdo con la presente invención como una tercera red que también opera de acuerdo con el primer protocolo de transmisión y que tiene direcciones de red de acuerdo con la primera convención de direcciones. Los huéspedes en el dominio IPv4 10 son únicamente IPv4, y los huéspedes en los dominios 12 y 14 IPv6, son únicamente IPv6. El dominio 10 IPv4 constituye, de acuerdo con la presente invención, una segunda red que opera de acuerdo con un segundo protocolo de transmisión y que tiene direcciones de red de acuerdo con una segunda convención de direccionamiento. Para simplificar los dibujos, no se muestran huéspedes IPv4, y en cada uno de los dominios 12 y 14 IPv6, únicamente se muestra un huésped IPv6 (28 y 30, respectivamente, a los que se hará referencia posteriormente) . El primer dominio 12 IPvß se conecta al dominio 10 IPv4 por medio de un ruteador de límite 16A, y el segundo dominio 14 IPv6 se conecta al dominio 10 IPv4 vía un ruteador de límite 16B. El ruteador de límite 16B es idéntico al ruteador de límite 16A, y cada uno constituye una interconexión. El dominio 10 IPv4 contiene un sistema 20 de nombre de dominio (DNS, por sus siglas en inglés) completo que incluye una pluralidad de servidores 22 DNS, de los cuales solo se muestran dos servidores DNS, 22A y 22B, y los dominios 12 y 14 de IPv6 contienen los servidores 24 y 26 DNS respectivos. Supóngase que un huésped 28 en el primer dominio 12 IPv6 desea enviar un paquete a un huésped 30 en el segundo dominio 14 IPv6. Por lo tanto, para esta transacción, el huésped 28 se denomina como el huésped 28 fuente y el huésped 30 se denomina como el huésped 30 de destino. El huésped 28 fuente conoce el nombre del huésped 30 de destino, de modo que construye de una manera conocida un mensaje de solicitud DNS IPv6 (no mostrado) que solicita la dirección IPv6 del huésped 30 de destino. El huésped 28 de fuente envía este mensaje de solicitud DNS como una solicitud recursiva a su servidor DNS local, el cual en esta modalidad es el servidor 24 DNS. El servidor 24 DNS, de una manera conocida, enviará un número de mensajes de solicitud DNS repetitivos (no mostrados) al DNS 20 hasta que aprenda acerca del servidor 26 DNS. Finalmente, el mensaje de solicitud DNS (no mostrado) avanzará hacia el servidor 26 DNS solicitando la dirección IPv6 del huésped 30 de destino. Conforme la solicitud DNS pasa del primer dominio 12 IPv6 a través del ruteador límite 16A al dominio 10 IPv4, se procesa por un convertidor de protocolo (PC) 32A (véase la figura 2) y experimenta una traducción IPv6/IPv4. De manera correspondiente, conforme la solicitud DNS pasa del dominio 10 IPv4 a través del ruteador de límite 16B al segundo dominio 14 IPv6, es procesado por un convertidor 32B de protocolo y experimenta una traducción IPv4/IPv6. Los convertidores de protocolo 32A y 32B se adaptan a una especificación conocida como traducción de dirección de red-traducción de protocolo (NAT-PT) . Traducen entre las direcciones IPv4 e IPv6 y mantienen un estado durante el tiempo de la sesión, y la traducción entre los mensajes de solicitud DNS IPv4 e IPv6 y los mensajes de respuesta de DNS, incluyendo la traducción de los encabezadores IP y la información útil DNS es controlada por una compuerta de capa de aplicación (ALG) . En la técnica, un término alternativo para un mensaje de respuesta DNS es un mensaje de respuesta DNS. Para información más detallada que pueda obtener el lector de la fuerza de tarea de ingeniería de internet (IETF) , se encuentra el documento como draft-ietf-ngtrans-natpt-05.txt, o cualquier variante del mismo, "Network Address Translation - Protocol Translation (NATPT) " , por G. Tsirtsis y P. Srishuresh. El servidor 26 DNS responde al mensaje de respuesta DNS para la dirección IPv6 del huésped 30 de destino con un mensaje 34 de respuesta DNS IPv6 (véase la figura 3) que tiene un formato convencional de campo 36 de dirección de destino, un campo 38 de dirección de fuente y un registro 40 de dirección de respuesta que contiene la dirección IPv6 del huésped 30 de destino.

- Si - Este mensaje 34 de respuesta DNS IPv6 se desplaza a través del segundo dominio 14 IPv6 al ruteador de límite 16B en donde se convierte en un mensaje 42 de respuesta DNS IPv4 (véase la figura 4) que comprende un campo 44 de dirección de destino, 5 un campo 46 de dirección de fuente, un registro 48 de dirección de respuesta y, de acuerdo con la presente invención, registros 50 y 52 adicionales, y este mensaje 42 se desplaza a través' del dominio 10 de IPv4 al ruteador límite 16A en donde se convierte en un mensaje 54 de respuesta de DNS IPv6 que comprende un campo 10 56 de dirección de destino, un campo 58 de dirección de fuente y un registro 60 de dirección de respuesta, y se envía al huésped 28 fuente. La ruta que toma el mensaje de respuesta DNS (en sus diversas formas, es decir, 34, 42 y 54) en los dominios 10, 12 y 14 depende de la configuración de DNS en cada uno de los 15 dominios, pero tendrá que pasar a través del ruteador límite 16B y del ruteador límite 16A, en ese orden. Por conveniencia, los términos "campo" y "registro" se utilizan de manera sinónima e intercambiable en esta descripción, aunque en la técnica, un campo generalmente se toma como una 20 parte constitutiva de un registro. Cuando el mensaje 34 de respuesta DNS IPv6 se recibe por el ruteador de límite 16B vía su controlador 62B de interfaz de red IPv6, es alimentado en paralelo al convertidor 32B de protocolo y a un controlador 64B, y también a un encapsulador 86B 25 y a un encapsulador 90B 6 a 4. El controlador 64B se conecta vía una línea 65A de control a las entradas de control del convertidor 32B de protocolo, el encapsulador 86B y el encapsulador 9OB 6 a 4 y al colocar una dirección adecuada en la línea 65A de control que selecciona uno de estos dispositivos apropiados . El controlador 64B (i) reconoce que el mensaje recibido es un mensaje de respuesta DNS y habilita al convertidor 32B de protocolo, (ii) recupera la dirección IPv6 del registro 40 de respuesta y escribe este mensaje a una posición 66B de almacenamiento formada por parte de su memoria 68B interna; (iii) escribe la dirección IPv4 del ruteador de límite 16B, es decir, la dirección IPv4 del punto final de terminación de encapsulado en el ruteador de límite 16B, a la posición 70B de almacenamiento formada también por parte de su memoria 68B interna; (iv) recibe del convertidor 32B de protocolo el mensaje 42 de respuesta DNS convertido; anexa el contenido de la posición 70B de almacenamiento como el primer registro 50 adicional, y el contenido de la posición 68B de almacenamiento del segundo registro 52 adicional; y (v) envía el mensaje 42 de respuesta DNS IPv4 resultante al controlador 72B de interfaz de red IPv4 para transmisión sobre el dominio 10 IPv4 al ruteador de límite 16A. En una variante, el mensaje 34 de respuesta DNS IPv6 recibido se alimenta únicamente al controlador 64B, el cual escribe este mensaje en una posición 74B de almacenamiento formado por parte de su memoria 68B interna. El controlador 64B después (i) recupera la dirección IPv6 del registro 40 de respuesta y escribe este mensaje en la posición 66B de almacenamiento; (ii) escribe la dirección IPv4 en el ruteador de límite 16B a la posición de almacenamiento 70B; (iii) genera un mensaje de respuesta DNS IPv6 modificado al recuperar el contenido de la posición 66B de almacenamiento y al anexar el contenido de la posición 70B de almacenamiento como el primer registro 50 adicional, y el contenido de la posición 66B de almacenamiento como el segundo registro 52 adicional; y (iv) envía este mensaje de respuesta DNS IPv6 modificado al convertidor 32B de protocolo. El ALG del convertidor 32 de protocolo procesa únicamente los encabezadores y registra la respuesta de dirección del mensaje de respuesta DNS para producir el mensaje 42 de respuesta DNS IPv4 resultante, es decir, permite que los registros adicionales permanezcan sin cambio. Se apreciará que la alimentación del mensaje recibido directamente al convertidor 32B de protocolo y el envío de una señal de habilitación en la línea 65A de control al convertidor 32B de protocolo por el controlador 64B, es equivalente, en términos lógicos, al envío del mensaje recibido al convertidor 32B de protocolo por el controlador 64B en la variante anterior, y constituye el envío del mensaje al convertidor 32B de protocolo, de acuerdo con la presente invención. Cuando el mensaje 42 de respuesta de DNS IPv4 se recibe por el ruteador de límite 16A vía su controlador 72A de interfaz de red IPv4, después se alimenta en paralelo al convertidor 32A de protocolo y al controlador 64A. El controlador 64A (i) recibe del convertidor 32A de protocolo la salida del mensaje de respuesta DNS IPv6 que comprende un campo 56 de dirección de destino, un campo 58 de dirección de fuente, un registro 60 de dirección de respuesta y registros 50, 52 adicionales; y ii) recupera las direcciones IPv6 del segundo registro 52 adicional, es decir, la verdadera dirección IPv6 del huésped 30 de destino, y la inserta en el registro 60 de dirección de respuesta de ese mensaje de salida en vez de la dirección IPv6 compatible con IPv4 para el huésped 30 de destino, el cual ha generado el convertidor 32A de protocolo. El controlador 64A después separa los registros 50, 52 adicionales y envía el mensaje 54 de respuesta DNS IPv6 resultante (véase la figura 5) a un controlador 62A de interfaz de red IPv6 del ruteador de límite 16A para transmisión al huésped 28 de fuente. De manera adicional, se arregla al controlador 64A para recuperar la dirección de IPv4 del punto final de terminación de encapsulado desde el primer registro 50 adicional, para crear un mapeado de la dirección IPv6 del huésped 30 de destino a las direcciones del punto final de terminación de encapsulado IPv4, y para almacenar este mapeo, es decir, crear una entrada, en una tabla 76A de punto final de IPv6/encapsulado formada, en parte, por una memoria interna 68A del controlador 64A y que constituye una tabla de búsqueda de la presente invención. En una variante, los registros adicionales 50, 52 son separados del mensaje de respuesta DNS antes de la recuperación de su contenido. En otra variante, los registros adicionales permanecen unidos al mensaje de respuesta DNS, pero esto no es tan eficiente como el separar los registros adicionales. En esta modalidad, cada entrada en la tabla 76A de punto final de IPv6/encapsulado comprende un primer elemento 78A que comprende la dirección IPV6 de un huésped 30 de destino correspondiente, un segundo elemento 80A que comprende la dirección IPv4 del punto final de terminación de encapsulado, es decir, el ruteador de límite 16B, y un tercero y cuarto elementos 82A y 84A, que se describirán posteriormente . Ante la recepción del mensaje 54 de respuesta DNS IPv6 resultante, el huésped 28 de fuente recupera la dirección IPv6 de su registro 60 de dirección y la almacena para uso en el envío de paquete de datos al huésped 30 de destino. De una manera conocida, el huésped 28 de fuente genera para cada uno de estos datos paquetes de un encabezador que incluye un campo de dirección de fuente y un campo de dirección de destino, y escribe la dirección IPv6 recuperada dentro del campo de dirección de destino. Ante la recepción de cada uno de estos paquetes de datos en el ruteador de límite 16A, el controlador 64A recupera la dirección de destino y, de acuerdo con la dirección de destino recuperada, accesa a la tabla 76A de punto final de IPvd/encapsulado. Si existe una coincidencia con el contenido de un primer elemento 78A de una entrada, el controlador 64A recupera el punto final de terminación de encapsulado IPv4 correspondiente del segundo elemento 80A de esa entrada, e instruye al encapsulador 86A para encápsular el paquete en un paquete IPv4. De esta manera, el encapsulador 86A anexa un encabezador IPv4 dentro del cual se ha insertado su propia dirección IPv4 dentro del campo de fuente, y la dirección de punto final de terminación de conversión IPv4 recuperada dentro del campo de destino. En esta modalidad, el encapsulador 86A almacena su propia dirección IPv4 para su uso. En las variantes, el controlador 64A almacena esta dirección IPv4, y la pasa, junto con las direcciones de punto final de terminación de encapsulado IPv4 recuperadas, al encapsulador 86A cuando lo instruye para realizar la encapsulación. En esta modalidad, el encapsulador 86A se arregla para recibir el paquete directamente del controlador 62A de interfaz de red IPv6 del ruteador de límite 16A, pero no realiza la encapsulación sino hasta que es instruido por el controlador 64A. En una variante, el controlador 64A recibe el paquete directamente del controlador 62A de interfaz de red IPv6 y lo pasa al encapsulador 86A, si existe una coincidencia. En la práctica, cuando el ruteador de límite 16A recibe un paquete, el controlador 64A lo escribe en una posición de almacenamiento de su memoria interna 68A y el controlador 64A pasará al encapsulador 86A la dirección de la posición de almacenamiento pertinente, junto con una instrucción para el encapsulador 86A para accesar esa posición de almacenamiento. Ante la recepción del paquete IPv4 encapsulante en el ruteador de límite 16B, un desencapsulador 88B del ruteador de límite 16B separa el encabezador IPv4 y recupera la información útil de ese paquete IPv4, es decir, desencapsula el paquete IPv6 original del huésped 28 fuente, y envía el paquete Ipv6 al huésped 30 de destino. El controlador 64B también genera un mapeo (en su tabla 76B de punto final de IPv6/encapsulado) de la dirección IPv6 del huésped 28 fuente y el punto final de origen del encapsulado, es decir, la dirección IPv4 del ruteador de límite 16A de origen, y este es recuperado respectivamente del campo de dirección de fuente del encabezador IPv6 y del campo de dirección de fuente del encabezador IPv4. Cuando el huésped 30 de destino regresa un paquete de respuesta, un controlador 64B del ruteador de límite 16B recupera la dirección de destino, "huésped 28 IPv6" del paquete de respuesta recibido, accesa su tabla 76B de punto final de IPv6/encapsulado, de acuerdo con la dirección de destino recuperada (es decir, busca un elemento de coincidencia 78B) , recupera la dirección IPv4 correspondiente (elemento 80B) e instruye al encapsulador 86B para encapsular el paquete de respuesta en un paquete IPv4 dirigido a un desencapsulador 88A del ruteador de límite 16A utilizando la dirección de punto final que se origina en el encapsulado IPv4 recién recuperada del elemento 80B de la tabla 76B de punto final de IPv6/encapsulado. Ante la recepción de este paquete IPv4 en el ruteador de límite 16A, el desencapsulador 88A realiza la desencapsulación para recuperar el paquete de respuesta, y el ruteador de límite 16A después envía el paquete de respuesta recuperado al huésped 28 de fuente . El huésped 28 de fuente y el huésped 30 de destino ahora están en una sesión en la cual los paquetes IPv6 pasan entre ellos vía en encapsulado recién establecido entre los ruteadores de límite 16A y 16B. El mecanismo descrito antes proporciona para un huésped IPv6, el cual está en un dominio IPv6 aislado, para comunicarse con otro huésped IPv6, el cual está en otro dominio IPv6 aislado, vía un dominio IPv4 intermedio, sin ningún conocimiento de si el otro huésped es IPv6, y sin que el huésped IPv6 fuente necesite nada diferente de un procedimiento de comunicación habitual con otro huésped IPv6 dentro de su propio dominio IPv6. El servidor DNS local para el huésped IPv6 fuente realiza una solicitud vía el dominio IPv4 al servidor DNS de IPv6 que está en la misma red, como el huésped IPv6 de destino, y los ruteadores de límite automáticamente establecen los mapeos respectivos asociando el punto final de túnel y la dirección IPv6 de los huéspedes IPv6 detrás de los ruteadores de límite. En modalidades alternativas, algunas de las entradas de la tabla 76A de punto final de IPv6/encapsulado se pueden generar por el personal administrativo del operador de red. Esto se conoce como una configuración manual de un encapsulado, y el encapsulado es permanente hasta que es cambiado en una fecha posterior por el personal administrativo. Como se muestra en la figura 2, el ruteador 16A de límite también comprende un encapsulador 90A de encapsulado 6 a 4 (y un desencapsulador 92A de encapsulado 6 a 4) y de esta manera puede trabajar, de manear conjunta con un ruteador de límite que este habilitado de manera similar, aunque en las variantes esto se puede omitir. Las direcciones 94 IPv6 especiales (véase la figura 6) utilizada para esta técnica tiene un formato de tres partes de la cual una primera parte 96 tiene 32 bitios el cual es un prefijo que identifica de manera única que el paquete va a ser encapsulado por la técnica de encapsulado 6 a 4, una segunda parte 98 que tiene 32 bitios es la dirección IPv4 al punto final del túnel 6 a 4, y la tercera parte 100 tiene 64 bitios y se conoce como la ID de interfaz, la cual es una dirección MAC modificada del huésped de destino. La segunda parte 98 constituye un campo de subdirección determinado previamente de la dirección de destino de la presente invención.

En las variantes que tienen un encapsulador de encapsulado diferente, se utiliza un prefijo respectivo diferente para el mismo propósito. En algunas variantes de estas modalidades, el controlador 64A se arregla para reconocer la presencia de este prefijo dentro de las direcciones de destino recuperadas de un paquete recibido, para recuperar desde su segunda parte 98 la dirección IPv4 del punto final de encapsulado 6 a 4 y para instruir al encapsulador 90A de encapsulado 6 a 4 para manejar el paquete recibido utilizando la dirección IPv4 recuperada. Esto constituye derivar la dirección al segundo tipo directamente. De manera alternativa, el encapsulador 90A de encapsulado 6 a 4 se arregla para recuperar la dirección IPv6 especial y extraer de su segunda parte 98 la dirección IPv4 del punto final de encapsulado 6 a 4. Como se menciona en lo anterior, cuando el controlador 64A se arregla para llevar a cabo reconocimiento del prefijo, el prefijo que se va a reconocer se almacena en una posición de almacenamiento de su memoria interna 68A y esta posición de almacenamiento puede ser cualquier entrada o parte de una entrada de la tabla 76A de punto final de IPv6/encapsulado. Los desencapsuladores 88B y 92B tienen direcciones IPv4 respectivas, las cuales se utilizan por los encapsuladores correspondientes 86A y 90A para generar sus paquetes encapsulados respectivos.

En el arreglo preferido del ruteador de límite que tiene una pluralidad de encapsuladores diferentes, por ejemplo 86, 90, el controlador 64A accesa a la tabla 76A de punto final de IPv6/encapsulado de acuerdo con un conjunto de criterios de coincidencia para cubrir el intervalo de posibles situaciones, estas son: a) un encapsulado que se ha establecido de antemano por la técnica de solicitud DNS descrita en lo anterior y existe una entrada IPv6/IPv4 específica de destino para IPv6 en la tabla 76A de punto final de IPv6/encapsulado; b) ya se ha establecido un encapsulado por una de las técnicas de encapsulado conocidas y existe una entrada IPv6/IPv4 en la tabla 76A de punto final de IPv6/encapsulado de la cual el primer elemento 78A tiene una primera parte en forma de un prefijo específico que corresponde a esa técnica de encapsulado; c) el personal de administración de red ha configurado manualmente el ruteador de límite 16 para definir un encapsulado para un huésped de destino IPv6 específico utilizando 6 a 4 (o 6 sobre 4) u otro ruteador de límite (el cual puede ser un ruteador de límite 16B o un ruteador de límite diferente (no mostrado) asociado con un dominio IPv6 adicional (no mostrado) ) y para este caso, la tabla 76A de punto final de IPv6/encapsulado tiene una entrada cuyo primer elemento 78A es la dirección compatible con IPv4 (o mapeada por IPv4) de ese huésped de destino; d) el personal de administración de red ha configurado manualmente el ruteador de límite 16A para definir un encapsulado a huéspedes de destino IPv6 no especificados utilizando un ruteador de límite 6 a 4 (o 6 sobre 4) u otro ruteador de límite diferente (el cual puede ser un ruteador de límite 16B o un ruteador de límite diferente asociado con un dominio IPv6 adicional, y para este caso, la tabla 76A de punto final de IPv6/túnel tiene una entrada que tiene su primer elemento 78A en forma de un prefijo 6 a 4 o 6 sobre 4) seguido por la dirección IPv4 de ese otro bloqueador de límite, seguido por caracteres nulos y en algunas variantes, el segundo elemento 80A de esta entrada contiene caracteres nulos, mientras que en otras variantes adicionales, el segundo elemento 80A de esta entrada contiene la dirección IPv4 de ese otro ruteador de límite; y e) una tabla que contiene una entrada cuyo primer elemento 78A es una dirección IPv6 compatible con IPv4 o mapeada por IPv4, genérica, es decir, sus primeros 80 bitios son todos cero y los 32 bitios finales (o, en una variante, 48) son caracteres nulos (ceros) , el segundo y cuarto elementos 80A y 84A contienen caracteres nulos, y un tercer elemento 82A contiene el identificador "PC". El controlador 64A utiliza su tabla 76A de punto final de IPv6/encapsulado para determinar el manejo apropiado del paquete recibido de la siguiente manera.

Si el controlador 64A envía una entrada que tiene un primer elemento 78A que coincide con la dirección de destino recuperada completa, entonces el contenido del segundo elemento 80A de esa entrada se recupera y se utiliza como la dirección de destino IPv4, es decir, la del ruteador de límite 16B, el punto final del encapsulado. Adicionalmente, el contenido del tercer elemento 82A de esa entrada se recupera y se utiliza como una verificación de que la dirección de destino IPv4 recuperada y el paquete recibido por el ruteador de límite 16A se van a procesar por el encapsulador 86A. El contenido del tercer elemento 82A es un identificador para un encapsulador 86A, 90A (por ejemplo "EN"), o un identificador para el convertidor de protocolo 32A (por ejemplo, "PC") . Como una verificación adicional, el cuarto elemento 82A de esa entrada contiene un identificador para el tipo de encapsulación. En otras palabras, para una entrada que coincide con la dirección de destino recuperada completa, . como se acaba de describir, el identificador de tipo de encapsulación será "DNS" para significar que se va a utilizar el encapsulador 86A. Si el controlador 64A encuentra que cualquier entrada cuyo primer elemento 78A tiene primeros 32 bitios que coinciden con los primeros 32 bitios, es decir, la parte de prefijo especial 6 a 4 de la dirección de destino recuperada, entonces se verifican el tercero y cuarto elementos 82A y 84A de esa entrada ("EN" y "6 a 4", respectivamente), se recuperan la dirección de destino IPv4 del segundo elemento 80A de esa entrada y se envía con el paquete recibido por el ruteador de límite 16A que se va a procesar por el encapsulador 90A. Esto constituye la recuperación indirecta de la dirección del segundo tipo a partir 5 de un campo de subdirección predeterminado de la dirección de destino. Si la dirección de destino recuperada es compatible con IPv4 o mapeada por IPv4, es decir, el paquete va a ser convertido en cuanto a protocolo para un destino IPv4, entonces sus primero 10 80 bitios serán todos cero, y los siguientes 16 bitios serán todos ceros si la dirección es compatible con IPv4, o todos serán unos si la dirección está mapeada por IPv4. Por lo tanto, el controlador 64A verifica para buscar si la tabla 76A de punto final de IPv6/encapsulado contiene una entrada cuyo primer 15 elemento 78A tenga sus primeros 80 bitios todos ceros. El contenido del segundo elemento 80A de tal entrada serán caracteres nulos, debido a que no está involucrado encapsulado, y el contenido del cuarto elemento 84A de tal entrada serán todos caracteres nulos, debido a que no este involucrada encapsulación. 20 El contenido del tercer elemento 82A de esa entrada se recupera y se utiliza como una verificación de que la dirección de destino IPv4 recuperada y el paquete recibido por el ruteador de límite 16A van a ser procesados por el convertidor de protocolo 32A. En este caso, el contenido del tercer elemento 82A es un identificador para el convertidor de protocolo 32A (por ejemplo "PC") . En otras variantes, el controlador 64A se coloca para tener acceso a la tabla 76A de punto final de IPv6/encapsulado, como en lo anterior, y únicamente es instruida por el encapsulador 90A de encapsulado 6 a 4 ante la detección de una coincidencia con una entrada, y en este caso el controlador 64A pasa la dirección IPv6 especial al encapsulador 90A de encapsulado 6 a 4, o alternativamente el controlador 64A extrae la dirección IPv4 al punto final del encapsulado 6 a 4 y lo hace pasar al encapsulador 82A de encapsulado 6 a 4, o nuevamente al controlador 64A, ante la detección de tal coincidencia, recupera el elemento 80A de la entrada coincidente. Este elemento 80A contiene la dirección IPv4 del punto final de túnel 6 a 4, el cual sea insertado dentro de ese elemento 80A por el controlador (o bien manualmente) ante la creación de esa entrada. En la modalidad anterior, el servidor DNS local para el huésped 28 fuente es el servidor 24 DNS IPv6, pero pueden existir modalidades alternativas de los servidores 22 IPv4 del DNS 20. En tales modalidades alternativas, aunque el huésped 28 puede enviar un mensaje de solicitud de DNS para obtener la dirección IPv6 del huésped 30 y, por la presente invención, establecer un encapsulado a través del dominio 10 IPv4, la situación no es simétrica en la medida en que el huésped 30 no puede actuar como una fuente y establecer un túnel correspondiente a través del dominio 10 de IPv4 al huésped 28. Para que un huésped IPv6 pueda ser susceptible de contacto, es decir, actuar como un destino, por el método de la presente invención, es necesario que el servidor DNS local para ese huésped IPv6 sea un servidor DNS IPv6 en el mismo dominio IPv6 que el huésped IPv6, debido a que el mensaje de respuesta DNS debe pasar a través del ruteador de límite adyacente a ese huésped IPv6 con el fin de que se puede establecer en encapsulado. En otras palabras, el mensaje de solicitud DNS debe pasar a través del dominio IPv4 y no detenerse en un servidor DNS IPv4 que actúa como el servidor DNS local para el destino propuesto del huésped IPv6.

Claims (21)

REIVINDICACIONES

1. Una interfaz para uso entre una primera red que opera de acuerdo con primer protocolo de transmisión y que tiene direcciones de red de acuerdo con un primer convención de direccionamiento, denominado en la presente como dirección del primer tipo, y una segunda red que opera de acuerdo con un segundo protocolo de transmisión y que tiene direcciones de red de acuerdo con una segunda convención de direccionamiento, denominado en la presente como direcciones del segundo tipo, la interfaz tiene direcciones del primer tipo y direcciones del segundo tipo, y que comprende: un convertidor de protocolo arreglado para convertir un mensaje que tiene un formato de acuerdo con un primer protocolo de transmisión, denominado en la presente como un mensaje del primer tipo, en un mensaje que tiene un formato de acuerdo con el segundo protocolo de transmisión, denominado en la presente como mensaje del segundo tipo; un medio para encapsulamiento arreglado para que responda a la recepción de una dirección del segundo tipo junto con un mensaje del primer tipo al encapsular el mensaje recibido del primer tipo como la información útil del mensaje de segundo tipo encapsulante resultante, utilizando la dirección de segundo tipo recibida como la dirección de destino del mensaje de segundo tipo encapsulante resultante y utilizando la dirección de segundo tipo de la interfaz como la fuente de dirección del mensaje de segundo tipo encapsulante resultante; y un controlador de interfaz arreglado para responder a la recepción por la interfaz de un mensaje del primer tipo de la primera red al : examinar la dirección de destino del mensaje de primer tipo recibida de la primera red para determinar si el mensaje de primer tipo es de un formato predeterminado, y de ser así, enviar el convertidor de protocolo de que el mensaje del primer tipo recibido de la primera red, de otra manera, derivar, directa o indirectamente, de la dirección de destino del mensaje del primer tipo, una dirección del segundo tipo para uso por el medio de encapsulamiento, y enviar al medio de encapsulamiento la dirección de segundo tipo derivada, junto con el mensaje del primer tipo recibido de la primera red.

2. La interfaz, como se reivindica en la reivindicación 1, en donde el controlador se arregla para derivar la dirección de segundo tipo directamente al recuperarla de un campo de subdirección determinado previamente de la dirección de destino.

3. La interfaz, como se reivindica en la reivindicación 1, en donde el controlador se arregla para derivar la dirección de segundo tipo directamente al accesar, de acuerdo con la dirección de destino, una tabla de búsqueda que tiene entradas en forma de una dirección de primer tipo asociada con una dirección del segundo tipo, y recuperar la dirección del segundo tipo de una entrada que tiene una dirección del primer tipo que coincide con la dirección de destino.

4. La interfaz, como se reivindica en la reivindicación 3 , en donde cada entrada de la tabla de búsqueda comprende un campo que contiene un identificador para identificar si el controlador va a enviar un mensaje del primer tipo recibido de la primera red al convertidor de protocolo o al medio de encapsulado .

5. La interfaz, como se reivindica cualquiera de las reivindicaciones 1 a 4, en donde el medio de encapsulado comprende una pluralidad de encapsuladores diferentes, cada encapsulador está arreglado para operar de acuerdo con un tipo de encapsulación respectivo y el controlador está arreglado para enviar el mensaje del primer tipo recibido de la primera red a uno apropiado de la pluralidad de encapsuladores diferentes que dependen del formato de la dirección de destino del mensaje del primer tipo.

6. La interfaz, como se reivindica en la reivindicación 5, cuando depende de la reivindicación 3 o la reivindicación 4, en donde cada entrada de la tabla de búsqueda comprende un campo para contener un identificador para identificar un tipo de encapsulacidn.

7. La interfaz, como se reivindica en cualquiera de las reivindicaciones precedentes, que incluye además un medio para desencapsular un mensaje de segundo tipo encapsulado para recuperar su información útil.

8. La interfaz, como se reivindica en cualquiera de las reivindicaciones precedentes, en donde el protocolo convertidor se arregla adicionalmente para convertir un mensaje del segundo tipo en un mensaje del primer tipo.

9. Un método para operar una interfaz entre una primera red y una segunda red, la primera red tiene direcciones de red de acuerdo con una primera convención de direccionamiento, denominada en la presente como dirección del primer tipo, y transmitir mensajes de acuerdo con un primer protocolo de transmisión, denominado en la presente como mensajes del primer tipo, y una segunda red que tiene direcciones de red de acuerdo con una segunda convención de dirección, denominada en la presente como direcciones del segundo tipo, y transmitir mensajes de acuerdo con un segundo protocolo de transmisión, denominado en la presente como mensajes del segundo tipo, el método comprende las etapas de: examinar la dirección de destino del mensaje de primer tipo recibida de la primera red; y si la dirección de destino de ese mensaje de primer tipo recibido es de un primer formato determinado previamente, el protocolo convierte el mensaje de primer tipo recibido; de otra manera, encapsula el mensaje recibido del primer tipo, de acuerdo con el segundo protocolo de transmisión utilizando, como la dirección de destino del mensaje de segundo tipo encapsulado resultante, una dirección ,de segundo tipo derivada directa o indirectamente de la dirección de destino del mensaje de primer tipo recibido.

10. Un método para operar una interfaz entre una primera red y una segunda red, la primera red tiene direcciones de red de acuerdo con una primera convención de direccionamiento, denominada en la presente como dirección del primer tipo, y transmitir mensajes de acuerdo con un primer protocolo de transmisión, denominado en la presente como mensajes del primer tipo, y una segunda red que tiene direcciones de red de acuerdo con una segunda convención de dirección, denominada en la presente como direcciones del segundo tipo, y transmitir mensajes de acuerdo con un segundo protocolo de transmisión, denominado en la presente como mensajes del segundo tipo, el método comprende las etapas de: examinar la dirección de destino del mensaje de primer tipo recibida de la primera red; y si la dirección de destino de ese mensaje de primer tipo recibido es de un primer formato determinado previamente, el protocolo convierte el mensaje de primer tipo recibido; y si la dirección de destino de ese mensaje de primer tipo recibido es de un segundo formato determinado previamente, encapsular el mensaje de primer tipo, recibido de acuerdo con el segundo protocolo de transmisión utilizando, como la dirección de destino de un mensaje de segundo tipo encapsulante resultante, una dirección del segundo tipo derivada, directa o indirectamente, de la dirección de destino de ese mensaje del primer tipo recibido.

11. El método, como se reivindica en la reivindicación 10, en donde el segundo formato de dirección determinado previamente incluye un identificador que identifica un tipo de encapsulación.

12. Un método, como se reivindica en cualquiera de las reivindicaciones 9 ó 10, en donde el primer formato determinado previamente incluye una primera porción determinada previamente cuyo contenido identifica al mensaje del primer tipo recibido como adecuado para protocolo de conversión.

13. El método, como se reivindica en la reivindicación 12, en donde el primer "formato determinado previamente también incluye una segunda porción determinada previamente cuyo contenido, constituye la dirección del segundo tipo utilizada como la dirección de destino de un mensaje del segundo tipo encapsulado resultante .

,14. El método, como se reivindica en cualquiera de las reivindicaciones 9 a 13, en donde la dirección del segundo tipo se deriva directamente al recuperarla de un campo de subdirección determinado previamente de la dirección de destino.

15. El método, como se reivindica en cualquiera de las reivindicaciones 9 a 14 , en donde la etapa de examen comprende las subetapas de recuperar la dirección de destino del mensaje de primer tipo recibida, y accesar una tabla de búsqueda de acuerdo con la dirección de destino recuperada.

16. El método, como se reivindica en la reivindicación 15, para uso cuando la tabla de búsqueda comprende entradas en forma de una dirección de primer tipo asociada con una dirección del segundo tipo, y en donde la recuperación de la dirección de segundo tipo de una entrada que tiene su dirección de primer tipo que coincide con la dirección de destino constituye derivar indirectamente la dirección de segundo tipo a partir de la dirección de destino de ese mensaje de primer tipo recibido.

17. El método, como se reivindica en la reivindicación 16, para uso cuando las entradas de la tabla de búsqueda incluyen un primer campo identificador que contiene un identificador que identifica si el mensaje del primer tipo va a ser convertido por protocolo o encapsulado, y que incluye las etapas de recuperar el identificador del primer campo identificador de la entrada que tiene su dirección del primer tipo que coincide con la dirección c. de destino, y verificar que el identificador recuperado es consistente con cualquiera del protocolo de conversión o encapsulación que se va a realizar ante ese mensaje de primer tipo recibido.

18. El método, como se reivindica ya sea en la reivindicación 16 o en la reivindicación 17, para uso cuando las entradas de la tabla de búsqueda incluyen un segundo campo identificador que contiene un identificador que identifica un tipo de encapsulación, y en donde existe una pluralidad de tipos de encapsulación disponibles, y que incluye las etapas de recuperar el identificador del segundo campo identificador de la entrada que tiene su dirección del primer tipo que coincide con la dirección de destino, y verificar que el identificador recuperado es consistente con el tipo de encapsulación que se va a realizar ante el mensaje de primer tipo recibido.

19. Una interfaz para uso entre una primera red que opera de acuerdo con un primer protocolo de transmisión y que tiene direcciones de red de acuerdo con una primera convención de direccionamiento, y una segunda red que opera de acuerdo con un segundo protocolo de transmisión y que tiene una dirección de red de acuerdo con una segunda convención de direccionamiento, la interfaz es sustancialmente como se describe en la presente con referencia a los dibujos.

20. Un método para operar una interfaz entre una primera red que opera de acuerdo con un primer protocolo de transmisión y que tiene direcciones de red de acuerdo con una primera convención de direccionamiento, y una _ segunda red que opera de acuerdo con un segundo protocolo de transmisión y que tiene segundas direcciones de acuerdo con una segunda convención de direccionamiento, el método es sustancialmente como se describe en la presente con referencia a los dibujos.

21. Una interfaz para uso entre una primera red y una segunda red, la primera red tiene direcciones de red de acuerdo con una primera convención de direccionamiento, denominada en la presente como direcciones del primer tipo, y que transmiten mensajes de acuerdo con un primer protocolo de transmisión, denominado en la presente como mensajes del primer tipo, y la segunda red tiene direcciones de red de acuerdo con una segunda convención de direccionamiento, denominada en la presente como direcciones del segundo tipo, y que transmite mensajes de acuerdo con un segundo protocolo de transmisión, denominado en la presente como mensajes del segundo tipo, la interfaz comprende: un medio para examinar la dirección de destino de un mensaje de primer tipo recibido en el aparato de interfaz desde la primera red para determinar si la dirección de destino de ese mensaje de primer tipo recibido es de un primer formato determinado previamente; un convertidor de protocolo que responde a una determinación del medio de examen de que la dirección de destino 5 del mensaje de primer tipo recibido es de un primer formato determinado previamente para convertir ese mensaje del primer tipo recibido; y un medio para encapsular que responde a una determinación de un medio de examen de que la dirección de destino de ese mensaje de primer tipo recibido no es de un primer 10 formato determinado previamente para encapsular el mensaje de primer tipo recibido de acuerdo con el segundo protocolo de transmisión utilizando como la dirección de destino de un mensaje de segundo tipo encapsulante resultante, una dirección de segundo tipo derivada, directa o indirectamente, de la dirección de 15 destino de ese mensaje del primer tipo recibido. f ) RESUMEN Un método para interconectar y una interfase por un dominio IPv4. La interfase comprende un convertidor del protocolo un encapsulador/desencapsulador y un controlador. Cuando una fuente IPv6 desea enviar a un destino nombrado en el otro dominio IPv6, al fuente envía una dirección IPv6 normal solicitada al servidor DNS local, el cual lo releva a un servidor de nombre IPv6 en el otro dominio IPv6. El mensaje de respuesta que contiene la dirección IPv6 verdadera del destino, es recibido en la interfase remota, que se anexa al mensaje de respuesta DNS convertido del protocolo que resulta un primer registro adicional que contiene la dirección IPv6 verdadera y un segundo registro adicional que contiene la dirección IPv4 de esa interfase. Al recibirse en la otra interfase, los registros adicionales son eliminados y sus contenidos almacenados en una entrada de una tabla y la dirección IPv6 verdadera escrita en el registro de dirección del mensaje de respuesta DNS IPv6 que resulta. Cuando la interfase recibe un paquete de un huésped IPv6, checa si la dirección de destino acopla con la entrada de la tabla y si es así envía el paquete al encapsulador junto con la dirección IPv4 de la interfase remota. La interfase remota extrae la dirección de la fuente y la dirección de la interfase de encapsulación y las almacena en una entrada en su tabla correspondiente para emplearse en encapsular los paquetes que regresen a la fuente. Sin embargo, si se reconoce la dirección de destino como formato IPv4 mapeado, el paquete es enviado a un convertidor de 5 protocolo. ' )