Chapter 10 IPv6 in Depth (Reference)

This chapter contains the following reference information about the Solaris 10 IPv6 implementation.

• IPv6 Addressing Formats Beyond the Basics

• IPv6 Packet Header Format

• Dual-Stack Protocols

• Solaris 10 IPv6 Implementation

• IPv6 Neighbor Discovery Protocol

• IPv6 Routing

• IPv6 Tunnels

• IPv6 Extensions to Solaris Name Services

• NFS and RPC IPv6 Support

• IPv6 Over ATM Support

For an overview of IPv6, refer to Chapter 3, Planning an IPv6 Addressing Scheme (Overview). For tasks on configuring an IPv6-enabled network, refer to Chapter 6, Enabling IPv6 on a Network (Tasks).

IPv6 Addressing Formats Beyond the Basics

Chapter 3, Planning an IPv6 Addressing Scheme (Overview) introduces the most common IPv6 addressing formats: unicast site address and link-local address. This section includes in-depth explanations of addressing formats that are not covered in detail in Chapter 3, Planning an IPv6 Addressing Scheme (Overview):

• 6to4-Derived Addresses

• IPv6 Multicast Addresses in Depth

6to4-Derived Addresses

If you plan to configure a 6to4 tunnel from a router or host endpoint, you must advertise the 6to4 site prefix in the /etc/inet/ndpd.conf file on the endpoint system. For an introduction and tasks for configuring 6to4 tunnels, refer to How to Configure a 6to4 Tunnel.

The next figure shows the parts of a 6to4 site prefix.

Figure 10–1 Parts of a 6to4 Site Prefix

The next figure shows the parts of a subnet prefix for a 6to4 site, such as you would include in the ndpd.conf file.

Figure 10–2 Parts of a 6to4 Subnet Prefix

This table explains the parts of a 6to4 subnet prefix.

6to4-Derived Addressing on a Host

When an IPv6 host receives the 6to4-derived prefix by way of a router advertisement, the host automatically reconfigures a 6to4-derived address on an interface. The address has the following format:

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

The output from the ifconfig -a command on a host with a 6to4 interface might resemble the following:

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

In this output, the 6to4-derived address follows inet6.

This table explains the parts of the 6to4-derived address.

IPv6 Multicast Addresses in Depth

The IPv6 multicast address provides a method for distributing identical information or services to a defined group of interfaces, called the multicast group. Typically, the interfaces of the multicast group are on different nodes. An interface can belong to any number of multicast groups. Packets sent to the multicast address go to all members of the multicast group. For example, one use of multicast addresses is for broadcasting information, similar to the capability of the IPv4 broadcast address.

The following table shows the format of the multicast address.

The following is a summary of the contents of each field.

• 11111111 – Identifies the address as a multicast address.

• FLGS – Set of the four flags 0,0,P,T. The first two flags must be zero. The P field has one of the following values:

  • 0 = Multicast address that is not assigned based on the network prefix

  • 1 = Multicast address that is assigned based on the network prefix

  If P is set to 1, then T must also be 1.

• Reserved - Reserved value of zero.

• Plen - Number of bits in the site prefix that identify the subnet, for a multicast address that is assigned based on a site prefix.

• Group ID - Identifier for the multicast group, either permanent or dynamic.

For complete details about the multicast format, refer to RFC 3306, "Unicast-Prefix-based IPv6 Multicast Addresses.

Some IPv6 multicast addresses are permanently assigned by the Internet Assigned Numbers Authority (IANA). Some examples are the All Nodes Multicast Addresses and All Routers Multicast Addresses that are required by all IPv6 hosts and IPv6 routers. IPv6 multicast addresses can also be dynamically allocated. For more information about the proper use of multicast addresses and groups, see RFC 3307, "Allocation Guidelines for IPv6 Multicast Addresses".

IPv6 Packet Header Format

The IPv6 protocol defines a set of headers, including the basic IPv6 header and the IPv6 extension headers. The following figure shows the fields that appear in the IPv6 header and the order in which the fields appear.

Figure 10–3 IPv6 Basic Header Format

The following list describes the function of each header field.

• Version – 4-bit version number of Internet Protocol = 6.

• Traffic class – 8-bit traffic class field.

• Flow label – 20-bit field.

• Payload length – 16-bit unsigned integer, which is the rest of the packet that follows the IPv6 header, in octets.

• Next header – 8-bit selector. Identifies the type of header that immediately follows the IPv6 header. Uses the same values as the IPv4 protocol field.

• Hop limit – 8-bit unsigned integer. Decremented by one by each node that forwards the packet. The packet is discarded if the hop limit is decremented to zero.

• Source address – 128 bits. The address of the initial sender of the packet.

• Destination address – 128 bits. The address of the intended recipient of the packet. The intended recipient is not necessarily the recipient if an optional routing header is present.

IPv6 Extension Headers

IPv6 options are placed in separate extension headers that are located between the IPv6 header and the transport-layer header in a packet. Most IPv6 extension headers are not examined or processed by any router along a packet's delivery path until the packet arrives at its final destination. This feature provides a major improvement in router performance for packets that contain options. In IPv4, the presence of any options requires the router to examine all options.

Unlike IPv4 options, IPv6 extension headers can be of arbitrary length. Also, the number of options that a packet carries is not limited to 40 bytes. This feature, in addition to the manner in which IPv6 options are processed, permits IPv6 options to be used for functions that are not practical in IPv4.

