Capítulo 11 IPv6 en profundidad (referencia)

Este capítulo proporciona la siguiente información de referencia relativa a la implementación de IPv6 en Oracle Solaris 10.

• Formatos de direcciones IPv6 que no son los básicos

• Formato del encabezado de los paquetes de IPv6

• Protocolos de pila doble

• Implementación de IPv6 en Oracle Solaris 10

• Protocolo ND de IPv6

• Encaminamiento de IPv6

• Túneles de IPv6

• Extensiones de IPv6 para servicios de nombres de Oracle Solaris

• Admisión de NFS y RPC IPv6

• Admisión de IPv6 en ATM

Para obtener una descripción general de los conceptos relativos a IPv6, consulte el Capítulo 3Introducción a IPv6 (descripción general). Para obtener información sobre tareas relativas a la configuración de redes habilitadas para IPv6, consulte el Capítulo 7Configuración de una red IPv6 (tareas)..

Novedades de IPv6 en profundidad

En Solaris 10 7/07, el archivo /etc/inet/ipnodes pasa a estar obsoleto. Utilice /etc/inet/ipnodes únicamente para las versiones anteriores de Oracle Solaris 10, tal como se explica en los procedimientos individuales.

Formatos de direcciones IPv6 que no son los básicos

El Capítulo 3Introducción a IPv6 (descripción general), presenta los formatos más comunes de direcciones IPv6: direcciones de sitios unidifusión y direcciones locales de vínculo. Esta sección proporciona descripciones pormenorizadas de formatos de direcciones que se tratan de manera general en el Capítulo 3Introducción a IPv6 (descripción general):

• Direcciones 6to4 derivadas

• Direcciones multidifusión IPv6 en profundidad

Direcciones 6to4 derivadas

Si tiene previsto configurar un túnel de 6to4 desde un punto final de enrutador o host, el prefijo de sitio de 6to4 se debe anunciar en el archivo /etc/inet/ndpd.conf del sistema de puntos finales. Para obtener una introducción e información sobre tareas relativas a la configuración de túneles de 6to4, consulte Cómo configurar un túnel 6to4.

La figura siguiente ilustra las partes que conforman un prefijo de sitio de 6to4.

Figura 11–1 Partes de un prefijo de sitio de 6to4

La figura siguiente ilustra las distintas partes de un prefijo de subred de un sitio de 6to4, de la forma que se incluiría en el archivo ndpd.conf.

Figura 11–2 Partes de un prefijo de subred de 6to4

Esta tabla explica las partes que componen un prefijo de subred de 6to4, y sus respectivas longitudes y definiciones.

Direcciones 6to4 derivadas en un host

Cuando un host de IPv6 recibe el prefijo de 6to4 derivado mediante un anuncio de enrutador, de forma automática el host vuelve a configurar una dirección 6to4 derivada en una interfaz. La dirección tiene el formato siguiente:

prefix:IPv4-address:subnet-ID:interface-ID/64

La salida del comando ifconfig -a en un host con una interfaz de 6to4 tiene un aspecto similar al siguiente:

qfe1:3: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6>
 mtu 1500 index 7
        inet6 2002:8192:56bb:9258:a00:20ff:fea9:4521/64 

En esta salida, la dirección 6to4 derivada sigue a inet6.

Esta tabla explica las partes de la dirección derivada 6to4, sus longitudes y la información que proporcionan.

Direcciones multidifusión IPv6 en profundidad

La dirección multidifusión IPv6 brinda un método para distribuir los mismos servicios o información a un grupo de interfaces establecido, denominado grupo de multidifusión. En general, las interfaces del grupo de multidifusión se encuentran en distintos nodos. Una interfaz puede pertenecer a cualquier cantidad de grupos de multidifusión. Los paquetes que se envían al grupo de multidifusión van a parar a todos los miembros del grupo. Uno de los usos de las direcciones multidifusión consiste en transmitir información, equivalente a la capacidad de la dirección de transmisión IPv4.

En la tabla siguiente se muestra el formato de la dirección multidifusión.

A continuación se resume el contenido de cada campo.

• 11111111: identifica la dirección como dirección multidifusión.

• FLGS: conjunto de los cuatro indicadores 0,0,P,T. Los dos primeros deben ser cero. El campo P tiene uno de los valores siguientes:

  • 0 = Dirección multidifusión que no se asigna en función del prefijo de red

  • 1 = Dirección multidifusión que se asigna en función del prefijo de red

  Si P se establece en 1, T debe ser también 1.

• Reservado: valor reservado de cero.

• Plen: cantidad de bits del prefijo de sitio que identifican la subred, para una dirección multidifusión que se asigna a partir de un prefijo de sitio.

• ID de grupo: identificador del grupo de multidifusión, ya sea permanente o dinámico.

Para obtener información detallada sobre el formato multidifusión, consulte RFC 3306, Unicast-Prefix-based IPv6 Multicast Addresses.

Determinadas direcciones multidifusión IPv6 son asignadas permanentemente por la IANA (Internet Assigned Numbers Authority). Ejemplos son las direcciones multidifusión de todos los nodos y todos los enrutadores multidifusión que necesitan todos los hosts y enrutadores de IPv6. Las direcciones multidifusión IPv6 también se pueden asignar dinámicamente. Para obtener más información sobre el uso adecuado de grupos y direcciones multidifusión, consulte RFC 3307, Allocation Guidelines for IPv 6 Multicast Addresses.

Formato del encabezado de los paquetes de IPv6

El protocolo IPv6 define un conjunto de encabezados, que se dividen en básicos y de extensión. La figura siguiente ilustra los campos que tiene un encabezado de IPv6 y el orden en que aparecen.

Figura 11–3 Formato de encabezado básico de IPv6

En la lista siguiente se describe la función de cada campo de encabezado.

• Versión: número de versión de 4 bits del protocolo de Internet = 6.

• Clase de tráfico: campo de clase de tráfico de 8 bits.

• Etiqueta de flujo: campo de 20 bits.

• Tamaño de carga útil: entero sin signo de 16 bits, que representa el resto del paquete que sigue al encabezado de IPv6, en octetos.

• Encabezado siguiente: selector de 8 bits. Identifica el tipo de encabezado que va inmediatamente después del encabezado de IPv6. Emplea los mismos valores que el campo de protocolo IPv4.

• Límite de salto: entero sin signo de 8 bits. Disminuye en uno cada nodo que reenvía el paquete. El paquete se desecha si el límite de salto se reduce a cero.

• Dirección de origen: 128 bits. Dirección del remitente inicial del paquete.

• Dirección de destino: 128 bits. Dirección del destinatario previsto del paquete. El destinatario previsto no es necesariamente el destinatario si existe un encabezado de enrutamiento opcional.

Encabezados de extensión de IPv6

Las opciones de IPv6 se colocan en encabezados de extensión independientes que se ubican entre el encabezado de IPv6 y el encabezado de capa de transporte de un paquete. Ningún enrutador procesa ni examina la mayoría de los encabezados de extensión de IPv6 durante el recorrido de distribución del paquete hasta que éste llega a su destino. Esta función supone una mejora importante en el rendimiento de los enrutadores en paquetes que contienen opciones. En IPv4, la presencia de cualquier opción hace que el enrutador examine todas las opciones.

A diferencia de las opciones de IPv4, los encabezados de extensión de IPv6 pueden tener un tamaño arbitrario. Asimismo, la cantidad de opciones que lleva un paquete no se limita a 40 bytes. Aparte de la forma de procesar las opciones de IPv6, esta función permite que las opciones de IPv6 se apliquen a funciones que no resultan viables en IPv4.

Para mejorar el rendimiento al controlar los encabezados de opciones subsiguientes, así como el protocolo de transporte que va después, las opciones de IPv6 siempre son un múltiplo entero de 8 octetos. El múltiplo entero de 8 octetos mantiene la alineación de los encabezados subsiguientes.

Hay definidos los siguientes encabezados de extensión de IPv6:

• Encaminamiento: enrutamiento extendido, por ejemplo ruta holgada fijada en origen de IPv4

• Fragmentación: fragmentación y montaje

• Autenticación: integridad y autenticación, y seguridad

• Encapsulado de carga útil: confidencialidad

• Opciones de salto a salto: opciones especiales que necesitan procesamiento salto a salto

• Opciones de destino: información opcional que el nodo de destino debe examinar

Protocolos de pila doble

En general, el término pila doble se refiere a una duplicación completa de todos los niveles de la pila de protocolos de aplicaciones en la capa de red. Un ejemplo de duplicación completa es un sistema que ejecuta los protocolos OSI y TCP/IP.

Oracle Solaris es un entorno de doble pila: implementa tanto el protocolo IPv4 como el IPv6. Al instalar el sistema operativo, se elige entre habilitar los protocolos IPv6 en la capa de IP o utilizar únicamente los protocolos IPv4 predeterminados. El resto de la pila TCP/IP es idéntica. Por lo tanto, en IPv4 e IPv6 pueden ejecutarse los mismos protocolos de transporte, TCP UDP y SCTP. Además, se pueden ejecutar las mismas aplicaciones. La Figura 11–4 ilustra el funcionamiento de los protocolos IPv4 e IPv6 como pila doble en las distintas capas del conjunto de protocolos de Internet.

Figura 11–4 Arquitectura de protocolos de pila doble

En el caso hipotético de pila doble, los subconjuntos de enrutadores y hosts se actualizan para admitir IPv6, además de IPv4. Con este planteamiento de pila doble, los nodos actualizados siempre pueden interoperar con nodos que son sólo de IPv4 mediante IPv4.

Implementación de IPv6 en Oracle Solaris 10

