Chapter 16 IPv6 Files and Commands (Reference)

The Solaris implementation of IPv6 consists primarily of changes to the TCP/IP stack, both at the kernel and user level. New IPv6 modules enable tunneling, router discovery, and stateless address autoconfiguration. This chapter describes the concepts that are associated with the Solaris implementation of IPv6.

This chapter contains the following information:

• Overview of the Solaris IPv6 Implementation

• IPv6 Network Interface Configuration File

• Nodes With Multiple Network Interfaces

• IPv6 Daemons

• IPv6 Extensions to Existing Utilities

• Controlling Display Output

• Solaris Tunneling Interfaces for IPv6

• IPv6 Extensions to Solaris Name Services

• NFS and RPC IPv6 Support

• IPv6–Over-ATM Support

Overview of the Solaris IPv6 Implementation

As a part of the IPv4 to IPv6 transition, IPv6 specifies methods for encapsulating IPv6 packets within IPv4 packets. IPv6 also specifies IPv6 packets that are encapsulated within IPv6 packets. Consequently, a new module, tun(7M), which performs the actual packet encapsulation, has been added. This module, which is known as the tunneling module, is plumbed and is configured by using the ifconfig utility the same as any physical interface. This module enables the tunneling module to be pushed between IP device and IP module. Tunneling devices also have entries in the system interface list.

The ifconfig(1M) utility is also modified. You use this utility to create the IPv6 stack. This utility also supports new parameters that are described in this chapter.

The in.ndpd(1M) daemon is added to perform router discovery and stateless address autoconfiguration.

IPv6 Network Interface Configuration File

IPv6 uses the file /etc/hostname6.interface at start up to automatically define network interfaces in the same way IPv4 uses /etc/hostname.interface. A minimum of one /etc/hostname.* or /etc/hostname6.* file should exist on the local machine. The Solaris installation program creates these files for you. In the file name, replace interface with the device name of the primary network interface.

The file name has the following syntax:

hostname.interface
hostname6.interface

Interface has the following syntax:

dev[.Module[.Module ...]]PPA

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

The following list shows examples of valid file names:

hostname6.le0
hostname6.ip.tun0
hostname.ip.tun0

IPv6 Interface Configuration File Entry

