This section discusses the IPv6-related daemons.
Thein.ndpd daemon implements the IPv6 Neighbor Discovery protocol and router discovery. The daemon also implements address autoconfiguration for IPv6. The following shows the supported options of in.ndpd.
Turns on debugging.
Turns on debugging for specific events.
Specifies a file to read configuration data from, instead of the default /etc/inet/ndpd.conf file.
Prints related information for each interface.
Does not loop back router advertisements.
Ignores received packets.
Specifies verbose mode, reporting various types of diagnostic messages.
Turns on packet tracing.
The in.ndpd daemon is controlled by parameters that are set in the /etc/inet/ndpd.conf configuration file and any applicable parameters in the /var/inet/ndpd_state.interface startup file.
When the /etc/inet/ndpd.conf file exists, the file is parsed and used to configure a node as a router. Table 10–2 lists the valid keywords that might appear in this file. When a host is booted, routers might not be immediately available. Advertised packets by the router might be dropped. Also, advertised packets might not reach the host.
The /var/inet/ndpd_state.interface file is a state file. This file is updated periodically by each node. When the node fails and is restarted, the node can configure its interfaces in the absence of routers. This file contains the interface address, the last time that the file was updated, and how long the file is valid. This file also contains other parameters that are “learned” from previous router advertisements.
You do not need to alter the contents of state files. The in.ndpd daemon automatically maintains state files.
See the in.ndpd(1M) man page and the ndpd.conf(4) man page for lists of configuration variables and allowable values.
The in.ripngd daemon implements the Routing Information Protocol next-generation for IPv6 routers (RIPng). RIPng defines the IPv6 equivalent of RIP. When you configure an IPv6 router with the routeadm command and turn on IPv6 routing, the in.ripngd daemon implements RIPng on the router.
The following shows the supported options of RIPng.
n specifies the alternate port number that is used to send or receive RIPnG packets.
Suppresses routing information.
Forces routing information even if the daemon is acting as a router.
Suppresses use of poison reverse.
If in.ripngd does not act as a router, the daemon enters only a default route for each router.
An IPv6-enabled server application can handle both IPv4 requests and IPv6 requests, or IPv6 requests only. The server always handles requests through an IPv6 socket. Additionally, the server uses the same protocol that the corresponding client uses. To add or modify a service for IPv6, use the commands available from the Service Management Facility (SMF).
For information about the SMF commands, refer to SMF Command-Line Administrative Utilities in System Administration Guide: Basic Administration.
For an example task that uses SMF to configure an IPv4 service manifest that runs over SCTP, refer to How to Add Services That Use the SCTP Protocol.
To configure an IPv6 service, you must ensure that the proto field value in the inetadm profile for that service lists the appropriate value:
For a service that handles both IPv4 and IPv6 requests, choose tcp6, udp6, or sctp. A proto value of tcp6, udp6, or sctp6 causes inetd to pass on an IPv6 socket to the server. The server contains an IPv4-mapped address in case a IPv4 client has a request.
For a service that handles only IPv6 requests, choose tcp6only or udp6only. With either of these values for proto, inetd passes the server an IPv6 socket.
If you replace a Solaris command with another implementation, you must verify that the implementation of that service supports IPv6. If the implementation does not support IPv6, then you must specify the proto value as either tcp, udp, or sctp.
Here is a profile that results from running inetadm for an echo service manifest that supports both IPv4 and IPv6 and runs over 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 |
To change the value of the proto field, use the following syntax:
# inetadm -m FMRI proto="transport-protocols" |
All servers that are provided with Solaris software require only one profile entry that specifies proto as tcp6, udp6, or sctp6. However, the remote shell server (shell) and the remote execution server (exec) now are composed of a single service instance, which requires a proto value containing both the tcp and tcp6only values. For example, to set the proto value for shell, you would issue the following command:
# inetadm -m network/shell:default proto="tcp,tcp6only" |
See IPv6 extensions to the Socket API in Programming Interfaces Guide for more details on writing IPv6-enabled servers that use sockets.
When you add or modify a service for IPv6, keep in mind the following caveats:
You need to specify the proto value as tcp6, sctp6, or udp6 to enable both IPv4 or IPv6 connections. If you specify the value for proto as tcp, sctp, or udp, the service uses only IPv4.
Though you can add a service instance that uses one-to-many style SCTP sockets for inetd, this is not recommended. inetd does not work with one-to-many style SCTP sockets.
If a service requires two entries because its wait-status or exec properties differ, then you must create two instances/services from the original service.