Esta sección describe los archivos, comandos y daemons que habilitan IPv6 en Oracle Solaris.

Archivos de configuración de IPv6

Esta sección describe los archivos de configuración que forman parte de una implementación de IPv6:

• Archivo de configuración ndpd.conf

• Archivo de configuración de interfaces de IPv6

• Archivo de configuración /etc/inet/ipaddrsel.conf

Archivo de configuración ndpd.conf

El archivo /etc/inet/ndpd.conf se utiliza para configurar opciones empleadas por el daemon del protocolo ND in.ndpd. En el caso de un enrutador, ndpd.conf se utiliza sobre todo para configurar el prefijo de sitio que se debe anunciar en el vínculo. En lo que respecta a un host, ndpd.conf se usa para desactivar la configuración automática de redes o para configurar direcciones temporales.

La tabla siguiente muestra las palabras clave que se utilizan en el archivo ndpd.conf.

En el archivo ndpd.conf, las palabras clave de esta tabla se usan con un conjunto de variables de configuración de enrutador. Puede encontrar una definición detallada de estas variables en RFC 2461, Neighbor Discovery for IP Version 6 (IPv6).

En la siguiente tabla aparecen las variables necesarias para configurar una interfaz, junto con breves definiciones.

En la siguiente tabla se muestran las variables que se utilizan para configurar prefijos IPv6.

Ejemplo 11–1 Archivo /etc/inet/ndpd.conf