To improve performance when handling subsequent option headers, and the transport protocol that follows, IPv6 options are always an integer multiple of 8 octets long. The integer multiple of 8 octets retains the alignment of subsequent headers.

The following IPv6 extension headers are currently defined:

• Routing – Extended routing, such as IPv4 loose source route

• Fragmentation – Fragmentation and reassembly

• Authentication – Integrity and authentication, and security

• Encapsulating Security Payload – Confidentiality

• Hop-by-Hop options – Special options that require hop-by-hop processing

• Destination options – Optional information to be examined by the destination node

Dual-Stack Protocols

The term dual-stack normally refers to a complete duplication of all levels in the protocol stack from applications to the network layer. One example of complete duplication is a system that runs both the OSI and TCP/IP protocols.

The Solaris OS is dual-stack, meaning that the Solaris OS implements both IPv4 and IPv6 protocols. When you install the operating system, you can choose to enable the IPv6 protocols in the IP layer or use only the default IPv4 protocols. The remainder of the TCP/IP stack is identical. Consequently, the same transport protocols, TCP UDP and SCTP, can run over both IPv4 and IPv6. Also, the same applications can run over both IPv4 and IPv6. Figure 10–4 shows how the IPv4 and IPv6 protocols work as a dual-stack throughout the various layers of the Internet protocol suite.

Figure 10–4 Dual-Stack Protocol Architecture

In the dual-stack scenario, subsets of both hosts and routers are upgraded to support IPv6, in addition to IPv4. The dual-stack approach ensures that the upgraded nodes can always interoperate with IPv4-only nodes by using IPv4.

Solaris 10 IPv6 Implementation

This section describes the files, commands, and daemons that enable IPv6 in the Solaris OS.

IPv6 Configuration Files

This section describes the configuration files that are part of an IPv6 implementation:

• ndpd.conf Configuration File

• IPv6 Interface Configuration File

• /etc/inet/ipaddrsel.conf Configuration File

ndpd.conf Configuration File

The /etc/inet/ndpd.conf file is used to configure options that are used by the in.ndpd Neighbor Discovery daemon. For a router, you primarily use ndpd.conf to configure the site prefix to be advertised to the link. For a host, you use ndpd.conf to turn off address autoconfiguration or to configure temporary addresses.

The next table shows the keywords that are used in the ndpd.conf file.

In the ndpd.conf file, you use the keywords in this table with a set of router configuration variables. These variables are defined in detail in RFC 2461, Neighbor Discovery for IP Version 6 (IPv6).

The next table shows the variables for configuring an interface, along with brief definitions.

The next table shows the variables that are used for configuring IPv6 prefixes.

Example 10–1 /etc/inet/ndpd.conf File

