Esta sección trata sobre los daemons relacionados con IPv6.
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.
Activa la depuración.
Activa la depuración para determinados eventos.
Especifica un archivo cuyos datos de configuración deban leerse, en lugar del archivo predeterminado /etc/inet/ndpd.conf.
Imprime información relativa a cada interfaz.
No efectúa bucles de retorno de anuncios de enrutador.
Hace caso omiso de paquetes recibidos.
Especifica el modo detallado; informa de varios tipos de mensajes de diagnóstico.
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.
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.
n especifica el número de puerto alternativo que se usa para enviar o recibir paquetes de RIPnG.
Suprime información de enrutamiento.
Fuerza la información de enrutamiento aun en caso de que el daemon funcione como enrutador.
Suprime el uso de valores negativos.
Si in.ripngd no funciona como enrutador, el daemon especifica sólo un enrutador predeterminado para cada enrutador.
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.
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.