The autoconfiguration of interfaces in IPv6 enables a node to compute its own link-local address that is based on its link-layer address. Consequently, the interface configuration file for IPv6 might not have an entry. In this instance, the startup scripts configure an interface. The node then “learns” of other addresses and prefixes through the neighbor discovery daemon, in.ndpd. If you require static addresses for an interface, use the ifconfig utility. Consequently, the address or host name is stored in /etc/hostname6.interface (or /etc/hostname.interface. The content is passed to ifconfig when the interface is configured.

In this instance, the file contains only one entry. The entry is the host name or IP address that is associated with the network interface. For example, suppose smc0 is the primary network interface for a machine that is called ahaggar. The /etc/hostname6.* file for the interface would have the name /etc/hostname6.smc0. The file would contain the entry ahaggar.

The networking start up script examines the number of interfaces and the existence of the /etc/inet/ndpd.conf file to start routing daemons and packet forwarding. See How to Configure a Solaris IPv6 Router.

IPv6 Extensions to the ifconfig Utility

The ifconfig utility now enables IPv6 interfaces and the tunneling module to be plumbed. The ifconfig(1M) utility uses an extended set of ioctls to configure both IPv4 and IPv6 network interfaces. The following table shows the set of options that are added to this utility. See How to Display Interface Address Assignments for a description of useful diagnostic procedures that use this utility.

Enabling IPv6 Nodes provides IPv6 configuration procedures.

Examples—New ifconfig Utility Options

The following usage of the ifconfig command creates the hme0:3 logical interface to the 1234::5678/64 IPv6 address. This command enables the interface with the up option. The command also reports status. The command disables the interface. Finally, the command deletes the interface.

Example 16–1 Examples—Using addif and removeif

# ifconfig hme0 inet6 addif 1234::5678/64 up
Created new logical interface hme0:3

# ifconfig hme0:3 inet6
hme0:3: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
		inet6 1234::5678/64 

# ifconfig hme0:3 inet6 down

# ifconfig hme0 inet6 removeif 1234::5678

The following usage of the ifconfig command opens the device that is associated with the physical interface name. The command configures the streams that are needed for TCP/IP to use the device. The command reports the status of the device. The command configures the source and the destination address for the tunnel. Finally, the command reports the new status of the device after the configuration.

Example 16–2 Examples—Using tsrc/tdst and index

# ifconfig ip.tun0 inet6 plumb index 13

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

# ifconfig ip.tun0 inet6 tsrc 120.46.86.158 tdst 120.46.86.122

# 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

Nodes With Multiple Network Interfaces

If a node contains more than one network interface, you must create additional /etc/hostname.interface files for the additional network interfaces.

IPv4 Behavior

For example, consider the system timbuktu, which is shown in Figure 4–1. This system has two network interfaces. This system also functions as a router. The primary network interface le0 is connected to network 192.9.200. The IP address of the system is 192.9.200.70. The host name for the system is timbuktu. The Solaris installation program creates the /etc/hostname.le0 file for the primary network interface. The installation program also enters the timbuktu host name in the file.

The second network interface is le1. This interface is connected to network 192.9.201. Although this interface is physically installed on the timbuktu system, the interface must have a separate IP address. Therefore, you have to create manually the /etc/hostname.le1 file for this interface. The entry in the file is the name of the router, timbuktu-201.

IPv6 Behavior

If IPv6 is to be configured, only the interfaces for /etc/hostname6.le0 and /etc/hostname6.le1 must exist. Each interface address is configured automatically when the system is started.

IPv6 Daemons

This section describes the following IPv6 daemons:

• in.ndpd – Daemon for IPv6 autoconfiguration

• in.ripngd – Network routing daemon for IPv6

• inetd – Internet services daemon

in.ndpd Daemon

This daemon implements router discovery and auto-address configuration for IPv6. The following table shows the supported options.

Parameters control the actions in.ndpd. Those parameters are set in the /etc/inet/ndpd.conf configuration file and the /var/inet/ndpd_state.interface startup file (if the parameters exist).

When the /etc/inet/ndpd.conf file exists, the file is parsed and used to configure a node as a router. The following table lists the valid keywords that might appear in this file. When a host is booted, routers might not be immediately available, or advertised packets by the router might be dropped and 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 time that the file is 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 the state files. The in.ndpd daemon automatically maintains the state files.

The ifdefault/prefixdefault entries must precede the if and prefix entries in the configuration file.

See the in.ndpd(1M) man page and see also the ndpd.conf(4) man page for a list of configuration variables and allowable values.

Example—/etc/inet/ndpd.conf File

The following example provides a template of commented lines and also shows an example of how the keywords and configuration variables are used.

# 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 qe2 AdvSendAdvertisements 1
prefix 2:0:0:54::/64 qe2
prefix fec0:0:0:54::/64 qe2

in.ripngd Daemon

The in.ripngd daemon implements the RIP next-generation routing protocol for IPv6 routers. RIP next generation defines the IPv6 equivalent of RIP. RIP is a widely used IPv4 routing protocol that is based on the Bellman-Ford distance vector algorithm. The following table shows the supported options.

inetd Internet Services Daemon

An IPv6–enabled server is a server that can handle IPv4 or IPv6 addresses. The server uses the same protocol that the corresponding client uses. The /etc/inet/inetd.conf file contains the list of servers that inetd(1M) invokes when this daemon receives an Internet request over a socket. Each socket-based Internet server entry is composed of a single line that uses the following syntax:

service_name socket_type proto flags user server_pathname args

See the inetd.conf(4) man page for a description of the possible values for each field. In the Solaris operating environment, to specify a service as IPv6-enabled in the /etc/inet/inetd.conf file, you must specify the proto field as tcp6 or udp6. If the service is IPv4-only, the proto field must be specified as tcp or udp. By specifying a proto value of tcp6 or udp6 for a service, inetd passes the specific daemon an AF_INET6 socket.

The following entry in the inetd.conf file depicts a udp server (myserver) that can communicate with both IPv4 and IPv6 client applications.

Example 16–3 Server Communicating With Both IPv4 and IPv6 Client Applications

myserver   dgram   udp6	wait	root	/usr/sbin/myserver	myserver

An IPv6–enabled server can inherit an AF_INET (IPv4 only) or an AF_INET6 (IPv6 and IPv4) socket from inetd. The proto value for the service is specified as either tcp6 (udp6) or tcp (udp). For these types of servers, you can also specify two inetd.conf entries. You can specify proto as tcp. You can also specify proto as tcp6.

Because AF_INET6 sockets work with either the IPv4 or IPv6 protocols, specifying a proto value of tcp6 (udp6) is sufficient.

See Programming Interfaces Guide for details on writing various types of IPv6–enabled servers.

All servers that are provided with Solaris software require only one inetd entry that specifies proto as tcp6 or udp6. However, the remote shell server (shell) and the remote execution server (exec) must have an entry for both the tcp and tcp6 proto values. The following example shows the inetd entries for rlogin, telnet, shell, and exec.

Example 16–4 inetd.conf Entries for Servers Provided With Solaris Software

login stream	tcp6 nowait root  /usr/sbin/in.rlogind  in.rlogind
telnet stream	tcp6 nowait root /usr/sbin/in.telnetd in.telnetd
shell	stream	tcp	nowait	root	/usr/sbin/in.rshd	in.rshd
shell	stream	tcp6	nowait	root	/usr/sbin/in.rshd	in.rshd
exec	stream	tcp	nowait	root	/usr/sbin/in.rexecd	in.rexecd
exec	stream	tcp6	nowait	root	/usr/sbin/in.rexecd	in.rexecd

TCP Wrappers are a public domain utility that is used to monitor and to filter incoming requests for various network services, such as telnet. If you specify TCP Wrappers as the server_pathname for any of these services, you must ensure that TCP Wrappers are IPv6 capable. Otherwise, you must specify proto as tcp or udp for those services that are being used with TCP Wrappers.

In addition, if you replace a Solaris utility with another implementation, you must verify if the implementation of that service supports IPv6. If the implementation does not support IPv6, then you must specify the proto value as either tcp or udp.

If you specify proto as tcp or udp only, the service uses only IPv4. You need to specify proto as tcp6 or udp6 to enable either IPv4 or IPv6 connections. If the service does not support IPv6, then do not specify tcp6 or udp6.

See IPv6 extensions to the Socket API in Programming Interfaces Guide for more details on writing IPv6 enabled servers that use sockets.

IPv6 Extensions to Existing Utilities

User-level interface changes also include extensions to the following utilities:

• netstat(1M)

• snoop(1M)

• route(1M)

• ping(1M)

• traceroute(1M)

The ifconfig(1M) utility has also changed. See IPv6 Extensions to the ifconfig Utility for a description.

netstat(1M)

In addition to displaying IPv4 network status, netstat can display IPv6 network status as well. You can choose which protocol information to display by setting the DEFAULT_IP value in the /etc/default/inet_type file and 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 with the -f option. For more information on the inet_type file, see the inet_type(4) man page.

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

snoop(1M)

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. By specifying the ip or ip6 protocol keywords, 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 Only IPv6 Network Traffic for a description of procedures that use this command.

route(1M)

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

ping(1M)

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.

Additionally, you can ping all the addresses of a multihomed target host by using the -a command-line option. See the ping(1M) man page for details. See How to Probe All Multihomed Host Addresses for a description of a procedure that uses this command.

traceroute(1M)

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. See the traceroute(1M) man page for details.

Controlling Display Output

You can control how the netstat and ifconfig commands display output:

• Use keywords that are added to the command line to specify either inet or inet6 addresses.

• Set the configuration variable DEFAULT_IP in the /etc/default/inet_type file.

You can set the value of DEFAULT_IP to IP_VERSION4, IP_VERSION6, or BOTH. If you do not create this file by specifying the DEFAULT_IP, then netstat and ifconfig displays both versions.

The inet or inet6 keyword option overrides the value that is set in the inet_type file when you use the netstat and ifconfig commands.

See How to Control the Display Output of IPv6 Related Commands for a description of procedures.

Solaris Tunneling Interfaces for IPv6

Tunneling interfaces have the following format:

ip.tun ppa

ppa is the physical point of attachment.

The Solaris software does not yet support encapsulating packets within IPv6 packets.

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

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

/etc/hostname6.ip.tun0

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

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

Example 16–5 hostname6.interface Entries

tsrc 120.68.100.23 tdst 120.68.7.19 up
addif 1234:1234::1 5678:5678::2 up

In this example, the IPv4 source and destination addresses are used as tokens to autoconfigure IPv6 link-local addresses of the source and destination for the ip.tun0 interface. Two interfaces are configured, the ip.tun0 interface, and a logical interface (ip.tun0:1) that has the source and destination IPv6 addresses specified by the addif command.

As mentioned previously, the contents of these configuration files are passed to ifconfig without change when the system is started as multiuser. The previous example is equivalent to the following:

# ifconfig ip.tun0 inet6 plumb
# ifconfig ip.tun0 inet6 tsrc 120.68.100.23 tdst 120.68.7.19 up
# ifconfig ip.tun0 inet6 addif 1234:1234::1 5678:5678::2 up

The following display 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 120.68.100.23  tunnel dst 120.68.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 1234:1234::1/128 --> 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

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 120.68.100.23 tdst 120.68.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 120.68.100.23  tunnel dst 120.68.7.19
        inet6 fe80::1/10 --> fe80::2

For specific information about tun, see the tun(7M) man page. For a general description of tunneling concepts during the transition to IPv6, see Tunneling Mechanism. For a description of a procedure for configuring tunnels, see How to Configure IPv6 Over IPv4 Tunnels.

IPv6 Extensions to Solaris Name Services

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

/etc/inet/ipnodes File

The /etc/inet/ipnodes file stores both IPv4 and IPv6 addresses. This file serves as a local database that associates the names of hosts with their IPv4 and IPv6 addresses. You should not store host names and their addresses in static files, such as /etc/inet/ipnodes. However, for testing purposes, store IPv6 addresses in a file in the same way that IPv4 addresses are stored in /etc/inet/hosts. The ipnodes file uses the same format convention as the hosts file. See Network Databases for a description of the hosts file. See ipnodes(4) man page for a description of the ipnodes file.

IPv6–aware utilities use the new /etc/inet/ipnodes database. The existing /etc/hosts database, which contains only IPv4 addresses, remains the same to facilitate existing applications. If the ipnodes database does not exist, IPv6–aware utilities use the existing hosts database.

If you need to add addresses, you must add IPv4 addresses to both the hosts and ipnodes files. You add only IPv6 addresses to the ipnodes file.

Example—/etc/inet/ipnodes File

#
# Internet IPv6 host table
# with both IPv4 and IPv6 addresses
#
::1     localhost
2::9255:a00:20ff:fe78:f37c   fripp.guitars.com fripp fripp-v6
fe80::a00:20ff:fe78:f37c     fripp-11.guitars.com frippll
120.46.85.87   				 fripp.guitars.com fripp fripp-v4
2::9255:a00:20ff:fe87:9aba   strat.guitars.com strat strat-v6
fe80::a00:20ff:fe87:9aba     strat-11.guitars.com stratll
120.46.85.177  				 strat.guitars.com strat strat-v4 loghost

You must group host name addresses by the host name, as shown in the previous example.

NIS Extensions for IPv6

Two new maps have been added for NIS: ipnodes.byname and ipnodes.byaddr. Similar to /etc/inet/ipnodes, these maps contain both IPv4 and IPv6 information. The hosts.byname and hosts.byaddr maps contain only IPv4 information. These maps remain the same to facilitate existing applications.

NIS+ Extensions for IPv6

A new table has been added for NIS+ named ipnodes.org_dir. The table contains both IPv4 and IPv6 addresses for a host. The hosts.org_dir table contains only IPv4 addresses for a host. This table remains the same to facilitate existing applications.

DNS Extensions for IPv6

A new resource record that is defined as an AAAA record has been specified by RFC 1886. This AAAA record maps a host name into an 128–bit IPv6 address. The PTR record is still used with IPv6 to map IP addresses into host names. The thirty two 4–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

In addition to the capability of looking up IPv6 addresses through /etc/inet/ipnodes, IPv6 support has been added to the NIS, NIS+, and DNS name services. Consequently, the nsswitch.conf(4) file has been modified to support IPv6 lookups. An ipnodes line has been added to the /etc/nsswitch.conf file. This addition enables you to perform lookups in the new databases for each of the Solaris Name Services (NIS, NIS+, DNS, and files). The following bold line shows an example of the ipnodes entry:

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

Before changing the /etc/nsswitch.conf file to search ipnodes in multiple name services, populate these ipnodes databases with IPv4 and IPv6 addresses. Otherwise, unnecessary delays can result in the resolution of host addresses (including possible boot-timing delays).

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. The getipnodebyname() command consults the database that is specified in the ipnodes entry in the nsswitch.conf file. If the lookup fails, then the command consults the database that is specified in the hosts entry in the nsswitch.conf file.

Figure 16–1 Relationship Between nsswitch.conf and Name Services

For more information on Naming Services, see System Administration Guide: Naming and Directory Services.

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 nismatch command works with the new NIS+ tables. The nslookup command can look up the new AAAA records in DNS. For a description of the changes to the name services see NIS Extensions for IPv6, NIS+ Extensions for IPv6, and DNS Extensions for IPv6.

For a description of procedures that use these commands, see Displaying IPv6 Name Service Information.

NFS and RPC IPv6 Support

NFS software and 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 operating environment now supports IPv6–over-ATM a permanent virtual circuits (PVCs) and a static switched virtual circuits (SVC).