The following example shows how the keywords and configuration variables are used in the ndpd.conf file. Remove the comment (#) to activate the 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

IPv6 Interface Configuration File

IPv6 uses the /etc/hostname6.interface file at start up to automatically define IPv6 logical interfaces. When you select the IPv6 Enabled option during Solaris installation, the installation program creates an /etc/hostname6.interface file for the primary network interface, in addition to the /etc/hostname.interface file.

If more than one physical interface is detected during installation, you are prompted as to whether you want to configure these interfaces. The installation program creates IPv4 physical interface configuration files and IPv6 logical interface configuration files for each additional interface that you indicate.

As with IPv4 interfaces, you can also configure IPv6 interfaces manually, after Solaris installation. You create/etc/hostname6.interface files for the new interfaces. For instructions for manually configuring interfaces, refer to Part I, Administering Single Interfaces, in System Administration Guide: Network Interfaces and Network Virtualization.

The network interface configuration file names have the following syntax:

hostname.interface
hostname6.interface

The interface variable has the following syntax:

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

dev

Indicates a network interface device. The device can be a physical network interface, such as eri or qfe, or a logical interface, such as a tunnel. See IPv6 Interface Configuration File for more details.

Module

Lists one or more STREAMS modules to be pushed onto the device when the device is plumbed.

PPA

Indicates the physical point of attachment.

The syntax [.[.]] is also accepted.

Example 10–2 IPv6 Interface Configuration Files

The following are examples of valid IPv6 configuration file names:

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

/etc/inet/ipaddrsel.conf Configuration File

The /etc/inet/ipaddrsel.conf file contains the IPv6 default address selection policy table. When you install the Solaris OS with IPv6 enabled, this file contains the contents that are shown in Table 10–5.

You can edit the contents of /etc/inet/ipaddrsel.conf. However, in most cases, you should refrain from modifying this file. If modification is necessary, refer to the procedure How to Administer the IPv6 Address Selection Policy Table. For more information on ippaddrsel.conf, refer to Reasons for Modifying the IPv6 Address Selection Policy Table and the ipaddrsel.conf(4) man page.

IPv6-Related Commands

This section describes commands that are added with the Solaris IPv6 implementation. The text also describes modifications to existing commands to support IPv6.

ipaddrsel Command

The ipaddrsel command enables you to modify the IPv6 default address selection policy table.

The Solaris kernel uses the IPv6 default address selection policy table to perform destination address ordering and source address selection for an IPv6 packet header. The /etc/inet/ipaddrsel.conf file contains the policy table.

The following table lists the default address formats and their priorities for the policy table. You can find technical details for IPv6 address selection in the inet6(7P) man page.

In this table, IPv6 prefixes (::1/128 and ::/0) take precedence over 6to4 addresses (2002::/16) and IPv4 addresses (::/96 and ::ffff:0:0/96). Therefore, by default, the kernel selects the global IPv6 address of the interface for packets going to another IPv6 destination. The IPv4 address of the interface has a lower priority, particularly for packets going to an IPv6 destination. Given the selected IPv6 source address, the kernel also uses the IPv6 format for the destination address.

Reasons for Modifying the IPv6 Address Selection Policy Table

Under most instances, you do not need to change the IPv6 default address selection policy table. If you do need to administer the policy table, you use the ipaddrsel command.

You might want to modify the policy table under the following circumstances:

• If the system has an interface that is used for a 6to4 tunnel, you can give higher priority to 6to4 addresses.

• If you want a particular source address to be used only in communications with a particular destination address, you can add these addresses to the policy table. Then, you can use ifconfig to flag these addresses as preferred.

• If you want IPv4 addresses to take precedence over IPv6 addresses, you can change the priority of ::ffff:0:0/96 to a higher number.

• If you need to assign a higher priority to deprecated addresses, you can add the deprecated address to the policy table. For example, site-local addresses are now deprecated in IPv6. These addresses have the prefix fec0::/10. You can change the policy table to give higher priority to site-local addresses.

For details about the ipaddrsel command, refer to the ipaddrsel(1M) man page.

6to4relay Command

6to4 tunneling enables communication between isolated 6to4 sites. However, to transfer packets with a native, non-6to4 IPv6 site, the 6to4 router must establish a tunnel with a 6to4 relay router. The 6to4 relay router then forwards the 6to4 packets to the IPv6 network and ultimately, to the native IPv6 site. If your 6to4-enabled site must exchange data with a native IPv6 site, you use the 6to4relay command to enable the appropriate tunnel.

Because the use of relay routers is insecure, tunneling to a relay router is disabled by default in the Solaris OS. Carefully consider the issues that are involved in creating a tunnel to a 6to4 relay router before deploying this scenario. For detailed information on 6to4 relay routers, refer to Considerations for Tunnels to a 6to4 Relay Router. If you decide to enable 6to4 relay router support, you can find the related procedures in How to Configure a 6to4 Tunnel.

Syntax of 6to4relay

The 6to4relay command has the following syntax:

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

-e

Enables support for tunnels between the 6to4 router and an anycast 6to4 relay router. The tunnel endpoint address is then set to 192.88.99.1, the default address for the anycast group of 6to4 relay routers.

-a IPv4-address

Enables support for tunnels between the 6to4 router and a 6to4 relay router with the specified IPv4-address.

-d

Disables support for tunneling to the 6to4 relay router, the default for the Solaris OS.

-h

Displays help for 6to4relay.

For more information, refer to the 6to4relay(1M) man page.

Example 10–3 Default Status Display of 6to4 Relay Router Support

The 6to4relay command, without arguments, shows the current status of 6to4 relay router support. This example shows the default for the Solaris OS implementation of IPv6.

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

Example 10–4 Status Display With 6to4 Relay Router Support Enabled

If relay router support is enabled, 6to4relay displays the following output:

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

Example 10–5 Status Display With a 6to4 Relay Router Specified

If you specify the -a option and an IPv4 address to the 6to4relay command, the IPv4 address that you give with -a is displayed instead of 192.88.99.1.

6to4relay does not report successful execution of the -d, -e, and-a IPv4 address options. However, 6to4relay does display any error messages that might be generated when you run these options.

ifconfig Command Extensions for IPv6 Support

The ifconfig command enables IPv6 interfaces and the tunneling module to be plumbed. ifconfig uses an extended set of ioctls to configure both IPv4 and IPv6 network interfaces. The following describes ifconfig options that support IPv6 operations. See Monitoring the Interface Configuration With the ifconfig Command for a range of both IPv4 and IPv6 tasks that involve ifconfig.

index

Sets the interface index.

tsrc/tdst

Sets the tunnel source or destination.

addif

Creates the next available logical interface.

removeif

Deletes a logical interface with a specific IP address.

destination

Sets the point-to-point destination address for an interface.

set

Sets an address, netmask, or both for an interface.

subnet

Sets the subnet address of an interface.

xmit/-xmit

Enables or disables packet transmission on an interface.

Chapter 6, Enabling IPv6 on a Network (Tasks) provides IPv6 configuration procedures.

Example 10–6 Adding a Logical IPv6 Interface With the -addif Option of the ifconfig Command

The following form of the ifconfig command creates the hme0:3 logical interface:

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

This form of ifconfig verifies the creation of the new interface:

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

Example 10–7 Removing a Logical IPv6 Interface With the -removeif Option of the ifconfig Command

The following form of the ifconfig command removes the hme0:3 logical interface.

# ifconfig hme0:3 inet6 down

# ifconfig hme0 inet6 removeif 1234::5678

Example 10–8 Using ifconfig to Configure an IPv6 Tunnel Source

# ifconfig ip.tun0 inet6 plumb index 13

Opens the tunnel to be associated with the physical interface name.

# 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 --> :: 

Configures the streams that are needed for TCP/IP to use the tunnel device and report the status of the device.

# ifconfig ip.tun0 inet6 tsrc 120.46.86.158 tdst 120.46.86.122

Configures the source and the destination address for the tunnel.

# 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

Reports the new status of the device after the configuration.

Example 10–9 Configuring a 6to4 Tunnel Through ifconfig (Long Form)

This example of a 6to4 pseudo-interface configuration uses the subnet ID of 1 and specifies the host ID, in hexadecimal form.

# 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 

Example 10–10 Configuring a 6to4 Tunnel Through ifconfig (Short Form)

This example shows the short form for configuring a 6to4 tunnel.

# 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 

netstat Command Modifications for IPv6 Support

The netstat command displays both IPv4 and IPv6 network status. You can choose which protocol information to display by setting the DEFAULT_IP value in the /etc/default/inet_type file or by using the -f command-line option. With a permanent setting of DEFAULT_IP, you can ensure that netstat displays only IPv4 information. You can override this setting by using the -f option. For more information on the inet_type file, see the inet_type(4) man page.

The -p option of the netstat command displays the net-to-media table, which is the ARP table for IPv4 and the neighbor cache for IPv6. See the netstat(1M) man page for details. See How to Display the Status of Sockets for descriptions of procedures that use this command.

snoop Command Modifications for IPv6 Support

The snoop command can capture both IPv4 and IPv6 packets. This command can display IPv6 headers, IPv6 extension headers, ICMPv6 headers, and Neighbor Discovery protocol data. By default, the snoop command displays both IPv4 and IPv6 packets. If you specify the ip or ip6 protocol keyword, the snoop command displays only IPv4 or IPv6 packets. The IPv6 filter option enables you to filter through all packets, both IPv4 and IPv6, displaying only the IPv6 packets. See the snoop(1M) man page for details. See How to Monitor IPv6 Network Traffic for procedures that use the snoop command.

route Command Modifications for IPv6 Support

The route command operates on both IPv4 and IPv6 routes, with IPv4 routes as the default. If you use the -inet6 option on the command line immediately after the route command, operations are performed on IPv6 routes. See the route(1M) man page for details.

ping Command Modifications for IPv6 Support

The ping command can use both IPv4 and IPv6 protocols to probe target hosts. Protocol selection depends on the addresses that are returned by the name server for the specific target host. By default, if the name server returns an IPv6 address for the target host, the ping command uses the IPv6 protocol. If the server returns only an IPv4 address, the ping command uses the IPv4 protocol. You can override this action by using the -A command-line option to specify which protocol to use.

For detailed information, see the ping(1M) man page. For procedures that use ping, refer to Probing Remote Hosts With the ping Command.

traceroute Command Modifications for IPv6 Support

You can use the traceroute command to trace both the IPv4 and IPv6 routes to a specific host. From a protocol perspective, traceroute uses the same algorithm as ping. Use the -A command-line option to override this selection. You can trace each individual route to every address of a multihomed host by using the -a command-line option.

For detailed information, see the traceroute(1M) man page. For procedures that use traceroute, refer to Displaying Routing Information With the traceroute Command.

IPv6-Related Daemons

This section discusses the IPv6-related daemons.

in.ndpd Daemon, for Neighbor Discovery

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.

-d

Turns on debugging.

-D

Turns on debugging for specific events.

-f

Specifies a file to read configuration data from, instead of the default /etc/inet/ndpd.conf file.

-I

Prints related information for each interface.

-n

Does not loop back router advertisements.

-r

Ignores received packets.

-v

Specifies verbose mode, reporting various types of diagnostic messages.

-t

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.

in.ripngd Daemon, for IPv6 Routing

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.

-p n

n specifies the alternate port number that is used to send or receive RIPnG packets.

-q

Suppresses routing information.

-s

Forces routing information even if the daemon is acting as a router.

-P

Suppresses use of poison reverse.

-S

If in.ripngd does not act as a router, the daemon enters only a default route for each router.

inetd Daemon and IPv6 Services

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.

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

• Autoconfiguration Process

• Neighbor Solicitation and Unreachability

• Duplicate Address Detection Algorithm

• Comparison of Neighbor Discovery to ARP and Related IPv4 Protocols

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.

1. A multicast-capable interface is enabled, for example, during system startup of a node.

2. 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.

3. 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.

   1. If another node already uses the proposed address, that node returns a neighbor advertisement stating that the address is already in use.

   2. 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.

4. 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.

5. 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.

Neighbor Solicitation and Unreachability

Neighbor Discovery uses neighbor solicitation messages to determine if more than one node is assigned the same unicast address. Neighbor unreachability detection detects the failure of a neighbor or the failure of the forward path to the neighbor. This detection requires positive confirmation that packets that are sent to a neighbor are actually reaching that neighbor. Neighbor unreachability detection also determines that packets are being processed properly by the node's IP layer.

Neighbor unreachability detection uses confirmation from two sources: upper-layer protocols and neighbor solicitation messages. When possible, upper-layer protocols provide a positive confirmation that a connection is making forward progress. For example, when new TCP acknowledgments are received, it is confirmed that previously sent data has been delivered correctly.

When a node does not get positive confirmation from upper-layer protocols, the node sends unicast neighbor solicitation messages. These messages solicit neighbor advertisements as reachability confirmation from the next hop. To reduce unnecessary network traffic, probe messages are sent only to neighbors to which the node is actively sending packets.

Duplicate Address Detection Algorithm

To ensure that all configured addresses are likely to be unique on a particular link, nodes run a duplicate address detection algorithm on addresses. The nodes must run the algorithm before assigning the addresses to an interface. The duplicate address detection algorithm is performed on all addresses.

The autoconfiguration process that is described in this section applies only to hosts, and not routers. Because host autoconfiguration uses information that is advertised by routers, routers need to be configured by some other means. However, routers generate link-local addresses by using the mechanism that is described in this chapter. In addition, routers are expected to successfully pass the duplicate address detection algorithm on all addresses prior to assigning the address to an interface.

Proxy Advertisements

A router that accepts packets on behalf of a target address can issue non-override neighbor advertisements. The router can accept packets for a target address that is unable to respond to neighbor solicitations. Currently, the use of proxy is not specified. However, proxy advertising can potentially be used to handle cases such as mobile nodes that have moved off-link. Note that the use of proxy is not intended as a general mechanism to handle nodes that do not implement this protocol.

Inbound Load Balancing

Nodes with replicated interfaces might need to load balance the reception of incoming packets across multiple network interfaces on the same link. Such nodes have multiple link-local addresses assigned to the same interface. For example, a single network driver can represent multiple network interface cards as a single logical interface that has multiple link-local addresses.

Load balancing is handled by allowing routers to omit the source link-local address from router advertisement packets. Consequently, neighbors must use neighbor solicitation messages to learn link-local addresses of routers. Returned neighbor advertisement messages can then contain link-local addresses that differ, depending on which issued the solicitation.

Link-Local Address Change

A node that knows its link-local address has been changed can send out multicast unsolicited, neighbor advertisement packets. The node can send multicast packets to all nodes to update cached link-local addresses that have become invalid. The sending of unsolicited advertisements is a performance enhancement only. The detection algorithm for neighbor unreachability ensures that all nodes reliably discover the new address, though the delay might be somewhat longer.

Comparison of Neighbor Discovery to ARP and Related IPv4 Protocols

The functionality of the IPv6 Neighbor Discovery protocol corresponds to a combination of the IPv4 protocols: Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP) Router Discovery, and ICMP Redirect. IPv4 does not have a generally agreed on protocol or mechanism for neighbor unreachability detection. However, host requirements do specify some possible algorithms for dead gateway detection. Dead gateway detection is a subset of the problems that neighbor unreachability detection solves.

