Skip Navigation Links | |
Exit Print View | |
![]() |
System Administration Guide: IP Services Oracle Solaris 11 Express 11/10 |
1. Planning an IPv4 Addressing Scheme (Tasks)
2. Planning an IPv6 Addressing Scheme (Overview)
3. Planning an IPv6 Network (Tasks)
4. Configuring TCP/IP Network Services and IPv4 Addressing (Tasks)
5. Enabling IPv6 on a Network (Tasks)
6. Administering a TCP/IP Network (Tasks)
8. Troubleshooting Network Problems (Tasks)
9. TCP/IP and IPv4 in Depth (Reference)
IPv6 Addressing Formats Beyond the Basics
6to4-Derived Addressing on a Host
IPv6 Multicast Addresses in Depth
Oracle Solaris IPv6 Implementation
/etc/inet/ipaddrsel.conf Configuration File
netstat Command Modifications for IPv6 Support
snoop Command Modifications for IPv6 Support
route Command Modifications for IPv6 Support
ping Command Modifications for IPv6 Support
traceroute Command Modifications for IPv6 Support
in.ndpd Daemon, for Neighbor Discovery
IPv6 Neighbor Discovery Protocol
ICMP Messages From Neighbor Discovery
Obtaining a Router Advertisement
Prefix Configuration Variables
Neighbor Solicitation and Unreachability
Duplicate Address Detection Algorithm
Comparison of Neighbor Discovery to ARP and Related IPv4 Protocols
IPv6 Extensions to Oracle Solaris Name Services
Changes to the nsswitch.conf File
Changes to Name Service Commands
12. Planning for DHCP Service (Tasks)
13. Configuring the DHCP Service (Tasks)
14. Administering DHCP (Tasks)
15. Configuring and Administering the DHCP Client
16. Troubleshooting DHCP (Reference)
17. DHCP Commands and Files (Reference)
18. IP Security Architecture (Overview)
20. IP Security Architecture (Reference)
21. Internet Key Exchange (Overview)
23. Internet Key Exchange (Reference)
24. IP Filter in Oracle Solaris (Overview)
Part IV Networking Performance
26. Integrated Load Balancer Overview
27. Configuration of Integrated Load Balancer Tasks
28. Virtual Router Redundancy Protocol (Overview)
29. VRRP Configuration (Tasks)
30. Implementing Congestion Control
Part V IP Quality of Service (IPQoS)
31. Introducing IPQoS (Overview)
32. Planning for an IPQoS-Enabled Network (Tasks)
33. Creating the IPQoS Configuration File (Tasks)
34. Starting and Maintaining IPQoS (Tasks)
35. Using Flow Accounting and Statistics Gathering (Tasks)
This section describes the files, commands, and daemons that enable IPv6 in Oracle Solaris.
This section describes the configuration files that are part of an IPv6 implementation:
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.
Table 10-2 /etc/inet/ndpd.conf Keywords
|
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.
Table 10-3 /etc/inet/ndpd.conf Interface Configuration Variables
|
The next table shows the variables that are used for configuring IPv6 prefixes.
Table 10-4 /etc/inet/ndpd.conf Prefix Configuration Variables
|
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
The /etc/inet/ipaddrsel.conf file contains the IPv6 default address selection policy table. When you install Oracle Solaris 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.
This section describes commands that are added with the Oracle Solaris IPv6 implementation. The text also describes modifications to existing commands to support IPv6.
The ipaddrsel command enables you to modify the IPv6 default address selection policy table.
The Oracle 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.
Table 10-5 IPv6 Address Selection Policy Table
|
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.
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 ipadm to flag these addresses as preferred. For more information about the ipadm command, refer to the ipadm(1M) man page.
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.
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 Oracle Solaris. 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 Create and Configure an IP Tunnel.
The 6to4relay command has the following syntax:
6to4relay -e [-a IPv4-address] -d -h
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.
Enables support for tunnels between the 6to4 router and a 6to4 relay router with the specified IPv4-address.
Disables support for tunneling to the 6to4 relay router, the default for Oracle Solaris.
Displays help for 6to4relay.
For more information, refer to the 6to4relay(1M) man page.
Example 10-2 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 Oracle Solaris implementation of IPv6.
# /usr/sbin/6to4relay 6to4relay:6to4 Relay Router communication support is disabled
Example 10-3 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-4 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.
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.
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.
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.
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.
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.
This section discusses the IPv6-related daemons.
Thein.ndpd daemon implements the IPv6 Neighbor Discovery protocol and router discovery. The daemon also implements address autoconfiguration for IPv6. The following shows the supported options of in.ndpd.
Turns on debugging.
Turns on debugging for specific events.
Specifies a file to read configuration data from, instead of the default /etc/inet/ndpd.conf file.
Prints related information for each interface.
Does not loop back router advertisements.
Ignores received packets.
Specifies verbose mode, reporting various types of diagnostic messages.
Turns on packet tracing.
The in.ndpd daemon is controlled by parameters that are set in the /etc/inet/ndpd.conf configuration file and any applicable parameters in the /var/inet/ndpd_state.interface startup file.
When the /etc/inet/ndpd.conf file exists, the file is parsed and used to configure a node as a router. Table 10-2 lists the valid keywords that might appear in this file. When a host is booted, routers might not be immediately available. Advertised packets by the router might be dropped. Also, advertised packets might not reach the host.
The /var/inet/ndpd_state.interface file is a state file. This file is updated periodically by each node. When the node fails and is restarted, the node can configure its interfaces in the absence of routers. This file contains the interface address, the last time that the file was updated, and how long the file is valid. This file also contains other parameters that are “learned” from previous router advertisements.
Note - You do not need to alter the contents of state files. The in.ndpd daemon automatically maintains state files.
See the in.ndpd(1M) man page and the ndpd.conf(4) man page for lists of configuration variables and allowable values.
The in.ripngd daemon implements the Routing Information Protocol next-generation for IPv6 routers (RIPng). RIPng defines the IPv6 equivalent of RIP. When you configure an IPv6 router with the routeadm command and turn on IPv6 routing, the in.ripngd daemon implements RIPng on the router.
The following shows the supported options of RIPng.
n specifies the alternate port number that is used to send or receive RIPnG packets.
Suppresses routing information.
Forces routing information even if the daemon is acting as a router.
Suppresses use of poison reverse.
If in.ripngd does not act as a router, the daemon enters only a default route for each router.
An IPv6-enabled server application can handle both IPv4 requests and IPv6 requests, or IPv6 requests only. The server always handles requests through an IPv6 socket. Additionally, the server uses the same protocol that the corresponding client uses. To add or modify a service for IPv6, use the commands available from the Service Management Facility (SMF).
For information about the SMF commands, refer to SMF Command-Line Administrative Utilities in System Administration Guide: Basic Administration.
For an example task that uses SMF to configure an IPv4 service manifest that runs over SCTP, refer to How to Add Services That Use the SCTP Protocol.
To configure an IPv6 service, you must ensure that the proto field value in the inetadm profile for that service lists the appropriate value:
For a service that handles both IPv4 and IPv6 requests, choose tcp6, udp6, or sctp. A proto value of tcp6, udp6, or sctp6 causes inetd to pass on an IPv6 socket to the server. The server contains an IPv4-mapped address in case a IPv4 client has a request.
For a service that handles only IPv6 requests, choose tcp6only or udp6only. With either of these values for proto, inetd passes the server an IPv6 socket.
If you replace an Oracle 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 Oracle Solaris software require only one profile entry that specifies proto as tcp6, udp6, or sctp6. However, the remote shell server (shell) and the remote execution server (exec) now are composed of a single service instance, which requires a proto value containing both the tcp and tcp6only values. For example, to set the proto value for shell, you would issue the following command:
# inetadm -m network/shell:default proto="tcp,tcp6only"
See IPv6 extensions to the Socket API in Programming Interfaces Guide for more details on writing IPv6-enabled servers that use sockets.
When you add or modify a service for IPv6, keep in mind the following caveats:
You need to specify the proto value as tcp6, sctp6, or udp6 to enable both IPv4 or IPv6 connections. If you specify the value for proto as tcp, sctp, or udp, the service uses only IPv4.
Though you can add a service instance that uses one-to-many style SCTP sockets for inetd, this is not recommended. inetd does not work with one-to-many style SCTP sockets.
If a service requires two entries because its wait-status or exec properties differ, then you must create two instances/services from the original service.