Previous
Considerations When Configuring a Service for IPv6
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.
IPv6 Neighbor Discovery Protocol
IPv6 introduces the Neighbor Discovery protocol, as described in RFC 2461, Neighbor Discovery for IP Version 6 (IPv6). For an overview of major Neighbor Discovery features, refer to IPv6 Neighbor Discovery Protocol Overview.
This section discusses the following features of the Neighbor Discovery protocol:
ICMP Messages From Neighbor Discovery
Neighbor Discovery defines five new Internet Control Message Protocol (ICMP) messages. The messages serve the following purposes:
Router solicitation - When an interface becomes enabled, hosts can send router solicitation messages. The solicitations request routers to generate router advertisements immediately, rather than at their next scheduled time.
Router advertisement - Routers advertise their presence, various link parameters, and various Internet parameters. Routers advertise either periodically, or in response to a router solicitation message. Router advertisements contain prefixes that are used for on-link determination or address configuration, a suggested hop-limit value, and so on.
Neighbor solicitation - Nodes send neighbor solicitation messages to determine the link-layer address of a neighbor. Neighbor solicitation messages are also sent to verify that a neighbor is still reachable by a cached link-layer address. Neighbor solicitations are also used for duplicate address detection.
Neighbor advertisement - A node sends neighbor advertisement messages in response to a neighbor solicitation message. The node can also send unsolicited neighbor advertisements to announce a link-layer address change.
Redirect - Routers use redirect messages to inform hosts of a better first hop for a destination, or that the destination is on the same link.
Autoconfiguration Process
This section provides an overview of the typical steps that are performed by an interface during autoconfiguration. Autoconfiguration is performed only on multicast-capable links.
A multicast-capable interface is enabled, for example, during system startup of a node.
The node begins the autoconfiguration process by generating a link-local address for the interface.
The link-local address is formed from the Media Access Control (MAC) address of the interface.
The node sends a neighbor solicitation message that contains the tentative link-local address as the target.
The purpose of the message is to verify that the prospective address is not already in use by another node on the link. After verification, the link-local address can be assigned to an interface.
If another node already uses the proposed address, that node returns a neighbor advertisement stating that the address is already in use.
If another node is also attempting to use the same address, the node also sends a neighbor solicitation for the target.
The number of neighbor solicitation transmissions or retransmissions, and the delay between consecutive solicitations, are link specific. You can set these parameters, if necessary.
If a node determines that its prospective link-local address is not unique, autoconfiguration stops. At that point, you must manually configure the link-local address of the interface.
To simplify recovery, you can supply an alternate interface ID that overrides the default identifier. Then, the autoconfiguration mechanism can resume by using the new, presumably unique, interface ID.
When a node determines that its prospective link-local address is unique, the node assigns the address to the interface.
At this point, the node has IP-level connectivity with neighboring nodes. The remaining autoconfiguration steps are performed only by hosts.
Obtaining a Router Advertisement
The next phase of autoconfiguration involves obtaining a router advertisement or determining that no routers are present. If routers are present, the routers send router advertisements that specify what type of autoconfiguration a host should perform.
Routers send router advertisements periodically. However, the delay between successive advertisements is generally longer than a host that performs autoconfiguration can wait. To quickly obtain an advertisement, a host sends one or more router solicitations to the all-routers multicast group.
Prefix Configuration Variables
Router advertisements also contain prefix variables with information that stateless address autoconfiguration uses to generate prefixes. The Stateless Address Autoconfiguration field in router advertisements are processed independently. One option field that contains prefix information, the Address Autoconfiguration flag, indicates whether the option even applies to stateless autoconfiguration. If the option field does apply, additional option fields contain a subnet prefix with lifetime values. These values indicate the length of time that addresses created from the prefix remain preferred and valid.
Because routers periodically generate router advertisements, hosts continually receive new advertisements. IPv6-enabled hosts process the information that is contained in each advertisement. Hosts add to the information. They also refresh the information that is received in previous advertisements.
Address Uniqueness
For security reasons, all addresses must be tested for uniqueness prior to their assignment to an interface. The situation is different for addresses that are created through stateless autoconfiguration. The uniqueness of an address is determined primarily by the portion of the address that is formed from an interface ID. Thus, if a node has already verified the uniqueness of a link-local address, additional addresses need not be tested individually. The addresses must be created from the same interface ID. In contrast, all addresses that are obtained manually should be tested individually for uniqueness. System administrators at some sites believe that the overhead of performing duplicate address detection outweighs its benefits. For these sites, the use of duplicate address detection can be disabled by setting a per-interface configuration flag.
To accelerate the autoconfiguration process, a host can generate its link-local address, and verify its uniqueness, while the host waits for a router advertisement. A router might delay a response to a router solicitation for a few seconds. Consequently, the total time necessary to complete autoconfiguration can be significantly longer if the two steps are done serially.