The following list compares the Neighbor Discovery protocol to the related set of IPv4 protocols.

• Router discovery is part of the base IPv6 protocol set. IPv6 hosts do not need to snoop the routing protocols to find a router. IPv4 uses ARP, ICMP router discovery, and ICMP redirect for router discovery.

• IPv6 router advertisements carry link-local addresses. No additional packet exchange is needed to resolve the router's link-local address.

• Router advertisements carry site prefixes for a link. A separate mechanism is not needed to configure the netmask, as is the case with IPv4.

• Router advertisements enable address autoconfiguration. Autoconfiguration is not implemented in IPv4.

• Neighbor Discovery enables IPv6 routers to advertise an MTU for hosts to use on the link. Consequently, all nodes use the same MTU value on links that lack a well-defined MTU. IPv4 hosts on the same network might have different MTUs.

• Unlike IPv4 broadcast addresses, IPv6 address resolution multicasts are spread over 4 billion (2^32) multicast addresses, greatly reducing address resolution-related interrupts on nodes other than the target. Moreover, non-IPv6 machines should not be interrupted at all.

• IPv6 redirects contain the link-local address of the new first hop. Separate address resolution is not needed on receiving a redirect.

• Multiple site prefixes can be associated with the same IPv6 network. By default, hosts learn all local site prefixes from router advertisements. However, routers can be configured to omit some or all prefixes from router advertisements. In such instances, hosts assume that destinations are on remote networks. Consequently, hosts send the traffic to routers. A router can then issue redirects, as appropriate.