En el ejemplo siguiente se muestra el modo de utilizar las palabras clave y las variables de configuración en el archivo ndpd.conf. Elimine el comentario (#) para activar la variable.

# ifdefault      [variable-value ]*
# prefixdefault [variable-value ]*
# if ifname   [variable-value ]*
# prefix prefix/length ifname
#
#  Per interface configuration variables
#
#DupAddrDetectTransmits
#AdvSendAdvertisements
#MaxRtrAdvInterval
#MinRtrAdvInterval
#AdvManagedFlag
#AdvOtherConfigFlag
#AdvLinkMTU
#AdvReachableTime
#AdvRetransTimer
#AdvCurHopLimit
#AdvDefaultLifetime
#
# Per Prefix:  AdvPrefixList configuration variables
#
#
#AdvValidLifetime
#AdvOnLinkFlag
#AdvPreferredLifetime
#AdvAutonomousFlag
#AdvValidExpiration
#AdvPreferredExpiration

ifdefault AdvReachableTime 30000 AdvRetransTimer 2000
prefixdefault AdvValidLifetime 240m AdvPreferredLifetime 120m

if qe0 AdvSendAdvertisements 1
prefix 2:0:0:56::/64 qe0
prefix fec0:0:0:56::/64 qe0

if qe1 AdvSendAdvertisements 1
prefix 2:0:0:55::/64 qe1
prefix fec0:0:0:56::/64 qe1

if hme1 AdvSendAdvertisements 1
prefix  2002:8192:56bb:1::/64 qfe0 

if hme1 AdvSendAdvertisements 1
prefix  2002:8192:56bb:2::/64 hme1

Archivo de configuración de interfaces de IPv6

IPv6 utiliza el archivo /etc/hostname6.interfaz al inicio para definir interfaces lógicas de IPv6 de manera automática. Si al instalar Oracle Solaris se elige la opción de habilitar para IPv6, el programa de instalación crea un archivo /etc/hostname6.interfaz para la interfaz de red principal, además del archivo /etc/hostname. interfaz.

Si durante la instalación se detecta más de una interfaz física, se pregunta al usuario si desea configurar dichas interfaces. El programa de instalación crea archivos de configuración de interfaces físicas de IPv4 e interfaces lógicas de IPv6 para cada interfaz adicional que se especifique.

Al igual que las interfaces de IPv4, las de IPv6 se pueden configurar manualmente, tras instalar Oracle Solaris. El usuario crea archivos /etc/hostname6. interfaz para las nuevas interfaces. Para obtener instrucciones sobre la configuración manual de interfaces, consulte Administración de interfaces en Solaris 10 3/05 o el Capítulo 6Administración de interfaces de red (tareas).

Los nombres de archivos de configuración de interfaz de red presentan la sintaxis siguiente:

hostname.interface
hostname6.interface

La variable interfaz presenta la sintaxis siguiente:

dev[.module[.module ...]]PPA

dis

Indica un dispositivo de interfaz de red. El dispositivo puede ser una interfaz física de red, por ejemplo eri o qfe, o una interfaz lógica, por ejemplo un túnel. Para obtener más información, consulte Archivo de configuración de interfaces de IPv6.

Módulo

Presenta uno o varios módulos STREAMS para insertar en el dispositivo cuando dicho dispositivo esté conectado.

PFC

Indica el punto físico de conexión.

La sintaxis [.[.también se acepta.

Ejemplo 11–2 Archivos de configuración de interfaz de IPv6

A continuación se presentan ejemplos de nombres válidos de archivos de configuración de IPv6:

hostname6.qfe0
hostname.ip.tun0
hostname.ip6.tun0
hostname6.ip6to4tun0
hostname6.ip.tun0
hostname6.ip6.tun0

Archivo de configuración /etc/inet/ipaddrsel.conf

El archivo /etc/inet/ipaddrsel.conf contiene la tabla de directrices de selección de direcciones predeterminadas de IPv6. Si Oracle Solaris se instala habilitado para IPv6, este archivo tiene el contenido que se muestra en la Tabla 11–5.

El contenido de /etc/inet/ipaddrsel.conf se puede editar. Ahora bien, en la mayoría de los casos no es conveniente modificarlo. Si hace falta realizar cambios, consulte el procedimiento Cómo administrar la tabla de directrices de selección de direcciones IPv6. Para obtener más información sobre ippaddrsel.conf, consulte Motivos para modificar la tabla de directrices de selección de direcciones IPv6 y la página de comando man ipaddrsel.conf(4).

Comandos relacionados con IPv6

Esta sección describe comandos que se agregan con la implementación de IPv6 en Oracle Solaris. Asimismo, se especifican las modificaciones realizadas en los comandos para poder admitir IPv6.

Comando ipaddrsel

El comando ipaddrsel permite modificar la tabla de directrices de selección de direcciones predeterminadas de IPv6.

El núcleo de Oracle Solaris utiliza la tabla de directrices de selección de direcciones predeterminadas de IPv6 para ordenar direcciones de destino y seleccionar direcciones de origen en un encabezado de paquetes de IPv6. El archivo /etc/inet/ipaddrsel.conf contiene la tabla de directivas.

En la tabla siguiente se enumeran los formatos de direcciones predeterminadas y las correspondientes prioridades en la tabla de directrices. En la página de comando man inet6(7P) hay más información referente a aspectos técnicos sobre la selección de direcciones IPv6.

En esta tabla, los prefijos de IPv6 (::1/128 y ::/0) tienen prioridad sobre las direcciones 6to4 (2002::/16) y las direcciones IPv4 (::/96 y ::ffff:0:0/96). Así pues, de forma predeterminada, el núcleo selecciona la dirección IPv6 global de la interfaz para paquetes que se dirigen a otro destino de IPv6. La dirección IPv4 de la interfaz tiene una prioridad inferior, sobre todo en cuanto a paquetes que se dirigen a un destino de IPv6. A partir de la dirección IPv6 de origen seleccionada, el núcleo también utiliza el formato de IPv6 para la dirección de destino.

Motivos para modificar la tabla de directrices de selección de direcciones IPv6

En la mayoría de los casos, no se necesita cambiar la tabla de directrices de selección de direcciones predeterminadas de IPv6. Para administrar la tabla de directrices, se utiliza el comando ipaddrsel.

La tabla de directrices podría modificarse en alguno de los supuestos siguientes:

• Si el sistema tiene una interfaz que se emplea para un túnel de 6to4, puede otorgar mayor prioridad a las direcciones 6to4.

• Si desea utilizar una determinada dirección de origen sólo para comunicarse con una determinada dirección de destino, puede agregar dichas direcciones a la tabla de directrices. A continuación, mediante el comando ifconfig etiquete las direcciones en función de las preferencias.

• Si quiere otorgar más prioridad a las direcciones IPv4 respecto a las de IPv6, la prioridad de ::ffff:0:0/96 puede cambiarse por un número superior.

• Si debe asignar mayor prioridad a direcciones descartadas, tales direcciones se pueden incorporar a la tabla de directrices. Por ejemplo, las direcciones locales de sitio ahora se descartan en IPv6. Estas direcciones tienen el prefijo fec0::/10. La tabla de directrices se puede modificar para conceder mayor prioridad a las direcciones locales de sitio.

Para obtener más información sobre el comando ipaddrsel, consulte la página de comando man ipaddrsel(1M).

Comando 6to4relay

El establecimiento de túneles de 6to4 permite las comunicaciones entre sitios de 6to4 que están aislados. Sin embargo, para transferir paquetes con un sitio de IPv6 nativo que no sea de 6to4, el enrutador de 6to4 debe establecer un túnel con un enrutador de relé de 6to4. Así, el enrutador de relé de 6to4 reenvía los paquetes de 6to4 a la red IPv6 y, en última instancia, al sitio de IPv6 nativo. Si el sitio habilitado para 6to4 debe intercambiar datos con sitio de IPv6 nativo, utilice el comando 6to4relay para habilitar el túnel correspondiente.

Como el uso de enrutadores de relé no es seguro, en Oracle Solaris de manera predeterminada se inhabilita el establecimiento de túneles con un enrutador de relé. Antes de implementar esta situación hipotética, debe tener muy en cuenta los problemas que comporta crear un túnel con un enrutador de relé de 6to4. Para obtener más información sobre enrutadores de relé de 6to4, consulte Consideraciones para túneles hasta un enrutador de reenvío 6to4. Si decide habilitar la admisión de enrutadores de relé 6to4, encontrará los procedimientos en Cómo configurar un túnel 6to4.

Sintaxis de 6to4relay

El comando 6to4relay presenta la sintaxis siguiente:

6to4relay -e [-a IPv4-address] -d -h

-e

Habilita el uso de túneles entre el enrutador de 6to4 y un enrutador de relé de 6to4 de difusión por proximidad. Así, la dirección de punto final de túnel se establece en 192.88.99.1, que es la predeterminada para el grupo de difusión por proximidad de enrutadores de relé de 6to4.

-a dirección_IPv4

Habilita el uso de túneles entre el enrutador de 6to4 y un enrutador de relé de 6to4 con la dirección_IPv4 que se especifique.

-d

Anula la admisión del establecimiento de túneles con el enrutador de relé de 6to4, que es el predeterminado de Oracle Solaris.

-h

Muestra la ayuda del comando 6to4relay.

Para obtener más información, consulte la página de comando man 6to4relay(1M).

Ejemplo 11–3 Pantalla de estado predeterminado de admisión de enrutador de relé de 6to4

El comando 6to4relay, sin argumentos, muestra el estado actual de la admisión de enrutadores de relé de 6to4. Este ejemplo ilustra el valor predeterminado de la implementación de IPv6 en Oracle Solaris.

# /usr/sbin/6to4relay
6to4relay:6to4 Relay Router communication support is disabled

Ejemplo 11–4 Pantalla de estado con admisión habilitada de enrutadores de relé de 6to4

Si se habilita la admisión de enrutadores de relé, 6to4relay muestra la salida siguiente:

# /usr/sbin/6to4relay
6to4relay:6to4 Relay Router communication support is enabled
IPv4 destination address of Relay Router=192.88.99.1

Ejemplo 11–5 Pantalla de estado con un enrutador de relé de 6to4 especificado

Si se especifica la opción -a y una dirección IPv4 en el comando 6to4relay, en lugar de -192.88.99.1 se muestra la dirección IPv4 que se proporciona con a.

6to4relay no indica la ejecución correcta de las opciones de -dirección_IPv4 -d, -e y a. Ahora bien, 6to4relay muestra cualquier mensaje de error que se pudiera generar durante la ejecución de dichas opciones.

Extensiones del comando ifconfig para admisión de IPv6

El comando ifconfig habilita las interfaces de IPv6 y el módulo de establecimiento de túneles que se debe conectar. ifconfig utiliza un conjunto de comandos ioctls ampliado para configurar las interfaces de red IPv4 e IPv6. A continuación se describen las opciones de ifconfig que admiten operaciones de IPv6. Consulte Supervisión de la configuración de interfaz con el comando ifconfig para obtener una serie de tareas de IPv4 e IPv6 que afectan a ifconfig.

index

Establece el índice de interfaces.

tsrc/tdst

Establece el origen o destino de túneles.

addif

Crea la siguiente interfaz lógica disponible.

removeif

Elimina una interfaz lógica con una determinada dirección IP.

destination

Establece la dirección de destino punto a punto para una interfaz.

set

Establece una dirección, máscara de red o ambas cosas para una interfaz.

subnet

Establece la dirección de subred de una interfaz.

xmit/-xmit

Habilita o inhabilita la transmisión de paquetes en una interfaz.

En el Capítulo 7Configuración de una red IPv6 (tareas)., encontrará procedimientos de configuración de IPv6.

Ejemplo 11–6 Adición de una interfaz de IPv6 lógica con la opción -addif del comando ifconfig

La forma siguiente del comando ifconfig crea la interfaz lógica hme0:3:

# ifconfig hme0 inet6 addif up
Created new logical interface hme0:3

Esta forma del comando ifconfig verifica la creación de la interfaz:

# ifconfig hme0:3 inet6
hme0:3: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
		inet6  inet6 fe80::203:baff:fe11:b321/10

Ejemplo 11–7 Eliminación de una interfaz de IPv6 lógica con la opción -removeif del comando ifconfig

La forma siguiente del comando ifconfig elimina la interfaz lógica hme0:3:

# ifconfig hme0:3 inet6 down

# ifconfig hme0 inet6 removeif 1234::5678

Ejemplo 11–8 Uso del comando ifconfig para configurar un origen de túneles de IPv6

# ifconfig ip.tun0 inet6 plumb index 13

Abre el túnel que se debe asociar con el nombre de la interfaz física.

# ifconfig ip.tun0 inet6
ip.tun0: flags=2200850<POINTOPOINT,RUNNING,MULTICAST,NONUD,
#IPv6> mtu 1480 index 13
		inet tunnel src 0.0.0.0 
		inet6 fe80::/10 --> :: 

Configura los correspondientes flujos de TCP/IP para utilizar el dispositivo de túneles e informar sobre el estado del dispositivo.

# ifconfig ip.tun0 inet6 tsrc 120.46.86.158 tdst 120.46.86.122

Configura la dirección de origen y de destino del túnel.

# ifconfig ip.tun0 inet6
ip.tun0: flags=2200850<POINTOPOINT,RUNNING,MULTICAST,NONUD,
IPv6> mtu 1480 index 13
		inet tunnel src 120.46.86.158  tunnel dst 120.46.86.122
		inet6 fe80::8192:569e/10 --> fe80::8192:567a

Informa sobre el nuevo estado del dispositivo tras la configuración.

Ejemplo 11–9 Configuración de un túnel de 6to4 mediante ifconfig (forma completa)

En este ejemplo de configuración de pseudointerfaz de 6to4 se utiliza el ID de subred de 1 y se especifica el ID de host, en forma hexadecimal.

# ifconfig ip.6to4tun0 inet6 plumb
# ifconfig ip.6to4tun0 inet tsrc 129.146.86.187 \
2002:8192:56bb:1::8192:56bb/64 up

# ifconfig ip.6to4tun0 inet6
ip.6to4tun0: flags=2200041<UP,RUNNING,NONUD,IPv6>mtu 1480 index 11
        inet tunnel src 129.146.86.187 
        tunnel hop limit 60 
        inet6 2002:8192:56bb:1::8192:56bb/64 

Ejemplo 11–10 Configuración de un túnel de 6to4 mediante ifconfig (forma abreviada)

En este ejemplo se muestra la forma abreviada para la configuración de un túnel de 6to4.

# ifconfig ip.6to4tun0 inet6 plumb
# ifconfig ip.6to4tun0 inet tsrc 129.146.86.187 up

# ifconfig ip.6to4tun0 inet6
ip.6to4tun0: flags=2200041<UP,RUNNING,NONUD,IPv6>mtu 1480 index 11
        inet tunnel src 129.146.86.187 
        tunnel hop limit 60 
        inet6 2002:8192:56bb::1/64 

Modificaciones del comando netstat para admitir IPv6

El comando netstat muestra el estado de redes IPv4 e IPv6. Puede elegir la información de protocolo que se visualizará; para ello, establezca el valor de DEFAULT_IP en el archivo /etc/default/inet_type o recurra a la opción de línea de comandos -f. Si se aplica un valor permanente de DEFAULT_IP, se garantiza que netstat muestre únicamente información relativa a IPv4. Este valor puede anularse mediante la opción -f. Para obtener más información sobre el archivo inet_type, consulte la página de comando man inet_type(4).

La opción -p del comando netstat muestra la tabla de red a soporte, que es la tabla ARP para IPv4 y la caché interna para IPv6. Consulte la página de comando man netstat(1M) para obtener más información. Consulte Cómo visualizar el estado de los sockets para obtener descripciones de procedimientos que utilizan este comando.

Modificaciones del comando snoop para admitir IPv6

El comando snoop puede capturar paquetes de IPv4 e IPv6. Este comando puede mostrar encabezados de IPv6, encabezados de extensiones de IPv6, encabezados de ICMPv6 y datos de protocolo ND. De manera predeterminada, el comando snoop muestra paquetes de IPv4 e IPv6. Si especifica la palabra clave de protocolo ip o ip6, el comando snoop muestra sólo paquetes de IPv4 o IPv6, respectivamente. La opción para filtrar IPv6 permite filtrar en todos los paquetes, tanto de IPv4 como IPv6, y mostrar únicamente los paquetes de IPv6. Consulte la página de comando man snoop(1M) para obtener más información. Consulte Cómo supervisar tráfico de redes IPv6 para obtener información sobre procedimientos que utilizan el comando snoop.

Modificaciones del comando route para admitir IPv6

El comando route funciona en rutas IPv4 e IPv6; el valor predeterminado son las rutas IPv4. Si la opción -inet6 de la línea de comandos se utiliza inmediatamente después del comando route, las operaciones se llevan a cabo en rutas IPv6. Consulte la página de comando man route(1M) para obtener más información.

Modificaciones del comando ping para admitir IPv6

El comando ping utiliza protocolos IPv4 e IPv6 para sondear hosts de destino. La selección de protocolo depende de las direcciones que devuelve el servidor de nombres en relación con el host de destino específico. De forma predeterminada, si el servidor de nombres devuelve una dirección IPv6 para el host de destino, el comando ping utiliza el protocolo IPv6. Si el servidor devuelve sólo una dirección IPv4, el comando ping emplea el protocolo IPv4. Si desea anular esta acción, utilice la opción de línea de comandos -A para indicar el protocolo que debe usarse.

Para obtener más información, consulte la página de comando man ping(1M) Para obtener información sobre procedimientos que utilicen el comando ping , consulte Sondeo de hosts remotos con el comando ping.

Modificaciones del comando traceroute para admitir IPv6

El comando traceroute efectúa el seguimiento de las rutas IPv4 e IPv6 de un determinado host. En una perspectiva de protocolos, traceroute utiliza el mismo algoritmo que ping. Si desea anular esta selección, utilice la opción de línea de comandos -A. Puede efectuar el seguimiento de cada ruta en cada dirección de un host con varias direcciones permanentes mediante la opción de línea de comandos -a.

Para obtener más información, consulte la página de comando man traceroute(1M) Para obtener información sobre procedimientos que usan el comando traceroute, consulte Visualización de información de enrutamiento con el comando traceroute.

Daemons relacionados con IPv6

Esta sección trata sobre los daemons relacionados con IPv6.

Daemon in.ndpd, para el protocolo ND

El daemon in.ndpd implementa el protocolo ND de IPv6 y el descubrimiento de enrutadores. Asimismo, implementa la configuración automática de direcciones para IPv6. A continuación se muestran las opciones admitidas de in.ndpd.

-d

Activa la depuración.

-D

Activa la depuración para determinados eventos.

-f

Especifica un archivo cuyos datos de configuración deban leerse, en lugar del archivo predeterminado /etc/inet/ndpd.conf.

-I

Imprime información relativa a cada interfaz.

-n

No efectúa bucles de retorno de anuncios de enrutador.

-r

Hace caso omiso de paquetes recibidos.

-v

Especifica el modo detallado; informa de varios tipos de mensajes de diagnóstico.

-t

Activa el seguimiento de paquetes.

El daemon in.ndpd lo controlan parámetros que se establecen en el archivo de configuración /etc/inet/ndpd.conf y los pertinentes parámetros del archivo de inicio de /var/inet/ndpd_state. interfaz.

Si existe el archivo /etc/inet/ndpd.conf, se analiza y utiliza para configurar un nodo como enrutador. En la Tabla 11–2 figuran las palabras clave válidas que podrían aparecer en este archivo. Si se inicia un host, podría suceder que los enrutadores no estuvieran disponibles de manera inmediata. Los paquetes anunciados por el enrutador podrían perderse. Asimismo, los paquetes anunciados quizá no se comuniquen con el host.

El archivo /var/inet/ndpd_state.interfaz es un archivo de estado. Cada nodo lo actualiza periódicamente. Si el nodo falla y se reinicia, el nodo puede configurar sus interfaces si no hay enrutadores. Este archivo contiene las direcciones de interfaz, la última vez que se modificó el archivo y el tiempo que este archivo será válido. Asimismo, el archivo contiene otros parámetros que se "aprenden" a partir de anteriores anuncios de enrutador.

No es necesario modificar el contenido de archivos de estado. El daemon in.ndpd mantiene los archivos de estado de forma automática.

Consulte las páginas de comando man in.ndpd(1M) y ndpd.conf(4) para obtener listas de variables de configuración y valores permitidos.

Daemon in.ripngd, para enrutamiento de IPv6

El daemon in.ripngd implementa el protocolo RIPng (Routing Information Protocol) para enrutadores IPv6. RIPng define el equivalente de IPv6 de RIP. Si se configura un enrutador de IPv6 con el comando routeadm y se activa el enrutamiento de IPv6, el daemon in.ripngd implementa el protocolo RIPng en el enrutador.

A continuación se muestran las opciones admitidas del protocolo RIPng.

-p n

n especifica el número de puerto alternativo que se usa para enviar o recibir paquetes de RIPnG.

-q

Suprime información de enrutamiento.

-s

Fuerza la información de enrutamiento aun en caso de que el daemon funcione como enrutador.

-P

Suprime el uso de valores negativos.

-S

Si in.ripngd no funciona como enrutador, el daemon especifica sólo un enrutador predeterminado para cada enrutador.

Daemon inetd y servicios de IPv6

Una aplicación de servidores habilitada para IPv6 puede asumir solicitudes de IPv4 e IPv6, o únicamente de IPv6. El servidor controla siempre las solicitudes mediante un socket de IPv6. Además, el servidor emplea el mismo protocolo que el del cliente correspondiente. Si desea agregar o modificar un servicio de IPv6, emplee los comandos disponibles en la Utilidad de gestion de servicios (SMF).

• Para obtener información sobre los comandos de SMF, consulte SMF Command-Line Administrative Utilities de System Administration Guide: Basic Administration.

• Para ver una tarea de ejemplo que utilice SMF en la configuración de un manifiesto de servicio de IPv4 que se ejecute en SCTP, consulte Cómo agregar servicios que utilicen el protocolo SCTP.

Si desea configurar un servicio de IPv6, asegúrese de que el valor del campo proto del perfil inetadm relativo a ese servicio presente el valor correspondiente:

• Si necesita un servicio que controle solicitudes de IPv4 e IPv6, elija tcp6, udp6 o sctp. Un valor de proto de tcp6, udp6 o sctp6 hace que inetd pase en un socket de IPv6 al servidor. El servidor contiene una dirección asignada a IPv4 en caso de que un cliente IPv4 tenga una solicitud.

• Si necesita un servicio que únicamente controle solicitudes de IPv6, elija tcp6only o udp6only. Si se asigna cualquiera de estos valores a proto, inetd pasa el servidor a un socket de IPv6.

Si reemplaza un comando de Oracle Solaris por otra implementación, compruebe que la implementación de ese servicio admita IPv6. Si la implementación no admite IPv6, el valor de proto debe especificarse como tcp, udp o sctp.

A continuación se muestra un perfil generado tras la ejecución de inetadm para un manifiesto de servicio echo que admite IPv4 e IPv6, y se ejecuta mediante SCTP:

# inetadm -l svc:/network/echo:sctp_stream
	SCOPE    NAME=VALUE	  name="echo"
	         endpoint_type="stream"
	         proto="sctp6"
	         isrpc=FALSE
	         wait=FALSE
	         exec="/usr/lib/inet/in.echod -s"
	         user="root"
	default  bind_addr=""
	default  bind_fail_max=-1
	default  bind_fail_interval=-1
	default  max_con_rate=-1
	default  max_copies=-1
	default  con_rate_offline=-1
	default  failrate_cnt=40
	default  failrate_interval=60
	default  inherit_env=TRUE
	default  tcp_trace=FALSE
	default  tcp_wrappers=FALSE

Si desea cambiar el valor del campo proto, aplique la sintaxis siguiente:

# inetadm -m FMRI proto="transport-protocols"

Todos los servidores que se proporcionan con el software Oracle Solaris necesitan sólo una entrada de perfil que especifique proto como tcp6, udp6 o sctp6. No obstante, el servidor de shell remoto (shell) y el servidor de ejecución remoto (exec) se componen en la actualidad de una sola instancia de servicio, que necesita un valor de proto que contenga los valores de tcp y tcp6only. Por ejemplo, para establecer el valor de proto para shell, debe ejecutarse el comando siguiente:

# inetadm -m network/shell:default proto="tcp,tcp6only"

Para obtener más información sobre la escritura en servidores habilitados para IPv6 que utilizan sockets, consulte las extensiones de IPv6 de Socket API en la Programming Interfaces Guide.

Puntos que tener en cuenta al configurar un servicio para IPv6

Al agregar o modificar un servicio para IPv6, tenga en cuenta lo siguiente:

• El valor de proto debe establecerse en tcp6, sctp6 o udp6 para permitir conexiones IPv4 o IPv6. Si el valor deproto se establece en tcp, sctp o udp, el servicio utiliza sólo IPv4.

• Si bien puede agregar una instancia de servicio que utilice sockets SCTP de uno a varios estilos para inetd, no es recomendable. inetd no funciona con sockets SCTP de uno a varios estilos.

• Si un servicio necesita dos entradas debido a diferencias en las propiedades de wait-status o exec, debe crear dos instancias o servicios a partir del servicio original.

Protocolo ND de IPv6

IPv6 introduce el protocolo ND (Neighbor Discovery), tal como se describe en RFC 2461, Neighbor Discovery for IP Version 6 (IPv6). Para obtener una descripción general de las características de este protocolo, consulte Descripción general del protocolo ND de IPv6.

Esta sección trata sobre las características siguientes del protocolo ND:

• Mensajes de ICMP del protocolo ND

• Proceso de configuración automática

• Solicitud e inasequibilidad de vecinos

• Algoritmo de detección de direcciones duplicadas

• Comparación del protocolo ND con ARP y protocolos relacionados con IPv4

Mensajes de ICMP del protocolo ND

El protocolo ND define cinco mensajes nuevos de ICMP (Internet Control Message Protocol). Dichos mensajes tienen los objetivos siguientes:

• Solicitud de enrutador: al habilitarse una interfaz, los hosts pueden enviar mensajes de solicitud de enrutador. Se solicita a los enrutadores que generen inmediatamente anuncios de enrutador, en lugar de hacerlo la próxima vez que se hubiera programado.

• Anuncio de enrutador: los enrutadores anuncian su presencia, así como varios parámetros de vínculos y de Internet. Los enrutadores anuncian de manera periódica o como respuesta a un mensaje de solicitud de enrutador. Los anuncios de enrutador contienen prefijos que se usan para la determinación de onlinks o configuración de direcciones, un valor de límite de salto propuesto, etcétera.

• Solicitud de vecino: los nodos envían mensajes de solicitud de vecino para determinar la dirección de capa de vínculo de un vecino. Los mensajes de solicitud de vecino también sirven para verificar que se pueda contactar con un vecino mediante una dirección de capa de vínculo almacenada en caché. Asimismo, las solicitudes de vecino se usan para detectar direcciones duplicadas.

• Anuncio de vecino: un nodo envía mensajes de anuncio de vecino como respuesta a un mensaje de solicitud de vecino. El nodo también puede enviar anuncios de vecino no solicitados para anunciar un cambio de dirección de capa de vínculo.

• Redirección: los enrutadores emplean mensajes de redirección para indicar a los hosts el mejor primer salto para acceder a un destino, o para indicar que el destino está en el mismo vínculo.

Proceso de configuración automática

Esta sección proporciona una descripción general de los pasos habituales que realizan las interfaces durante la configuración automática. La configuración automática se efectúa sólo en vínculos que permiten multidifusión.

1. Una interfaz que permite multidifusión se habilita, por ejemplo, al iniciar el sistema de un nodo.

2. El nodo empieza el proceso de configuración automática generando una dirección local de vínculo para la interfaz.

   La dirección local de vínculo se forma a partir de la dirección MAC de la interfaz.

3. El nodo envía un mensaje de solicitud de vecino que contiene la dirección local de vínculo provisional como destino.

   La finalidad del mensaje es verificar que otro nodo del vínculo no esté utilizando ya la dirección de prueba. Tras verificarla, la dirección local de vínculo puede asignarse a una interfaz.

   1. Si la dirección propuesta ya la usa otro nodo, dicho nodo genera un anuncio de vecino para informar de ello.

   2. Si otro nodo intenta utilizar la misma dirección, dicho nodo también envía una solicitud de vecino para el destino.

      La cantidad de transmisiones y retransmisiones de solicitudes de vecino, así como el retraso entre solicitudes consecutivas, dependen de cada vínculo. Si es preciso, establezca estos parámetros.

4. Si un nodo determina que la dirección local de vínculo de prueba no es exclusiva, se detiene el proceso de configuración automática. De ser así, la dirección local de vínculo de la interfaz se debe configurar manualmente.

   Para simplificar la recuperación, puede especificar otro ID de interfaz que anule el predeterminado. De este modo, el mecanismo de configuración automática puede reanudar su funcionamiento con el nuevo ID de interfaz, que en principio es exclusivo.

5. Si un nodo determina que la dirección local de vínculo de prueba es exclusiva, el nodo la asigna a la interfaz.

   En ese momento, el nodo dispone de conectividad IP con nodos vecinos. Los demás pasos de la configuración automática los efectúan solamente hosts.

Obtención de un anuncio de enrutador

La fase siguiente de la configuración automática consiste en obtener un anuncio de enrutador o determinar que no hay enrutadores. Si hay enrutadores, éstos envían anuncios de enrutador para indicar la clase de configuración automática que debe ejecutar un host.

Los enrutadores envían periódicamente solicitudes de enrutador. No obstante, el retraso entre los sucesivos anuncios suele ser superior a lo que puede esperar un host que efectúa la configuración automática. Para obtener rápidamente un anuncio, el host envía una o varias solicitudes de enrutador al grupo multidifusión de todos los enrutadores.

Variables en la configuración de prefijos

Los anuncios de enrutador pueden contener también variables de prefijo con información que la configuración automática de direcciones emplea en la generación de prefijos. El campo de configuración automática de direcciones sin estado de los anuncios de enrutador se procesa de manera independiente. El indicador de configuración de direcciones, un campo de opción que contiene información de prefijo, indica si la opción se aplica también a la configuración automática sin estado. Si se aplica el campo de opción, otros campos de opciones contienen un prefijo de subred con valores continuamente vigentes. Estos valores indican la duración que tendrán la validez y preferencia de las direcciones creadas a partir del prefijo.

Debido a que los enrutadores generan periódicamente anuncios de enrutador, los hosts reciben anuncios nuevos de manera constante. Los hosts habilitados para IPv6 procesan la información que hay en cada anuncio. Los hosts se agregan a la información. También ponen al día la información recibida en anuncios anteriores.

Exclusividad de las direcciones

Por motivos de seguridad, antes de asignarse a la interfaz debe verificarse que todas las direcciones sean exclusivas. Es distinto en el caso de direcciones creadas con configuración automática sin estado. La exclusividad de una dirección la determina la parte de la dirección formada por un ID de interfaz. Por eso, si un nodo ya ha comprobado la exclusividad de una dirección local de vínculo, no hace falta verificar las direcciones adicionales una a una. Las direcciones deben crearse a partir del mismo ID de interfaz. Por su parte, debe comprobarse la exclusividad de todas las direcciones que se obtengan manualmente. Los administradores de sistemas de algunos sitios consideran que el esfuerzo y los recursos dedicados a detectar direcciones duplicadas son mayores que sus ventajas. En estos sitios, la detección de direcciones duplicadas se puede inhabilitar estableciendo un indicador de configuración según la interfaz.

Para acelerar el proceso de configuración automática, un host puede generar su propia dirección local de vínculo y verificar su exclusividad, mientras el host espera un anuncio de enrutador. Un enrutador podría retrasar durante unos segundos la respuesta a una solicitud de enrutador. Por lo tanto, el tiempo total que se necesita para completar la configuración automática puede ser considerablemente superior si los dos pasos se realizan en serie.

Solicitud e inasequibilidad de vecinos

El protocolo ND utiliza mensajes de solicitud de vecino para determinar si la misma dirección unidifusión tiene asignado más de un nodo. La detección de inasequibilidad de vecinos descubre el error de un vecino o de la ruta de reenvío del vecino. Esta clase de detección precisa la confirmación positiva de que los paquetes que se envían a un vecino lleguen realmente a su destino. Asimismo, la detección de inasequibilidad de vecinos determina que la capa IP del nodo procese correctamente los paquetes.

La detección de inasequibilidad de vecinos utiliza la confirmación a partir de dos puntos de referencia: los protocolos de capa superior y los mensajes de solicitud de vecino. Si es posible, los protocolos de capa superior brindan la confirmación positiva de que una conexión avanza en el reenvío. Por ejemplo, si se reciben reconocimientos de TCP, se confirma la correcta entrega de los datos enviados con anterioridad.

Si un nodo no obtiene una confirmación positiva de los protocolos de capa superior, dicho nodo envía mensajes de solicitud de vecino unidifusión. Estos mensajes solicitan anuncios de vecino como confirmación de asequibilidad a partir del próximo salto. Para reducir el tráfico redundante en la red, los mensajes sonda se envían sólo a los vecinos a los que el nodo esté enviando paquetes.

Algoritmo de detección de direcciones duplicadas

Para asegurarse de que todas las direcciones configuradas puedan ser exclusivas en un determinado vínculo, los nodos ejecutan en las direcciones un algoritmo de detección de direcciones duplicadas. Los nodos deben ejecutar el algoritmo antes de asignar las direcciones a una interfaz. El algoritmo de detección de direcciones duplicadas se ejecuta en todas las direcciones.

El proceso de configuración automática que se describe en esta sección detección de direcciones duplicadas sólo es válido para hosts, no para enrutadores. Debido a que la configuración automática de hosts emplea información anunciada por enrutadores, éstos se deben configurar por otros medios. Sin embargo, los enrutadores generan direcciones locales de vínculo mediante el mecanismo que se explica en este capítulo. Además, en principio los enrutadores deben superar correctamente el algoritmo de detección de direcciones duplicadas en todas las direcciones antes de asignar la dirección a una interfaz.

Anuncios de proxy

Un enrutador que acepta paquetes de parte de una dirección de destino puede ejecutar anuncios que no se anulan. El enrutador puede aceptar paquetes de parte de una dirección de destino que sea incapaz de responder a solicitudes de destino. En la actualidad no se especifica el uso de proxy. Ahora bien, el anuncio de proxy se puede utilizar para ocuparse de casos como nodos móviles que se han desplazado fuera del vínculo. El uso de proxy no se ha concebido como mecanismo general para controlador nodos que no implementen este protocolo.

Equilibrio de la carga entrante

Los nodos con interfaces duplicadas quizá deban equilibrar la carga de la recepción de paquetes entrantes en las distintas interfaces de red del mismo vínculo. Estos nodos disponen de varias direcciones locales de vínculo asignadas a la misma interfaz. Por ejemplo, un solo controlador de red puede representar a varias tarjetas de interfaz de red como una única interfaz lógica que dispone de varias direcciones locales de vínculo.

El equilibrio de carga se controla permitiendo que los enrutadores omitan la dirección local de vínculo de origen de los paquetes de anuncio de enrutador. Por consiguiente, los vecinos deben emplear mensajes de solicitud de vecino para aprender las direcciones locales de vínculo de los enrutadores. Los mensajes de anuncio de vecino devueltos pueden contener direcciones locales de vínculo diferentes, en función del que haya emitido la solicitud.

Cambio de dirección local de vínculo

Un nodo que sepa que se ha modificado su dirección local de vínculo puede enviar paquetes de anuncios de vecinos multidifusión no solicitados. El nodo puede enviar paquetes multidifusión a todos los nodos para actualizar las direcciones locales de vínculo almacenadas en caché que ya no sean válidas. El envío de anuncios no solicitados es una simple mejora del rendimiento. El algoritmo de detección de inasequibilidad de vecinos se asegura de que todos los nodos descubran la nueva dirección de manera fiable, aunque ello comporte un retraso algo mayor.

Comparación del protocolo ND con ARP y protocolos relacionados con IPv4

El funcionamiento del protocolo ND de IPv6 equivale a combinar los siguientes protocolos de IPv4: ARP (Address Resolution Protocol), ICMP (Internet Control Message Protocol, Router Discovery e ICMP Redirect. IPv4 carece de un protocolo general establecido y de un mecanismo para detectar la inasequibilidad de vecinos. Sin embargo, los requisitos de host especifican determinados algoritmos para la detección de portales inactivos. La detección de portales inactivos es un subconjunto de los problemas que soluciona la detección de inasequibilidad de vecinos.

En la lista siguiente se comparan el protocolo ND con el conjunto correspondiente de protocolos de IPv4.

• El descubrimiento de enrutador forma parte del conjunto básico de protocolos de IPv6. Los hosts de IPv6 no necesitan aplicar el comando snoop a los protocolos de enrutamiento para buscar un enrutador. IPv4 utiliza ARP, descubrimiento de enrutadores ICMP y redirección de ICMP para el descubrimiento de enrutador.

• Los anuncios de enrutador de IPv6 llevan direcciones locales de vínculo. Para resolver la dirección local de vínculo no hace falta un intercambio adicional de paquetes.

• Los anuncios de enrutador llevan los prefijos de sitio para un vínculo. No hace falta un mecanismo aparte para configurar la máscara de red, como sucede con IPv4.

• Los anuncios de enrutador permiten la configuración automática de direcciones. En IPv4 no se implementa la configuración automática.

• El protocolo ND permite que los enrutadores de IPv6 anuncien una MTU (Maximum Transmission Unit, unidad de transmisión máxima) para hosts para utilizarse en el vínculo. Por lo tanto, todos los nodos emplean el mismo valor de MTU en los vínculos que carecen de una MTU bien definida. Podría ser que los hosts de IPv4 de una misma red tuvieran distintas MTU.

• A diferencia de las direcciones de emisión IPv4, las multidifusiones de resolución de direcciones IPv6 se distribuyen en cuatro mil millones (2^32) de direcciones multidifusión, lo cual reduce significativamente las interrupciones por resolución de direcciones en nodos que no sean el de destino. Además, no es recomendable interrumpir sistemas que no sean IPv6.

• Las redirecciones de IPv6 contienen la dirección local de vínculo del primer salto nuevo. Al recibir una redirección no hace falta una resolución de direcciones aparte.

• Una misma red IPv6 puede tener asociados varios prefijos de sitio. De forma predeterminada, los hosts aprenden todos los prefijos de sitio locales a partir de anuncios de enrutador. Sin embargo, es posible configurar los enrutadores para que omitan todos o algunos prefijos de anuncios de enrutador. En esos casos, los hosts dan por sentado que los destinos se encuentran en redes remotas. Por lo tanto, los hosts envían el tráfico a enrutadores. Así pues, un enrutador puede ejecutar redirecciones si es preciso.

• A diferencia de IPv4, el destinatario de un mensaje de redirección de IPv6 da por sentado que el próximo salto nuevo se da en la red local. En IPv4, un host hace caso omiso de los mensajes de redirección que especifiquen un próximo salto que no se ubique en la red local, conforme a la máscara de red. El mecanismo de redirección de IPv6 es análogo a la función XRedirect de IPv4. El mecanismo de redirección es útil en vínculos de soportes compartidos y de no emisión. En esta clase de redes, los nodos no deben comprobar todos los prefijos de destinos de vínculo local.

• La detección de inasequibilidad de vecinos de IPv6 mejora la distribución de paquetes si hay enrutadores que funcionan mal. Esta capacidad mejora la distribución de paquetes en vínculos con particiones o que funcionan parcialmente mal. Asimismo, mejora la distribución de paquetes en nodos que modifican sus direcciones locales de vínculo. Por ejemplo, los nodos móviles pueden salir de la red local sin perder ninguna clase de conectividad debido a memorias caché de ARP que hayan quedado obsoletas. IPv4 carece de método equivalente para la detección de inasequibilidad de vecinos.

• A diferencia de ARP, el protocolo ND detecta errores parciales en vínculos mediante la detección de inasequibilidad de vecinos. El protocolo ND evita el envío de tráfico a vecinos si no existe conectividad bidireccional.

• Las direcciones locales de vínculo permiten la identificación exclusiva de enrutadores y los hosts de IPv6 mantienen las asociaciones de enrutador. La capacidad de identificar enrutadores es necesaria en anuncios de enrutador y mensajes de redirección. Los hosts deben mantener asociaciones de enrutador si el sitio emplea prefijos globales nuevos. IPv4 carece de un método equiparable para la identificación de enrutadores.

• Debido a que los mensajes de protocolo ND tienen un límite de salto de 255 en la recepción, dicho protocolo es inmune a ataques de spoofing provenientes de nodos que no están en el vínculo. Por el contrario, los nodos que no están en vínculos de IPv4 pueden enviar mensajes de redirección de ICMP. Asimismo, los nodos que no están en vínculos de IPv4 pueden enviar mensajes de anuncio de enrutador.

• La colocación de resolución de direcciones en la capa de ICMP hace que el protocolo ND sea más independiente en cuanto a soportes que ARP. por consiguiente, se pueden utilizar la autenticación IP y los mecanismos de seguridad estándar.

Encaminamiento de IPv6

El enrutamiento de IPv6 es casi idéntico al de IPv4 en la dirección de enrutamiento entre dominios sin clase (CIDR). La única diferencia estriba en que las direcciones son IPv6 de 128 bits, en lugar de IPv4 de 32 bits. Con extensiones sumamente sencillas, todos los algoritmos de enrutamiento de IPv4, por ejemplo OSPF, RIP, IDRP e IS-IS, son válidos para enrutar IPv6.

Asimismo, IPv6 incluye extensiones sencillas de enrutamiento que admiten nuevas y potentes posibilidades de enrutamiento. A continuación se describen las nuevas funciones de enrutamiento:

• La selección del proveedor se basa en las directrices, el rendimiento, los costes, etcétera

• Movilidad de los hosts, enrutamiento a la ubicación actual

• Redireccionamiento automático, enrutamiento a la dirección nueva

Para acceder a las nuevas funciones de enrutamiento, debe crear secuencias de direcciones IPv6 que utilicen la opción de enrutamiento de IPv6. Un origen de IPv6 utiliza la opción de enrutamiento para obtener uno o varios nodos intermedios, o un grupo topológico, que debe visitarse en dirección al destino del paquete. Es una función muy parecida a las opciones de ruta de registro y ruta holgada fija en origen de IPv4.

Para que las secuencias de direcciones sean una función general, los hosts de IPv6 deben, en la mayoría de los casos, invertir las rutas de un paquete que reciba un host. El paquete se debe autenticar correctamente mediante el encabezado de autenticación de IPv6. El paquete debe contener secuencias de direcciones para devolver el paquete al emisor. Esta técnica obliga a que las implementaciones de hosts de IPv6 admitan el control y la inversión de las rutas de origen. El control y la inversión de las rutas de origen es la clave que permite a los proveedores trabajar con los hosts que implementan las nuevas funciones de IPv6 como la selección de proveedor y las direcciones extendidas.

Anuncio de enrutador

En vínculos con capacidad multidifusión y punto a punto, cada enrutador envía, de forma periódica, al grupo multidifusión un paquete de anuncios de enrutador que informa de su disponibilidad. Un host recibe anuncios de enrutador de todos los enrutadores, y confecciona una lista de enrutadores predeterminados. Los enrutadores generan anuncios de enrutador con la suficiente frecuencia para que los hosts aprendan su presencia en pocos minutos. Sin embargo, los enrutadores no anuncian con suficiente frecuencia como para que una falta de anuncios permita detectar un error de enrutador. La detección de errores es factible mediante un algoritmo de detección independiente que determina la inasequibilidad de vecinos.

Prefijos de anuncio de enrutador

Los anuncios de enrutador contienen una lista de prefijos de subred que se usan para determinar si un host se encuentra en el mismo vínculo que el enrutador. La lista de prefijos también se utiliza en la configuración de direcciones autónomas. Los indicadores que se asocian con los prefijos especifican el uso concreto de un determinado prefijo. Los hosts utilizan los prefijos del vínculo anunciados para configurar y mantener una lista que se emplea para decidir si el destino de un paquete se encuentra en el vínculo o fuera de un enrutador. Un destino puede encontrarse en un vínculo aunque dicho destino no aparezca en ningún prefijo del vínculo que esté anunciado. En esos casos, un enrutador puede enviar una redirección. La redirección indica al remitente que el destino es un vecino.

Los anuncios de enrutador, y los indicadores de prefijo, permiten a los enrutadores informar a los hosts sobre cómo efectuar la configuración automática de direcciones sin estado.

Mensajes de anuncio de enrutador

Los mensajes de anuncio de enrutador contienen también parámetros de Internet, por ejemplo el límite de salto que los hosts deben emplear en los paquetes salientes. También es posible que los mensajes de anuncio de enrutador contengan parámetros de vínculo, por ejemplo la MTU de vínculo. Esta función permite la administración centralizada de los parámetros importantes. Los parámetros se pueden establecer en enrutadores y propagarse automáticamente a todos los hosts que estén conectados.

Los nodos llevan a cabo la resolución de direcciones enviando al grupo de multidifusión una solicitud de vecino que pide al nodo de destino que devuelva su dirección de capa de vínculo. Los mensajes de solicitud de vecino multidifusión se envían a la dirección multidifusión de nodo solicitado de la dirección de destino. El destino devuelve su dirección de capa de vínculo en un mensaje de anuncio de vecino unidifusión. Para que el iniciador y el destino resuelvan sus respectivas direcciones de capa de vínculo basta con un solo par de paquetes de solicitud-respuesta. El iniciador incluye su dirección de capa de vínculo en la solicitud de vecino.

Túneles de IPv6

Para minimizar las dependencias en una sitio de IPv4/IPv6 de doble pila, todos los enrutadores de la ruta entre dos nodos IPv6 no necesitan ser compatibles con IPv6. El mecanismo que admite esta clase de configuración en red se denomina colocación en túneles. Básicamente, los paquetes de IPv6 se colocan en paquetes de IPv4, que luego se enrutan a través de enrutadores de IPv4. La figura siguiente ilustra el mecanismo de colocación en túneles mediante enrutadores de IPv4, cosa que en la figura se señala mediante una R.

Figura 11–5 Mecanismo de colocación en túneles de IPv6

La implementación de IPv6 en Oracle Solaris incluye dos clases de mecanismos de colocación en túneles:

• Túneles configurados entre dos enrutadores, como en la Figura 11–5

• Túneles automáticos que terminan en los hosts de punto final

Un túnel configurado se utiliza actualmente en Internet para otras finalidades, por ejemplo en MBONE, el núcleo multidifusión de IPv4. Desde un punto de vista operativo, el túnel se compone de dos enrutadores que se configuran para tener un vínculo punto a punto virtual entre los dos enrutadores en la red IPv4. Es probable que esta clase de túnel se utilice en Internet en un futuro previsible.

Los túneles automáticos necesitan direcciones compatibles con IPv4. Los túneles automáticos se pueden utilizar para conectar con IPv6 cuando no estén disponibles los enrutadores de IPv6. Estos túneles se pueden originar en un host de pila doble o un enrutador de pila doble configurando una interfaz de red de colocación automática en túneles. Los túneles siempre terminan en el host de pila doble. Estos túneles funcionan determinando dinámicamente la dirección IPv4 de destino, que es el punto final del túnel, extrayendo la dirección de la dirección de destino compatible con IPv4.

Túneles configurados

Las interfaces colocadas en túneles tienen el siguiente formato:

ip.tun ppa

ppa es el punto físico de conexión.

Al iniciar el sistema, se conecta remotamente con el módulo de colocación en túneles (tun) mediante el comando ifconfig, en la parte superior de IP para crear una interfaz virtual. La conexión remota se lleva a cabo creando el correspondiente archivo hostname6.*.

Por ejemplo, para crear un túnel con el fin de encapsular paquetes de IPv6 en una red IPv4, IPv6 sobre IPv4, debe crear el siguiente nombre de archivo:

/etc/hostname6.ip.tun0

El contenido de este archivo se pasa a ifconfig tras la conexión de las interfaces. El contenido se convierte en los parámetros que se necesitan para configurar un túnel de extremo a extremo.

Ejemplo 11–11 Archivo hostname6.ip.tun0 para un túnel IPv6 sobre IPv4

A continuación se muestra un ejemplo de entradas para el archivo hostname6.ip.tun0:

tsrc 10.10.10.23 tdst 172.16.7.19 up
addif 2001:db8:3b4c:1:5678:5678::2 up

En este ejemplo, las direcciones IPv4 de origen y destino se usan como tokens para configurar automáticamente direcciones IPv6 locales de vínculo. Estas direcciones son el origen y destino de la interfaz ip.tun0. Se configuran dos interfaces. Se configura la interfaz ip.tun0. También se configura una interfaz lógica ip.tun0:1. La interfaz lógica tiene las direcciones IPv6 de origen y destino especificadas mediante el comando addif.

El contenido de estos archivos de configuración se pasa al comando ifconfig sin modificarse cuando el sistema se inicia en modo multiusuario. Las entradas del Ejemplo 11–11 equivalen a lo siguiente:

# ifconfig ip.tun0 inet6 plumb
# ifconfig ip.tun0 inet6 tsrc 10.0.0.23 tdst 172.16.7.19 up
# ifconfig ip.tun0 inet6 addif 2001:db8:3b4c:1:5678:5678::2 up

A continuación se muestra la salida del comando ifconfig -a para este túnel.

ip.tun0: flags=2200850<UP,POINTOPOINT,RUNNING,MULTICAST,
  NONUD,IPv6> mtu 1480 index 6
        inet tunnel src 10.0.0.23  tunnel dst 172.16.7.19
        inet6 fe80::c0a8:6417/10 --> fe80::c0a8:713
ip.tun0:1: flags=2200850<UP,POINTOPOINT,RUNNING,MULTICAST,NONUD,IPv6> mtu 1480 
  index 5
        inet6 2001:db8:3b4c:1:5678:5678::2 

Para configurar más interfaces lógicas, agregue líneas al archivo de configuración. Para ello, utilice la siguiente sintaxis:

addif IPv6-source IPv6-destination up

Si cualquiera de los extremos del túnel es un enrutador de IPv6 que anuncia uno o varios prefijos a través del túnel, los comandos addif no se necesitan en los archivos de configuración de túneles. Es posible que sólo hagan falta tsrc y tdst debido a que todas las demás direcciones se configuran automáticamente.

En algunas circunstancias, determinadas direcciones locales de vínculo de origen y destino se deben configurar manualmente para un túnel en concreto. Para incluir estas direcciones locales de vínculo, cambie la primera línea del archivo de configuración. La línea siguiente es a modo de ejemplo:

tsrc 10.0.0.23 tdst 172.16.7.19 fe80::1/10 fe80::2 up

Tenga en cuenta que la longitud del prefijo de la dirección local de vínculo de origen es de 10. En este ejemplo, la interfaz ip.tun0 tiene un aspecto parecido al siguiente:

ip.tun0: flags=2200850<UP,POINTOPOINT,RUNNING,MULTICAST,NONUD,IPv6> mtu 1480 
index 6
        inet tunnel src 10.0.0.23  tunnel dst 172.16.7.19
        inet6 fe80::1/10 --> fe80::2

Para crear un túnel con el fin de encapsular paquetes de IPv6 en una red IPv6, IPv6 sobre IPv6, debe crear el siguiente nombre de archivo:

/etc/hostname6.ip6.tun0

Ejemplo 11–12 Archivo hostname6.ip6.tun0 para un túnel IPv6 sobre IPv6

A continuación se muestra un ejemplo de entradas del archivo hostname6.ip6.tun0 para encapsulado de IPv6 en una red IPv6:

tsrc 2001:db8:3b4c:114:a00:20ff:fe72:668c 
        tdst 2001:db8:15fa:25:a00:20ff:fe9b:a1c3
fe80::4 fe80::61 up

Para crear un túnel con el fin de encapsular paquetes de IPv4 en una red IPv6, IPv4 sobre IPv6, debe crear el siguiente nombre de archivo:

/etc/hostname.ip6.tun0

Ejemplo 11–13 Archivo hostname.ip6.tun0 para un túnel IPv4 sobre IPv6

A continuación se muestra un ejemplo de entradas del archivo hostname6.ip6.tun0 para encapsulado de IPv4 en una red IPv6:

tsrc 2001:db8:3b4c:114:a00:20ff:fe72:668c 
         tdst 2001:db8:15fa:25:a00:20ff:fe9b:a1c3
10.0.0.4 10.0.0.61 up

Para crear un túnel con el fin de encapsular paquetes de IPv4 en una red IPv6, IPv4 sobre IPv4, debe crear el siguiente nombre de archivo:

/etc/hostname.ip.tun0

Ejemplo 11–14 Archivo hostname.ip.tun0 para un túnel IPv4 sobre IPv64

A continuación se muestra un ejemplo de entradas del archivo hostname.ip.tun0 para encapsulado de IPv4 en una red IPv4:

tsrc 172.16.86.158 tdst 192.168.86.122
10.0.0.4 10.0.0.61 up

Para obtener información sobre tun, consulte la página de comando man tun(7M). Para obtener una descripción general sobre los conceptos de la colocación en túneles de IPv6, consulte Descripción general sobre los túneles de IPv6. Para obtener una descripción sobre los procedimientos que seden realizar para configurar túneles, consulte Tareas de configuración de túneles para compatibilidad con IPv6 (mapa de tareas).

Túneles automáticos 6to4

Oracle Solaris incluye túneles 6to4 como método provisional preferido para realizar la transición de direcciones IPv4 a IPv6. Los túneles 6to4 permiten que ubicaciones IPv6 aisladas se comuniquen mediante un túnel automático a través de una red IPv4 que no admite IPv6. Para utilizar túneles 6to4 debe configurar un enrutador de límite de sistema en la red IPv6 como un punto final del túnel automático 6to4. Después, el enrutador 6to4 puede participar en un túnel hasta otra ubicación 6to4, o, si es necesario, hasta un ubicación IPv6 nativa, no 6to4.

Esta sección proporciona material de referencia sobre los siguientes temas 6to4:

• Configuración de un túnel 6to4

• Direcciones 6to4, incluido el formato del anuncio

• Descripción del flujo de paquetes a través de un túnel 6to4

• Configuración de un túnel entre un enrutador 6to4 y un enrutador de reenvío 6to4

• Puntos que considerar antes de configurar la compatibilidad con enrutador de reenvío 6to4

La tabla siguiente describe tareas adicionales para configurar túneles 6to4 y los recursos para obtener información adicional útil.

Configuración de un túnel 6to4

Un túnel 6to4 proporciona conectividad IPv6 a todas las ubicaciones 6to4 en cualquier parte. Asimismo, el túnel ejerce como vínculo con todas las ubicaciones IPv6, incluida Internet IPv6 nativa, siempre que el enrutador se configure para reenviar a un enrutador de repetición. La figura siguiente ilustra la forma en que un túnel 6to4 proporciona esta clase de conectividad entre sitios 6to4.

Figura 11–6 Túnel entre dos ubicaciones 6to4

La figura muestra dos redes 6to4 independientes, Site A y Site B. Cada ubicación tiene configurado un enrutador con una conexión externa a una red IPv4. Un túnel 6to4 en la red IPv4 proporciona una conexión para vincular ubicaciones 6to4.

Antes de que una ubicación IPv6 pueda convertirse en 6to4, debe configurar al menos una interfaz de enrutador para que admite 6to4. Esta interfaz debe proporcionar la conexión externa a la red IPv4. La dirección configurada en qfe0 debe ser única globalmente. En esta figura, la interfaz qfe0 del enrutador de límite de sistema Router A conecta la ubicación Site A con la red IPv4. La interfaz qfe0 ya debe estar configurada con una dirección IPv4 antes de que sea posible configurar qfe0 como una pseudointerfaz 6to4.

En la figura, la ubicación 6to4 Site A está compuesta de dos subredes, que están conectadas a las interfaces hme0 y hme1 del enrutador Router A. Todos los hosts IPv6 de ambas subredes de la ubicación Site A se reconfiguran automáticamente con direcciones derivadas 6to4 al recibir el anuncio del enrutador Router A.

La ubicación Site B es otra ubicación 6to4 aislada. Para recibir correctamente tráfico de la ubicación Site A, se debe configurar un enrutador de límite en la ubicación Site B para admitir 6to4. De no ser así, los paquetes que reciba el enrutador de Site A no se reconocen y se descartan.

Flujo de paquetes a través del túnel 6to4

Esta sección describe el flujo de paquetes entre un hosts en una ubicación 6to4 y un host en una ubicación 6to4 remota. Esta situación hipotética utiliza la topología de la Figura 11–6. En el ejemplo se considera que los enrutadores y hosts 6to4 ya están configurados.

1. Un host en la subred 1 (Subnet 1) de la ubicación 6to4 Site A envía una transmisión, con un host de la ubicación 6to4 Site B como destino. El encabezado de cada paquete tiene una dirección de origen derivada de 6to4 y una dirección de destino derivada de 6to4.

2. El enrutador de la ubicación Site A encapsula cada paquete 6to4 dentro de un encabezado IPv4. En este proceso, el enrutador establece la dirección IPv4 de destino del encabezado de encapsulado en la dirección de enrutador de la ubicación Site B. En cada paquete de IPv6 que pasa por la interfaz de túnel, la dirección de destino de IPv6 también contiene la dirección de destino de IPv4. De este modo, el enrutador puede determinar la dirección IPv4 de destino que se establece en el encabezado de encapsulado. Después, el enrutador utiliza procedimientos estándar IPv4 para reenviar los paquetes a través de la red IPv4.

3. Cualquier enrutador IPv4 que encuentren los paquetes en su camino utilizará la dirección de destino IPv4 del paquete para reenviarlo. Esta dirección es la dirección IPv4 globalmente única de la interfaz del enrutador Router B, que también funciona como pseudo-interfaz 6to4.

4. Los paquetes de Site A llegan al enrutador Router B, que desencapsula los paquetes IPv6 del encabezado IPv4.

5. A continuación, Router B utiliza la dirección de destino del paquete IPv6 para reenviar los paquetes al receptor en Site B.

Consideraciones para túneles hasta un enrutador de reenvío 6to4

Los enrutadores de reenvío 6to4 funcionan como puntos finales para túneles desde enrutadores 6to4 que necesitan comunicarse con redes IPv6 nativas, no 6to4. Los enrutadores de reenvío son básicamente puentes entre la ubicación 6to4 y ubicaciones IPv6 nativas. Debido a que esta solución puede llegar a ser muy insegura, Oracle Solaris no tiene la admisión de enrutadores 6to4 habilitada. No obstante, si es necesario establecer un túnel de este tipo en su ubicación, puede utilizar el comando 6to4relay para activar la situación hipotética siguiente de creación de túneles.

Figura 11–7 Túnel desde una ubicación 6to4 hasta un enrutador de reenvío 6to4

En la Figura 11–7, la ubicación 6to4 Site A necesita comunicarse con un nodo en la ubicación IPv6 nativa Site B. La figura muestra la ruta de tráfico desde Site A hasta un túnel 6to4 a través de una red IPv4. Los puntos finales del túnel son el enrutador 6to4 Router A y un enrutador de reenvío 6to4. Más allá del enrutador de reenvío 6to4 se encuentra la red IPv6, a la que está conectada la ubicación IPv6 Site B.

Flujo de paquetes entre una ubicación 6to4 y una ubicación IPv6 nativa

En esta sección se describe el flujo de paquetes desde una ubicación 6to4 hasta una ubicación IPv6 nativa. Esta situación hipotética utiliza la topología de la Figura 11–7.

1. Un host en la ubicación 6to4 Site A envía una transmisión que especifica como destino un host en la ubicación IPv6 nativa Site B. El encabezado de cada paquete tiene una dirección derivada 6to4 como dirección de destino. La dirección de destino es una dirección IPv6 estándar.

2. El enrutador 6to4 de la ubicación Site A encapsula cada paquete dentro de un encabezado IPv4, que tiene la dirección IPv4 del enrutador de reenvío 6to4 como destino. El enrutador 6to4 utiliza procedimientos IPv4 estándar para reenviar el paquete a través de la red IPv4. Cualquier enrutador IPv4 que encuentren los paquetes en su camino los reenviará al enrutador de reenvío 6to4.

3. El enrutador de reenvío 6to4 de difusión por proximidad más cercano físicamente a la ubicación Site A recibe los paquetes destinados al grupo de difusión por proximidad 192.88.99.1.

   ---

   Nota –

   Los enrutadores de reenvío 6to4 que forman parte del grupo de difusión por proximidad de enrutador de reenvío 6to4 tienen la dirección IP 192.88.99.1. Esta dirección de difusión por proximidad es la dirección predeterminada de enrutadores de reenvío 6to4. Si necesita utilizar un enrutador de reenvío 6to4 específico, puede anular la dirección predeterminada y especificar la dirección IPv4 del enrutador.

   ---

4. El enrutador de reenvío desencapsula el encabezado IPv4 de los paquetes 6to4 y, de este modo, revela la dirección de destino IPv6 nativa.

5. A continuación, el enrutador de reenvío envía los paquetes, que ahora son sólo IPv6, a la red IPv6, donde los recibe un enrutador de la ubicación Site B. El enrutador reenvía los paquetes al nodo IPv6 de destino.

Extensiones de IPv6 para servicios de nombres de Oracle Solaris

En esta sección se describen los cambios de denominación incorporados con la implementación de IPv6. Puede almacenar direcciones IPv6 en cualquiera de los servicios de nombres de Oracle Solaris, NIS, LDAP, DNS y archivos. También puede utilizar NIS en transportes IPv6 RPC para recuperar datos de NIS.

Extensiones de DNS para IPv6

El registro de recursos AAAA, propio de IPv6, se ha especificado en la RFC 1886 DNS Extensions to Support IP Version 6. Este registro AAAA asigna un nombre de host en una dirección IPv6 de 128 bits. El registro PTR se sigue usando en IPv6 para asignar direcciones IP en nombres de host. Las cuatro porciones de 32 bits de las direcciones de 128 bits se invierten para una dirección IPv6. Cada porción se convierte a su correspondiente valor ASCII hexadecimal. A continuación, se agrega ip6.int.

Cambios en el archivo nsswitch.conf

En Solaris 10 11/06 y versiones anteriores, aparte de poder buscar direcciones IPv6 mediante /etc/inet/ipnodes, se ha incorporado la admisión de IPv6 a los nombres de servicios DNS, NIS y LDAP. En consecuencia, se ha modificado el archivo nsswitch.conf para poder realizar búsquedas de IPv6.

hosts:  files dns nisplus [NOTFOUND=return]
ipnodes: files dns nisplus [NOTFOUND=return]

Antes de cambiar el archivo /etc/nsswitch.conf para buscar ipnodes en varios servicios de nombres, debe rellenar estas bases de datos de ipnodes con direcciones IPv4 e IPv6. De lo contrario, pueden darse retrasos innecesarios en la resolución de direcciones de host, incluso en el momento del inicio.

El diagrama siguiente ilustra la relación nueva entre el archivo nsswitch.conf y las nuevas bases de datos de servicios de nombres para aplicaciones que utilizan los comandos gethostbyname y getipnodebyname. Los términos en cursiva son nuevos. El comando gethostbyname comprueba únicamente las direcciones IPv4 almacenadas en /etc/inet/hosts. En Solaris 10 11/06 y versiones anteriores, el comando getipnodebyname consulta la base de datos que se indica en la entrada ipnodes del archivo nsswitch.conf. Si falla la búsqueda, el comando comprueba la base de datos que se indica en la entrada hosts del archivo nsswitch.conf.

Figura 11–8 Relación entre nsswitch.conf y los servicios de nombres

Para obtener más información acerca de los servicios de nombres, consulte la System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Cambios en los comandos de servicio de nombres

Para admitir IPv6, busque direcciones IPv6 con los comandos del servicio de nombres vigente. Por ejemplo, el comando ypmatch funciona con las nuevas asignaciones NIS. El comando nslookup busca los nuevos registros AAAA en DNS.

Admisión de NFS y RPC IPv6

NFS y Remote Procedure Call (RPC) son programas totalmente compatibles con IPv6. No han cambiado los comandos ya existentes relacionados con los servicios de NFS. Además, la mayoría de las aplicaciones RPC también funcionan con IPv6 sin cambios. Es posible que haya que actualizar algunas aplicaciones RPC avanzadas con reconocimiento de transporte.

Admisión de IPv6 en ATM

Oracle Solaris admite IPv6 en ATM, PVC (Permanent Virtual Circuits, circuitos virtuales permanentes) y SVC (Static Switched Virtual Circuits, circuitos virtuales conmutados estáticos).