• Unlike IPv4, the recipient of an IPv6 redirect message assumes that the new next-hop is on the local network. In IPv4, a host ignores redirect messages that specify a next-hop that is not on the local network, according to the network mask. The IPv6 redirect mechanism is analogous to the XRedirect facility in IPv4. The redirect mechanism is useful on non-broadcast and shared media links. On these networks, nodes should not check for all prefixes for local link destinations.

• IPv6 neighbor unreachability detection improves packet delivery in the presence of failing routers. This capability improves packet delivery over partially failing or partitioned links. This capability also improves packet delivery over nodes that change their link-local addresses. For example, mobile nodes can move off the local network without losing any connectivity because of stale ARP caches. IPv4 has no corresponding method for neighbor unreachability detection.

• Unlike ARP, Neighbor Discovery detects half-link failures by using neighbor unreachability detection. Neighbor Discovery avoids sending traffic to neighbors when two-way connectivity is absent.

• By using link-local addresses to uniquely identify routers, IPv6 hosts can maintain the router associations. The ability to identify routers is required for router advertisements and for redirect messages. Hosts need to maintain router associations if the site uses new global prefixes. IPv4 does not have a comparable method for identifying routers.

• Because Neighbor Discovery messages have a hop limit of 255 upon receipt, the protocol is immune to spoofing attacks originating from off-link nodes. In contrast, IPv4 off-link nodes can send ICMP redirect messages. IPv4 off-link nodes can also send router advertisement messages.

• By placing address resolution at the ICMP layer, Neighbor Discovery becomes more media independent than ARP. Consequently, standard IP authentication and security mechanisms can be used.

IPv6 Routing

Routing in IPv6 is almost identical to IPv4 routing under Classless Inter-Domain Routing (CIDR). The only difference is that the addresses are 128-bit IPv6 addresses instead of 32-bit IPv4 addresses. With very straightforward extensions, all of IPv4's routing algorithms, such as OSPF, RIP, IDRP, and IS-IS, can be used to route IPv6.

IPv6 also includes simple routing extensions that support powerful new routing capabilities. The following list describes the new routing capabilities:

• Provider selection that is based on policy, performance, cost, and so on

• Host mobility, route to current location

• Auto-readdressing, route to new address

You obtain the new routing capabilities by creating sequences of IPv6 addresses that use the IPv6 routing option. An IPv6 source uses the routing option to list one or more intermediate nodes, or topological group, to be visited on the way to a packet's destination. This function is very similar in function to IPv4's loose source and record route option.

To make address sequences a general function, IPv6 hosts are required, in most instances, to reverse routes in a packet that a host receives. The packet must be successfully authenticated by using the IPv6 authentication header. The packet must contain address sequences in order to return the packet to its originator. This technique forces IPv6 host implementations to support the handling and reversal of source routes. The handling and reversal of source routes is the key that enables providers to work with hosts that implement the new IPv6 capabilities such as provider selection and extended addresses.

Router Advertisement

On multicast-capable links and point-to-point links, each router periodically sends to the multicast group a router advertisement packet that announces its availability. A host receives router advertisements from all routers, building a list of default routers. Routers generate router advertisements frequently enough so that hosts learn of their presence within a few minutes. However, routers do not advertise frequently enough to rely on an absence of advertisements to detect router failure. A separate detection algorithm that determines neighbor unreachability provides failure detection.

Router Advertisement Prefixes

Router advertisements contain a list of subnet prefixes that is used to determine if a host is on the same link (on-link) as the router. The list of prefixes is also used for autonomous address configuration. Flags that are associated with the prefixes specify the intended uses of a particular prefix. Hosts use the advertised on-link prefixes to build and maintain a list that is used to decide when a packet's destination is on-link or beyond a router. A destination can be on-link even though the destination is not covered by any advertised on-link prefix. In such instances, a router can send a redirect. The redirect informs the sender that the destination is a neighbor.

Router advertisements, and per-prefix flags, enable routers to inform hosts how to perform stateless address autoconfiguration.

Router Advertisement Messages

Router advertisement messages also contain Internet parameters, such as the hop limit, that hosts should use in outgoing packets. Optionally, router advertisement messages also contain link parameters, such as the link MTU. This feature enables the centralized administration of critical parameters. The parameters can be set on routers and automatically propagated to all hosts that are attached.

Nodes accomplish address resolution by sending to the multicast group a neighbor solicitation that asks the target node to return its link-layer address. Multicast neighbor solicitation messages are sent to the solicited-node multicast address of the target address. The target returns its link-layer address in a unicast neighbor advertisement message. A single request-response pair of packets is sufficient for both the initiator and the target to resolve each other's link-layer addresses. The initiator includes its link-layer address in the neighbor solicitation.

IPv6 Tunnels

To minimize any dependencies at a dual-stack, IPv4/IPv6 site, all the routers in the path between two IPv6 nodes do not need to support IPv6. The mechanism that supports such a network configuration is called tunneling. Basically, IPv6 packets are placed inside IPv4 packets, which are then routed through the IPv4 routers. The following figure illustrates the tunneling mechanism through IPv4 routers, which are indicated in the figure by “R.”

Figure 10–5 IPv6 Tunneling Mechanism

The Solaris IPv6 implementation includes two types of tunneling mechanisms:

• Configured tunnels between two routers, as in Figure 10–5

• Automatic tunnels that terminate at the endpoint hosts

A configured tunnel is currently used on the Internet for other purposes, for example, on the MBONE, the IPv4 multicast backbone. Operationally, the tunnel consists of two routers that are configured to have a virtual point-to-point link between the two routers over the IPv4 network. This kind of tunnel is likely to be used on some parts of the Internet for the foreseeable future.

Automatic tunnels require IPv4-compatible addresses. Automatic tunnels can be used to connect IPv6 nodes when IPv6 routers are not available. These tunnels can originate either on a dual-stack host or on a dual-stack router by configuring an automatic tunneling network interface. The tunnels always terminate on the dual-stack host. These tunnels work by dynamically determining the destination IPv4 address, which is the endpoint of the tunnel, by extracting the address from the IPv4-compatible destination address.

Configured Tunnels

Tunneling interfaces have the following format:

ip.tun ppa

ppa is the physical point of attachment.

At system startup, the tunneling module (tun) is pushed, by the ifconfig command, on top of IP to create a virtual interface. The push is accomplished by creating the appropriate hostname6.* file.

For example, to create a tunnel to encapsulate IPv6 packets over an IPv4 network, IPv6 over IPv4, you would create the following file name:

/etc/hostname6.ip.tun0

The content of this file is passed to ifconfig after the interfaces have been plumbed. The content becomes the parameters that are necessary to configure a point-to-point tunnel.

Example 10–11 hostname6.ip.tun0 File for an IPv6 Over IPv4 Tunnel

The following is an example of entries in the hostname6.ip.tun0 file:

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

In this example, the IPv4 source and destination addresses are used as tokens to autoconfigure IPv6 link-local addresses. These addresses are the source and destination for the ip.tun0 interface. Two interfaces are configured. The ip.tun0 interface is configured. A logical interface, ip.tun0:1, is also configured. The logical interface has the source and destination IPv6 addresses specified by the addif command.

The contents of these configuration files are passed to ifconfig without change when the system is started in multiuser mode. The entries in Example 10–11 are equivalent to the following:

# 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

The following shows the output of ifconfig -a for this tunnel.

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 

You can configure more logical interfaces by adding lines to the configuration file by using the following syntax:

addif IPv6-source IPv6-destination up

When either end of the tunnel is an IPv6 router that advertises one or more prefixes over the tunnel, you do not need addif commands in the tunnel configuration files. Only tsrc and tdst might be required because all other addresses are autoconfigured.

In some situations, specific source and destination link-local addresses need to be manually configured for a particular tunnel. Change the first line of the configuration file to include these link-local addresses. The following line is an example:

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

Notice that the source link-local address has a prefix length of 10. In this example, the ip.tun0 interface resembles the following:

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

To create a tunnel to encapsulate IPv6 packets over an IPv6 network, IPv6 over IPv6, you create the following file name:

/etc/hostname6.ip6.tun0

Example 10–12 hostname6.ip6.tun0 File for an IPv6 over IPv6 Tunnel

The following is an example of entries in the hostname6.ip6.tun0 file for IPv6 encapsulation over an IPv6 network:

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

To create a tunnel to encapsulate IPv4 packets over an IPv6 network, IPv4 over IPv6, you would create the following file name:

/etc/hostname.ip6.tun0

Example 10–13 hostname.ip6.tun0 File for an IPv4 Over IPv6 Tunnel

The following is an example of entries in the hostname.ip6.tun0 file for IPv4 encapsulation over an IPv6 network:

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

To create a tunnel to encapsulate IPv4 packets over an IPv4 network, IPv4 over IPv4, you would create the following file name:

/etc/hostname.ip.tun0

Example 10–14 hostname.ip.tun0 for an IPv4 Over IPv4 Tunnel

The following is an example of entries in the hostname.ip.tun0 file for IPv4 encapsulation over an IPv4 network:

tsrc 172.16.86.158 tdst 192.168.86.122
10.0.0.4 10.0.0.61 up

For specific information about tun, see the tun(7M) man page. .For a general description of tunneling concepts during the transition to IPv6, see Overview of IPv6 Tunnels. For a description of procedures for configuring tunnels, see Tasks for Configuring Tunnels for IPv6 Support (Task Map).

6to4 Automatic Tunnels

The Solaris OS includes 6to4 tunnels as a preferred interim method for making the transition from IPv4 to IPv6 addressing. 6to4 tunnels enable isolated IPv6 sites to communicate across an automatic tunnel over an IPv4 network that does not support IPv6. To use 6to4 tunnels, you must configure a boundary router on your IPv6 network as one endpoint of the 6to4 automatic tunnel. Thereafter, the 6to4 router can participate in a tunnel to another 6to4 site, or, if required, to a native IPv6, non-6to4 site.

This section provides reference materials on the following 6to4 topics:

• Topology of a 6to4 tunnel

• 6to4 addressing, including the format of the advertisement

• Description of the packet flow across a 6to4 tunnel

• Topology of a tunnel between a 6to4 router and a 6to4 relay router

• Points to consider before you configure 6to4 relay router support

More information about 6to4 routing is available from the following sources.

Topology of a 6to4 Tunnel

A 6to4 tunnel provides IPv6 connectivity to all 6to4 sites everywhere. Likewise, the tunnel also functions a link to all IPv6 sites, including the native IPv6 internet, provided that the tunnel is configured to forward to a relay router. The following figure shows how a 6to4 tunnel provides this connectivity between 6to4 sites.

Figure 10–6 Tunnel Between Two 6to4 Sites

The figure depicts two isolated 6to4 networks, Site A and Site B. Each site has configured a router with an external connection to an IPv4 network. A 6to4 tunnel across the IPv4 network provides a connection to link 6to4 sites.

Before an IPv6 site can become a 6to4 site, you must configure at least one router interface for 6to4 support. This interface must provide the external connection to the IPv4 network. The address that you configure on qfe0 must be globally unique. In this figure, boundary Router A's interface qfe0 connects Site A to the IPv4 network. Interface qfe0 must already be configured with an IPv4 address before you can configure qfe0 as a 6to4 pseudo-interface.

In the figure, 6to4 Site A is composed of two subnets, which are connected to interfaces hme0 and hme1 on Router A. All IPv6 hosts on either subnet of Site A automatically reconfigure with 6to4-derived addresses upon receipt of the advertisement from Router A.

Site B is another isolated 6to4 site. To correctly receive traffic from Site A, a boundary router on Site B must be configured for 6to4 support. Otherwise, packets that the router receives from Site A are not recognized and are then dropped.

Packet Flow Through the 6to4 Tunnel

This section describes the flow of packets from a host at one 6to4 site to a host at a remote 6to4 site. This scenario uses the topology that is shown in Figure 10–6. Moreover, the scenario assumes that the 6to4 routers and the 6to4 hosts are already configured.

1. A host on Subnet 1 of 6to4 Site A sends a transmission, with a host at 6to4 Site B as the destination. Each packet header has a 6to4-derived source address and 6to4-derived destination address.

2. Site A's router encapsulates each 6to4 packet within an IPv4 header. In this process, the router sets the IPv4 destination address of the encapsulating header to Site B's router address. For each IPv6 packet that flows through the tunnel interface, the packet's IPv6 destination address also contains the IPv4 destination address. Thus, the router is able to determine the IPv4 destination address that is set on the encapsulating header. Then, the router uses standard IPv4 routing procedures to forward the packet over the IPv4 network.

3. Any IPv4 routers that the packets encounter use the packets' IPv4 destination address for forwarding. This address is the globally unique IPv4 address of the interface on Router B, which also serves as the 6to4 pseudo-interface.

4. Packets from Site A arrive at Router B, which decapsulates the IPv6 packets from the IPv4 header.

5. Router B then uses the destination address in the IPv6 packet to forward the packets to the recipient host at Site B.

Considerations for Tunnels to a 6to4 Relay Router

6to4 relay routers function as endpoints for tunnels from 6to4 routers that need to communicate with native IPv6, non-6to4 networks. Relay routers are essentially bridges between the 6to4 site and native IPv6 sites. Because this solution might be insecure, by default, the Solaris OS does not enable 6to4 relay router support. However, if your site requires such a tunnel, you can use the 6to4relay command to enable the following tunneling scenario.

Figure 10–7 Tunnel From a 6to4 Site to a 6to4 Relay Router

In Figure 10–7, 6to4 Site A needs to communicate with a node at the native IPv6 Site B. The figure shows the path of traffic from Site A onto a 6to4 tunnel over an IPv4 network. The tunnel has 6to4 Router A and a 6to4 relay router as its endpoints. Beyond the 6to4 relay router is the IPv6 network, to which IPv6 Site B is connected.

Packet Flow Between a 6to4 Site and a Native IPv6 Site

This section describes the flow of packets from a 6to4 site to a native IPv6 site. This scenario uses the topology that is shown in Figure 10–7.

1. A host on 6to4 Site A sends a transmission that specifies as the destination a host at native IPv6 Site B. Each packet header has a 6to4-derived address as its source address. The destination address is a standard IPv6 address.

2. Site A's 6to4 router encapsulates each packet within an IPv4 header, which has the IPv4 address of the 6to4 relay router as its destination. The 6to4 router uses standard IPv4 routing procedures to forward the packet over the IPv4 network. Any IPv4 routers that the packets encounter forward the packets to the 6to4 relay router.

3. The physically closest anycast 6to4 relay router to Site A retrieves the packets that are destined for the 192.88.99.1 anycast group.

   ---

   Note –

   6to4 relay routers that are part of the 6to4 relay router anycast group have the IP address 192.88.99.1. This anycast address is the default address for 6to4 relay routers. If you need to use a specific 6to4 relay router, you can override the default and specify that router's IPv4 address.

   ---

4. The relay router decapsulates the IPv4 header from the 6to4 packets, revealing the native IPv6 destination address.

5. The relay router then sends the now IPv6-only packets onto the IPv6 network, where the packets are ultimately retrieved by a router at Site B. The router then forwards the packets to the destination IPv6 node.

IPv6 Extensions to Solaris Name Services

This section describes naming changes that were introduced by the implementation of IPv6. You can store IPv6 addresses in any of the Solaris naming services, NIS, LDAP, DNS, and files. You can also use NIS over IPv6 RPC transports to retrieve any NIS data.

DNS Extensions for IPv6

An IPv6-specific resource record, the AAAA resource record, has been specified by in RFC 1886 DNS Extensions to Support IP Version 6. This AAAA record maps a host name into a 128 bit IPv6 address. The PTR record is still used with IPv6 to map IP addresses into host names. The 32 four bit nibbles of the 128 bit address are reversed for an IPv6 address. Each nibble is converted to its corresponding hexadecimal ASCII value. Then, ip6.int is appended.

Changes to the nsswitch.conf File

IPv6 support has been added to the NIS, LDAP, and DNS name services. Consequently, the nsswitch.conf file has been modified to support IPv6 lookups.

The following diagram shows the new relationship between the nsswitch.conf file and the new name services databases for applications that use the gethostbyname and getipnodebyname commands. Items in italics are new. The gethostbyname command checks only for IPv4 addresses that are stored in /etc/inet/hosts. If the lookup fails, then the command checks the database that is specified in the hosts entry in the nsswitch.conf file.

Figure 10–8 Relationship Between nsswitch.conf and Name Services

For more information on name services, see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Changes to Name Service Commands

To support IPv6, you can look up IPv6 addresses with the existing name service commands. For example, the ypmatch command works with the new NIS maps. The nslookup command can look up the new AAAA records in DNS.

NFS and RPC IPv6 Support

NFS software and Remote Procedure Call (RPC) software support IPv6 in a seamless manner. Existing commands that are related to NFS services have not changed. Most RPC applications also run on IPv6 without any change. Some advanced RPC applications with transport knowledge might require updates.

IPv6 Over ATM Support

The Solaris OS supports IPv6 over ATM, permanent virtual circuits (PVC), and static switched virtual circuits (SVC).