System Administration Guide: IP Services

Part II TCP/IP Administration

This part contains tasks and conceptual information for configuring, administering, and troubleshooting TCP/IP networks.

Chapter 2 Planning Your TCP/IP Network (Tasks)

This chapter describes the issues you must resolve in order to create your network in an organized, cost-effective manner. After you resolve these issues, you can devise a network plan as you configure and administer your network in the future.

This chapter contains the following information:

For tasks for configuring a network, refer to Chapter 5, Configuring TCP/IP Network Services and IPv4 Addressing (Tasks).

Network Planning (Task Map)

The following table lists different tasks for configuring the network. The table includes a description of what each task accomplishes and the section in the current documentation where the specific steps to perform the task are detailed.

Task 

Description 

For Information 

1. Plan your hardware requirements and network topology 

Determine the types of equipment that you need and the layout of this equipment at your site. 

2. Obtain a registered IP address for your network 

Your network must have a unique IP address if you plan to communicate outside your local network, for example, over the Internet. 

Refer to Obtaining Your Network's IP Number.

3. Devise an IP addressing scheme for your systems, based on your IPv4 network prefix or IPv6 site prefix. 

Determine how addresses are to be deployed at your site. 

Refer to Designing an IPv4 Addressing Scheme or refer to Preparing an IPv6 Addressing Plan.

4. Create a list that contains the IP addresses and host names of all machines on your network.  

Use the list to build network databases 

Refer to Network Databases

5. Determine which name service to use on your network.  

Decide whether to use NIS, LDAP, DNS, or the network databases in the local /etc directory.

Refer to Selecting a Name Service and Directory Service

6. Establish administrative subdivisions, if appropriate for your network 

Decide if your site requires that you divide your network into administrative subdivisions 

Refer to Administrative Subdivisions

7. Determine where to place routers in the network design. 

If your network is large enough to require routers, create a network topology that supports them. 

Refer to Planning for Routers on Your Network

8. If required, design a strategy for subnets. 

You might need to create subnets for administering your IP address space or to make more IP addresses available for users. 

For IPv4 subnet planning, refer to What Is Subnetting?

For IPv6 subnet planning, refer to Creating a Numbering Scheme for Subnets

Determining the Network Hardware

When you design your network, you must decide what type of network best meets the needs of your organization. Some of the planning decisions you must make involve the following network hardware:

Based on these factors, you can determine the size of your local area network.


Note –

How you plan the network hardware is outside the scope of this manual. For assistance, refer to the manuals that come with your hardware.


Deciding on an IP Addressing Format for Your Network

The number of systems that you expect to support affects how you configure your network. Your organization might require a small network of several dozen standalone systems that are located on one floor of a single building. Alternatively, you might need to set up a network with more than 1,000 systems in several buildings. This setup can require you to further divide your network into subdivisions that are called subnets.

When you plan your network addressing scheme, consider the following factors:

The worldwide growth of the Internet since 1990 has resulted in a shortage of available IP addresses. To remedy this situation, the Internet Engineering Task Force (IETF) has developed a number of IP addressing alternatives. Types of IP addresses in use today include the following:

If your organization has been assigned more than one IP address for your network or uses subnets, appoint a centralized authority within your organization to assign network IP addresses. That authority should maintain control of a pool of assigned network IP addresses, and assign network, subnet, and host addresses as required. To prevent problems, ensure that duplicate or random network numbers do not exist in your organization.

IPv4 Addresses

These 32-bit addresses are the original IP addressing format that was designed for TCP/IP. Originally, IP networks have three classes, A, B, and C. The network number that is assigned to a network reflects this class designation plus 8 or more bits to represent a host. Class-based IPv4 addresses require you to configure a netmask for the network number. Furthermore, to make more addresses available for systems on the local network, these addresses were often divided into subnets.

Today, IP addresses are referred to as IPv4 addresses. Although you can no longer obtain class-based IPv4 network numbers from an ISP, many existing networks still have them. For more information about administering IPv4 addresses, refer to Designing Your IPv4 Addressing Scheme.

IPv4 Addresses in CIDR Format

The IETF has developed Classless Inter-Domain Routing (CIDR) addresses as a short to medium term fix for the shortage of IPv4 addresses. In addition, CIDR format was designed as a remedy to the lack of capacity of the global Internet routing tables. An IPv4 address with CIDR notation is 32 bits in length and has the same dotted decimal format. However, CIDR adds a prefix designation after the rightmost byte to define the network portion of the IPv4 address. For more information, refer to Designing Your CIDR IPv4 Addressing Scheme.

DHCP Addresses

The Dynamic Host Configuration Protocol (DHCP) protocol enables a system to receive configuration information from a DHCP server, including an IP address, as part of the booting process. DHCP servers maintain pools of IP address from which to assign addresses to DHCP clients. A site that uses DHCP can use a smaller pool of IP addresses than would be needed if all clients were assigned a permanent IP address. You can set up the Oracle Solaris DHCP service to manage your site's IP addresses, or a portion of the addresses. For more information, refer to Chapter 12, About Oracle Solaris DHCP (Overview).

IPv6 Addresses

The IETF has deployed 128–bit IPv6 addresses as the long term solution to the shortage of available IPv4 addresses. IPv6 addresses provide greater address space than is available with IPv4. Oracle Solaris supports IPv4 and IPv6 addressing on the same host, through the use of dual-stack TCP/IP. As with IPv4 addresses in CIDR format, IPv6 addresses have no notion of network classes or netmasks. As in CIDR, IPv6 addresses use prefixes to designate the portion of the address that defines the site's network. For an introduction to IPv6, refer to IPv6 Addressing Overview.

Private Addresses and Documentation Prefixes

The IANA has reserved a block of IPv4 addresses and an IPv6 site prefix for use on private networks. You can deploy these addresses on systems within an enterprise network but be aware that packets with private addresses cannot be routed across the Internet. For more information on private addresses, refer to Using Private IPv4 Addresses.


Note –

Private IPv4 addresses are also reserved for documentation purposes. The examples in this book use private IPv4 addresses and the reserved IPv6 documentation prefix.


Obtaining Your Network's IP Number

An IPv4 network is defined by a combination of an IPv4 network number plus a network mask, or netmask. An IPv6 network is defined by its site prefix, and, if subnetted, its subnet prefix.

Unless your network plans to be private in perpetuity, your local users most likely need to communicate beyond the local network. Therefore, you must obtain a registered IP number for your network from the appropriate organization before your network can communicate externally. This address becomes the network number for your IPv4 addressing scheme or the site prefix for your IPv6 addressing scheme.

Internet Service Providers provide IP addresses for networks with pricing that is based on different levels of service. Investigate with various ISPs to determine which provides the best service for your network. ISP's typically offer dynamically allocated addresses or static IP addresses to businesses. Some ISPs offer both IPv4 and IPv6 addresses.

If your site is an ISP, you obtain IP address blocks for your customers from the Internet Registry (IR) for your locale. The Internet Assigned Numbers Authority (IANA) is ultimately responsible for delegating registered IP addresses to IRs around the world. Each IR has registration information and templates for the locale that the IR services. For information about the IANA and its IRs, refer to the IANA's IP Address Service page.


Note –

Do not arbitrarily assign IP addresses to your network, even if you are not currently attaching the network to external TCP/IP networks. Instead, use private addresses as described in Using Private IPv4 Addresses.


Designing an IPv4 Addressing Scheme


Note –

For IPv6 address planning information, refer to Preparing an IPv6 Addressing Plan.


This section gives an overview IPv4 addressing to aid you in designing an IPv4 addressing plan. For information on IPv6 addresses, see IPv6 Addressing Overview. For information on DHCP addresses, see Chapter 12, About Oracle Solaris DHCP (Overview).

Each IPv4-based network must have the following:

The IPv4 address is a 32-bit number that uniquely identifies a network interface on a system, as explained in How IP Addresses Apply to Network Interfaces. An IPv4 address is written in decimal digits, divided into four 8-bit fields that are separated by periods. Each 8-bit field represents a byte of the IPv4 address. This form of representing the bytes of an IPv4 address is often referred to as the dotted-decimal format.

The following figure shows the component parts of an IPv4 address, 172.16.50.56.

Figure 2–1 IPv4 Address Format

The figure divides the IPv4 address into two parts, network
part and network host, which are described in the next context.

172.16

Registered IPv4 network number. In class-based IPv4 notation, this number also defines the IP network class, Class B in this example, that would have been registered by the IANA.

50.56

Host part of the IPv4 address. The host part uniquely identifies an interface on a system on a network. Note that for each interface on a local network, the network part of the address is the same, but the host part must be different.

If you plan to subnet a class-based IPv4 network, you need to define a subnet mask, or netmask, as explained in netmasks Database.

The next example shows of the CIDR format address 192.168.3.56/22

Figure 2–2 CIDR Format IPv4 Address

The figure shows the three parts of the CIDR address,
network part, host part, and network prefix, which are described in the next
context.

192.168.3

Network part, which consists of the IPv4 network number that is received from an ISP or IR.

56

Host part, which you assign to an interface on a system.

/22

Network prefix, which defines how many bits of the address comprise the network number. The network prefix also provides the subnet mask for the IP address. Network prefixes are also assigned by the ISP or IR.

An Oracle Solaris-based network can combine standard IPv4 addresses, CIDR format IPv4 addresses, DHCP addresses, IPv6 addresses, and private IPv4 addresses.

Designing Your IPv4 Addressing Scheme

This section describes the classes into which standard IPv4 address are organized. Though the IANA no longer gives out class-based network numbers, these network numbers are still in use on many networks. You might need to administer the address space for a site with class-based network numbers. For a complete discussion of IPv4 network classes, refer to Network Classes.

The following table shows the division of the standard IPv4 address into network and host address spaces. For each class, “Range” specifies the range of decimal values for the first byte of the network number. “Network Address” indicates the number of bytes of the IPv4 address that are dedicated to the network part of the address. Each byte is represented by xxx. “Host Address” indicates the number of bytes that are dedicated to the host part of the address. For example, in a class A network address, the first byte is dedicated to the network, and the last three bytes are dedicated to the host. The opposite designation is true for a class C network.

Table 2–1 Division of the IPv4 Classes

Class 

Byte Range 

Network Number 

Host Address 

A

0–127  

xxx

xxx.xxx.xxx

B

128–191  

xxx.xxx

xxx.xxx

C

192–223  

xxx.xxx.xxx

xxx

The numbers in the first byte of the IPv4 address define whether the network is class A, B, or C. The remaining three bytes have a range from 0–255. The two numbers 0 and 255 are reserved. You can assign the numbers 1–254 to each byte, depending on the network class that was assigned to your network by the IANA.

The following table shows which bytes of the IPv4 address are assigned to you. The table also shows the range of numbers within each byte that are available for you to assign to your hosts.

Table 2–2 Range of Available IPv4 Classes

Network Class 

Byte 1 Range 

Byte 2 Range 

Byte 3 Range  

Byte 4 Range 

A

0–127 

1–254 

1–254  

1–254 

B

128–191 

Preassigned by IANA 

1–254 

1–254 

C

192–223 

Preassigned by IANA 

Preassigned by IANA 

1–254 

IPv4 Subnet Number

Local networks with large numbers of hosts are sometimes divided into subnets. If you divide your IPv4 network number into subnets, you need to assign a network identifier to each subnet. You can maximize the efficiency of the IPv4 address space by using some of the bits from the host part of the IPv4 address as a network identifier. When used as a network identifier, the specified part of the address becomes the subnet number. You create a subnet number by using a netmask, which is a bitmask that selects the network and subnet parts of an IPv4 address. Refer to Creating the Network Mask for IPv4 Addresses for details.

Designing Your CIDR IPv4 Addressing Scheme

The network classes that originally constituted IPv4 are no longer in use on the global Internet. Today, the IANA distributes classless CIDR format addresses to its registries around the world. Any IPv4 address that you obtain from an ISP is in CIDR format, as shown in Figure 2–2.

The network prefix of the CIDR address indicates how many IPv4 addresses are available for hosts on your network. Note that these host addresses are assigned to interfaces on a host. If a host has more than one physical interface, you need to assign a host address for every physical interface that is in use.

The network prefix of a CIDR address also defines the length of the subnet mask. Most Oracle Solaris 10 commands recognize the CIDR prefix designation of a network's subnet mask. However, the Oracle Solaris installation program and /etc/netmask file require you to set the subnet mask by using dotted decimal representation. In these two cases, use the dotted decimal representation of the CIDR network prefix, as shown in the next table.

Table 2–3 CIDR Prefixes and Their Decimal Equivalent

CIDR Network Prefix 

Available IP Addresses 

Dotted Decimal Subnet Equivalent 

/19 

8,192  

255.255.224.0 

/20 

4,096  

255.255.240.0 

/21 

2,048 

255.255.248.0 

/22 

1024 

255.255.252.0 

/23 

512 

255.255.254.0 

/24 

256 

255.255.255.0 

/25 

128 

255.255.255.128 

/26 

64 

255.255.255.192 

/27 

32 

255.255.255.224 

For more information on CIDR addresses, refer to the following sources:

Using Private IPv4 Addresses

The IANA has reserved three blocks of IPv4 addresses for companies to use on their private networks. These addresses are defined in RFC 1918, Address Allocation for Private Internets. You can use these private addresses, also known as 1918 addresses, for systems on local networks within a corporate intranet. However, private addresses are not valid on the Internet. Do not use them on systems that must communicate outside the local network.

The following table lists the private IPv4 address ranges and their corresponding netmasks.

IPv4 Address Range 

netmask 

10.0.0.0 - 10.255.255.255 

10.0.0.0 

172.16.0.0 - 172.31.255.255 

172.16.0.0 

192.168.0.0 - 192.168.255.255 

192.168.0.0 

How IP Addresses Apply to Network Interfaces

To connect to the network, a system must have at least one physical network interface. Each network interface must have its own unique IP address. During Oracle Solaris installation, you must supply the IP address for the first interface that the installation program finds. Usually that interface has the name device-name0, for example eri0 or hme0. This interface is considered the primary network interface.

If you add a second network interface to a host, that interface also must have its own unique IP address. When you add the second network interface, the host then becomes multihomed. By contrast, when you add a second network interface to a host and enable IP forwarding, that host becomes a router. See Configuring an IPv4 Router for an explanation.

Each network interface has a device name, a device driver, and an associated device file in the /devices directory. The network interface might have a device name such as eri or smc0, which are device names for two commonly used Ethernet interfaces.

For information and tasks related to interfaces, refer to Administering Interfaces in Solaris 10 3/05 or Chapter 6, Administering Network Interfaces (Tasks).


Note –

This book assumes that your systems have Ethernet network interfaces. If you plan to use different network media, refer to the manuals that come with the network interface for configuration information.


Naming Entities on Your Network

After you receive your assigned network IP address and you have given the IP addresses to your systems, the next task is to assign names to the hosts. Then you must determine how to handle name services on your network. You use these names initially when you set up your network and later when you expand your network through routers, bridges, or PPP.

The TCP/IP protocols locate a system on a network by using its IP address. However, if you use a recognizable name, then you can easily identify the system. Therefore, the TCP/IP protocols (and Oracle Solaris) require both the IP address and the host name to uniquely identify a system.

From a TCP/IP perspective, a network is a set of named entities. A host is an entity with a name. A router is an entity with a name. The network is an entity with a name. A group or department in which the network is installed can also be given a name, as can a division, a region, or a company. In theory, the hierarchy of names that can be used to identify a network has virtually no limit. The domain name identifies a domain.

Administering Host Names

Many sites let users pick host names for their machines. Servers also require at least one host name, which is associated with the IP address of its primary network interface.

As a system administrator, you must ensure that each host name in your domain is unique. In other words, no two machines on your network can both have the name “fred.” However, the machine “fred” might have multiple IP addresses.

When planning your network, make a list of IP addresses and their associated host names for easy access during the setup process. The list can help you verify that all host names are unique.

Selecting a Name Service and Directory Service

Oracle Solaris enables you to use three types of name services: local files, NIS, and DNS. Name services maintain critical information about the machines on a network, such as the host names, IP addresses, Ethernet addresses, and so forth. Oracle Solaris also gives you the option of using the LDAP directory service in addition to or instead of a name service. For an introduction to name services on Oracle Solaris, refer to Part I, About Naming and Directory Services, in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Network Databases

When you install the operating system, you supply the host name and IP address of your server, clients, or standalone system as part of the procedure. The Oracle Solaris installation program adds this information into the hosts and, in Solaris 10 11/06 and earlier Solaris 10 releases, the ipnodes network database. This database is part of a set of network databases that contain information necessary for TCP/IP operation on your network. The name service that you select for your network reads these databases.

The configuration of the network databases is critical. Therefore, you need to decide which name service to use as part of the network planning process. Moreover, the decision to use name services also affects whether you organize your network into an administrative domain. Network Databases and the nsswitch.conf File has detailed information on the set of network databases.

Using NIS or DNS as the Name Service

The NIS and DNS name services maintain network databases on several servers on the network. System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) describes these name services and explains how to configure the databases. In addition, the guide explain the “namespace” and “administrative domain” concepts in detail.

Using Local Files as the Name Service

If you do not implement NIS, LDAP, or DNS, the network uses local files to provide the name service. The term “local files” refers to the series of files in the /etc directory that the network databases use. The procedures in this book assume you are using local files for your name service, unless otherwise indicated.


Note –

If you decide to use local files as the name service for your network, you can set up another name service at a later date.


Domain Names

Many networks organize their hosts and routers into a hierarchy of administrative domains. If you are using the NIS or DNS name service, you must select a domain name for your organization that is unique worldwide. To ensure that your domain name is unique, you should register the domain name with the InterNIC. If you plan to use DNS, you also need to register your domain name with the InterNIC.

The domain name structure is hierarchical. A new domain typically is located below an existing, related domain. For example, the domain name for a subsidiary company can be located below the domain of the parent company. If the domain name has no other relationship, an organization can place its domain name directly under one of the existing top-level domains.

The following are a few examples of top-level domains:

You select the name that identifies your organization, with the provision that the name must be unique.

Administrative Subdivisions

The question of administrative subdivisions deals with matters of size and control. The more hosts and servers that you have in a network, the more complex your management task. You might want to handle such situations by setting up additional administrative divisions. Add networks of a particular class. Divide existing networks into subnets. The decision about setting up administrative subdivisions for your network is determined by the following factors:

Planning for Routers on Your Network

Recall that in TCP/IP, two types of entities exist on a network: hosts and routers. All networks must have hosts, while not all networks require routers. The physical topology of the network determines if you need routers. This section introduces the concepts of network topology and routing. These concepts are important when you decide to add another network to your existing network environment.


Note –

For complete details and tasks for router configuration on IPv4 networks, refer to Packet Forwarding and Routing on IPv4 Networks. For complete details and tasks for router configuration on IPv6 networks, refer to Configuring an IPv6 Router.


Network Topology Overview

Network topology describes how networks fit together. Routers are the entities that connect networks to each other. A router is any machine that has two or more network interfaces and implements IP forwarding. However, the system cannot function as a router until properly configured, as described in Configuring an IPv4 Router.

Routers connect two or more networks to form larger internetworks. The routers must be configured to pass packets between two adjacent networks. The routers also should be able to pass packets to networks that lie beyond the adjacent networks.

The following figure shows the basic parts of a network topology. The first illustration shows a simple configuration of two networks that are connected by a single router. The second illustration shows a configuration of three networks, interconnected by two routers. In the first example, Router R joins Network 1 and Network 2 into a larger internetwork. In the second example, Router R1 connects Networks 1 and 2. Router R2 connects Networks 2 and 3. The connections form a network that includes Networks 1, 2, and 3.

Figure 2–3 Basic Network Topology

Diagram shows the topology of two networks that are connected
by a single router.

In addition to joining networks into internetworks, routers route packets between networks that are based on the addresses of the destination network. As internetworks grow more complex, each router must make more and more decisions about the packet destinations.

The following figure shows a more complex case. Router R3 directly connects networks 1 and 3. The redundancy improves reliability. If network 2 goes down, router R3 still provides a route between networks 1 and 3. You can interconnect many networks. However, the networks must use the same network protocols.

Figure 2–4 A Network Topology That Provides an Additional Path Between Networks

Diagram shows the topology of three networks that are
connected by two routers.

How Routers Transfer Packets

The IP address of the recipient, which is a part of the packet header, determines how the packet is routed. If this address includes the network number of the local network, the packet goes directly to the host with that IP address. If the network number is not the local network, the packet goes to the router on the local network.

Routers maintain routing information in routing tables. These tables contain the IP address of the hosts and routers on the networks to which the router is connected. The tables also contain pointers to these networks. When a router receives a packet, the router checks its routing table to determine if the table lists the destination address in the header. If the table does not contain the destination address, the router forwards the packet to another router that is listed in its routing table. Refer to Configuring an IPv4 Router for detailed information on routers.

The following figure shows a network topology with three networks that are connected by two routers.

Figure 2–5 A Network Topology With Three Interconnected Networks

Diagram shows a sample of three networks that are connected
by two routers.

Router R1 connects networks 192.9.200 and 192.9.201. Router R2 connects networks 192.9.201 and 192.9.202. If Host A on network 192.9.200 sends a message to Host B on network 192.9.202, the following events occur:

  1. Host A sends a packet out over network 192.9.200. The packet header contains the IPv4 address of the recipient Host B, 192.9.202.10.

  2. None of the machines on network 192.9.200 has the IPv4 address 192.9.202.10. Therefore, Router R1 accepts the packet.

  3. Router R1 examines its routing tables. No machine on network 192.9.201 has the address 192.9.202.10. However, the routing tables do list Router R2.

  4. R1 then selects R2 as the “next hop” Router. R1 sends the packet to R2.

  5. Because R2 connects network 192.9.201 to 192.9.202, R2 has routing information for Host B. Router R2 then forwards the packet to network 192.9.202, where Host B accepts the packet.

Chapter 3 Introducing IPv6 (Overview)

This chapter presents an overview of the Oracle Solaris Internet Protocol version 6 (IPv6) implementation. This implementation includes the associated daemon and utilities that support the IPv6 address space.

IPv6 and IPv4 addresses coexist in the Oracle Solaris networking environment. Systems that are configured with IPv6 addresses retain their IPv4 addresses, if these addresses already exist. Operations that involve IPv6 addresses do not adversely affect IPv4 operations, and vice versa.

The following major topics are discussed:

For more detailed information about IPv6, consult the following chapters.

Major Features of IPv6

The defining feature of IPv6 is increased address space in comparison to IPv4. IPv6 also improves Internet capabilities in numerous areas, as outlined in this section.

Expanded Addressing

IP address size increases from 32 bits in IPv4 to 128 bits in IPv6, to support more levels of addressing hierarchy. In addition, IPv6 provides many more addressable IPv6 systems. For more information, see IPv6 Addressing Overview.

Address Autoconfiguration and Neighbor Discovery

The IPv6 Neighbor Discovery (ND) protocol facilitates the autoconfiguration of IPv6 addresses. Autoconfiguration is the ability of an IPv6 host to automatically generate its own IPv6 address, which makes address administration easier and less time-consuming. For more information, see IPv6 Address Autoconfiguration.

The Neighbor Discovery protocol corresponds to a combination of these IPv4 protocols: Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP), Router Discovery (RDISC), and ICMP Redirect. IPv6 routers use Neighbor Discovery to advertise the IPv6 site prefix. IPv6 hosts use Neighbor Discovery for various purposes, which include soliciting the prefix from an IPv6 router. For more information, see IPv6 Neighbor Discovery Protocol Overview.

Header Format Simplification

The IPv6 header format either drops or makes optional certain IPv4 header fields. This change keeps the bandwidth cost of the IPv6 header as low as possible, despite the increased address size. Even though IPv6 addresses are four times longer than IPv4 addresses, the IPv6 header is only twice the size of the IPv4 header.

Improved Support for IP Header Options

Changes in the way IP header options are encoded allow for more efficient forwarding. Also, IPv6 options have less stringent limits on their length. The changes provide greater flexibility for introducing new options in the future.

Application Support for IPv6 Addressing

Many critical Oracle Solaris network services recognize and support IPv6 addresses, for example:

Additional IPv6 Resources

In addition to this Part, you can obtain information about IPv6 from the sources that are listed in the following sections.

IPv6 Requests for Comments and Internet Drafts

Many RFCs are available regarding IPv6. The following table lists the major IPv6 articles and their Internet Engineering Task Force (IETF) web locations as of this writing.

Table 3–1 IPv6–Related RFCs and Internet Drafts

RFC or Internet Draft 

Subject 

Location 

RFC 2461, Neighbor Discovery for IP Version 6 (IPv6)

Describes the features and functions of IPv6 Neighbor Discovery protocol 

http://www.ietf.org/rfc/rfc2461.txt$number=2461

RFC 3306, Unicast—Prefix—Based IPv6 Multicast Addresses

Describes the format and types of IPv6 multicast addresses 

ftp://ftp.rfc-editor.org/in-notes/rfc3306.txt

RFC 3484: Default Address Selection for Internet Protocol version 6 (IPv6)

Describes the algorithms used in IPv6 default address selection 

http://www.ietf.org/rfc/rfc3484?number=3484

RFC 3513, Internet Protocol version 6 (IPv6) Addressing Architecture

Contains complete details about the types of IPv6 addresses and includes many examples 

http://www.ietf.org/rfc/rfc3513.txt?number=3513

RFC 3587, IPv6 Global Unicast Address Format

Defines the standard format for IPv6 unicast addresses 

http://www.ietf.org/rfc/rfc3587.txt?number=3587

Web Sites

The following web sites provide useful information about IPv6.

Table 3–2 IPv6–Related Web Sites

Web Site 

Description 

Location 

IPv6 Forum 

Links to IPv6–related presentations, events, classes, and implementations worldwide are available from this society's web site 

http://www.ipv6forum.com

Internet Educational Task Force IPv6 Working Group 

Links to all relevant IPv6 RFCs and Internet Drafts are on the home page of this IETF working group 

http://www.ietf.org/html.charters/ipv6-charter.html

IPv6 Network Overview

This section introduces terms that are fundamental to the IPv6 network topology. The following figure shows the basic parts of an IPv6 network.

Figure 3–1 Basic Components of an IPv6 Network

The following text describes the figure.

The figure depicts an IPv6 network and its connection to an ISP. The internal network consists of Links 1, 2, 3, and 4. Each link is populated by hosts and terminated by a router. Link 4, which is the network's DMZ, is terminated on one end by the boundary router. The boundary router runs an IPv6 tunnel to an ISP, which provides Internet connectivity for the network. Links 2 and 3 are administered as Subnet 8a. Subnet 8b consists only of systems on Link 1. Subnet 8c is contiguous with the DMZ on Link 4.

As illustrated in Figure 3–1, an IPv6 network has essentially the same components as an IPv4 network. However, IPv6 terminology differs slightly from IPv4 terminology. Here is a list of familiar terms for network components as they are used in an IPv6 context.

node

Any system with an IPv6 address and interface that is configured for IPv6 support. This generic term applies to both hosts and routers.

IPv6 router

A node that forwards IPv6 packets. At least one of the router's interfaces must be configured for IPv6 support. An IPv6 router can also advertise the registered IPv6 site prefix for the enterprise over the internal network.

IPv6 host

A node with an IPv6 address. An IPv6 host can have more than one interface that is configured for IPv6 support. As in IPv4, IPv6 hosts do not forward packets.

link

A single, contiguous network medium that is bounded on either end by a router.

neighbor

An IPv6 node that is on the same link as the local node.

IPv6 subnet

The administrative segment of an IPv6 network. Components of an IPv6 subnet can directly correspond to all nodes on a link, as in IPv4. Nodes on a link can be administered in separate subnets, if required. Additionally, IPv6 does support multilink subnets, where nodes on more than one link can be components of a single subnet. Links 2 and 3 in Figure 3–1 are components of multilink Subnet 8a.

IPv6 tunnel

A tunnel that provides a virtual point-to-point path between an IPv6 node and another IPv6 node endpoint. IPv6 supports manually configurable tunnels and automatic 6to4 tunnels.

boundary router

The router at the edge of a network that provides one end of the IPv6 tunnel to an endpoint outside the local network. This router must have at least one IPv6 interface to the internal network. For the external network, the router can have an IPv6 interface or an IPv4 interface.

IPv6 Addressing Overview

IPv6 addresses are assigned to interfaces, rather than to nodes, in recognition that a node can have more than one interface. Moreover, you can assign more than one IPv6 address to an interface.


Note –

For complete technical information about the IPv6 address format, go to RFC 2374, IPv6 Global Unicast Address Format


IPv6 defines three address types:

unicast

Identifies an interface of an individual node.

multicast

Identifies a group of interfaces, usually on different nodes. Packets that are sent to the multicast address go to all members of the multicast group.

anycast

Identifies a group of interfaces, usually on different nodes. Packets that are sent to the anycast address go to the anycast group member node that is physically closest to the sender.

Parts of the IPv6 Address

An IPv6 address is 128 bits in length and consists of eight, 16-bit fields, with each field bounded by a colon. Each field must contain a hexadecimal number, in contrast to the dotted-decimal notation of IPv4 addresses. In the next figure, the x's represent hexadecimal numbers.

Figure 3–2 Basic IPv6 Address Format

The figure shows the three parts of an IPv6 address,
which are described in the next text.

The leftmost three fields (48 bits) contain the site prefix. The prefix describes the public topology that is usually allocated to your site by an ISP or Regional Internet Registry (RIR).

The next field is the 16-bit subnet ID, which you (or another administrator) allocate for your site. The subnet ID describes the private topology, also known as the site topology, because it is internal to your site.

The rightmost four fields (64 bits) contain the interface ID, also referred to as a token. The interface ID is either automatically configured from the interface's MAC address or manually configured in EUI-64 format.

Consider again the address in Figure 3–2:

2001:0db8:3c4d:0015:0000:0000:1a2f:1a2b

This example shows all 128 bits of an IPv6 address. The first 48 bits, 2001:0db8:3c4d, contain the site prefix, representing the public topology. The next 16 bits, 0015, contain the subnet ID, representing the private topology for the site. The lower order, rightmost 64 bits, 0000:0000:1a2f:1a2b, contain the interface ID.

Abbreviating IPv6 Addresses

Most IPv6 addresses do not occupy all of their possible 128 bits. This condition results in fields that are padded with zeros or contain only zeros.

The IPv6 addressing architecture allows you use the two-colon (::) notation to represent contiguous 16-bit fields of zeros. For example, you might abbreviate the IPv6 address in Figure 3–2 by replacing the two contiguous fields of zeros in the interface ID with two colons. The resulting address is 2001:0db8:3c4d:0015::1a2f:1a2b. Other fields of zeros can be represented as a single 0. You can also omit any leading zeros in a field, such as changing 0db8 to db8.

So the address 2001:0db8:3c4d:0015:0000:0000:1a2f:1a2b can be abbreviated as 2001:db8:3c4d:15::1a2f:1a2b.

You can use the two colon notation to replace any contiguous fields of all zeros in the IPv6 address. For example, the IPv6 address 2001:0db8:3c4d:0015:0000:d234::3eee:0000 can be collapsed into 2001:db8:3c4d:15:0:d234:3eee::.

Prefixes in IPv6

The leftmost fields of the IPv6 address contain the prefix, which is used for routing IPv6 packets. IPv6 prefixes have the following format:

prefix/length in bits

Prefix length is stated in classless inter-domain routing (CIDR) notation. CIDR notation is a slash at the end of the address that is followed by the prefix length in bits. For information on CIDR format IP addresses, refer to Designing Your CIDR IPv4 Addressing Scheme.

The site prefix of an IPv6 address occupies up to 48 of the leftmost bits of the IPv6 address. For example, the site prefix of the IPv6 address 2001:db8:3c4d:0015:0000:0000:1a2f:1a2b/48 is contained in the leftmost 48 bits, 2001:db8:3c4d. You use the following representation, with zeros compressed, to represent this prefix:

2001:db8:3c4d::/48


Note –

The prefix 2001:db8::/32 is a special IPv6 prefix that is used specifically for documentation examples.


You can also specify a subnet prefix, which defines the internal topology of the network to a router. The example IPv6 address has the following subnet prefix.

2001:db8:3c4d:15::/64

The subnet prefix always contains 64 bits. These bits include 48 bits for the site prefix, in addition to 16 bits for the subnet ID.

The following prefixes have been reserved for special use:

2002::/16

Indicates that a 6to4 routing prefix follows.

fe80::/10

Indicates that a link-local address follows.

ff00::/8

Indicates that a multicast address follows.

Unicast Addresses

IPv6 includes two different unicast address assignments:

The type of unicast address is determined by the leftmost (high order) contiguous bits in the address, which contain the prefix.

The unicast address format is organized in the following hierarchy:

Global Unicast Address

The global unicast address is globally unique in the Internet. The example IPv6 address that is shown in Prefixes in IPv6 is a global unicast address. The next figure shows the scope of the global unicast address, as compared to the parts of the IPv6 address.

Figure 3–3 Parts of the Global Unicast Address

The figure divides a unicast address into its public
topology, the site prefix and its site topology, the subnet ID, and interface
ID.

Public Topology

The site prefix defines the public topology of your network to a router. You obtain the site prefix for your enterprise from an ISP or Regional Internet Registry (RIR).

Site Topology and IPv6 Subnets

IN IPv6, the subnet ID defines an administrative subnet of the network and is up to 16 bits in length. You assign a subnet ID as part of IPv6 network configuration. The subnet prefix defines the site topology to a router by specifying the specific link to which the subnet has been assigned.

IPv6 subnets are conceptually the same as IPv4 subnets, in that each subnet is usually associated with a single hardware link. However, IPv6 subnet IDs are expressed in hexadecimal notation, rather than in dotted decimal notation.

Interface ID

The interface ID identifies an interface of a particular node. An interface ID must be unique within the subnet. IPv6 hosts can use the Neighbor Discovery protocol to automatically generate their own interface IDs. Neighbor Discovery automatically generates the interface ID, based on the MAC or EUI-64 address of the host's interface. You can also manually assign interface IDs, which is recommended for IPv6 routers and IPv6-enabled servers. For instructions on how to create a manual EUI-64 address, refer to RFC 3513 Internet Protocol Version 6 (IPv6) Addressing Architecture.

Transitional Global Unicast Addresses

For transition purposes, the IPv6 protocol includes the ability to embed an IPv4 address within an IPv6 address. This type of IPv4 address facilitates the tunneling of IPv6 packets over existing IPv4 networks. One example of a transitional global unicast address is the 6to4 address. For more information on 6to4 addressing, refer to 6to4 Automatic Tunnels.

Link-Local Unicast Address

The link-local unicast address can be used only on the local network link. Link-local addresses are not valid nor recognized outside the enterprise. The following example shows the format of the link-local address.


Example 3–1 Parts of the Link-Local Unicast Address

The figure illustrates the format of an IPv6 link local
address, which is described in the next context.

A link-local prefix has the following format:

fe80::interface-ID/10

The following is an example of a link-local address:

fe80::23a1:b152


fe80

Hexadecimal representation of the 10-bit binary prefix 1111111010. This prefix identifies the type of IPv6 address as link local.

interface-ID

Hexadecimal address of the interface, which is usually derived from the 48-bit MAC address.

When you enable IPv6 during Oracle Solaris installation, the lowest numbered interface on the local machine is configured with a link-local address. Each interface requires at least one link-local address to identify the node to other nodes on the local link. Therefore, you need to manually configure link-local addresses for additional interfaces of a node. After configuration, the node uses its link-local addresses for automatic address configuration and neighbor discovery.

Multicast Addresses

IPv6 supports the use of multicast addresses. The multicast address identifies a multicast group, which is a group of interfaces, usually on different nodes. An interface can belong to any number of multicast groups. If the first 16 bits of an IPv6 address is ff00n, the address is a multicast address.

Multicast addresses are used for sending information or services to all interfaces that are defined as members of the multicast group. For example, one use of multicast addresses is to communicate with all IPv6 nodes on the local link.

When an interface's IPv6 unicast address is created, the kernel automatically makes the interface a member of certain multicast groups. For example, the kernel makes each node a member of the Solicited Node multicast group, which is used by the Neighbor Discovery protocol to detect reachability. The kernel also automatically makes a node a member of the All-Nodes or All Routers multicast groups.

For detailed information about multicast addresses, refer to IPv6 Multicast Addresses in Depth. For technical information, see RFC 3306, Unicast-Prefix-based IPv6 Multicast Addresses, which explains the multicast address format. For more information about the proper use of multicast addresses and groups, RFC 3307, Allocation Guidelines for IPv6 Multicast Addresses.

Anycast Addresses and Groups

IPv6 anycast addresses identify a group of interfaces on different IPv6 nodes. Each group of interfaces is known as an anycast group. When a packet is sent to the anycast address, the anycast group member that is physically closest to the sender receives the packet.


Note –

The Oracle Solaris implementation of IPv6 does not support the creation of anycast addresses and groups. However, Oracle Solaris IPv6 nodes can send packets to anycast addresses. For more information, see Considerations for Tunnels to a 6to4 Relay Router.


IPv6 Neighbor Discovery Protocol Overview

IPv6 introduces the Neighbor Discovery protocol, which uses messaging as the means to handle the interaction between neighbor nodes. Neighbor nodes are IPv6 nodes that are on the same link. For example, by issuing neighbor discovery-related messages, a node can learn a neighbor's link-local address. Neighbor Discovery controls the following major activities on the IPv6 local link:

Neighbor Discovery uses the following ICMP message types for communication among nodes on a link:

For detailed information on Neighbor Discovery messages and other Neighbor Discovery protocol topics, refer to IPv6 Neighbor Discovery Protocol. For technical information on Neighbor Discovery, see RFC 2461, Neighbor Discovery for IP Version 6 (IPv6).

IPv6 Address Autoconfiguration

A major feature of IPv6 is a host's ability to autoconfigure an interface. Through Neighbor Discovery, the host locates an IPv6 router on the local link and requests a site prefix. The host does the following, as part of the autoconfiguration process:

Stateless Autoconfiguration Overview

Stateless autoconfiguration requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. The stateless mechanism enables a host to generate its own addresses. The stateless mechanism uses local information as well as nonlocal information that is advertised by routers to generate the addresses.

You can implement temporary addresses for an interface, which are also autoconfigured. You enable a temporary address token for one or more interfaces on a host. However, unlike standard, autoconfigured IPv6 addresses, a temporary address consists of the site prefix and a randomly generated 64 bit number. This random number becomes the interface ID portion of the IPv6 address. A link-local address is not generated with the temporary address as the interface ID.

Routers advertise all prefixes that have been assigned on the link. IPv6 hosts use Neighbor Discovery to obtain a subnet prefix from a local router. Hosts automatically create IPv6 addresses by combining the subnet prefix with an interface ID that is generated from an interface's MAC address. In the absence of routers, a host can generate only link-local addresses. Link-local addresses can only be used for communication with nodes on the same link.


Note –

Do not use stateless autoconfiguration to create the IPv6 addresses of servers. Hosts automatically generate interface IDs that are based on hardware-specific information during autoconfiguration. The current interface ID could become invalid if the existing interface is swapped for a new interface.


Overview of IPv6 Tunnels

For most enterprises, the introduction of IPv6 to an existing IPv4 network must occur on a gradual, step-by-step basis. The Oracle Solaris dual-stack network environment supports both IPv4 and IPv6 functionality. Because most networks use the IPv4 protocol, IPv6 networks currently require a way to communicate outside their borders. IPv6 networks use tunnels for this purpose.

In most IPv6 tunneling scenarios, the outbound IPv6 packet is encapsulated inside an IPv4 packet. The boundary router of the IPv6 network sets up a point-to-point tunnel over various IPv4 networks to the boundary router of the destination IPv6 network. The packet travels over the tunnel to the destination network's boundary router, which decapsulates the packet. Then, the router forwards the separate IPv6 packet to the destination node.

The Oracle Solaris IPv6 implementation supports the following tunneling scenarios:

For detailed information about IPv6 tunnels, refer to IPv6 Tunnels. For information about IPv4- to-IPv4 tunnels and VPN, refer to Virtual Private Networks and IPsec.

Chapter 4 Planning an IPv6 Network (Tasks)

Deploying IPv6 on a new network or an existing network requires a major planning effort. This chapter contains the planning tasks that are necessary before you can configure IPv6 at your site. For existing networks, IPv6 deployment should be phased in gradually. The topics in this chapter help you phase in IPv6 onto an otherwise IPv4-only network.

The following topics are discussed in this chapter:

For an introduction to IPv6 concepts, refer to Chapter 3, Introducing IPv6 (Overview). For detailed information, refer to Chapter 11, IPv6 in Depth (Reference).

IPv6 Planning (Task Maps)

Complete the tasks in the next task map in sequential order to accomplish the planning tasks necessary for IPv6 deployment.

The following table lists different tasks for configuring the IPv6 network. The table includes a description of what each task accomplishes and the section in the current documentation where the specific steps to perform the task are detailed.

Task 

Description 

For Instructions 

1. Prepare your hardware to support IPv6. 

Ensure that your hardware can be upgraded to IPv6. 

Preparing the Network Topology for IPv6 Support

2. Get an ISP that supports IPv6. 

Ensure that your current ISP supports IPv6. Otherwise, find an ISP who can support IPv6. You can use two ISPs, one ISP for IPv6 and one for ISP IPv4 communications. 

 

3. Ensure that your applications are IPv6 ready. 

Verify that your applications can run in an IPv6 environment. 

How to Prepare Network Services for IPv6 Support

4. Get a site prefix. 

Obtain a 48-bit site prefix for your site from your ISP or from the nearest RIR. 

Obtaining a Site Prefix

5. Create a subnet addressing plan. 

You need to plan the overall IPv6 network topology and addressing scheme before you can configure IPv6 on the various nodes in your network. 

Creating a Numbering Scheme for Subnets

6. Design a plan for tunnel usage. 

Determine which routers should run tunnels to other subnets or external networks. 

Planning for Tunnels in the Network Topology

7. Create an addressing plan for entities on the network. 

Your plan for addressing servers, routers, and hosts should be in place before IPv6 configuration. 

Creating an IPv6 Addressing Plan for Nodes

8. Develop an IPv6 security policy. 

Investigate IP Filter, IP security architecture (IPsec), Internet Key Exchange (IKE), and other Oracle Solaris security features as you develop an IPv6 security policy. 

Part IV, IP Security

9. (Optional) Set up a DMZ. 

For security purposes, you need an addressing plan for the DMZ and its entities before you configure IPv6. 

Security Considerations for the IPv6 Implementation

10. Enable the nodes to support IPv6. 

Configure IPv6 on all routers and hosts. 

IPv6 Router Configuration (Task Map)

11. Turn on network services. 

Make sure that existing servers can support IPv6. 

Major TCP/IP Administrative Tasks (Task Map)

12. Update name servers for IPv6 support. 

Make sure that DNS, NIS, and LDAP servers are updated with the new IPv6 addresses. 

Configuring Name Service Support for IPv6

IPv6 Network Topology Scenario

The tasks throughout this chapter explain how to plan for IPv6 services on a typical enterprise network. The following figure shows the network that is referred to throughout the chapter. Your proposed IPv6 network might include some or all of the network links that are illustrated in this figure.

Figure 4–1 IPv6 Network Topology Scenario

The figure shows an IPv6 network. The next text describes
the figure's contents.

The enterprise network scenario consists of five subnets with existing IPv4 addresses. The links of the network correspond directly to the administrative subnets. The four internal networks are shown with RFC 1918-style private IPv4 addresses, which is a common solution for the lack of IPv4 addresses. The addressing scheme of these internal networks follows:

The external, public network 172.16.85 functions as the corporation's DMZ. This network contains web servers, anonymous FTP servers, and other resources that the enterprise offers to the outside world. Router 2 runs a firewall and separates public network 172.16.85 from the internal backbone. On the other end of the DMZ, Router 1 runs a firewall and serves as the enterprise's boundary server.

In Figure 4–1, the public DMZ has the RFC 1918 private address 172.16.85. In the real world, the public DMZ must have a registered IPv4 address. Most IPv4 sites use a combination of public addresses and RFC 1918 private addresses. However, when you introduce IPv6, the concept of public addresses and private addresses changes. Because IPv6 has a much larger address space, you use public IPv6 addresses on both private networks and public networks.

Preparing the Existing Network to Support IPv6


Note –

The Oracle Solaris dual protocol stack supports concurrent IPv4 and IPv6 operations. You can successfully run IPv4–related operations during and after deployment of IPv6 on your network.


IPv6 introduces additional features to an existing network. Therefore, when you first deploy IPv6, you must ensure that you do not disrupt any operations that are working with IPv4. The subjects covered in this section describe how to introduce IPv6 to an existing network in a step-by-step fashion.

Preparing the Network Topology for IPv6 Support

The first step in IPv6 deployment is to assess which existing entities on your network can support IPv6. In most cases, the network topology-wires, routers, and hosts-can remain unchanged as you implement IPv6. However, you might have to prepare existing hardware and applications for IPv6 before actually configuring IPv6 addresses on network interfaces.

Verify which hardware on your network can be upgraded to IPv6. For example, check the manufacturers' documentation for IPv6 readiness regarding the following classes of hardware:


Note –

All procedures in the this Part assume that your equipment, particularly routers, can be upgraded to IPv6.


Some router models cannot be upgraded to IPv6. For more information and a workaround, refer to IPv4 Router Cannot Be Upgraded to IPv6.

Preparing Network Services for IPv6 Support

The following typical IPv4 network services in the current Oracle Solaris release are IPv6 ready:

The IMAP mail service is for IPv4 only.

Nodes that are configured for IPv6 can run IPv4 services. When you turn on IPv6, not all services accept IPv6 connections. Services that have been ported to IPv6 will accept a connection. Services that have not been ported to IPv6 continue to work with the IPv4 half of the protocol stack.

Some issues can arise after you upgrade services to IPv6. For details, see Problems After Upgrading Services to IPv6.

Preparing Servers for IPv6 Support

Because servers are considered IPv6 hosts, by default their IPv6 addresses are automatically configured by the Neighbor Discovery protocol. However, many servers have multiple network interface cards (NICs) that you might want to swap out for maintenance or replacement. When you replace one NIC, Neighbor Discovery automatically generates a new interface ID for that NIC. This behavior might not be acceptable for a particular server.

Therefore, consider manually configuring the interface ID portion of the IPv6 addresses for each interface of the server. For instructions, refer to How to Configure a User-Specified IPv6 Token. Later, when you need to replace an existing NIC, the already configured IPv6 address is applied to the replacement NIC.

ProcedureHow to Prepare Network Services for IPv6 Support

  1. Update the following network services to support IPv6:

    • Mail servers

    • NIS servers

    • NFS


      Note –

      LDAP supports IPv6 without requiring IPv6-specific configuration tasks.


  2. Verify that your firewall hardware is IPv6 ready.

    Refer to the appropriate firewall-related documentation for instructions.

  3. Verify that other services on your network have been ported to IPv6.

    For more information, refer to marketing collateral and associated documentation for the software.

  4. If your site deploys the following services, make sure that you have taken the appropriate measures for these services:

  5. Audit any network services that are offered by a node prior to converting that node to IPv6.

ProcedureHow to Prepare DNS for IPv6 Support

The current Oracle Solaris release supports DNS resolution on both the client side and the server side. Do the following to prepare DNS services for IPv6.

For more information that is related to DNS support for IPv6, refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

  1. Ensure that the DNS server that performs recursive name resolution is dual-stacked (IPv4 and IPv6) or for IPv4 only.

  2. On the DNS server, populate the DNS database with relevant IPv6 database AAAA records in the forward zone.


    Note –

    Servers that run multiple critical services require special attention. Ensure that the network is working properly. Also ensure that all critical services are ported to IPv6. Then, add the server's IPv6 address to the DNS database.


  3. Add the associated PTR records for the AAAA records into the reverse zone.

  4. Add either IPv4 only data, or both IPv6 and IPv4 data into the NS record that describes zones.

Planning for Tunnels in the Network Topology

The IPv6 implementation supports a number of tunnel configurations to serve as transition mechanisms as your network migrates to a mix of IPv4 and IPv6. Tunnels enable isolated IPv6 networks to communicate. Because most of the Internet runs IPv4, IPv6 packets from your site need to travel across the Internet through tunnels to destination IPv6 networks.

Here are some major scenarios for using tunnels in the IPv6 network topology:

For procedures for configuring tunnels, refer to Tasks for Configuring Tunnels for IPv6 Support (Task Map). For conceptual information regarding tunnels, refer to IPv6 Tunnels.

Security Considerations for the IPv6 Implementation

When you introduce IPv6 into an existing network, you must take care not to compromise the security of the site. Be aware of the following security issues as you phase in your IPv6 implementation:

This book includes security features that can be used within an IPv6 implementation.

Preparing an IPv6 Addressing Plan

A major part of the transition from IPv4 to IPv6 includes the development of an addressing plan. This task involves the following preparations:

Obtaining a Site Prefix

Before you configure IPv6, you must obtain a site prefix. The site prefix is used to derive IPv6 addresses for all the nodes in your IPv6 implementation. For an introduction to site prefixes, refer to Prefixes in IPv6.

Any ISP that supports IPv6 can provide your organization with a 48-bit IPv6 site prefix. If your current ISP only supports IPv4, you can use another ISP for IPv6 support while retaining your current ISP for IPv4 support. In such an instance, you can use one of several workarounds. For more information, see Current ISP Does Not Support IPv6.

If your organization is an ISP, then you obtain site prefixes for your customers from the appropriate Internet registry. For more information, see the Internet Assigned Numbers Authority (IANA).

Creating the IPv6 Numbering Scheme

Unless your proposed IPv6 network is entirely new, use your existing IPv4 topology as the basis for the IPv6 numbering scheme.

Creating a Numbering Scheme for Subnets

Begin your numbering scheme by mapping your existing IPv4 subnets into equivalent IPv6 subnets. For example, consider the subnets illustrated in Figure 4–1. Subnets 1–4 use the RFC 1918 IPv4 private address designation for the first 16 bits of their addresses, in addition to the digits 1–4 to indicate the subnet. For illustrative purposes, assume that the IPv6 prefix 2001:db8:3c4d/48 has been assigned to the site.

The following table shows how the private IPv4 prefixes map into IPv6 prefixes.

IPv4 Subnet Prefix 

Equivalent IPv6 Subnet Prefix  

192.168.1.0/24

2001:db8:3c4d:1::/64

192.168.2.0/24

2001:db8:3c4d:2::/64

192.168.3.0/24

2001:db8:3c4d:3::/64

192.168.4.0/24

2001:db8:3c4d:4::/64

Creating an IPv6 Addressing Plan for Nodes

For most hosts, stateless autoconfiguration of IPv6 addresses for their interfaces is an appropriate, time saving strategy. When the host receives the site prefix from the nearest router, Neighbor Discovery automatically generates IPv6 addresses for each interface on the host.

Servers need to have stable IPv6 addresses. If you do not manually configure a server's IPv6 addresses, a new IPv6 address is autoconfigured whenever a NIC card is replaced on the server. Keep the following tips in mind when you create addresses for servers:

Due to the limited number of IPv4 addresses, in the past a network designer had to consider where to use global, registered addresses and private, RFC 1918 addresses. However, the notion of global and private IPv4 addresses does not apply to IPv6 addresses. You can use global unicast addresses, which include the site prefix, on all links of the network, including the public DMZ.

Chapter 5 Configuring TCP/IP Network Services and IPv4 Addressing (Tasks)

TCP/IP network administration evolves in two stages. The first stage is to assemble the hardware. Then, you configure the daemons, files, and services that implement the TCP/IP protocol.

This chapter explains how to configure TCP/IP on a network that implements IPv4 addressing and services.


Note –

Many of the tasks in this chapter apply to both IPv4-only and IPv6-enabled networks. Where configuration tasks differ between the two addressing formats, the IPv4 configuration steps are in this chapter. The tasks in this chapter then cross reference the equivalent IPv6 tasks in Chapter 7, Configuring an IPv6 Network (Tasks).


This chapter contains the following information:

What's New in This Chapter

In Solaris 10 8/07, the following changes are made:

Before You Configure an IPv4 Network (Task Map)

Before you configure TCP/IP, complete the tasks that are listed in the following table. The table includes a description of what each task accomplishes and the section in the current documentation where the specific steps to perform the task are detailed.

Task 

Description 

For Instructions 

1. Design the network topology. 

Determine the physical layout of the network. 

Network Topology Overview and IPv4 Autonomous System Topology

2. Obtain a network number from your ISP or Regional Internet Registry (RIR). 

Get a registered network number, which enables systems at your site to communicate externally. 

Designing Your IPv4 Addressing Scheme.

3. Plan the IPv4 addressing scheme for the network. If applicable, include subnet addressing. 

Use the network number as the basis for your addressing plan. 

Designing Your IPv4 Addressing Scheme.

4. Assemble the network hardware depending on the network topology. Assure that the hardware is functioning properly. 

Set up the systems, network media, routers, switches, hubs and bridges that you outlined in the network topology design. 

The hardware manuals and Network Topology Overview.

5. Assign IPv4 addresses and host names to all systems in the network. 

Assign the IPv4 addresses during Oracle Solaris installation or post installation, in the appropriate files. 

Designing Your IPv4 Addressing Scheme and How to Change the IPv4 Address and Other Network Configuration Parameters

6. Run configuration software that is required by network interfaces and routers, if applicable. 

Configure routers and multihomed hosts. 

Planning for Routers on Your Network and Configuring an IPv4 Router for information on routers.

7. Determine which name service or directory service your network uses: NIS, LDAP, DNS, or local files. 

Configure your selected name service and/or directory service. 

System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

8. Select domain names for your network, if applicable. 

Choose a domain name for your network and register it with the InterNIC. 

System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)

Determining Host Configuration Modes

As a network administrator, you configure TCP/IP to run on hosts and routers (if applicable). You can configure these systems to obtain configuration information from files on the local system or from files that are located on other systems on the network. You need the following configuration information:

A system that obtains TCP/IP configuration information from local files operates in local files mode. A system that obtains TCP/IP configuration information from a remote network server operates in network client mode.

Systems That Should Run in Local Files Mode

To run in local files mode, a system must have local copies of the TCP/IP configuration files. These files are described in TCP/IP Configuration Files. The system should have its own disk, though this recommendation is not strictly necessary.

Most servers should run in local files mode. This requirement includes the following servers:

Additionally, routers should run in local files mode.

Systems that function exclusively as print servers do not need to run in local files mode. Whether individual hosts should run in local files mode depends on the size of your network.

If you are running a very small network, the amount of work that is involved in maintaining these files on individual hosts is manageable. If your network serves hundreds of hosts, the task becomes difficult, even with the network divided into a number of administrative subdomains. Thus, for large networks, using local files mode is usually less efficient. However, because routers and servers must be self-sufficient, they should be configured in local files mode.

Network Configuration Servers

Network configuration servers are the servers that supply the TCP/IP configuration information to hosts that are configured in network client mode. These servers support three booting protocols:

Network configuration servers can also function as NFS file servers.

If you are configuring any hosts as network clients, then you must also configure at least one system on your network as a network configuration server. If your network is subnetted, then you must have at least one network configuration server for each subnet with network clients.

Systems That Are Network Clients

Any host that obtains its configuration information from a network configuration server operates in network client mode. Systems that are configured as network clients do not require local copies of the TCP/IP configuration files.

Network client mode simplifies administration of large networks. Network client mode minimizes the number of configuration tasks that you perform on individual hosts. Network client mode assures that all systems on the network adhere to the same configuration standards.

You can configure network client mode on all types of computers. For example, you can configure network client mode on standalone systems.

Mixed Configurations

Configurations are not limited to either an all-local-files mode or an all-network-client mode. Routers and servers should always be configured in local mode. For hosts, you can use any combination of local files and network client mode.

IPv4 Network Topology Scenario

Figure 5–1 shows the hosts of a fictitious network with the network number 192.9.200. The network has one network configuration server, which is called sahara. Hosts tenere and nubian have their own disks and run in local files mode. Host faiyum also has a disk, but this system operates in network client mode.

Finally, the system timbuktu is configured as a router. The system includes two network interfaces. The first interface is named timbuktu. This interface belongs to network 192.9.200. The second interface is named timbuktu-201. This interface belongs to network 192.9.201. Both networks are in the organizational domain deserts.worldwide.com. The domain uses local files as its name service.

Figure 5–1 Hosts in an IPv4 Network Topology Scenario

Diagram shows a sample network with one network server
that serves four hosts.

Adding a Subnet to a Network (Task Map)

If you are changing from a network that does not use a subnet to a network that does use a subnet, perform the tasks in the following task map.


Note –

The information in this section applies to IPv4 subnets only. For information on planning IPv6 subnets, refer to Preparing the Network Topology for IPv6 Support and Creating a Numbering Scheme for Subnets.


The following table lists different tasks for adding a subnet to the current network. The table includes a description of what each task accomplishes and the section in the current documentation where the specific steps to perform the task are detailed.

Task 

Description 

For Instructions 

1. Determine if your network topology requires subnets. 

Decide on the new subnet topology, including where to locate routers and hosts on the subnets. 

Planning for Routers on Your Network, What Is Subnetting?, and Network Classes

2. Assign the IP addresses with the new subnet number to the systems to become members of the subnet. 

Configure IP addresses that use the new subnet number, either during Oracle Solaris installation or later, in the /etc/hostname.interface file.

Deciding on an IP Addressing Format for Your Network

3. Configure the network mask of the subnet on all prospective systems in the subnet. 

Modify the /etc/inet/netmasks file, if you are manually configuring network clients. Or, supply the netmask to the Oracle Solaris installation program.

netmasks Database and Creating the Network Mask for IPv4 Addresses

4. Edit the network databases with the new IP addresses of all systems in the subnet. 

Modify /etc/inet/hosts and, for Solaris 10 11/06 and earlier releases,/etc/inet/ipnodes, on all hosts to reflect the new host addresses.

hosts Database

5. Reboot all systems. 

   

Network Configuration Task Map

The following table lists additional tasks to perform after changing from a network configuration without subnets to a network that uses subnets. The table includes a description of what each task accomplishes and the section in the current documentation where the specific steps to perform the task are detailed.

Task 

Description 

For Instructions 

Configure a host for local files mode 

Involves editing the nodename, hostname, hosts, defaultdomain, defaultrouter, and netmasks files

How to Configure a Host for Local Files Mode

Set up a network configuration server 

Involves turning on the in.tftp daemon, and editing the hosts, ethers, and bootparams files

How to Set Up a Network Configuration Server

Configure a host for network client mode 

Involves creating the hostname file, editing the hosts file, and deleting the nodename and defaultdomain files, if they exist

How to Configure Hosts for Network Client Mode

Specify a routing strategy for the network client 

Involves determining whether to use static routing or dynamic routing on the host. 

How to Enable Static Routing on a Single-Interface Host and How to Enable Dynamic Routing on a Single-Interface Host.

Modify the existing network configuration  

Involves changing the host name, IP address, and other parameters that were set at installation or configured at a later time. 

How to Change the IPv4 Address and Other Network Configuration Parameters

Configuring Systems on the Local Network

Network software installation occurs along with the installation of the operating system software. At that time, certain IP configuration parameters must be stored in appropriate files so that they can be read at boot time.

The network configuration process involves creating or editing the network configuration files. How configuration information is made available to a system's kernel is conditional. The availability depends on whether these files are stored locally (local files mode) or acquired from the network configuration server (network client mode).

The parameters that are supplied during network configuration follow:

If the Oracle Solaris installation program detects more one interface on the system, you can optionally configure the additional interfaces during installation. For complete instructions, see Oracle Solaris 10 9/10 Installation Guide: Basic Installations.

This chapter contains information on creating and editing local configuration files. See System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) for information on working with name service databases.

ProcedureHow to Configure a Host for Local Files Mode

Use this procedure for configuring TCP/IP on a host that runs in local files mode.

  1. Assume the Primary Administrator role, or become superuser

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Change to the /etc directory.

  3. Verify that the correct host name is set in the /etc/nodename file.

    When you specify the host name of a system during Oracle Solaris installation, that host name is entered into the /etc/nodename file. Make sure that the node name entry is the correct host name for the system.

  4. Verify that an /etc/hostname.interface file exists for each network interface on the system.

    For file syntax and basic information about the /etc/hostname.interface file, refer to Basics for Administering Physical Interfaces.

    The Oracle Solaris installation program requires you to configure at least one interface during installation. The first interface that you configure automatically becomes the primary network interface. The installation program creates an /etc/hostname.interface file for the primary network interface and any other interfaces that you optionally configure at installation time.

    If you configured additional interfaces during installation, verify that each interface has a corresponding /etc/hostname.interface file. You do not need to configure more than one interface during Oracle Solaris installation. However, if you later want to add more interfaces to the system, you must manually configure them.

    For steps for manually configuring interfaces, refer to Administering Interfaces in Solaris 10 3/05 or How to Configure a Physical Interface After System Installation, for releases starting with Solaris 10 1/06.

  5. For Solaris 10 11/06 and earlier releases, verify that the entries in the /etc/inet/ipnodes file are current.

    The Oracle Solaris 10 installation program creates the /etc/inet/ipnodes file. This file contains the node name and IPv4 address, and IPv6 address, if appropriate, of every interface that is configured during installation.

    Use the following format for entries in the /etc/inet/ipnodes file:


    IP-address node-name nicknames...
    

    nicknames are additional names by which an interface is known.

  6. Verify that the entries in the /etc/inet/hosts file are current.

    The Oracle Solaris installation program creates entries for the primary network interface, loopback address, and, if applicable, any additional interfaces that were configured during installation.

    1. Make sure that the existing entries in /etc/inet/hosts are current.

    2. (Optional) Add the IP addresses and corresponding names for any network interfaces that were added to the local host after installation.

    3. (Optional) Add the IP address or addresses of the file server, if the /usr file system is NFS mounted.

  7. Type the host's fully qualified domain name in the /etc/defaultdomain file.

    For example, suppose host tenere was part of the domain deserts.worldwide.com. Therefore, you would type deserts.worldwide.com in /etc/defaultdomain. See /etc/defaultdomain File for more information.

  8. Type the router's name in the /etc/defaultrouter file.

    See /etc/defaultrouter File for information about this file.

  9. Type the name of the default router and its IP addresses in the /etc/inet/hosts file.

    Additional routing options are available, as discussed in How to Configure Hosts for Network Client Mode. You can apply these options to a local files mode configuration.

  10. Add the network mask for your network, if applicable:

    • If the host gets its IP address from a DHCP server, you do not have to specify the network mask.

    • If you have set up a NIS server on the same network as this client, you can add netmask information into the appropriate database on the server.

    • For all other conditions, do the following:

    1. Type the network number and the netmask in the /etc/inet/netmasks file.

      Use the following format:


      network-number netmask

      For example, for the Class C network number 192.168.83, you would type:


      192.168.83.0    255.255.255.0
      

      For CIDR addresses, convert the network prefix into the equivalent dotted decimal representation. Network prefixes and their dotted decimal equivalents can be found in Table 2–3. For example, use the following to express the CIDR network prefix 192.168.3.0/22.


      192.168.3.0 255.255.252.0
    2. Change the lookup order for netmasks in /etc/nsswitch.conf, so that local files are searched first:


      netmasks:   files nis
  11. Reboot the system.

ProcedureHow to Set Up a Network Configuration Server

Information for setting up installation servers and boot servers is found in Oracle Solaris 10 9/10 Installation Guide: Basic Installations.

  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Change to the root (/) directory of the prospective network configuration server.

  3. Turn on the in.tftpd daemon by creating the directory /tftpboot:


    # mkdir /tftpboot
    

    This command configures the system as a TFTP, bootparams, and RARP server.

  4. Create a symbolic link to the directory.


    # ln -s /tftpboot/. /tftpboot/tftpboot
    
  5. Enable the tftp line in the /etc/inetd.conf file.

    Check that the entry reads as follows:


    tftp dgram udp6 wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot

    This line prevents in.tftpd from retrieving any file other than the files that are located in /tftpboot.

  6. Edit the hosts database.

    Add the host names and IP addresses for every client on the network.

  7. Edit the ethers database.

    Create entries for every host on the network that runs in network client mode.

  8. Edit the bootparams database.

    See bootparams Database. Use the wildcard entry or create an entry for every host that runs in network client mode.

  9. Convert the /etc/inetd.conf entry into a Service Management Facility (SMF) service manifest, and enable the resulting service:


    # /usr/sbin/inetconv
    
  10. Verify that in.tftpd is working correctly.


    # svcs network/tftp/udp6
    

    You should receive output resembling the following:


    STATE          STIME    FMRI
    online         18:22:21 svc:/network/tftp/udp6:default
Administering the in.tftpd Daemon

The in.tftpd daemon is managed by the Service Management Facility. Administrative actions on in.tftpd, such as enabling, disabling, or restarting, can be performed using the svcadm command. Responsibility for initiating and restarting this service is delegated to inetd. Use the inetadm command to make configuration changes and to view configuration information for in.tftpd. You can query the service's status by using the svcs command. For an overview of the Service Management Facility, refer to Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration.

Configuring Network Clients

Network clients receive their configuration information from network configuration servers. Therefore, before you configure a host as a network client you must ensure that at least one network configuration server is set up for the network.

ProcedureHow to Configure Hosts for Network Client Mode

Do the following procedure on each host to be configured in network client mode.

  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Search the /etc directory for the nodename file.

    If such a file exists, delete it.

    Eliminating /etc/nodename causes the system to use the hostconfig program to obtain the host name, domain name, and router addresses from the network configuration server. See Configuring Systems on the Local Network.

  3. Create the /etc/hostname.interface file, if it does not exist.

    Ensure that the file is empty. An empty /etc/hostname.interface file causes the system to acquire the IPv4 address from the network configuration server.

  4. Ensure that the /etc/inet/hosts file contains only the localhost name and IP address of the loopback network interface.


    # cat /etc/inet/hosts
    # Internet host table
    #
    127.0.0.1       localhost

    The IPv4 loopback interface has the IP address 127.0.0.1.

    For more information, see Loopback Address. The file should not contain the IP address and host name for the local host (primary network interface).

  5. Check for the existence of an /etc/defaultdomain file.

    If such a file exists, delete it.

    The hostconfig program automatically sets the domain name. To override the domain name that is set by hostconfig, type the substitute domain name in the /etc/defaultdomain file.

  6. Ensure that the search paths in the client's /etc/nsswitch.conf file reflect the name service requirements for your network.

ProcedureHow to Change the IPv4 Address and Other Network Configuration Parameters

This procedure explains how to modify the IPv4 address, host name, and other network parameters on a previously installed system. Use the procedure for modifying the IP address of a server or networked standalone system. The procedure does not apply to network clients or appliances. The steps create a configuration that persists across reboots.


Note –

The instructions apply specifically to changing the IPv4 address of the primary network interface. To add another interface to the system, refer to How to Configure a Physical Interface After System Installation.


In almost all cases, the following steps use traditional IPv4 dotted decimal notation to specify the IPv4 address and subnet mask. Alternatively, you can use CIDR notation to specify the IPv4 address in all the applicable files in this procedure. For an introduction to CIDR notation, see IPv4 Addresses in CIDR Format.

  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. For Solaris 10 11/06 and earlier releases only, modify the IP address in the /etc/inet/ipnodes file or equivalent ipnodes database.

    Use the following syntax for each IP address that you add to the system:


    IP-address host-name, nicknames
    IP-address interface-name, nicknames
    

    The first entry should contain the IP address of the primary network interface and the host name of the system. You can optionally add nicknames for the host name. When you add additional physical interfaces to a system, create entries in /etc/inet/ipnodes for the IP addresses and associated names of those interfaces.

  3. If the system's host name must change, modify the host name entry in the /etc/nodename file.

  4. Modify the IP address and, if applicable, the host name in the /etc/inet/hosts file or equivalent hosts database.

  5. Modify the IP address in the /etc/hostname.interface file for the primary network interface.

    You can use any of the following as the entry for the primary network interface in the /etc/hostnameinterface file:

    • IPv4 address, expressed in traditional dotted decimal format

      Use the following syntax:


      IPv4 address subnet mask
      

      The netmask entry is optional. If you do not specify it, the default netmask is assumed.

      Here is an example:


      # vi hostname.eri0
      10.0.2.5 netmask 255.0.0.0
      
    • IPv4 address, expressed in CIDR notation, if appropriate for your network configuration.


      IPv4 address/network prefix
      

      Here is an example:


      # vi hostname.eri0
      10.0.2.5/8
      

      The CIDR prefix designates the appropriate netmask for the IPv4 address. For example, the /8 above indicates the netmask 255.0.0.0.

    • Host name.

      To use the system's host name in the /etc/hostname.interface file, be sure that the host name and associated IPv4 address are also in the hosts database.

  6. If the subnet mask has changed, modify the subnet entries in the following files:

    • /etc/netmasks

    • (Optional) /etc/hostname.interface

  7. If the subnet address has changed, change the IP address of the default router in /etc/defaultrouter to that of the new subnet's default router.

  8. Reboot the system.


    # reboot -- -r
    

Example 5–1 Modifying the IPv4 Address and Other Network Parameters to Persist Across Reboots

This example shows how to change the following network parameters of a system that is moved to another subnet:

Check the system's current status:


# hostname
myhost
# ifconfig -a

lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
eri0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.0.0.14 netmask ff000000 broadcast 10.255.255.255
        ether 8:0:20:c1:8b:c3 

Next, change the system's host name and the IP address of eri0 in the appropriate files:


# vi /etc/nodename
mynewhostname

In Solaris 10 11/06 and earlier Solaris 10 releases only, do the following:
# vi /etc/inet/ipnodes
192.168.55.14   mynewhostname      #moved system to 192.168.55 net

# vi /etc/inet/hosts
#
# Internet host table
#
127.0.0.1       localhost
192.168.55.14   mynewhostname        loghost
# vi /etc/hostname.eri0
192.168.55.14   netmask  255.255.255.0

Finally, change the netmask and the IP address of the default router.


# vi /etc/netmasks.
.
.
192.168.55.0    255.255.255.0
# vi /etc/defaultrouter
192.168.55.200        #moved system to 192.168.55 net
#

After making these changes, reboot the system.


# reboot -- -r

Verify that the configuration you just set is maintained after the reboot:


# hostname
mynewhostname
# ifconfig -a

lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
eri0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.55.14 netmask ffffff00 broadcast 10.255.255.255
        ether 8:0:20:c1:8b:c3 


Example 5–2 Changing the IP Address and Host Name For the Current Session

This example shows how to change a host's name, IP address of the primary network interface, and subnet mask for the current session only. If you reboot, the system reverts to its previous IP address and subnet mask. The IP address for the primary network interface eri0 changes from 10.0.0.14 to 192.168.34.100.


# ifconfig -a

lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
eri0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.0.0.14 netmask ff000000 broadcast 10.255.255.255
        ether 8:0:20:c1:8b:c3 
# ifconfig eri0 192.168.34.100 netmask 255.255.255.0 broadcast + up
# vi /etc/nodename
mynewhostname

# ifconfig -a
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
eri0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.34.100 netmask ffffff00 broadcast 10.255.255.255
        ether 8:0:20:c1:8b:c3 
# hostname
mynewhostname


Example 5–3 Changing the IPv4 Address for the Current Session, Using CIDR Notation

This example shows how to change a host name and IP address for the current session only, using CIDR notation. If you reboot, the system reverts to its previous IP address and subnet mask. The IP address for the primary network interface, eri0, changes from 10.0.0.14 to 192.168.6.25/27.


# ifconfig -a

lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
eri0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.0.0.14 netmask ff000000 broadcast 10.255.255.255
        ether 8:0:20:c1:8b:c3 
# ifconfig eri0 192.168.6.25/27 broadcast + up
# vi /etc/nodename
mynewhostname
# ifconfig -a

lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
eri0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.06.25 netmask ffffffe0 broadcast 10.255.255.255
        ether 8:0:20:c1:8b:c3 
# hostname
mynewhostname

When you use CIDR notation for the IPv4 address, you do not have to specify the netmask. ifconfig uses the network prefix designation to determine the netmask. For example, for the 192.168.6.0/27 network, ifconfig sets the netmask ffffffe0. If you had used the more common /24 prefix designation, the resulting netmask is ffffff00. Using the /24 prefix designation is the equivalent of specifying the netmask 255.255.255.0 to ifconfig when configuring a new IP address.


See Also

To change the IP address of an interface other than the primary network interface, refer to System Administration Guide: Basic Administration and How to Configure a Physical Interface After System Installation.

Packet Forwarding and Routing on IPv4 Networks

This section contains procedures and examples that show how to configure forwarding and routing for routers and hosts on IPv4 networks.

Packet forwarding is the basic method for sharing information across systems on a network. Packets are transferred between a source interface and a destination interface, usually on two different systems. When you issue a command or send a message to a nonlocal interface, your system forwards those packets onto the local network. The interface with the destination IP address that is specified in the packet headers then retrieves the packets from the local network. If the destination address is not on the local network, the packets are then forwarded to the next adjacent network, or hop. By default, packet forwarding is automatically configured when you install Oracle Solaris.

Routing is the process by which systems decide where to send a packet. Routing protocols on a system “discover” the other systems on the local network. When the source system and the destination system are on the same local network, the path that packets travel between them is called a direct route. If a packet must travel at least one hop beyond its source system, the path between the source system and destination system is called an indirect route. The routing protocols learn the path to a destination interface and retain data about known routes in the system's routing table.

Routers are specially configured systems with multiple physical interfaces that connect the router to more than one local network. Therefore, the router can forward packets beyond the home LAN, regardless of whether the router runs a routing protocol. For more information about how routers forward packets, refer to Planning for Routers on Your Network.

Routing protocols handle routing activity on a system and, by exchanging routing information with other hosts, maintain known routes to remote networks. Both routers and hosts can run routing protocols. The routing protocols on the host communicate with routing daemons on other routers and hosts. These protocols assist the host in determining where to forward packets. When network interfaces are enabled, the system automatically communicates with the routing daemons. These daemons monitor routers on the network and advertise the routers' addresses to the hosts on the local network. Some routing protocols, though not all, also maintain statistics that you can use to measure routing performance. Unlike packet forwarding, you must explicitly configure routing on an Oracle Solaris system.

This section contains tasks for administering packet forwarding and routing on IPv4 routers and hosts. For information about routing on an IPv6-enabled network, refer to Configuring an IPv6 Router.

Routing Protocols Supported by Oracle Solaris

Routing protocols are classified as interior gateway protocols (IGPs), exterior gateway protocols (EGPs), or a combination of both. Interior gateway protocols exchange routing information between routers on networks under common administrative control. In the network topology shown in Figure 5–3, the routers run an IGP for exchanging routing information. Exterior gateway protocols enable the router that connects the local internetwork to an external network to exchange information with another router on the external network. For example, the router that connects a corporate network to an ISP runs an EGP to exchange routing information with its router counterpart at the ISP. Border Gateway Protocol (BGP) is a popular EGP that is used for carrying routing information between different organizations and IGPs.

The following table provides information about the Oracle Solaris routing protocols and the location of each protocol's associated documentation.

Table 5–1 Oracle Solaris Routing Protocols

Protocol 

Associated Daemon 

Description 

For Instructions 

Routing Information Protocol (RIP) 

in.routed

IGP that routes IPv4 packets and maintains a routing table 

How to Configure an IPv4 Router

Internet Control Message Protocol (ICMP) Router Discovery 

in.routed

Used by hosts to discover the presence of a router on the network 

How to Enable Static Routing on a Single-Interface Host and How to Enable Dynamic Routing on a Single-Interface Host

Routing Information Protocol, next generation (RIPng) Protocol 

in.ripngd

IGP that routes IPv6 packets and maintains a routing table 

How to Configure an IPv6-Enabled Router

Neighbor Discovery (ND) Protocol 

in.ndpd

Advertises the presence of an IPv6 router and discovers the presence of IPv6 hosts on a network 

Configuring an IPv6 Interface

Oracle Solaris 10 also supports the Open Source Quagga routing protocol suite. These protocols are available from the SFW consolidation disk, though they are not part of the mainOracle Solaris distribution. The following table lists the Quagga protocols:

Table 5–2 OpenSolaris Quagga Protocols

Protocol 

Daemon  

Description 

RIP protocol 

ripd

IPv4 distance vectoring IGP that routes IPv4 packets and advertises its routing table to neighbors. 

RIPng 

ripngd

IPv6 distance vectoring IGP. Routes IPv6 packets and maintains a routing table. 

Open Shortest Path First (OSPF) protocol 

ospfd

IPv4 link state IGP for packet routing and high availability networking 

Border Gateway Protocol (BGP) 

bgpd

IPv4 and IPv6 EGP for routing across administrative domains. 

The following figure shows an autonomous system that uses the Quagga routing protocols:

Figure 5–2 Corporate Network That Runs Quagga Protocols

This figure shows a corporate network that runs the Quagga
routing protocols. The context explains the figure.

The figure shows a corporate network autonomous system that is subdivided into two routing domains, A and B. Arouting domain is an internetwork with a cohesive routing policy, either for administrative purposes or because the domain uses a single routing protocol. Both domains in the figure run routing protocols from the Quagga protocol suite.

Routing Domain A is an OSPF domain, which is administered under a single OSPF domain ID. All systems within this domain run OSPF as their interior gateway protocol. In addition to internal hosts and routers, Domain A includes two border routers.

Border router R1 connects the Corporate Network to an ISP and ultimately the Internet. To facilitate communications between the Corporate Network and the outside world, R1 runs BGP over its externally facing network interface. The border router R5 connects Domain A with Domain B. All systems on Domain B are administered with RIP as their interior gateway protocol. Therefore, border router R5 must run OSPF on the Domain A facing interface and RIP on the Domain B facing interface.

For more information on the Quagga protocols, refer to the Open Solaris Quagga. For configuration procedures for these protocols, go to the documentation for quagga.

IPv4 Autonomous System Topology

Sites with multiple routers and networks typically administer their network topology as a single routing domain, or autonomous system (AS) . The following figure shows a typical network topology that would be considered a small AS. This topology is referenced in the examples throughout this section.

Figure 5–3 Autonomous System With Multiple IPv4 Routers

This topology diagram of an autonomous system is explained
in the following context.

The figure shows an AS that is divided into three local networks, 10.0.5.0, 172.20.1.0, and 192.168.5. Four routers share packet-forwarding and routing responsibilities. The AS includes the following types of systems:

Configuring an IPv4 Router

This section contains a procedure and example for configuring an IPv4 router. To configure an IPv6-enabled router, refer to How to Configure an IPv6-Enabled Router.

Because a router provides the interface between two or more networks, you must assign a unique name and IP address to each of the router's physical network interfaces. Thus, each router has a host name and an IP address that are associated with its primary network interface, in addition to a minimum of one more unique name and IP address for each additional network interface.

You can also use the following procedure to configure a system with only one physical interface (by default, a host) to be a router. You might configure a single interface system as a router if the system serves as one endpoint on a PPP link, as explained in Planning a Dial-up PPP Link in System Administration Guide: Network Services.


Note –

You can configure all interfaces of a router during Oracle Solaris system installation. For instructions, see Oracle Solaris 10 9/10 Installation Guide: Basic Installations.


ProcedureHow to Configure an IPv4 Router

The following instructions assume that you are configuring interfaces for the router after installation.

Before You Begin

After the router is physically installed on the network, configure the router to operate in local files mode, as described in How to Configure a Host for Local Files Mode. This configuration ensures that routers boot if the network configuration server is down.

  1. On the system to be configured as a router, assume the Primary Administrator role or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Starting in the Solaris 10 1/06 release, use the dladm show-link command to determine which interfaces are physically installed on the router.


    # dladm show-link
    

    The following example output from dladm show-link indicates that a qfe NIC with four interfaces and two bge interfaces are physically available on the system.


    qfe0             type: legacy    mtu: 1500       device: qfe0
    qfe1             type: legacy    mtu: 1500       device: qfe1
    qfe2             type: legacy    mtu: 1500       device: qfe0
    qfe3             type: legacy    mtu: 1500       device: qfe1
    bge0             type: non-vlan  mtu: 1500       device: bge0
    bge1             type: non-vlan  mtu: 1500       device: bge1
  3. Review which interfaces on the router were configured and plumbed during installation.


    # ifconfig -a
    

    The following example output from ifconfig -a shows that the interface qfe0 was configured during installation. This interface is on the 172.16.0.0 network. The remaining interfaces on the qfe NIC, qfe1 - qfe3, and the bge interfaces have not been configured.


    lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
            inet 127.0.0.1 netmask ff000000 
    qfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
            inet 172.16.26.232 netmask ffff0000 broadcast 172.16.26.255
            ether 0:3:ba:11:b1:15 
             
  4. Configure and plumb another interface.


    # ifconfig interface plumb up
    

    For example, for qfe1, you would type:


    # ifconfig qfe1 plumb up
    

    Note –

    Interfaces that are explicitly configured with the ifconfig command do not persist across reboots.


  5. Assign an IPv4 address and a netmask to the interface.


    Caution – Caution –

    You can configure an IPv4 routers to receive its IP address through DHCP, but this is recommended only for very experienced DHCP system administrators.



    # ifconfig interface IPv4-address netmask+netmask
    

    For example, to assign the IP address 192.168.84.3 to qfe1, do either of the following:

    • Using traditional IPv4 notation, type the following:


      # ifconfig qfe1 192.168.84.3 netmask + 255.255.255.0
      
    • Using CIDR notation, type the following:


      # ifconfig qfe1 192.168.84.3/24
      

      The prefix /24 automatically assigns the 255.255.255.0 netmask to qfe1. For a table of CIDR prefixes and their dotted-decimal netmask equivalents, refer to Figure 2–2.

  6. (Optional) To ensure that the interface configuration persists across reboots, create an /etc/hostname.interface file for each additional physical interface.

    For example, you would create the /etc/hostname.qfe1 and /etc/hostname.qfe2 files. Then you would type the host name timbuktu in /etc/hostname.qfe1 file and host name timbuktu-201 in /etc/hostname.qfe1. For more information about configuring single interfaces, refer to How to Configure a Physical Interface After System Installation.

    Be sure to do a configuration reboot after creating this file:


    # reboot -- -r
    
  7. Add the host name and IP address of each interface to the /etc/inet/hosts file.

    For example:


    172.16.26.232      deadsea        #interface for network 172.16.0.0
    192.168.200.20     timbuktu       #interface for network 192.168.200
    192.168.201.20     timbuktu-201   #interface for network 192.168.201
    192.168.200.9      gobi
    192.168.200.10     mojave
    192.168.200.110    saltlake
    192.168.200.12     chilean

    The interfaces timbuktu and timbuktu-201 are on the same system. Notice that the network address for timbuktu-201 is different from the network interface for timbuktu. The difference exists because the physical network media for network 192.168.201 is connected to the timbuktu-201 network interface while the media for network 192.168.200 is connected to the timbuktu interface.

  8. For Solaris 10 11/06 and earlier releases of Solaris 10 only, add the IP address and host name of each new interface into the /etc/inet/ipnodes file or equivalent ipnodes database.

    For example:


    vi /etc/inet/ipnodes
    172.16.26.232      deadsea        #interface for network 172.16.0.0
    192.168.200.20     timbuktu       #interface for network 192.168.200
    192.168.201.20     timbuktu-201   #interface for network 192.168.201
    
  9. If the router is connected to any subnetted network, add the network number and the netmask to the /etc/inet/netmasks file.

    • For traditional IPv4 address notation, such as 192.168.83.0, you would type:


      192.168.83.0    255.255.255.0
    • For CIDR addresses, use the dotted-decimal version of the prefix in the entry in the /etc/inet/netmask file. Network prefixes and their dotted-decimal equivalents can be found in Figure 2–2. For example, you would use the following entry in /etc/netmasks to express the CIDR network prefix 192.168.3.0/22:


      192.168.3.0 255.255.252.0
  10. Enable IPv4 packet forwarding on the router.

    Use either of the following commands to enable packet forwarding:

    • Use the routeadm command, as follows:


      # routeadm -e ipv4-forwarding -u
      
    • Use the following service management facility (SMF) command:


      # svcadm enable ipv4-forwarding
      

    At this point, the router can forward packets beyond the local network. The router also supports static routing, a process where you can manually add routes to the routing table. If you plan to use static routing on this system, then router configuration is complete. However, you need to maintain routes in the system routing table. For information on adding routes, see Configuring Routes and the route(1M) man page.

  11. (Optional) Start a routing protocol.

    The routing daemon /usr/sbin/in.routed automatically updates the routing table, a process that is known as dynamic routing. Turn on the default IPv4 routing protocols in either of the following ways:

    • Use the routeadm command, as follows:


      # routeadm -e ipv4-routing -u
      
    • Use the following SMF command to start a routing protocol such as RIP.


      # svcadm enable route:default
      

      The SMF FMRI associated with the in.routed daemon is svc:/network/routing/route.

    For information about the routeadm command, see the routeadm(1M) man page.


Example 5–4 Configuring the Default Router for a Network

This example shows how to upgrade a system with more than one interface to become a default router. The goal is to make Router 2, which is shown in Figure 5–3, the default router for network 172.20.1.0. Router 2 contains two wired network connections, one connection to network 172.20.1.0 and one to network 10.0.5.0. The example assumes that the router operates in local files mode, as described in How to Configure a Host for Local Files Mode.

After becoming superuser or assuming an equivalent role, you would determine out the status of the system's interfaces.Starting with Solaris 10 1/06, you can use the dladm command as follows:


# dladm show-link
ce0             type: legacy    mtu: 1500       device: ce0 
bge0            type: non-vlan  mtu: 1500       device: bge0 
bge1            type: non-vlan  mtu: 1500       device: bge1

# ifconfig -a
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 172.20.1.10 netmask ffff0000 broadcast 172.20.10.100
        ether 8:0:20:c1:1b:c6 

The output of dladm show-link indicates that three links are available on the system. Only the ce0 interface has been plumbed. You would begin default router configuration by physically connecting the bge0 interface to the 10.0.5.0 network. Then, you would plumb the interface and make it persist across reboots.


# ifconfig bge0 plumb up
# ifconfig bge0 10.0.5.10
# ifconfig -a
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 172.20.1.10 netmask ffff0000 broadcast 172.255.255.255
        ether 8:0:20:c1:1b:c6 
bge0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.0.5.10 netmask ff000000 broadcast 10.255.255.255
        ether 8:0:20:e5:95:c4
 # vi /etc/hostname.bge0
10.0.5.10
255.0.0.0

Reboot the system, using the reconfiguration boot command:


# reboot -- -r

Continue by configuring the following network databases with information about the newly plumbed interface and the network to which it is connected:


# vi /etc/inet/hosts
127.0.0.1       localhost
172.20.1.10        router2        #interface for network 172.20.1
10.0.5.10          router2-out    #interface for network 10.0.5
# vi /etc/inet/netmasks
172.20.1.0    255.255.0.0
10.0.5.0      255.0.0.0

Finally, use SMF to enable packet forwarding and then enable the in.routed routing daemon.


# svcadm enable ipv4-forwarding
# svcadm enable route:default

Now IPv4 packet forwarding and dynamic routing through RIP are enabled on Router 2. However, the default router configuration for network 172.20.1.0 is not yet complete. You would need to do the following:


Routing Tables and Routing Types

Both routers and hosts maintain a routing table. The routing daemon on each system updates the table with all known routes. The system's kernel reads the routing table before forwarding packets to the local network. The routing table lists the IP addresses of networks that the system knows about, including the system's local, default network. The table also lists the IP address of a gateway system for each known network. The gateway is a system that can receive outgoing packets and forward them one hop beyond the local network. The following is a simple routing table for a system on an IPv4-only network:


Routing Table: IPv4
  Destination           Gateway           Flags  Ref   Use   Interface
-------------------- -------------------- ----- ----- ------ ---------
default              172.20.1.10          UG       1    532   ce0
224.0.0.0            10.0.5.100           U        1      0   bge0
10.0.0.0             10.0.5.100           U        1      0   bge0
127.0.0.1            127.0.0.1            UH       1     57   lo0

You can configure two types of routing on an Oracle Solaris system: static and dynamic. You can configure either or both routing types on a single system. A system that implements dynamic routing relies on routing protocols, such as RIP for IPv4 networks, and RIPng for IPv6 networks, to maintain its routing tables. A system that runs only static routing does not rely on a routing protocol for routing information and for updating the routing table. Instead, you must maintain the system's known routes manually through the route command. For complete details, refer to the route(1M) man page.

When you configure routing for the local network or autonomous system, consider which type of routing to support on particular routers and hosts.

The following table shows the different types of routing and the networking scenarios to which each routing type is best applied.

Routing Type 

Best Used on 

Static 

Small networks, hosts that get their routes from a default router, and default routers that only need to know about one or two routers on the next few hops.

Dynamic 

Larger internetworks, routers on local networks with many hosts, and hosts on large autonomous systems. Dynamic routing is the best choice for systems on most networks.

Combined static and dynamic 

Routers that connect a statically routed network and a dynamically routed network, and border routers that connect an interior autonomous system with external networks. Combining both static and dynamic routing on a system is a common practice. 

The AS that is shown is Figure 5–3 combines both static and dynamic routing.

Configuring Routes

To implement dynamic routing for an IPv4 network, use the routeadm or svcadm command to start the in.routed routing daemon. For instructions, see How to Configure an IPv4 Router. Dynamic routing is the preferred strategy for most networks and autonomous systems. However, your network topology or a particular system on your network might require static routing. In that case, you must manually edit the system routing table to reflect the known route to the gateway. The next procedure shows how to add a static route.


Note –

Two routes to the same destination does not automatically cause the system to do load balancing or failover. If you need these capabilities, use IPMP, as explained in Chapter 30, Introducing IPMP (Overview).


ProcedureHow to Add a Static Route to the Routing Table

  1. View the current state of the routing table.

    Use your regular user account to run the following form of the netstat command:


    % netstat -rn
    

    Your output would resemble the following:


    Routing Table: IPv4
      Destination           Gateway           Flags  Ref   Use   Interface
    -------------------- -------------------- ----- ----- ------ ---------
    192.168.5.125        192.168.5.10          U      1   5879   ipge0
    224.0.0.0            198.168.5.10          U      1  0       ipge0
    default              192.168.5.10          UG     1  91908
    127.0.0.1            127.0.0.1             UH     1  811302   lo0
  2. Assume the Primary Administrator role or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  3. (Optional) Flush the existing entries in the routing table.


    # route flush
    
  4. Add a route that persists across system reboots.


    # route -p add -net network-address -gateway gateway-address
    
    -p

    Creates a route that must persist across system reboots. If you want the route to prevail only for the current session, do not use the -p option.

    add

    Indicates that you are about to add the following route.

    -net network-address

    Specifies that the route goes to the network with the address in network-address.

    -gateway gateway-address

    Indicates that the gateway system for the specified route has the IP address gateway-address.


Example 5–5 Adding a Static Route to the Routing Table

The following example shows how to add a static route to a system. The system is Router 2, the default router for the 172.20.1.0 network that is shown in Figure 5–3. In Example 5–4, Router 2 is configured for dynamic routing. To better serve as the default router for the hosts on network 172.20.1.0, Router 2 additionally needs a static route to the AS's border router, 10.0.5.150.

To view the routing table on Router 2, you would do the following:


# netstat -rn
Routing Table: IPv4
  Destination           Gateway           Flags  Ref   Use   Interface
-------------------- -------------------- ----- ----- ------ ---------
default              172.20.1.10          UG        1    249 ce0
224.0.0.0            172.20.1.10          U         1      0 ce0
10.0.5.0             10.0.5.20            U         1     78 bge0
127.0.0.1            127.0.0.1            UH        1     57 lo0

The routing table indicates two routes that Router 2 knows about. The default route uses Router 2's 172.20.1.10 interface as its gateway. The second route, 10.0.5.0, was discovered by the in.routed daemon running on Router 2. The gateway for this route is Router 1, with the IP address 10.0.5.20.

To add a second route to network 10.0.5.0, which has its gateway as the border router, you would do the following:


# route -p add -net 10.0.5.0/24 -gateway 10.0.5.150/24
add net 10.0.5.0: gateway 10.0.5.150

Now the routing table has a route for the border router, which has the IP address 10.0.5.150/24.


# netstat -rn
Routing Table: IPv4
  Destination           Gateway           Flags  Ref   Use   Interface
-------------------- -------------------- ----- ----- ------ ---------
default              172.20.1.10          UG        1    249 ce0
224.0.0.0            172.20.1.10          U         1      0 ce0
10.0.5.0             10.0.5.20            U         1     78 bge0
10.0.5.0             10.0.5.150           U         1    375 bge0
127.0.0.1            127.0.0.1            UH        1     57 lo0

Configuring Multihomed Hosts

In Oracle Solaris, a system with more than one interface is considered a multihomed host. A multihomed host does not forward IP packets. However, you can configure a multihomed host to run routing protocols. You typically configure the following types of systems as multihomed hosts:

ProcedureHow to Create a Multihomed Host

  1. On the prospective multihomed host, assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Configure and plumb each additional network interface that was not configured as part of the Oracle Solaris installation.

    Refer to How to Configure a Physical Interface After System Installation.

  3. Verify that IP forwarding is not enabled on the multihomed host.


    # routeadm
     
    

    The routeadm command without options reports the state of the routing daemons. The following output from routeadm shows that IPv4 forwarding is enabled:


       Configuration   Current              Current
                         Option   Configuration        System State
    ---------------------------------------------------------------
                   IPv4 routing   disabled             disabled
                   IPv6 routing   disabled             disabled
                IPv4 forwarding   enabled              disabled
                IPv6 forwarding   disabled             disabled
    
                Routing services   "route:default ripng:default"
  4. Turn off packet forwarding, if it is enabled on the system.

    Use either of the following commands:

    • For the routeadm command, type the following:


      # routeadm -d ipv4-forwarding -u
      
    • To use SMF, type the following:


      # svcadm disable ipv4-forwarding
      
  5. (Optional) Turn on dynamic routing for the multihomed host.

    Use either of the following commands to enable the in.routed daemon:

    • For the routeadm command, type the following:


      # routeadm -e ipv4-routing -u
      
    • To use SMF, type the following:


      # svcadm enable route:default
      

Example 5–6 Configuring a Multihomed Host

The following example shows how to configure the multihomed host that is shown in Figure 5–3. In the example, the system has the host name hostc. This host has two interfaces, which are both connected to network 192.168.5.0.

To begin, you would display the status of the system's interfaces.


# dladm show-link
hme0           type: legacy    mtu: 1500       device: hme0 
qfe0           type: legacy    mtu: 1500       device: qfe0 
qfe1           type: legacy    mtu: 1500       device: qfe1 
qfe2           type: legacy    mtu: 1500       device: qfe2 
qfe3           type: legacy    mtu: 1500       device: qfe3
# ifconfig -a
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
hme0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
      inet 192.168.5.82 netmask ff000000 broadcast 192.255.255.255
      ether 8:0:20:c1:1b:c6 
 

The dladm show-link command reports that hostc has two interfaces with a total of five possible links. However, only hme0 has been plumbed. To configure hostc as a multihomed host, you must add qfe0 or another link on the qfe NIC. First, you would physically connect the qfe0 interface to the 192.168.5.0 network. Then you would plumb the qfe0 interface, and make the interface persist across reboots.


# ifconfig qf0 plumb up
# ifconfig qfe0 192.168.5.85
# ifconfig -a
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
hme0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.5.82 netmask ff0000 broadcast 192.255.255.255
        ether 8:0:20:c1:1b:c6 
qfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.5.85 netmask ff000000 broadcast 192.255.255.255
        ether 8:0:20:e1:3b:c4
 # vi /etc/hostname.qfe0
192.168.5.85
255.0.0.0

Reboot the system, using the reconfiguration command:


# reboot -- -r

Next, you would add the qfe0 interface to the hosts database:


# vi /etc/inet/hosts
127.0.0.1           localhost
192.168.5.82        host3    #primary network interface for host3
192.168.5.85        host3-2  #second interface

Then, you would check the state of packet forwarding and routing on host3:


# routeadm
              Configuration   Current              Current
                     Option   Configuration        System State
---------------------------------------------------------------
               IPv4 routing   enabled              enabled
               IPv6 routing   disabled             disabled
            IPv4 forwarding   enabled              enabled
            IPv6 forwarding   disabled             disabled

           Routing services   "route:default ripng:default"

The routeadm command reports that dynamic routing through the in.routed daemon and packet forwarding are currently enabled. However, you would need to disable packet forwarding:


# svcadm disable ipv4-forwarding

You can also use the routeadm commands as shown in How to Create a Multihomed Host to turn off packet forwarding. When packet forwarding is disabled, host3 becomes a multihomed host.


Configuring Routing for Single-Interface Systems

Single-interface hosts need to implement some form of routing. If the host is to obtain its routes from one or more local default routers, then you must configure the host to use static routing. Otherwise, dynamic routing is recommended for the host. The following procedures contain the instructions for enabling both routing types.

ProcedureHow to Enable Static Routing on a Single-Interface Host

This procedure enables static routing on a single-interface host. Hosts that use static routing do not run a dynamic routing protocol such as RIP. Instead, the host must rely on the services of a default router for routing information. The figure IPv4 Autonomous System Topology shows several default routers and their client hosts. If you supplied the name of a default router when you installed a particular host, that host is already configured to use static routing.


Note –

You can also use the following procedure to configure static routing on a multihomed host.


For information about the /etc/defaultrouter file, see /etc/defaultrouter File. For information about static routing and the routing table, refer to Routing Tables and Routing Types.

  1. On the single interface host, assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Verify whether the /etc/defaultrouter file is present on the host.


    # cd /etc
    # ls | grep defaultrouter
    
  3. Open a text editor to create or modify the /etc/defaultrouter file

  4. Add an entry for the default router.


    # vi  /etc/defaultrouter
    router-IP
           
    

    where router-IP indicates the IP address of the default router for the host to use.

  5. Verify that routing and packet forwarding are not running on the host.


    # routeadm
       Configuration   Current              Current
                         Option   Configuration        System State
    ---------------------------------------------------------------
                   IPv4 routing   disabled             disabled
                   IPv6 routing   disabled             disabled
                IPv4 forwarding   disabled            disabled
                IPv6 forwarding   disabled             disabled
    
               Routing services   "route:default ripng:default"
  6. Add an entry for the default router in the local /etc/inet/hosts file.

    For information about configuring /etc/inet/hosts, refer to How to Change the IPv4 Address and Other Network Configuration Parameters.


Example 5–7 Configuring a Default Router and Static Routing for a Single-Interface Host

The following example shows how to configure static routing for hostb, a single-interface host on the network 172.20.1.0 that is shown in Figure 5–3. hostb needs to use Router 2 as its default router.

First, you would log in to hostb as superuser, or assume an equivalent role. Then, you would determine whether the /etc/defaultrouter file is present on the host:


# cd /etc
# ls | grep defaultrouter

No response from grep indicates that you need to create the /etc/defaultrouter file.


# vi /etc/defaultrouter
172.20.1.10

The entry in the /etc/defaultrouter file is the IP address of the interface on Router 2, which is attached to the 172.20.1.0 network. Next, you verify whether the host currently enables packet forwarding or routing.


# routeadm
   Configuration   Current              Current
                     Option   Configuration        System State
---------------------------------------------------------------
               IPv4 routing   disabled             disabled
               IPv6 routing   disabled             disabled
            IPv4 forwarding   enabled              enabled
            IPv6 forwarding   disabled             disabled

           Routing services   "route:default ripng:default"

Packet forwarding is enabled for this particular host. You would turn it off as follows:


# svcadm disable ipv4-forwarding

Lastly, you would make sure that the host's /etc/inet/hosts file has an entry for the new default router.


# vi /etc/inet/hosts
127.0.0.1           localhost
172.20.1.18         host2    #primary network interface for host2
172.20.1.10         router2  #default router for host2

ProcedureHow to Enable Dynamic Routing on a Single-Interface Host

Dynamic routing is the easiest way to manage routing on a host. Hosts that use dynamic routing run the routing protocols provided by the in.routed daemon for IPv4 or in.ripngd daemon for IPv6. Use the next procedure to enable IPv4 dynamic routing on a single interface host. For more information about dynamic routing, refer to Packet Forwarding and Routing on IPv4 Networks.

  1. On the host, assume the Primary Administrator role or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Verify whether the /etc/defaultrouter file exists.


    # cd /etc
    # ls | grep defaultrouter
    
  3. If /etc/defaultrouter exists, delete any entry that you find there.

    An empty /etc/defaultrouter file forces the host to use dynamic routing.

  4. Verify whether packet forwarding and routing are enabled on the host.


    # routeadm
       Configuration   Current              Current
                         Option   Configuration        System State
    ---------------------------------------------------------------
                   IPv4 routing   disabled             disabled
                   IPv6 routing   disabled             disabled
                IPv4 forwarding   enabled              enabled
                IPv6 forwarding   disabled             disabled
    
               Routing services   "route:default ripng:default"
  5. If packet forwarding is enabled, turn it off

    Use either of the following commands:

    • For the routeadm command, type the following:


      # routeadm -d ipv4-forwarding -u
      
    • To use SMF, type the following:


      # svcadm disable ipv4-forwarding
      
  6. Enable routing protocols on the host.

    Use either of the following commands:

    • For the routeadm command, type the following:


      # routeadm -e ipv4-routing -u
      
    • To use SMF, type the following:


      # svcadm enable route:default
      

    Now IPv4 dynamic routing is enabled. The host's routing table is dynamically maintained by the in.routed daemon.


Example 5–8 Running Dynamic Routing on a Single-Interface Host

The following example shows how to configure dynamic routing for hosta, a single-interface host on the network 192.168.5.0 that is shown in Figure 5–3. hosta currently uses Router 1 as its default router. However, hosta now needs to run dynamic routing.

First, you would log in to hosta as superuser or assume an equivalent role. Then, you would determine whether the /etc/defaultrouter file is present on the host:


# cd /etc
# ls | grep defaultrouter
defaultrouter

The response from grep indicates that a /etc/defaultrouter file exists for hosta.


# vi /etc/defaultrouter
192.168.5.10

The file has the entry 192.168.5.10, which is the IP address for Router 1. You would delete this entry to enable static routing. Next, you would need to verify whether packet forwarding and routing are already enabled for the host.


# routeadm   Configuration   Current              Current
                     Option   Configuration        System State
---------------------------------------------------------------
               IPv4 routing   disabled             disabled
               IPv6 routing   disabled             disabled
            IPv4 forwarding   disabled             disabled
            IPv6 forwarding   disabled             disabled

           Routing services   "route:default ripng:default"

Both routing and packet forwarding are turned off for hosta. Turn on routing to complete the configuration of dynamic routing for hosta, as follows:


# svcadm enable route:default

Monitoring and Modifying Transport Layer Services

The transport layer protocols TCP, SCTP, and UDP are part of the standard Oracle Solaris package. These protocols typically need no intervention to run properly. However, circumstances at your site might require you to log or modify services that run over the transport layer protocols. Then, you must modify the profiles for these services by using the Service Management Facility (SMF), which is described in Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration.

The inetd daemon is responsible for starting standard Internet services when a system boots. These services include applications that use TCP, SCTP, or UDP as their transport layer protocol. You can modify existing Internet services or add new services using the SMF commands. For more information about inetd, refer to inetd Internet Services Daemon.

Operations that involve the transport layer protocols include:

For detailed information on the inetd daemon refer to the inetd(1M)man page.

ProcedureHow to Log the IP Addresses of All Incoming TCP Connections

  1. On the local system, assume the Network Management role or become superuser.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Set TCP tracing to enabled for all services managed by inetd.


    # inetadm -M tcp_trace=TRUE
    

ProcedureHow to Add Services That Use the SCTP Protocol

The SCTP transport protocol provides services to application layer protocols in a fashion similar to TCP. However, SCTP enables communication between two systems, either or both of which can be multihomed. The SCTP connection is called an association. In an association, an application divides the data to be transmitted into one or more message streams, or multi-streamed. An SCTP connection can go to endpoints with multiple IP addresses, which is particularly important for telephony applications. The multihoming capabilities of SCTP are a security consideration if your site uses IP Filter or IPsec. Some of these considerations are described in the sctp(7P) man page.

By default, SCTP is included in the Oracle Solaris and does not require additional configuration. However, you might need to explicitly configure certain application layer services to use SCTP. Some example applications are echo and discard. The next procedure shows how to add an echo service that uses an SCTP one-to-one style socket.


Note –

You can also use the following procedure to add services for the TCP and UDP transport layer protocols.


The following task shows how to add an SCTP inet service that is managed by the inetd daemon to the SMF repository. The task then shows how to use the Service Management Facility (SMF) commands to add the service.

Before You Begin

Before you perform the following procedure, create a manifest file for the service. The procedure uses as an example a manifest for the echo service that is called echo.sctp.xml.

  1. Log in to the local system with a user account that has write privileges for system files.

  2. Edit the /etc/services file and add a definition for the new service.

    Use the following syntax for the service definition.


    service-name |port/protocol | aliases
    
  3. Add the new service.

    Go to the directory where the service manifest is stored and type the following:


    # cd dir-name
    # svccfg import service-manifest-name
    

    For a complete syntax of svccfg, refer to the svccfg(1M) man page.

    Suppose you want to add a new SCTP echo service using the manifest echo.sctp.xml that is currently located in the service.dir directory. You would type the following:


    # cd service.dir
    # svccfg import echo.sctp.xml
    
  4. Verify that the service manifest has been added:


    # svcs FMRI
    

    For the FMRI argument, use the Fault Managed Resource Identifier (FMRI) of the service manifest. For example, for the SCTP echo service, you would use the following command:


    # svcs svc:/network/echo:sctp_stream
    

    Your output should resemble the following:


    	STATE          STIME    FMRI
    disabled       16:17:00 svc:/network/echo:sctp_stream

    For detailed information about the svcs command, refer to the svcs(1) man page.

    The output indicates that the new service manifest is currently disabled.

  5. List the properties of the service to determine if you must make modifications.


    # inetadm -l FMRI
    

    For detailed information about the inetadm command, refer to the inetadm(1M) man page.

    For example, for the SCTP echo service, you would type the following:


    # inetadm -l svc:/network/echo:sctp_stream
    SCOPE    NAME=VALUE
    	         name="echo"
    	         endpoint_type="stream"
    	         proto="sctp"
    	         isrpc=FALSE
    	         wait=FALSE
    	         exec="/usr/lib/inet/in.echod -s"
             .
             .
             default  tcp_trace=FALSE
           	default  tcp_wrappers=FALSE
  6. Enable the new service:


    # inetadm -e FMRI
    
  7. Verify that the service is enabled:

    For example, for the new echo service, you would type the following:


    # inetadm | grep sctp_stream
    .
    .
    	enabled   online         svc:/network/echo:sctp_stream

Example 5–9 Adding a Service That Uses the SCTP Transport Protocol

The following example shows the commands to use and the file entries required to have the echo service use the SCTP transport layer protocol.


$ cat /etc/services
.
.
echo            7/tcp
echo            7/udp
echo            7/sctp

# cd service.dir

	# svccfg import echo.sctp.xml

# svcs network/echo*
	STATE          STIME    FMRI
	disabled       15:46:44 svc:/network/echo:dgram
	disabled       15:46:44 svc:/network/echo:stream
	disabled       16:17:00 svc:/network/echo:sctp_stream

# inetadm -l svc:/network/echo:sctp_stream
	SCOPE    NAME=VALUE
	         name="echo"
	         endpoint_type="stream"
	         proto="sctp"
	         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

# inetadm -e svc:/network/echo:sctp_stream

# inetadm | grep echo
	disabled  disabled       svc:/network/echo:stream
	disabled  disabled       svc:/network/echo:dgram
	enabled   online         svc:/network/echo:sctp_stream

ProcedureHow to Use TCP Wrappers to Control Access to TCP Services

The tcpd program implements TCP wrappers. TCP wrappers add a measure of security for service daemons such as ftpd by standing between the daemon and incoming service requests. TCP wrappers log successful and unsuccessful connection attempts. Additionally, TCP wrappers can provide access control, allowing or denying the connection depending on where the request originates. You can use TCP wrappers to protect daemons such as SSH, Telnet, and FTP. The sendmail application can also use TCP wrappers, as described in Support for TCP Wrappers From Version 8.12 of sendmail in System Administration Guide: Network Services.

  1. On the local system, assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Set TCP wrappers to enabled.


    # inetadm -M tcp_wrappers=TRUE
    
  3. Configure the TCP wrappers access control policy as described in the hosts_access(3) man page.

    This man page can be found in the /usr/sfw/man directory on the SFW CD-ROM, which is packaged along with the Oracle Solaris CD-ROM.

Administering Interfaces in Solaris 10 3/05

This section contains the following tasks for administering physical interfaces:

What's New in This Section

This section contains information on configuring interfaces for users of the Solaris 10 3/05 OS only. If you are using an update to the Oracle Solaris 10, refer to Chapter 6, Administering Network Interfaces (Tasks). For a complete listing of new Oracle Solaris features and a description of Oracle Solaris releases, refer to Oracle Solaris 10 9/10 What’s New.

Configuring Physical Interfaces in Solaris 10 3/05

An Oracle Solaris-based system usually has two types of interfaces, physical and logical. Physical interfaces consist of a driver and a connector into which you plug network media, such as an Ethernet cable. Logical interfaces are logically configured onto existing physical interfaces, such as interfaces that are configured for tunnels or configured with IPv6 addresses. This section describes how to configure physical interfaces after installation. Instructions for configuring logical interfaces are included with tasks for features that require logical interfaces, for example, How to Manually Configure IPv6 Over IPv4 Tunnels.

Types of physical interfaces include interfaces that are built into the system and separately purchased interfaces. Each interface resides on a network interface card (NIC).

Built-in NICs are present on the system when it is purchased. An example of an interface on a built-in NIC is the primary network interface, such as eri0 or hme0. You must configure the system's primary network interface at installation time.

NICs such as eri and hme have only one interface. However, many brands of NICs have multiple interfaces. A multiple interface NIC such as the qfe card has four interfaces, qfe0qfe3. The Oracle Solaris installation program detects all interfaces present at installation and asks if you want to configure the interfaces. You can configure these interfaces at boot time or at a later date.


Note –

NICs are also referred to as network adapters.


In addition to the built-in NICs, you can add separately purchased NICs to a system. You physically install a separately purchased NIC according to the manufacturer's instructions. Then, you need to configure the interfaces on the NIC so that the interfaces can be used for passing data traffic.

The following are reasons to configure additional interfaces on a system after installation:

ProcedureHow to Add a Physical Interface After Installation in Solaris 10 3/05 ONLY

Before You Begin

Determine the IPv4 addresses that you want to use for the additional interfaces.

The physical interface to be configured must be present on the system. For information on installing separately purchased NIC hardware, refer to the manufacturers instructions that accompany the NIC.

The next procedure assumes that you have performed a reconfiguration boot after physically installing a new interface.


Note –

The next procedure contains applies to users of the Solaris 10 3/05 OS only. If you are using an update to Oracle Solaris 10, refer to How to Configure a Physical Interface After System Installation.


  1. On the system with the interfaces to be configured, assume the Primary Administrator role or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Configure and plumb each interface.


    # ifconfig interface plumb up
    

    For example, for qfe0 you would type:


    # ifconfig qfe0 plumb up
    

    Note –

    Interfaces that are explicitly configured with the ifconfig command do not persist across a reboot.


  3. Assign an IPv4 address and netmask to the interface.


    # ifconfig interface IPv4-address netmask+netmask
    

    For example, for qfe0 you would type:


    # ifconfig qfe0 10.0.0.32 netmask + 255.255.255.0
    
  4. Verify that the newly configured interfaces are plumbed and configured, or “UP.”


    # ifconfig -a
    

    Check the status line for each interface that is displayed. Ensure that the output contains an UP flag on the status line, for example:


    qfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
  5. (Optional) To make the interface configuration persist across reboots, perform the following steps:

    1. Create an /etc/hostname.interface file for each interface to be configured.

      For example, to add a qfe0 interface, you would create the following file:


      # vi /etc/hostname.qfe0
      
    2. Edit the /etc/hostname.interface file.

      At a minimum, add the IPv4 address of the interface to the file. You can also add a netmask and other configuration information to the file.


      Note –

      To add an IPv6 address to an interface, refer to Modifying an IPv6 Interface Configuration for Hosts and Servers


    3. Add entries for the new interfaces into the /etc/inet/hosts file.

    4. Perform a reconfiguration boot.


      # reboot -- -r
      
    5. Verify that the interface you created in the /etc/hostname.interface file has been configured.


      # ifconfig -a
      

Example 5–10 Configuring an Interface After System Installation

The following example shows how to add two interfaces, qfe0 and qfe1. These interfaces are attached to the same network as the primary network interface, hme0. Note that this interface configuration exists until you reboot the system. For an example that shows how to make interface configurations persist across reboots, see Example 6–2. However, the dladm command that is used in that example is only available starting with the Solaris 10 1/06 OS.


# ifconfig qfe0 plumb up
# ifconfig qfe1 plumb up
# ifconfig qfe0 10.0.0.32 netmask 255.0.0.0
# ifconfig qfe1 10.0.0.33 netmask 255.0.0.0

# ifconfig -a
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
hme0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.0.0.14 netmask ff000000 broadcast 10.255.255.255
        ether 8:0:20:c1:8b:c3 
qfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
        inet 10.0.0.32 netmask ff000000 broadcast 10.255.255.255
        ether 8:0:20:c8:f4:1d 
qfe1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
        inet 10.0.0.33 netmask ff000000 broadcast 10.255.255.255
        ether 8:0:20:c8:f4:1e 

See Also

ProcedureHow to Remove a Physical Interface in Solaris 10 3/05 ONLY


Note –

The next procedure contains applies to users of the Solaris 10 3/05 OS only. If you are using an update to Oracle Solaris 10, refer to How to Remove a Physical Interface.


  1. On the system with the interface to be removed, assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Remove the physical interface.

    Use the following form of the ifconfig command:


    # ifconfig interfacedown unplumb
    

    For example, you would remove the interface eri1 as follows:


    # ifconfig eri1 down unplumb
    

Configuring VLANs in Solaris 10 3/05 ONLY


Note –

This section contains information on configuring VLANs for users of the Solaris 10 3/05 OS only. If you are using an update to Oracle Solaris 10, refer to Administering Virtual Local Area Networks.


Virtual local area networks (VLANs) are commonly used to split up groups of network users into manageable broadcast domains, to create logical segmentation of work groups, and to enforce security policies among each logical segment. With multiple VLANs on an adapter, a server with a single adapter can have a logical presence on multiple IP subnets. By default, 512 VLANs can be defined for each VLAN-aware adapter on your server.

If your network does not require multiple VLANs, you can use the default configuration, in which case no further configuration is necessary.

For an overview of VLANs, refer to Overview of VLAN Topology.

VLANs can be created according to various criteria, but each VLAN must be assigned a VLAN tag or VLAN ID (VID). The VID is a 12-bit identifier between 1 and 4094 that identifies a unique VLAN. For each network interface (for example, ce0, ce1, ce2, and so on) 512 possible VLANs can be created. Because IP subnets are commonly used, use IP subnets when setting up a VLAN network interface. This means that each VID assigned to a VLAN interface of a physical network interface belongs to different subnets.

Tagging an Ethernet frame requires the addition of a tag header to the frame. The header is inserted immediately following the destination MAC address and the source MAC address. The tag header consists of two bytes of the Ethernet Tag Protocol Identifier (TPID, 0x8100) and two bytes of Tag Control Information (TCI). The following figure shows the Ethernet Tag Header format.

Figure 5–4 Ethernet Tag Header Format

The figure shows the layout of the Ethernet tag header,
as described in the previous context.

ProcedureHow To Configure Static VLANs in Solaris 10 3/05 ONLY


Note –

This procedure contains information on configuring VLANs for users of the Solaris 10 3/05 OS only. If you are using an update to Oracle Solaris 10, refer to How to Configure a VLAN


  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Determine the type of interfaces in use on your system.

    The network adapter on your system might not be referred to by the letters ce, which is required for a VLAN.


    # ifconfig -a
    lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4>
    mtu 8232 index 1
            inet 127.0.0.1 netmask ff000000 
    hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4>
    mtu 1500 index 2
            inet 129.156.200.77 netmask ffffff00 broadcast
    129.156.200.255
  3. Create one hostname.cenum file (hostname6.cenum file for IPv6) for each VLAN that will be configured for each adapter on the server.

    Use the following naming format that includes both the VID and the physical point of attachment (PPA):

    VLAN logical PPA = 1000 * VID + Device PPA ce123000 = 1000*123 + 0

    For example: hostname.ce123000

    VLAN logical PPA = 1000 * VID + Device PPA ce11000 = 1000*11 + 0

    For example: hostname.ce11000

    This format limits the maximum number of PPAs (instances) you can configure to 1000 in the /etc/path_to_inst file.

    For example, on a server with the Sun Gigabit Ethernet/P 3.0 adapter having an instance of 0, that belongs to two VLANs with VIDs 123 and 224, you would use ce123000 and ce224000, respectively, as the two VLAN PPAs.

  4. Configure a VLAN virtual device:

    For example, you could use the following examples of ifconfig:


    # ifconfig ce123000 plumb up
    # ifconfig ce224000 plumb up
    

    The output of ifconfig -a on a system with VLAN devices ce123000 and ce224000 should resemble the following:


    # ifconfig -a
    lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
            inet 127.0.0.1 netmask ff000000 
    hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
            inet 129.144.131.91 netmask ffffff00 broadcast 129.144.131.255
            ether 8:0:20:a4:4f:b8 
    ce123000: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
            inet 199.199.123.3 netmask ffffff00 broadcast 199.199.123.255
            ether 8:0:20:a4:4f:b8 
    ce224000: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
            inet 199.199.224.3 netmask ffffff00 broadcast 199.199.224.255
            ether 8:0:20:a4:4f:b8 
  5. On the switch, set VLAN tagging and VLAN ports to coincide with the VLANs you have set up on the server.

    Using the examples in Step 4, you would set up VLAN ports 123 and 224 on the switch or VLAN ports 10 and 11.

    Refer to the documentation that came with your switch for specific instructions for setting VLAN tagging and ports.

Chapter 6 Administering Network Interfaces (Tasks)

This chapter contains tasks and information about network interfaces:

What's New in Administering Network Interfaces

The information in this chapter describes interface configuration starting with the Solaris 10 1/06 release. If you are using the original release of Solaris 10, 3/05, refer to Administering Interfaces in Solaris 10 3/05. For a complete listing of new Oracle Solaris features and a description of Oracle Solaris releases, refer to Oracle Solaris 10 9/10 What’s New.

In Solaris 10 1/06, the following new features were introduced:

In Solaris 10 7/07, the /etc/inet/ipnodes becomes obsolete. Use /etc/inet/ipnodes only for earlier Solaris 10 releases, as explained in the individual procedures.

Interface Administration (Task Map)

The following table lists different tasks for configuring network interfaces, including special configurations such as VLANs and link aggregations. The table includes a description of what each task accomplishes and the section in the current documentation where the specific steps to perform the task are detailed.

Task 

Description 

For Instructions 

Check the status of interfaces on a system. 

List all interfaces on the system and check which interfaces are already plumbed. 

How to Obtain Interface Status

Add a single interface after system installation. 

Change a system to a multihomed host or router by configuring another interface. 

How to Configure a Physical Interface After System Installation

SPARC: Check that the MAC address of an interface is unique. 

Ensure that the interface is configured with its factory-installed MAC address, rather than the system MAC address (SPARC only). 

SPARC: How to Ensure That the MAC Address of an Interface Is Unique

Plan for a virtual local area network (VLAN). 

Perform required planning tasks prior to creating a VLAN. 

How to Plan a VLAN Configuration

Configure a VLAN. 

Create and modify VLANs on your network. 

How to Configure a VLAN

Plan for aggregations. 

Design your aggregation and perform required planning tasks prior to configuring aggregations. 

Overview of Link Aggregations

Configure an aggregation. 

Perform various tasks related to link aggregations. 

How to Create a Link Aggregation

Plan for and configure an IPMP group. 

Configure failover and failback for interfaces that are members of an IPMP group. 

How to Plan for an IPMP Group

How to Configure an IPMP Group With Multiple Interfaces

Administering Individual Network Interfaces

After Oracle Solaris installation, you might configure or administer interfaces on a system for the following purposes:

This section contains information about configuring individual network interfaces , starting with the Solaris 10 1/06 release. Refer to the following sections for information about configuring interfaces into one of the following groupings:

ProcedureHow to Obtain Interface Status

Starting with Solaris 10 1/06, this procedure explains how to determine which interfaces are currently available on a system and their status. This procedure also shows which interfaces are currently plumbed. If you are using the earlier Solaris 10 3/05, refer to How to Get Information About a Specific Interface.

  1. On the system with the interfaces to be configured, assume the Primary Administrator role or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Determine which interfaces are currently installed on your system.


    # dladm show-link
    

    This step uses the dladm command, which is explained in detail in the dladm(1M) man page. This command reports on all the interface drivers that it finds, regardless of whether the interfaces are currently configured.

  3. Determine which interfaces on the system are currently plumbed.


    # ifconfig -a
    

    The ifconfig command has many additional functions, including plumbing an interface. For more information, refer to the ifconfig(1M) man page.


Example 6–1 Obtaining the Status of an Interface with the dladm command

The next example shows the status display of the dladm command.


# dladm show-link
ce0             type: legacy    mtu: 1500       device: ce0
ce1             type: legacy    mtu: 1500       device: ce1
bge0            type: non-vlan  mtu: 1500       device: bge0
bge1            type: non-vlan  mtu: 1500       device: bge1
bge2            type: non-vlan  mtu: 1500       device: bge2
 

The output of dladm show-link indicates that four interface drivers are available for the local host. Both the ce and the bge interfaces can be configured for VLANs. However, only the GLDV3 interfaces with a type of non-VLAN can be used for link aggregations.

The next example shows the status display of the ifconfig -a command.


# ifconfig -a
 lo0: flags=2001000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
8232 index 1
         inet 127.0.0.1 netmask ff000000  
ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>mtu 1500 index 3
         inet 192.168.84.253 netmask ffffff00 broadcast 192.168.84.255
        ether 0:3:ba:7:84:5e  
bge0: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4>mtu 1500 index 2
         inet 10.8.57.39 netmask ffffff00 broadcast 10.8.57.255
        ether 0:3:ba:29:fc:cc 

The output of the ifconfig -a command displays statistics for only two interfaces, ce0 and bge0. This output shows that only ce0 and bge0 have been plumbed and are ready for use by network traffic. These interfaces can be used in a VLAN. Because bge0 has been plumbed, you can no longer use this interface in an aggregation.


ProcedureHow to Configure a Physical Interface After System Installation

Use the next procedure for configuring interfaces. If you are using the Solaris 10 3/05 release, use the procedure How to Add a Physical Interface After Installation in Solaris 10 3/05 ONLY.

Before You Begin
  1. On the system with the interfaces to be configured, assume the Primary Administrator role or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Determine which interfaces are currently installed on the system.


    # dladm show-link
    
  3. Configure and plumb each interface.


    # ifconfig interface plumb up
    

    For example, for qfe0 you would type:


    # ifconfig qfe0 plumb up
    

    Note –

    Interfaces that are explicitly configured with the ifconfig command do not persist across a reboot.


  4. Assign an IPv4 address and netmask to the interface.


    # ifconfig interface IPv4-address netmask+netmask
    

    For example, for qfe0 you would type:


    # ifconfig
    qfe0 192.168.84.3 netmask + 255.255.255.0
    

    Note –

    You can specify an IPv4 address in either traditional IPv4 notation or CIDR notation.


  5. Verify that the newly configured interfaces are plumbed and configured, or “UP.”


    # ifconfig
    -a
    

    Check the status line for each interface that is displayed. Ensure that the output contains an UP flag on the status line, for example:


    qfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>
    mtu 1500 index 2
  6. (Optional) To make the interface configuration persist across reboots, perform the following steps:

    1. Create an /etc/hostname.interface file for each interface to be configured.

      For example, to add a qfe0 interface, you would create the following file:


      # vi /etc/hostname.qfe0
      

      Note –

      If you create alternate hostname files for the same interface, the alternate files must also follow the naming format hostname.[0–9]*, such as hostname.qfe0.a123. Names such as hostname.qfe0.bak or hostname.qfe0.old are invalid and will be ignored by scripts during system boot.

      Note, too, that a given interface must have only one corresponding hostname file. If you create an alternate hostname file for an interface with a valid filename, such as /etc/hostname.qfe and /etc/hostname.qfe.a123, the boot scripts will attempt to configure by referencing the contents of both hostname files and would therefore generate errors. To prevent these errors, provide an invalid file name to the hostname file that you do not want to use in a given configuration.


    2. Edit the /etc/hostname.interface file.

      At a minimum, add the IPv4 address of the interface to the file. You can use traditional IPv4 notation or CIDR notation to specify the IP address of the interface. You can also add a netmask and other configuration information to the file.


      Note –

      To add an IPv6 address to an interface, refer to Modifying an IPv6 Interface Configuration for Hosts and Servers


    3. For Solaris 10 11/06 and earlier releases of Oracle Solaris 10, add entries for the new interfaces into the /etc/inet/ipnodes file.

    4. Add entries for the new interfaces into the /etc/inet/hosts file.

    5. Perform a reconfiguration boot.


      # reboot -- -r
      
    6. Verify that the interface you created in the /etc/hostname.interface file has been configured.


      # ifconfig -a
      

      For examples, refer to Example 6–2.


Example 6–2 Adding Persistent Interface Configurations

The example shows how to configure the interfaces qfe0 and qfe1 to a host. These interfaces remain persistent across reboots.


# dladm show-link
eri0    type: legacy    mtu: 1500       device: eri0 
qfe0    type: legacy    mtu: 1500       device: qfe0 
qfe1    type: legacy    mtu: 1500       device: qfe1 
qfe2    type: legacy    mtu: 1500       device: qfe2 
qfe3    type: legacy    mtu: 1500       device: qfe3 
bge0    type: non-vlan  mtu: 1500       device: bge0
# vi /etc/hostname.qfe0
192.168.84.3 netmask 255.255.255.0
# vi /etc/hostname.qfe1 
192.168.84.72 netmask 255.255.255.0
# vi /etc/inet/hosts
# Internet host table 
# 
127.0.0.1       localhost 
10.0.0.14       myhost
192.168.84.3       interface-2 
192.168.84.72       interface-3
For Solaris 10 11/06 and earlier releases:# vi /etc/inet/ipnodes
10.0.0.14 myhost
192.168.84.3       interface-2 
192.168.84.72       interface-3

At this point, you would reboot the system.


# reboot -- -r

After the system boots, you would then verify the interface configuration.


ifconfig -a
# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu
8232 index 1
         inet 127.0.0.1 netmask ff000000  
eri0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
         inet 10.0.0.14netmask ff000000 broadcast 10.255.255.255
         ether 8:0:20:c1:8b:c3  
qfe0:flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3  
      inet 192.168.84.3 netmask ffffff00 broadcast 192.255.255.255
      ether 8:0:20:c8:f4:1d  
qfe1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>mtu 1500 index 4
         inet 192.168.84.72 netmask ffffff00 broadcast 10.255.255.255
        ether 8:0:20:c8:f4:1e 

See Also

ProcedureHow to Remove a Physical Interface

Use this procedure for removing a physical interface. If you are using the earlier Solaris 10 3/05, refer to How to Remove a Physical Interface in Solaris 10 3/05 ONLY.

  1. On the system with the interface to be removed, assume the Primary Administrator role or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Remove the physical interface.


    # ifconfig interface down unplumb 
    

    For example, to remove the interface qfe1, you would type:


    # ifconfig qfe1 down unplumb
    

ProcedureSPARC: How to Ensure That the MAC Address of an Interface Is Unique

Use this procedure for configuring MAC addresses.

Some applications require every interface on a host to have a unique MAC addresses. However, every SPARC based system has a system-wide MAC address, which by default is used by all interfaces. Here are two situations where you might want to configure the factory-installed MAC addresses for the interfaces on a SPARC system.

The EEPROM parameter local-mac-address? determines whether all interfaces on a SPARC system use the system-wide MAC address or their unique MAC address. The next procedure shows how to use the eeprom command to check the current value of local-mac-address? and change it, if necessary.

  1. On the system with the interfaces to be configured, assume the Primary Administrator role or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Determine whether all interfaces on the system currently use the system-wide MAC address.


    # eeprom local-mac-address?
    local-mac-address?=false

    In the example, the response to the eeprom command, local-mac-address?=false, indicates that all interfaces do use the system-wide MAC address. The value of local-mac-address?=false must be changed to local-mac-address?=true before the interfaces can become members of an IPMP group. You should also change local-mac-address?=false to local-mac-address?=true for aggregations.

  3. If necessary, change the value of local-mac-address? as follows:


    # eeprom local-mac-address?=true
    

    When you reboot the system, the interfaces with factory-installed MAC addresses now use these factory settings, rather than the system-wide MAC address. Interfaces without factory-set MAC addresses continue to use the system-wide MAC address.

  4. Check the MAC addresses of all the interfaces on the system.

    Look for cases where multiple interfaces have the same MAC address. In this example, all interfaces use the system-wide MAC address 8:0:20:0:0:1.


    ifconfig -a
    lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
          inet 127.0.0.1 netmask ff000000  
    hme0: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
          inet 10.0.0.112 netmask ffffff80 broadcast 10.0.0.127
          ether 8:0:20:0:0:1 
    ce0: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
          inet 10.0.0.114 netmask ffffff80 broadcast 10.0.0.127
          ether 8:0:20:0:0:1 
    ce1: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
          inet 10.0.0.118 netmask ffffff80 broadcast 10.0.0.127
          ether 8:0:20:0:0:1

    Note –

    Continue to the next step only if more than one network interface still has the same MAC address. Otherwise, go on to the final step.


  5. If necessary, manually configure the remaining interfaces so that all interfaces have unique MAC address.

    Specify a unique MAC address in the /etc/hostname.interface file for the particular interface.

    In the example in Step 4, you would need to configure ce0 and ce1 with locally administered MAC addresses. For example, to reconfigure ce1 with the locally administered MAC address 06:05:04:03:02, you would add the following line to /etc/hostname.ce1:


    ether 06:05:04:03:02 
    

    Note –

    To prevent any risk of manually configured MAC addresses conflicting with other MAC addresses on your network, you must always configure locally administered MAC addresses, as defined by the IEEE 802.3 standard.


    You also can use the ifconfig ether command to configure an interface's MAC address for the current session. However, any changes made directly with ifconfig are not preserved across reboots. Refer to the ifconfig(1M) man page for details.

  6. Reboot the system.

Basics for Administering Physical Interfaces

Network interfaces provide the connection between a system and a network. An Oracle Solaris-based system can have two types of interfaces, physical and logical. Physical interfaces consist of a software driver and a connector into which you connect network media, such as an Ethernet cable. Physical interfaces can be grouped for administrative or availability purposes. Logical interfaces are configured onto existing physical interfaces, usually for adding addresses and creating tunnel endpoints on the physical interfaces.


Note –

Logical network interfaces are described in the tasks where they are used: IPv6 tasks, IPMP tasks, DHCP tasks, and others.


Most computer systems have at least one physical interface that is built-in by the manufacturer on the main system board. Some systems can also have more than one built-in interface.

In addition to built-in interfaces, you can add separately purchased interfaces to a system. A separately purchased interface is known as a network interface card (NIC). You physically install a NIC according to the manufacturer's instructions.


Note –

NICs are also referred to as network adapters.


During system installation, the Oracle Solaris installation program detects any interfaces that are physically installed and displays each interface's name. You must configure at least one interface from the list of interfaces. The first interface to be configured during installation becomes the primary network interface. The IP address of the primary network interface is associated with the configured host name of the system, which is stored in the /etc/nodename file. However, you can configure any additional interfaces during installation or later.

Network Interface Names

Each physical interface is identified by a unique device name. Device names have the following syntax:


<driver-name><instance-number>

Driver names on Oracle Solaris systems could include ce, hme, bge, e1000g and many other driver names. The variable instance-number can have a value from zero to n, depending on how many interfaces of that driver type are installed on the system.

For example, consider a 100BASE-TX Fast Ethernet interface, which is often used as the primary network interface on both host systems and server systems. Some typical driver names for this interface are eri, qfe, and hme. When used as the primary network interface, the Fast Ethernet interface has a device name such as eri0 or qfe0.

NICs such as eri and hme have only one interface. However, many brands of NICs have multiple interfaces. For example, the Quad Fast Ethernet (qfe) card has four interfaces, qfe0 through qfe3.

Plumbing an Interface

An interface must be plumbed before it can pass traffic between the system and the network. The plumbing process involves associating an interface with a device name. Then, streams are set up so that the interface can be used by the IP protocol. Both physical interfaces and logical interfaces must be plumbed. Interfaces are plumbed either as part of the boot sequence or explicitly, with the appropriate syntax of the ifconfig command.

When you configure an interface during installation, the interface is automatically plumbed. If you decide during installation not to configure the additional interfaces on the system, those interfaces are not plumbed.

Oracle Solaris Interface Types

Starting with the Solaris 10 1/06 release, Oracle Solaris supports the following two types of interfaces:

Administering Virtual Local Area Networks


Note –

If you are using the earlier Solaris 3/05, refer to Configuring VLANs in Solaris 10 3/05 ONLY.


A virtual local area network (VLAN) is a subdivision of a local area network at the datalink layer of the TCP/IP protocol stack. You can create VLANs for local area networks that use switch technology. By assigning groups of users to VLANs, you can improve network administration and security for the entire local network. You can also assign interfaces on the same system to different VLANs.

Consider dividing your local network into VLANs if you need to do the following:

Overview of VLAN Topology

Switched LAN technology enables you to organize the systems on a local network into VLANs. Before you can divide a local network into VLANs, you must obtain switches that support VLAN technology. You can configure all ports on a switch to serve a single VLAN or multiple VLANs, depending on the VLAN topology design. Each switch manufacturer has different procedures for configuring the ports of a switch.

The following figure shows a local area network that has the subnet address 192.168.84.0. This LAN is subdivided into three VLANs, Red, Yellow, and Blue.

Figure 6–1 Local Area Network With Three VLANs

The surrounding context describes the figure's content.

Connectivity on LAN 192.168.84.0 is handled by Switches 1 and 2. The Red VLAN contains systems in the Accounting workgroup. The Human Resources workgroup's systems are on the Yellow VLAN. Systems of the Information Technologies workgroup are assigned to the Blue VLAN.

VLAN Tags and Physical Points of Attachment

Each VLAN in a local area network is identified by a VLAN tag, or VLAN ID (VID). The VID is assigned during VLAN configuration. The VID is a 12-bit identifier between 1 and 4094 that provides a unique identity for each VLAN. In Figure 6–1, the Red VLAN has the VID 789, the Yellow VLAN has the VID 456, and the Blue VLAN has the VID 123.

When you configure switches to support VLANs, you need to assign a VID to each port. The VID on the port must be the same as the VID assigned to the interface that connects to the port, as shown in the following figure.

Figure 6–2 Switch Configuration for a Network with VLANs

The surrounding context describes the figure's content.

Figure 6–2 shows multiple hosts that are connected to different VLANs. Two hosts belong to the same VLAN. In this figure, the primary network interfaces of the three hosts connect to Switch 1. Host A is a member of the Blue VLAN. Therefore, Host A's interface is configured with the VID 123. This interface connects to Port 1 on Switch 1, which is then configured with the VID 123. Host B is a member of the Yellow VLAN with the VID 456. Host B's interface connects to Port 5 on Switch 1, which is configured with the VID 456. Finally, Host C's interface connects to Port 9 on Switch 1. The Blue VLAN is configured with the VID 123.

The figure also shows that a single host can also belong to more than one VLAN. For example, Host A has two VLANs configured over the host's interface. The second VLAN is configured with the VID 456 and is connected to Port 3 which is also configured with the VID 456. Thus, Host A is a member of both the Blue VLAN and the Yellow VLAN.

During VLAN configuration, you have to specify the physical point of attachment, or PPA, of the VLAN. You obtain the PPA value by using this formula:


driver-name + VID * 1000 + device-instance

Note that the device-instance number must be less than 1000.

For example, you would create the following PPA for a ce1 interface to be configured as part of VLAN 456:


ce + 456 * 1000 + 1= ce456001

Planning for VLANs on a Network

Use the following procedure to plan for VLANs on your network.

ProcedureHow to Plan a VLAN Configuration

  1. Examine the local network topology and determine where subdivision into VLANs is appropriate.

    For a basic example of such a topology, refer to Figure 6–1.

  2. Create a numbering scheme for the VIDs, and assign a VID to each VLAN.


    Note –

    A VLAN numbering scheme might already exist on the network. If so, you must create VIDs within the existing VLAN numbering scheme.


  3. On each system, determine which interfaces will be members of a particular VLAN.

    1. Determine which interfaces are configured on a system.


      # dladm show-link
      
    2. Identify which VID will be associated with each datalink on the system.

    3. Create PPAs for each interface to be configured with a VLAN.

    All interfaces on a system do not necessarily have to be configured on the same VLAN.

  4. Check the connections of the interfaces to the network's switches.

    Note the VID of each interface and the switch port where each interface is connected.

  5. Configure each port of the switch with the same VID as the interface to which it is connected.

    Refer to the switch manufacturer's documentation for configuration instructions.

Configuring VLANs


Note –

If you are using the earlier Solaris 10 3/05, refer to Configuring VLANs in Solaris 10 3/05 ONLY.


Oracle Solaris now supports VLANs on the following interface types:

Of the legacy interface types, only the ce interface can become a member of a VLAN. You can configure interfaces of different types in the same VLAN.


Note –

You can configure multiple VLANs into an IPMP group. For more information about IPMP groups, see IPMP Interface Configurations.


ProcedureHow to Configure a VLAN

If you are using Solaris 10 3/05, use the procedure How To Configure Static VLANs in Solaris 10 3/05 ONLY.

  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Determine the types of interfaces in use on your system.


    # dladm show-link
    

    The output shows the available interface types:


    ce0             type: legacy    mtu: 1500       device: ce0
     ce1             type: legacy    mtu: 1500       device: ce1
     bge0            type: non-vlan  mtu: 1500       device: bge0
     bge1            type: non-vlan  mtu: 1500       device: bge1
     bge2            type: non-vlan  mtu: 1500       device: bge2
  3. Configure an interface as part of a VLAN.


    # ifconfig interface-PPA plumb IP-address up
    

    For example, you would use the following command to configure the interface ce1 with a new IP address 10.0.0.2 into a VLAN with the VID 123:


    # ifconfig ce123001 plumb 10.0.0.2
    up
    

    Note –

    You can assign IPv4 and IPv6 addresses to VLANs just as you do to other interfaces.


  4. (Optional) To make the VLAN settings persist across reboots, create a hostname.interface-PPA file for each interface that is configured as part of a VLAN.


    # cat hostname.interface-PPA
    IPv4-address
    
  5. On the switch, set VLAN tagging and VLAN ports to correspond with the VLANs that you have set up on the system.


Example 6–3 Configuring a VLAN

This example shows how to configure devices bge1 and bge2 into a VLAN with the VID 123.


# dladm show-link
ce0            type: legacy    mtu: 1500       device: ce0
ce1            type: legacy    mtu: 1500       device: ce1
bge0           type: non-vlan  mtu: 1500       device: bge0 
bge1           type: non-vlan  mtu: 1500       device: bge1 
bge2           type: non-vlan  mtu: 1500       device: bge2
# ifconfig bge123001 plumb 10.0.0.1 up
# ifconfig bge123002 plumb 10.0.0.2 up  
# cat hostname.bge123001   10.0.0.1
# cat hostname.bge123002   10.0.0.2
# ifconfig -a
 lo0: flags=2001000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
         inet 127.0.0.1 netmask ff000000  
 bge123001: flags=201000803<UP,BROADCAST,MULTICAST,IPv4,CoS> mtu 1500 index 2
         inet 10.0.0.1 netmask ff000000 broadcast 10.255.255.255
         ether 0:3:ba:7:84:5e  
bge123002:flags=201000803 <UP,BROADCAST,MULTICAST,IPv4,CoS> mtu 1500 index 3
         inet 10.0.0.2 netmask ff000000 broadcast 10.255.255.255
         ether 0:3:ba:7:84:5e  
ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>mtu 1500 index 4
         inet 192.168.84.253 netmask ffffff00 broadcast 192.168.84.255
         ether 0:3:ba:7:84:5e
# dladm show-link
ce0             type: legacy    mtu: 1500       device: ce0
ce1             type: legacy    mtu: 1500       device: ce1
bge0            type: non-vlan  mtu: 1500       device: bge0 
bge1            type: non-vlan  mtu: 1500       device: bge1 
bge2            type: non-vlan  mtu: 1500       device: bge2
bge123001       type: vlan 123  mtu: 1500       device: bge1 
bge123002       type: vlan 123  mtu: 1500       device: bge2

Overview of Link Aggregations


Note –

The original Oracle Solaris 10 release and earlier versions of Oracle Solaris do not support Link Aggregations. To create link aggregations for these earlier Oracle Solaris releases, use Sun Trunking, as described in the Sun Trunking 1.3 Installation and Users Guide.


Oracle Solaris supports the organization of network interfaces into link aggregations. A link aggregation consists of several interfaces on a system that are configured together as a single, logical unit. Link aggregation, also referred to as trunking, is defined in the IEEE 802.3ad Link Aggregation Standard.

The IEEE 802.3ad Link Aggregation Standard provides a method to combine the capacity of multiple full-duplex Ethernet links into a single logical link. This link aggregation group is then treated as though it were, in fact, a single link.

The following are features of link aggregations:

Link Aggregation Basics

The basic link aggregation topology involves a single aggregation that contains a set of physical interfaces. You might use the basic link aggregation in the following situations:

Figure 6–3 shows an aggregation for a server that hosts a popular web site. The site requires increased bandwidth for query traffic between Internet customers and the site's database server. For security purposes, the existence of the individual interfaces on the server must be hidden from external applications. The solution is the aggregation aggr1 with the IP address 192.168.50.32. This aggregation consists of three interfaces,bge0 through bge2. These interfaces are dedicated to sending out traffic in response to customer queries. The outgoing address on packet traffic from all the interfaces is the IP address of aggr1, 192.168.50.32.

Figure 6–3 Basic Link Aggregation Topology

The figure shows a block for the link aggr1. Three physical
interfaces, bge0–bge2, descend from the link block.

Figure 6–4 depicts a local network with two systems, and each system has an aggregation configured. The two systems are connected by a switch. If you need to run an aggregation through a switch, that switch must support aggregation technology. This type of configuration is particularly useful for high availability and redundant systems.

In the figure, System A has an aggregation that consists of two interfaces, bge0 and bge1. These interfaces are connected to the switch through aggregated ports. System B has an aggregation of four interfaces, e1000g0 through e1000g3. These interfaces are also connected to aggregated ports on the switch.

Figure 6–4 Link Aggregation Topology With a Switch

The figure is explained in the preceding context.

Back-to-Back Link Aggregations

The back-to-back link aggregation topology involves two separate systems that are cabled directly to each other, as shown in the following figure. The systems run parallel aggregations.

Figure 6–5 Basic Back-to-Back Aggregation Topology

The figure is explained in the following context.

In this figure, device bge0 on System A is directly linked to bge0 on System B, and so on. In this way, Systems A and B can support redundancy and high availability, as well as high-speed communications between both systems. Each system also has interface ce0 configured for traffic flow within the local network.

The most common application for back-to-back link aggregations is mirrored database servers. Both servers need to be updated together and therefore require significant bandwidth, high-speed traffic flow, and reliability. The most common use of back-to-back link aggregations is in data centers.

Policies and Load Balancing

If you plan to use a link aggregation, consider defining a policy for outgoing traffic. This policy can specify how you want packets to be distributed across the available links of an aggregation, thus establishing load balancing. The following are the possible layer specifiers and their significance for the aggregation policy:

Any combination of these policies is also valid. The default policy is L4. For more information, refer to the dladm(1M) man page.

Aggregation Mode and Switches

If your aggregation topology involves connection through a switch, you must note whether the switch supports the link aggregation control protocol (LACP). If the switch supports LACP, you must configure LACP for the switch and the aggregation. However, you can define one of the following modes in which LACP is to operate:

See the dladm(1M) man page and the switch manufacturer's documentation for syntax information.

Requirements for Link Aggregations

Your link aggregation configuration is bound by the following requirements:

ProcedureHow to Create a Link Aggregation

Before You Begin

Note –

Link aggregation only works on full-duplex, point-to-point links that operate at identical speeds. Make sure that the interfaces in your aggregation conform to this requirement.


If you are using a switch in your aggregation topology, make sure that you have done the following on the switch:

  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Determine which interfaces are currently installed on your system.


    # dladm show-link
    
  3. Determine which interfaces have been plumbed.


    # ifconfig -a
    
  4. Create an aggregation.


    # dladm create-aggr -d interface -d interface [...]key
    
    interface

    Represents the device name of the interface to become part of the aggregation.

    key

    Is the number that identifies the aggregation. The lowest key number is 1. Zeroes are not allowed as keys.

    For example:


    # dladm create-aggr -d bge0 -d bge1 1
    
  5. Configure and plumb the newly created aggregation.


    # ifconfig aggrkey plumb IP-address up
    

    For example:


    # ifconfig aggr1  plumb 192.168.84.14 up
    
  6. Check the status of the aggregation you just created.


    # dladm show-aggr
    

    You receive the following output:


    key: 1 (0x0001) policy: L4      address: 0:3:ba:7:84:5e (auto)
    device   address           speed         duplex  link    state
    bge0     0:3:ba:7:b5:a7    1000  Mbps    full    up      attached
    bge1     0:3:ba:8:22:3b    0     Mbps    unknown down    standby

    The output shows that an aggregation with the key of 1 and a policy of L4 was created.

  7. (Optional) Make the IP configuration of the link aggregation persist across reboots.

    1. For link aggregations with IPv4 addresses, create an /etc/hostname.aggrkey file. For IPv6–based link aggregations, create an /etc/hostname6.aggrkey file.

    2. Enter the IPv4 or IPv6 address of the link aggregation into the file.

      For example, you would create the following file for the aggregation that is created in this procedure:


      # vi /etc/hostname.aggr1
      192.168.84.14
      
    3. Perform a reconfiguration boot.


      # reboot -- -r
      
    4. Verify that the link aggregation configuration you entered in the /etc/hostname.aggrkey file has been configured.


      # ifconfig -a
      .
      .
      aggr1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
              inet 192.168.84.14 netmask ff000000 broadcast 192.255.255.

Example 6–4 Creating a Link Aggregation

This example shows the commands that are used to create a link aggregation with two devices, bge0 and bge1, and the resulting output.


# dladm show-link
ce0             type: legacy    mtu: 1500       device: ce0
ce1             type: legacy    mtu: 1500       device: ce1
bge0            type: non-vlan  mtu: 1500       device: bge0
bge1            type: non-vlan  mtu: 1500       device: bge1
bge2            type: non-vlan  mtu: 1500       device: bge2
# ifconfig -a
lo0: flags=2001000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.84.253 netmask ffffff00 broadcast 192.168.84.255
        ether 0:3:ba:7:84:5e 
# dladm create-aggr -d bge0 -d bge1 1
# ifconfig aggr1 plumb 192.168.84.14 up
# dladm show-aggr
key: 1 (0x0001) policy: L4      address: 0:3:ba:7:84:5e (auto)
device   address           speed         duplex  link    state
bge0     0:3:ba:7:b5:a7    1000  Mbps    full    up      attached
bge1     0:3:ba:8:22:3b    0     Mbps    unknown down    standby

# ifconfig -a
lo0: flags=2001000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.84.253 netmask ffffff00 broadcast 192.168.84.255
        ether 0:3:ba:7:84:5e 
aggr1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
        inet 192.168.84.14 netmask ff000000 broadcast 192.255.255.255
        ether 0:3:ba:7:84:5e 

Note that the two interfaces that were used for the aggregation were not previously plumbed by ifconfig.


ProcedureHow to Modify an Aggregation

This procedure shows how to make the following changes to an aggregation definition:

  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Modify the aggregation to change the policy.


    # dladm modify-aggr -Ppolicy key   
    
    policy

    Represents one or more of the policies L2, L3, and L4, as explained in Policies and Load Balancing.

    key

    Is a number that identifies the aggregation. The lowest key number is 1. Zeroes are not allowed as keys.

  3. If LACP is running on the switch to which the devices in the aggregation are attached, modify the aggregation to support LACP.

    If the switch runs LACP in passive mode, be sure to configure active mode for your aggregation.


    # dladm modify-aggr -l LACP mode -t timer-value key
    
    -l LACP mode

    Indicates the LACP mode in which the aggregation is to run. The values are active, passive, and off.

    -t timer-value

    Indicates the LACP timer value, either short or long.

    key

    Is a number that identifies the aggregation. The lowest key number is 1. Zeroes are not allowed as keys.


Example 6–5 Modifying a Link Aggregation

This example shows how to modify the policy of aggregation aggr1 to L2 and then turn on active LACP mode.


# dladm modify-aggr -P L2 1
# dladm modify-aggr -l active -t short 1
# dladm show-aggr
key: 1 (0x0001) policy: L2      address: 0:3:ba:7:84:5e (auto)
device   address           speed         duplex  link    state
bge0     0:3:ba:7:b5:a7    1000  Mbps    full    up      attached
bge1     0:3:ba:8:22:3b    0     Mbps    unknown down    standby

ProcedureHow to Remove an Interface From an Aggregation

  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Remove an interface from the aggregation.


    # dladm remove-aggr -d interface
    

Example 6–6 Removing Interfaces From an Aggregation

This example shows how to remove the interfaces of the aggregation aggr1.


# dladm show-aggr
key: 1 (0x0001) policy: L2      address: 0:3:ba:7:84:5e (auto)
device   address           speed         duplex  link    state
bge0     0:3:ba:7:b5:a7    1000  Mbps    full    up      attached
bge1     0:3:ba:8:22:3b    0     Mbps    unknown down    standby
# dladm remove-aggr -d bge1 1
# dladm show-aggr
key: 1 (0x0001) policy: L2      address: 0:3:ba:7:84:5e (auto)
device   address           speed         duplex  link    state
bge0     0:3:ba:7:b5:a7    1000  Mbps    full    up      attached
          

ProcedureHow to Delete an Aggregation

  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Delete the aggregation.


    # dladm delete-aggr key
    
    key

    Is a number that identifies the aggregation. The lowest key number is 1. Zeroes are not allowed as keys.


Example 6–7 How to Delete an Aggregation

This example shows how to remove the aggregation aggr1.


# dladm show-aggr
key: 1 (0x0001) policy: L2      address: 0:3:ba:7:84:5e (auto)
     device   address           speed     duplex  link    state
# dladm delete-aggr -d 1

ProcedureHow to Configure VLANs Over a Link Aggregation

In the same manner as configuring VLANs over an interface, you can also create VLANs on a link aggregation. VLANs are described in Administering Virtual Local Area Networks. This section combines configuring VLANs and link aggregations.

Before You Begin

Configure the link aggregation first with a valid IP address. Note the value of the aggregation's key which you will need when you create the VLANs over the aggregation. To create link aggregations, refer to How to Create a Link Aggregation.

  1. If a link aggregation has already been previously created, obtain that aggregation's key.


    # dladm show-aggr
    
  2. Create the VLANs over the link aggregation.


    # ifconfig aggrVIDkey plumb
    

    where

    VID

    The ID of the VLAN

    key

    The key of the link aggregation over which the VLAN is created. The key must be in a 3–digit format. For example, if the aggregation's key is 1, then the key number that is included in the name of the VLAN is 001.

  3. Repeat Step 2 to create other VLANs over the aggregation.

  4. Configure the VLANs with valid IP addresses.

  5. To create persistent VLAN configurations, add the IP address information to the corresponding /etc/hostname.VLAN configuration files.


Example 6–8 Configuring Multiple VLANs Over a Link Aggregation

In this example, two VLANs are configured on a link aggregation. The output of the dladm show-aggr command indicates that the link aggregation's key is 1. The VLANs are assigned VIDs 193 and 194, respectively.


# dladm show-aggr
key: 1 (0x0001) policy: L4      address: 0:3:ba:7:84:5e (auto)
device   address           speed         duplex  link    state
bge0     0:3:ba:7:b5:a7    1000  Mbps    full    up      attached
bge1     0:3:ba:8:22:3b    0     Mbps    unknown down    standby

# ifconfig aggr193001 plumb
# ifconfig aggr193001 192.168.10.5/24 up

# ifconfig aggr194001 plumb
# ifconfig aggr194001 192.168.10.25/24 up

# vi /etc/hostname.aggr193001
192.168.10.5/24

# vi /etc/hostname.aggr194001
192.168.10.25/24

Chapter 7 Configuring an IPv6 Network (Tasks)

This chapter contains tasks for configuring IPv6 on a network. The following major topics are covered:

For an overview of IPv6 concepts, refer to Chapter 3, Introducing IPv6 (Overview). For IPv6 planning tasks, refer to Chapter 4, Planning an IPv6 Network (Tasks). To find reference information about the tasks in this chapter, refer to Chapter 11, IPv6 in Depth (Reference).

Configuring an IPv6 Interface

The initial step in IPv6 configuration is enabling IPv6 on an interface. You can enable IPv6 support during the Oracle Solaris 10 installation process or by configuring IPv6 on the interfaces of an installed system.

During the Oracle Solaris 10 installation process, you can enable IPv6 on one or more of a system's interfaces. After installation, the following IPv6-related files and tables are in place:

This section describes how to enable IPv6 on the interfaces of an installed system.

Enabling IPv6 on an Interface (Task Map)

The following table lists different tasks for configuring the IPv6 interfaces. The table includes a description of what each task accomplishes and the section in the current documentation where the specific steps to perform the task are detailed.

Task 

Description 

For Instructions 

Enable IPv6 on an interface on a system that has already been installed with Oracle Solaris 10. 

Use this task for enabling IPv6 on an interface after Oracle Solaris 10 has been installed. 

How to Enable an IPv6 Interface for the Current Session

Make the IPv6-enabled interface persist across reboots. 

Use this task to make the IPv6 address of the interface permanent. 

How to Enable Persistent IPv6 Interfaces

Turn off IPv6 address autoconfiguration. 

Use this task if you need to manually configure the interface ID portion of the IPv6 address. 

How to Turn Off IPv6 Address Autoconfiguration

ProcedureHow to Enable an IPv6 Interface for the Current Session

Begin your IPv6 configuration process by enabling IPv6 on the interfaces of all systems that will become IPv6 nodes. Initially, the interface obtains its IPv6 address through the autoconfiguration process, as described in IPv6 Address Autoconfiguration. You then can tailor the node's configuration based on its function in the IPv6 network, either as a host, server, or router.


Note –

If the interface is on the same link as a router that currently advertises an IPv6 prefix, the interface obtains that site prefix as part of its autoconfigured addresses. For more information, refer to How to Configure an IPv6-Enabled Router.


The following procedure explains how to enable IPv6 for an interface that was added after Oracle Solaris 10 installation.

Before You Begin

Complete the planning tasks for the IPv6 network, such as upgrading hardware and software, and preparing an addressing plan. For more information, see IPv6 Planning (Task Maps).

  1. Log in to the prospective IPv6 node as Primary Administrator or as superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Enable IPv6 on an interface.


    # ifconfig inet6 interface plumb up
    
  3. Start the IPv6 daemonin.ndpd.


    # /usr/lib/inet/in.ndpd
    

    Note –

    You can display the status of a node's IPv6-enabled interfaces by using the ifconfig-a6 command.



Example 7–1 Enabling an IPv6 Interface After Installation

This example shows how to enable IPv6 on the qfe0 interface. Before you begin, check the status of all interfaces configured on the system.


# ifconfig -a
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
qfe0: flags=1000863 <UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,IPv4> mtu 1500 
           index 2
        inet 172.16.27.74 netmask ffffff00 broadcast 172.16.27.255
        ether 0:3:ba:13:14:e1 

Only the qfe0 interface is currently configured for this system. Enable IPv6 on this interface as follows:


# ifconfig inet6 qfe0 plumb up
# /usr/lib/inet/in.ndpd
# ifconfig -a6
lo0: flags=2000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1
        inet6 ::1/128 
qfe0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
        ether 0:3:ba:13:14:e1 
        inet6 fe80::203:baff:fe13:14e1/10

The example shows the status of the system's interface before and after qfe0becomes IPv6-enabled. The -a6 option of ifconfig shows just the IPv6 information for qfe0 and the loopback interface. Note that the output indicates that only a link-local address was configured for qfe0, fe80::203:baff:fe13:14e1/10. This address indicates that as of yet no router on the node's local link advertises a site prefix.

After IPv6 is enabled, you can use the ifconfig -a command to display both IPv4 and IPv6 addresses for all interfaces on a system.


Next Steps

ProcedureHow to Enable Persistent IPv6 Interfaces

This procedure explains how to enable IPv6 interfaces with autoconfigured IPv6 addresses that persist across subsequent reboots.


Note –

If the interface is on the same link as a router that currently advertises an IPv6 prefix, the interface obtains that site prefix as part of its autoconfigured addresses. For more information, refer to How to Configure an IPv6-Enabled Router.


  1. Log in to the IPv6 node as Primary Administrator or as superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Create IPv6 addresses for interfaces that were added after installation.

    1. Create the configuration file.


      # touch /etc/hostname6.interface
      
    2. Add addresses to the configuration file.


      inet6 ipv6-address up
      addif inet6 ipv6-address up
      ...
  3. Create a static IPv6 default route.


    # /usr/sbin/route -p add -inet6 default ipv6-address
    
  4. (Optional) Create an /etc/inet/ndpd.conf file that defines parameters for interface variables on the node.

    If you need to create temporary addresses for the host's interface, refer to Using Temporary Addresses for an Interface. For details about /etc/inet/ndpd.conf, refer to the ndpd.conf(4) man page and ndpd.conf Configuration File.

  5. Reboot the node.


    # reboot -- -r
    

    The reboot process sends router discovery packets. If a router responds with a site prefix, the node can configure any interface with a corresponding /etc/hostname6.interface file with a global IPv6 address. Otherwise, the IPv6-enabled interfaces are configured solely with link-local addresses. Rebooting also restarts in.ndpd and other network daemons in IPv6 mode.


Example 7–2 Making an IPv6 Interface Persist Across Reboots

This example shows how to make the IPv6 configuration for the qfe0 interface persist across reboots. In this example, a router on the local link advertises the site prefix and subnet ID 2001:db8:3c4d:15/64.

First, check the status of the system's interfaces.


# ifconfig -a
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
qfe0: flags=1000863 <UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,IPv4> mtu 1500 
           index 2
        inet 172.16.27.74 netmask ffffff00 broadcast 172.16.27.255
        ether 0:3:ba:13:14:e1 

# touch /etc/hostname6.qfe0
# vi /etc/hostname6.qfe0
inet6 fe80::203:baff:fe13:1431/10 up
addif inet6 2001:db8:3c4d:15:203:baff:fe13:14e1/64 up

# route -p add -inet6 default fe80::203:baff:fe13:1431
# reboot -- -r

Verify that the IPv6 address you configured is still applied to the qfe0 interface.


# ifconfig -a6
qfe0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
       ether 0:3:ba:13:14:e1 
       inet6 fe80::203:baff:fe13:14e1/10 
 qfe0:1: flags=2180841 <UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 
          index 2
        inet6 2001:db8:3c4d:15:203:baff:fe13:14e1/64

The output of ifconfig -a6 shows two entries for qfe0. The standard qfe0 entry includes the MAC address and the link-local address. A second entry, qfe0:1, indicates that a pseudo-interface was created for the additional IPv6 address on the qfe0 interface. The new, global IPv6 address, 2001:db8:3c4d:15:203:baff:fe13:14e1/64, includes the site prefix and subnet ID advertised by the local router.


Next Steps

ProcedureHow to Turn Off IPv6 Address Autoconfiguration

You normally should use address autoconfiguration to generate the IPv6 addresses for the interfaces of hosts and servers. However, sometimes you might want to turn off address autoconfiguration, especially if you want to manually configure a token, as explained in Configuring an IPv6 Token.

  1. Log in to the IPv6 node as Primary Administrator or as superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Create an /etc/inet/ndpd.conf file for the node.

    The /etc/inet/ndpd.conf file defines interface variables for the particular node. This file should have the following contents in order to turn off address autoconfiguration for all of the server's interfaces:


    if-variable-name StatelessAddrConf false

    For details about /etc/inet/ndpd.conf, refer to the ndpd.conf(4) man page and ndpd.conf Configuration File.

  3. Update the IPv6 daemon with your changes.


    # pkill -HUP in.ndpd
    

Configuring an IPv6 Router

The first step in configuring IPv6 on a network is configuring IPv6 on a router. Router configuration involves a number of discrete tasks, which are described in this section. You might perform some or all of the tasks, depending on your site requirements.

IPv6 Router Configuration (Task Map)

Perform the next tasks in the following table in order that is shown to configure the IPv6 network. The table includes a description of what each task accomplishes and the section in the current documentation where the specific steps to perform the task are detailed.

Task 

Description  

For Instructions 

1. Ensure that you have completed the required prerequisites before you begin IPv6 configuration. 

You must complete planning tasks and Oracle Solaris installation with IPv6 enabled interfaces before you configure an IPv6-enabled router. 

Chapter 4, Planning an IPv6 Network (Tasks) and Configuring an IPv6 Interface.

2. Configure a router. 

Define the site prefix for the network.  

How to Configure an IPv6-Enabled Router

3. Configure tunnel interfaces on the router. 

Set up a manual tunnel or a 6to4 tunnel interface on the router. The local IPv6 network needs tunnels to communicate with other, isolated IPv6 networks. 

4. Configure the switches on the network. 

If your network configuration includes switches, configure them for IPv6 at this point in the configuration process. 

Refer to switch manufacturer's documentation. 

5. Configure any hubs on your network. 

If your network configuration includes hubs, configure them for IPv6 at this point in the configuration process. 

Refer to hub manufacturer's documentation. 

6. Configure the network name service for IPv6.  

Configure your primary name service (DNS, NIS, or LDAP) to recognize IPv6 addresses after the router is configured for IPv6. 

How to Add IPv6 Addresses to DNS

7. (Optional) Modify the addresses for the IPv6-enabled interfaces on hosts and servers. 

After IPv6 router configuration, make further modifications on IPv6-enabled hosts and servers. 

Modifying an IPv6 Interface Configuration for Hosts and Servers

Configure applications to support IPv6 

Different applications might require different actions in order to support IPv6. 

Refer to applications' documentation 

ProcedureHow to Configure an IPv6-Enabled Router

This procedure assumes that all interfaces of the router were configured for IPv6 during Oracle Solaris installation.

  1. On the system that will become the IPv6 router, assume the Primary Administrator role or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Review which interfaces on the router were configured for IPv6 during installation.


    # ifconfig -a
    

    Check the output to ensure that the interfaces that you wanted to configure for IPv6 are now plumbed with link-local addresses. The following sample command output of ifconfig -a shows the IPv4 and IPv6 addresses that were configured for the router's interfaces.


    lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
            inet 127.0.0.1 netmask ff000000 
    dmfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
            inet 172.16.26.232 netmask ffffff00 broadcast 172.16.26.255
            ether 0:3:ba:11:b1:15 
    dmfe1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 3
            inet 172.16.26.220 netmask ffffff00 broadcast 172.16.26.255
            ether 0:3:ba:11:b1:16 
    lo0: flags=2000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1
            inet6 ::1/128 
    dmfe0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
            ether 0:3:ba:11:b1:15 
            inet6 fe80::203:baff:fe11:b115/10 
    dmfe1: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 3
            ether 0:3:ba:11:b1:16 
            inet6 fe80::203:baff:fe11:b116/10 

    The output also shows that the primary network interface dmfe0 and the additional interface dmfe1 were configured during installation with the IPv6 link–local addresses fe80::203:baff:fe11:b115/10 and fe80::203:baff:fe11:b116/10.

  3. Configure IPv6 packet forwarding on all interfaces of the router.

    For Solaris 10 11/03 and earlier releases, use the following command:


    # routeadm -e ipv6-forwarding -u
    

    Use either of the following to enable packet forwarding:

    • Use the routeadm command, as follows:


      # routeadm -e ipv6-forwarding -u
      
    • Use the following Service Management Facility (SMF) command, as follows:


      # svcadm enable ipv6-forwarding
  4. Start the routing daemon.

    The in.ripngd daemon handles IPv6 routing.

    For Solaris 10 11/06 and earlier releases, start in.ripngd by typing the following command:


    # routeadm -e ipv6-routing
    # routeadm -u
    

    Turn on IPv6 routing in either of the following ways:

    • Use the routeadm command as follows:


      # routeadm -e ipv6-routing -u
      
    • Use SMF to enable IPv6 routing:


      # svcadm enable ripng:default
      

    For syntax information on the routeadm command, see the routeadm(1M) man page.

  5. Create the /etc/inet/ndpd.conf file.

    You specify the site prefix to be advertised by the router and other configuration information in /etc/inet/ndpd.conf. This file is read by the in.ndpd daemon, which implements the IPv6 Neighbor Discovery protocol.

    For a list of variables and allowable values, refer to ndpd.conf Configuration File and the ndpd.conf(4)man page.

  6. Type the following text into the /etc/inet/ndpd.conf file:


    ifdefault AdvSendAdvertisements true
    prefixdefault AdvOnLinkFlag on AdvAutonomousFlag on
    

    This text tells the in.ndpd daemon to send out router advertisements over all interfaces of the router that are configured for IPv6.

  7. Add additional text to the /etc/inet/ndpd.conf file to configure the site prefix on the various interfaces of the router.

    The text should have the following format:


    prefix global-routing-prefix:subnet ID/64 interface
    

    The following sample /etc/inet/ndpd.conf file configures the router to advertise the site prefix 2001:0db8:3c4d::/48 over the interfaces dmfe0 and dmfe1.


    ifdefault AdvSendAdvertisements true
    prefixdefault AdvOnLinkFlag on AdvAutonomousFlag on
    
    if dmfe0 AdvSendAdvertisements 1
    prefix 2001:0db8:3c4d:15::0/64 dmfe0
    
    if dmfe1 AdvSendAdvertisements 1
    prefix 2001:0db8:3c4d:16::0/64 dmfe1
    
  8. Reboot the system.

    The IPv6 router begins advertising on the local link any site prefix that is in the ndpd.conf file.


Example 7–3 ifconfig Output Showing IPv6 Interfaces

The following example shows output from the ifconfig -a command such as you would receive after you finish the Configuring an IPv6 Router procedure.


lo0: flags=1000849 <UP LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
dmfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 172.16.15.232 netmask ffffff00 broadcast 172.16.26.255
        ether 0:3:ba:11:b1:15 
dmfe1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 3
        inet 172.16.16.220 netmask ffffff00 broadcast 172.16.26.255
        ether 0:3:ba:11:b1:16 
lo0: flags=2000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1
        inet6 ::1/128 
dmfe0: flags=2100841 <UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 2
        ether 0:3:ba:11:b1:15 
        inet6 fe80::203:baff:fe11:b115/10 
dmfe0:1: flags=2180841 <UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500
          index 2
        inet6 2001:db8:3c4d:15:203:baff:fe11:b115/64
dmfe1: flags=2100841 <UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 3
        ether 0:3:ba:11:b1:16 
        inet6 fe80::203:baff:fe11:b116/10 
dmfe1:1: flags=2180841 <UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500
           index 3
        inet6 2001:db8:3c4d:16:203:baff:fe11:b116/64

In this example, each interface that was configured for IPv6 now has two addresses. The entry with the name of the interface, such as dmfe0, shows the link-local address for that interface. The entry with the form interface:n, such as dmfe0:1, shows a global IPv6 address. This address includes the site prefix that you configured in the /etc/ndpd.conf file, in addition to the interface ID.


See Also

Modifying an IPv6 Interface Configuration for Hosts and Servers

This section explains how to modify the configuration of IPv6-enabled interfaces on nodes that are hosts or servers. In most instances, you should use address autoconfiguration for IPv6-enabled interfaces, as explained in Stateless Autoconfiguration Overview. However, you can modify the IPv6 address of an interface, if necessary, as explained in the tasks of this section.

Modifying an IPv6 Interface Configuration (Task Map)

The following table lists different tasks to modify an existing IPv6 network. The table includes a description of what each task accomplishes and the section in the current documentation where the specific steps to perform the task are detailed.

Task 

Description 

For Instructions 

Turn off IPv6 address autoconfiguration. 

Use this task if you need to manually configure the interface ID portion of the IPv6 address. 

How to Turn Off IPv6 Address Autoconfiguration

Create a temporary address for a host. 

Hide a host's interface ID by configuring a randomly created temporary address that is used as the lower 64 bits of the address. 

How to Configure a Temporary Address

Configure a token for the interface ID of a system. 

Create a 64-bit token to be used as the interface ID in an IPv6 address. 

How to Configure a User-Specified IPv6 Token

Using Temporary Addresses for an Interface

An IPv6 temporary address includes a randomly generated 64-bit number as the interface ID, instead of an interface's MAC address. You can use temporary addresses for any interfaces on an IPv6 node that you want to keep anonymous. For example, you might want to use temporary addresses for the interfaces of a host that needs to access public web servers. Temporary addresses implement IPv6 privacy enhancements. These enhancements are described in RFC 3041, available at “Privacy Extensions for Stateless Address Autoconfiguration in IPv6”.

You enable a temporary address in the /etc/inet/ndpd.conf file for one or more interfaces, if needed. However, unlike standard, autoconfigured IPv6 addresses, a temporary address consists of the 64-bit subnet prefix and a randomly generated 64-bit number. This random number becomes the interface ID segment of the IPv6 address. A link-local address is not generated with the temporary address as the interface ID.

Be aware that temporary addresses have a default preferred lifetime of one day. When you enable temporary address generation, you may also configure the following variables in the /etc/inet/ndpd.conf file:

valid lifetime TmpValidLifetime

Time span in which the temporary address exists, after which the address is deleted from the host.

preferred lifetime TmpPreferredLifetime

Elapsed time before the temporary address is deprecated. This time span should be shorter than the valid lifetime.

address regeneration

Duration of time before the expiration of the preferred lifetime, during which the host should generate a new temporary address.

You express the duration of time for temporary addresses as follows:

n

n number of seconds, which is the default

n h

n number of hours (h)

n d

n number of days (d)

ProcedureHow to Configure a Temporary Address

  1. Log in to the IPv6 host as Primary Administrator or as superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. If necessary, enable IPv6 on the host's interfaces

    Refer to How to Enable an IPv6 Interface for the Current Session.

  3. Edit the /etc/inet/ndpd.conf file to turn on temporary address generation.

    • To configure temporary addresses on all interfaces of a host, add the following line to /etc/inet/ndpd.conf:


      ifdefault TmpAddrsEnabled true
      
    • To configure a temporary address for a specific interface, add the following line to /etc/inet/ndpd.conf:


      if interface TmpAddrsEnabled true 
      
  4. (Optional) Specify the valid lifetime for the temporary address.


    ifdefault TmpValidLifetime duration
    

    This syntax specifies the valid lifetime for all interfaces on a host. The value for duration should be in seconds, hours, or days. The default valid lifetime is 7 days. You can also use TmpValidLifetime with the if interface keywords to specify the valid lifetime for a temporary address of a particular interface.

  5. (Optional) Specify a preferred lifetime for the temporary address, after which the address is deprecated.


    if interface TmpPreferredLifetime duration
    

    This syntax specifies the preferred lifetime for the temporary address of a particular interface. The default preferred lifetime is one day. You can also use TmpPreferredLifetime with the ifdefault keyword to specify the preferred lifetime for the temporary addresses on all interfaces of a host.


    Note –

    Default address selection gives a lower priority to IPv6 addresses that have been deprecated. If an IPv6 temporary address is deprecated, default address selection chooses a nondeprecated address as the source address of a packet. A nondeprecated address could be the automatically generated IPv6 address, or possibly, the interface's IPv4 address. For more information about default address selection, see Administering Default Address Selection.


  6. (Optional) Specify the lead time in advance of address deprecation, during which the host should generate a new temporary address.


    ifdefault TmpRegenAdvance duration
    

    This syntax specifies the lead time in advance of address deprecation for the temporary addresses of all interfaces on a host. The default is 5 seconds.

  7. Change the configuration of the in.ndpd daemon.


    # pkill -HUP in.ndpd
    # /usr/lib/inet/in.ndpd
    
  8. Verify that temporary addresses have been created by running the ifconfig -a6 command, as shown in Example 7–5.

    The output from ifconfig should have the word TEMPORARY in the same line as the interface definition.


Example 7–4 Temporary Address Variables in the /etc/inet/ndpd.conf File

The following example shows a segment of an /etc/inet/ndpd.conf file with temporary addresses enabled for the primary network interface.


ifdefault TmpAddrsEnabled true

ifdefault TmpValidLifetime 14d

ifdefault TmpPreferredLifetime 7d

ifdefault TmpRegenAdvance 6s


Example 7–5 ifconfig-a6 Command Output with Temporary Addresses Enabled

This example shows the output of the ifconfig command after temporary addresses are created.


# ifconfig -a6
lo0: flags=2000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1 
     inet6 ::1/128
hme0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 
     ether 8:0:20:b9:4c:54
     inet6 fe80::a00:20ff:feb9:4c54/10
hme0:1: flags=2080841 <UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2 
     inet6 2001:db8:3c4d:15:a00:20ff:feb9:4c54/64
hme0:2: flags=802080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6,TEMPORARY> mtu 1500 index 2 
      inet6 2001:db8:3c4d:15:7c37:e7d1:fc9c:d2cb/64

Note that the line following interface hme0:2 includes the word TEMPORARY. This designation indicates that the address 2001:db8:3c4d:15:7c37:e7d1:fc9c:d2cb/64 has a temporary interface ID.


See Also

Configuring an IPv6 Token

The 64-bit interface ID of an IPv6 address is also referred to as a token, as introduced in IPv6 Addressing Overview. During address autoconfiguration, the token is associated with the interface's MAC address. In most cases, nonrouting nodes, that is IPv6 hosts and servers, should use their autoconfigured tokens.

However, using autoconfigured tokens can be a problem for servers whose interfaces are routinely swapped as part of system maintenance. When the interface card is changed, the MAC address is also changed. Servers that depend on having stable IP addresses can experience problems as a result. Various parts of the network infrastructure, such as DNS or NIS, might have stored specific IPv6 addresses for the interfaces of the server.

To avoid address change problems, you can manually configure a token to be used as the interface ID in an IPv6 address. To create the token, you specify a hexadecimal number of 64 bits or less to occupy the interface ID portion of the IPv6 address. During subsequent address autoconfiguration, Neighbor Discovery does not create an interface ID that is based on the interface's MAC address. Instead, the manually created token becomes the interface ID. This token remains assigned to the interface, even when a card is replaced.


Note –

The difference between user-specified tokens and temporary addresses is that temporary addresses are randomly generated, rather than explicitly created by a user.


ProcedureHow to Configure a User-Specified IPv6 Token

The next instructions are particularly useful for servers whose interfaces are routinely replaced. They also are valid for configuring user-specified tokens on any IPv6 node.

  1. Verify that the interface you want to configure with a token is plumbed.

    An interface must be plumbed before you can configure a token for its IPv6 address.


    # ifconfig -a6
    

    qfe0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
            ether 0:3:ba:13:14:e1 
            inet6 fe80::203:baff:fe13:14e1/10

    This output shows that the network interface qfe0 is plumbed and has the link-local address fe80::203:baff:fe13:14e1/10. This address was automatically configured during installation.

  2. Create one or more 64-bit hexadecimal numbers to be used as tokens for the node's interfaces. For examples of tokens, refer to Link-Local Unicast Address.

  3. Configure each interface with a token.

    Use the following form of the ifconfig command for each interface to have a user-specified interface ID (token):


    ifconfig interface inet6  token address/64
    

    For example, you would use the following command to configure interface qfe0 with a token:


    # ifconfig qfe0 inet6 token ::1a:2b:3c:4d/64
    

    Repeat this step for every interface that will have a user-specified token.

  4. (Optional) Make the new IPv6 address persist across reboots.

    1. Edit or create an /etc/hostname6.interface file for each interface you configured with a token.

    2. Add the following text at the bottom of each /etc/hostname.6interface file:


      token ::token-name/64

      For example, you might add the following text to the bottom of an/etc/hostname6.interface file:


      token ::1a:2b:3c:4d/64

    After the system reboots, the token that you configured in an /etc/hostname6.interface file is applied to the interface's IPv6 address. This IPv6 address remains persistent across subsequent reboots.

  5. Update the IPv6 daemon with your changes.


    # pkill -HUP -in.ndpd
    

Example 7–6 Configuring a User-Specified Token on an IPv6 Interface

In the following example, the interface bge0:1 has an autoconfigured IPv6 address. The subnet prefix 2001:db8:3c4d:152:/64 is advertised by a router on the node's local link. The interface ID 2c0:9fff:fe56:8255 is generated from bge0:1's MAC address.


# ifconfig -a6
lo0: flags=2002000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
        inet6 ::1/128
bge0: flags=2100801 <UP,MULTICAST,IPv6> mtu 1500 index 5
        inet6 fe80::2c0:9fff:fe56:8255/10
        ether 0:c0:9f:56:82:55
bge0:1: flags=2180801 <UP, MULTICAST,ADDRCONF,IPv6>mtu 1500 index 5
        inet6 2001:db8:3c4d:152:c0:9fff:fe56:8255/64
# ifconfig bge0 inet6 token ::1a:2b:3c:4d/64
# vi /etc/hostname6.bge0
token ::1a:2b:3c:4d/64
# pkill -HUP -in.ndpd
# ifconfig -a6
lo0: flags=2002000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
        inet6 ::1/128
bge0: flags=2100801 <UP,MULTICAST,IPv6> mtu 1500 index 5
        inet6 fe80::2c0:9fff:fe56:8255/10
        ether 0:c0:9f:56:82:55
bge0:1: flags=2180801 <UP, MULTICAST,ADDRCONF,IPv6>mtu 1500 index 5
        inet6 2001:db8:3c4d:152:1a:2b:3c:4d/64

After the token is configured, the global address on the second status line of bge0:1 now has 1a:2b:3c:4dconfigured for its interface ID.


See Also

Administering IPv6-Enabled Interfaces on Servers

When you plan for IPv6 on a server, you must make a few decisions as you enable IPv6 on the server's interfaces. Your decisions affect the strategy to use for configuring the interface IDs, also known as tokens, of an interface's IPv6 address.

ProcedureHow to Enable IPv6 on a Server's Interfaces

Before You Begin

The next procedure assumes the following:

If applicable, upgrade the application software to support IPv6. Note that many applications that run on the IPv4 protocol stack also successfully run on IPv6. For more information, refer to How to Prepare Network Services for IPv6 Support.

  1. On the server, assume the Primary Administrator role or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Ensure that an IPv6 subnet prefix is configured on a router on the same link as the server.

    For more information, refer to Configuring an IPv6 Router.

  3. Use the appropriate strategy for the interface ID for the server's IPv6-enabled interfaces.

    By default, IPv6 address autoconfiguration uses the MAC address of an interface when creating the interface ID portion of the IPv6 address. If the IPv6 address of the interface is well known, swapping one interface for another interface can cause problems. The MAC address of the new interface will be different. During address autoconfiguration, a new interface ID is generated.

    • For an IPv6-enabled interface that you do not plan to replace, use the autoconfigured IPv6 address, as introduced in IPv6 Address Autoconfiguration.

    • For IPv6-enabled interfaces that must appear anonymous outside the local network, consider using a randomly generated token for the interface ID. For instructions and an example, refer to How to Configure a Temporary Address.

    • For IPv6-enabled interfaces that you plan to swap on a regular basis, create tokens for the interface IDs. For instructions and an example, refer to How to Configure a User-Specified IPv6 Token.

Tasks for Configuring Tunnels for IPv6 Support (Task Map)

The following table lists different tasks for configuring different types of IPv6 tunnels. The table includes a description of what each task accomplishes and the section in the current documentation where the specific steps to perform the task are detailed.

Task 

Description 

For Instructions 

Manually configure IPv6 over IPv4 tunnels. 

Manually creates an IPv6 tunnel over a IPv4 network, a solution for reaching remote IPv6 networks within a larger, mostly IPv4 enterprise network. 

How to Manually Configure IPv6 Over IPv4 Tunnels

Manually configure IPv6 over IPv6 tunnels. 

Manually configures an IPv6 tunnel over an IPv6 network, typically used within a large enterprise network. 

How to Manually Configure IPv6 Over IPv6 Tunnels

Manually configure IPv4 over IPv6 tunnels. 

Manually configures an IPv4 tunnel over an IPv6 network, useful for large networks with both IPv4 and IPv6 networks. 

How to Configure IPv4 Over IPv6 Tunnels

Automatically configure IPv6 over IPv4 tunnels (6to4 tunnels). 

Create an automatic, 6to4 tunnel, a solution for reaching an external IPv6 site over the Internet. 

How to Configure a 6to4 Tunnel

Configure a tunnel between a 6to4 router and a 6to4 relay router. 

Enables a tunnel to a 6to4 relay router by using the 6to4relay command.

How to Configure a 6to4 Tunnel to a 6to4 Relay Router

Configuring Tunnels for IPv6 Support

IPv6 networks are often isolated entities within the larger IPv4 world. Nodes on your IPv6 network might need to communicate with nodes on isolated IPv6 networks, either within your enterprise or remotely. Typically, you configure a tunnel between IPv6 routers, although IPv6 hosts can also function as tunnel endpoints. For tunnel planning information, refer to Planning for Tunnels in the Network Topology.

You can set up automatically or manually configured tunnels for the IPv6 network. The Oracle Solaris IPv6 implementation supports the following types of tunnel encapsulation:

For conceptual descriptions of tunnels, see IPv6 Tunnels.

ProcedureHow to Manually Configure IPv6 Over IPv4 Tunnels

This procedure describes how to set up a tunnel from an IPv6 node to a remote IPv6 node over an IPv4 network.

  1. Log in to the local tunnel endpoint as Primary Administrator or as superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Create the /etc/hostname6.ip.tunn file.

    where n represents the tunnel number, beginning at zero for the first tunnel. Then, add entries by following these substeps:

    1. Add the tunnel source address and the tunnel destination address.


      tsrc IPv4-source-address tdst IPv4-destination-address up
    2. (Optional) Add a logical interface for the source IPv6 address and the destination IPv6 addresses.


      addif IPv6-source-address  IPv6-destination-address 
      

      Omit this substep if you want the address autoconfigured for this interface. You do not need to configure link-local addresses for your tunnel.

  3. Reboot the system.

  4. Repeat this task on the opposite endpoint of the tunnel.


Example 7–7 Entry in the /etc/hostname6.ip.tun File for a Manual, IPv6 Over IPv4 Tunnel

This sample /etc/hostname6.ip.tun file shows a tunnel for which global source addresses and global destination addresses are manually configured.


tsrc 192.168.8.20 tdst 192.168.7.19 up
addif 2001:db8:3c4d:8::fe12:528 2001:db8:3c4d:7:a00:20ff:fe12:1234 up

ProcedureHow to Manually Configure IPv6 Over IPv6 Tunnels

This procedure describes how to set up a tunnel from an IPv6 node to a remote IPv6 node over an IPv6 network.

  1. Log in to the local tunnel endpoint as Primary Administrator or as superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Create the /etc/hostname6.ip6.tun n file.

    Use the values 0, 1, 2, and so on, for n. Then, add entries by following these substeps.

    1. Add the tunnel source address and the tunnel destination address.


      tsrc IPv6-source-address tdst IPv6-destination-address
      IPv6-packet-source-address IPv6-packet-destination-address up
    2. (Optional) Add a logical interface for the source IPv6 address and destination IPv6 address.


      addif IPv6-source-address  IPv6-destination-address up

      Omit this step if you want the address autoconfigured for this interface. You do not need to configure link-local addresses for your tunnel.

  3. Reboot the system.

  4. Repeat this procedure at the opposite endpoint of the tunnel.


Example 7–8 Entry in the /etc/hostname6.ip6.tun File for an IPv6 Over IPv6 Tunnel

This example shows the entry for an IPv6 over IPv6 tunnel.


tsrc 2001:db8:3c4d:22:20ff:0:fe72:668c tdst 2001:db8:3c4d:103:a00:20ff:fe9b:a1c3
fe80::4 fe80::61 up

ProcedureHow to Configure IPv4 Over IPv6 Tunnels

This procedure explains how to configure a tunnel between two IPv4 hosts over an IPv6 network. You would use this procedure if your corporate network is heterogeneous, with IPv6 subnets that separate IPv4 subnets.

  1. Log in to the local IPv4 tunnel endpoint as Primary Administrator or as superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Create the /etc/hostname.ip6.tunn file.

    Use the values 0, 1, 2, and so on, for n. Then, add entries by following these steps:

    1. Add the tunnel source address and the tunnel destination address.


      tsrc IPv6-source-address tdst IPv6-destination-address
      
    2. (Optional) Add a logical interface for the source IPv6 address and destination IPv6 address.


      addif IPv6-source-address  IPv6-destination-address up
  3. Reboot the local host.

  4. Repeat this procedure at the opposite endpoint of the tunnel.


Example 7–9 Entry in the /etc/hostname6.ip6.tun for an IPv4 Over IPv6 Tunnel

This example shows the entry for an IPv4 over IPv6 tunnel.


tsrc 2001:db8:3c4d:114:a00:20ff:fe72:668c tdst 2001:db8:3c4d:103:a00:20ff:fe9b:a1c3
10.0.0.4 10.0.0.61 up

ProcedureHow to Configure a 6to4 Tunnel

If your IPv6 network needs to communicate with a remote IPv6 network, consider using automatic, 6to4 tunnels. The process of configuring a 6to4 tunnel includes configuring the boundary router as a 6to4 router. The 6to4 router functions as the endpoint of a 6to4 tunnel between your network and an endpoint router at a remote IPv6 network.

Before You Begin

Before you configure 6to4 routing on an IPv6 network, you must have done the following:

  1. Log in to the prospective 6to4 router as Primary Administrator or as superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Configure a 6to4 pseudo-interface on the router by creating the /etc/hostname6.ip.6to4tun0 file.

    • If you plan to use the recommended convention of subnet ID=0 and host ID=1, use the short format for /etc/hostname6.ip.6to4tun0:


      tsrc IPv4-address up
    • If you plan to use other conventions for the subnet ID and host ID, use the long format for /etc/hostname6.ip.6to4tun0:


      tsrc IPv4-address 2002:IPv4-address:subnet-ID:interface-ID:/64 up

    The required parameters for /etc/hostname6.ip.6to4tun0 follow:

    tsrc

    Indicates that this interface is used as a tunnel source.

    IPv4-address

    Specifies, in dotted-decimal format, the IPv4 address that is configured on the physical interface to become the 6to4 pseudo-interface.

    The remaining parameters are optional. However, if you specify one optional parameter, you must specify all optional parameters.

    2002

    Specifies the 6to4 prefix.

    IPv4–address

    Specifies, in hexadecimal notation, the IPv4 address of the pseudo-interface.

    subnet-ID

    Specifies, in hexadecimal notation, a subnet ID other than 0.

    interface-ID

    Specifies an interface ID other than 1.

    /64

    Indicates that the 6to4 prefix has a length of 64 bits.

    up

    Configures the 6to4 interface as “up.”


    Note –

    Two IPv6 tunnels on your network cannot have the same source address and the same destination address. Packets are dropped as a result. This type of event can happen if a 6to4 router also performs tunneling through the atun command. For information about atun, refer to the tun(7M) man page.


  3. (Optional) Create additional 6to4 pseudo-interfaces on the router.

    Each prospective 6to4 pseudo-interface must have an already configured, globally unique IPv4 address.

  4. Reboot the 6to4 router.

  5. Verify the status of the interface.


    # ifconfig ip.6to4tun0 inet6
            
    

    If the interface is correctly configured, you receive output that is similar to the following:


    ip.6to4tun0: flags=2200041<UP,RUNNING,NONUD,IPv6>mtu 1480 index 11
            inet tunnel src 111.222.33.44 
            tunnel hop limit 60 
            inet6 2002:6fde:212c:10:/64 
  6. Edit the /etc/inet/ndpd.conf file to advertise 6to4 routing.

    For detailed information, refer to the ndpd.conf(4) man page.

    1. Specify the subnet to receive the advertisement in the first line.

      Create an if entry with the following format:


      if subnet-interface AdvSendAdvertisements 1

      For example, to advertise 6to4 routing to the subnet that is connected to interface hme0, replace subnet-interface with hme0.


      if hme0 AdvSendAdvertisements 1
    2. Add the 6to4 prefix as the second line of the advertisement.

      Create a prefix entry with following format:


      prefix 2002:IPv4-address:subnet-ID::/64 subnet-interface
      
  7. Reboot the router.

    Alternatively, you can issue a sighup to the /etc/inet/in.ndpd daemon to begin sending router advertisements. The IPv6 nodes on each subnet to receive the 6to4 prefix now autoconfigure with new 6to4-derived addresses.

  8. Add the new 6to4-derived addresses of the nodes to the name service that is used at the 6to4 site.

    For instructions, go to Configuring Name Service Support for IPv6.


Example 7–10 6to4 Router Configuration (Short Form)

The following is an example of the short form of /etc/hostname6.ip.6to4tun0:


# cat /etc/hostname6.ip.6to4tun0
tsrc 111.222.33.44 up


Example 7–11 6to4 Router Configuration (Long Form)

Here is an example of the long form of /etc/hostname6.ip.6to4tun0:


# cat /etc/hostname6.ip.6to4tun0
tsrc 111.222.33.44 2002:6fde:212c:20:1/64 up


Example 7–12 ifconfig Output Showing 6to4 Pseudo-Interface

The following sample shows output of the ifconfig command for a 6to4 pseudo-interface:


# ifconfig ip.6to4tun0 inet6
ip.6to4tun0: flags=2200041<UP,RUNNING,NONUD,IPv6> mtu 1480 index 11
        inet tunnel src 192.168.87.188
        tunnel hop limit 60 
        inet6 2002:c0a8:57bc::1/64 


Example 7–13 6to4 Advertisements in/etc/inet/ndpd.conf

The following sample /etc/inet/ndpd.conf file advertises 6to4 routing on two subnets:


if qfe0 AdvSendAdvertisements 1
prefix  2002:c0a8:57bc:10::/64 qfe0 

if qfe1 AdvSendAdvertisements 1
prefix  2002:c0a8:57bc:2::/64 qfe1

Configuring Multiple Routers at the 6to4 Site

For a multiple router site, the routers behind the 6to4 router might require further configuration to support 6to4. If your site uses RIP, you must configure on each non-6to4 router the static routes to the 6to4 router. If you use a commercial routing protocol, you do not need to create static routes to the 6to4 router.

ProcedureHow to Configure a 6to4 Tunnel to a 6to4 Relay Router


Caution – Caution –

Because of major security issues, by default, 6to4 relay router support is disabled in Oracle Solaris. See Security Issues When Tunneling to a 6to4 Relay Router.


Before You Begin

Before you enable a tunnel to a 6to4 relay router, you must have completed the following tasks:

  1. Log in to the 6to4 router as Primary Administrator or as superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Enable a tunnel to the 6to4 relay router by using either of the following formats:

    • Enable a tunnel to an anycast 6to4 relay router.


      # /usr/sbin/6to4relay -e
      

      The -e option sets up a tunnel between the 6to4 router and an anycast 6to4 relay router. Anycast 6to4 relay routers have the well-known IPv4 address 192.88.99.1. The anycast relay router that is physically nearest to your site becomes the endpoint for the 6to4 tunnel. This relay router then handles packet forwarding between your 6to4 site and a native IPv6 site.

      For detailed information about anycast 6to4 relay routers, refer to RFC 3068, "An Anycast Prefix for 6to4 Relay Routers".

    • Enable a tunnel to a specific 6to4 relay router.


      # /usr/sbin/6to4relay -e -a relay-router-address
      

      The -a option indicates that a specific router address is to follow. Replace relay-router-address with the IPv4 address of the specific 6to4 relay router with which you want to enable a tunnel.

    The tunnel to the 6to4 relay router remains active until you remove the 6to4 tunnel pseudo-interface.

  3. Delete the tunnel to the 6to4 relay router, when the tunnel is no longer needed:


    # /usr/sbin/6to4relay -d
    
  4. (Optional) Make the tunnel to the 6to4 relay router persistent across reboots.

    Your site might have a compelling reason to have the tunnel to the 6to4 relay router reinstated each time the 6to4 router reboots. To support this scenario, you must do the following:

    1. Edit the/etc/default/inetinit file.

      The line that you need to modify is at the end of the file.

    2. Change the “NO” value in the line ACCEPT6TO4RELAY=NO to “YES”.

    3. (Optional) Create a tunnel to a specific 6to4 relay router that persists across reboots.

      For the parameter RELAY6TO4ADDR, change the address 192.88.99.1 to the IPv4 address of the 6to4 relay router that you want to use.


Example 7–14 Getting Status Information About 6to4 Relay Router Support

You can use the /usr/bin/6to4relay command to find out whether support for 6to4 relay routers is enabled. The next example shows the output when support for 6to4 relay routers is disabled, as is the default in Oracle Solaris:


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

When support for 6to4 relay routers is enabled, you receive the following output:


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

Configuring Name Service Support for IPv6

This section describes how to configure the DNS and NIS name services to support IPv6 services.


Note –

LDAP supports IPv6 without requiring IPv6-specific configuration tasks.


For full details for administering DNS, NIS, and LDAP, refer to the System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

ProcedureHow to Add IPv6 Addresses to DNS

  1. Log in to the primary or secondary DNS server as Primary Administrator or as superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Edit the appropriate DNS zone file by adding AAAA records for each IPv6-enabled node:


    host-name  IN   AAAA 	host-address
    
  3. Edit the DNS reverse zone file and add PTR records:


    host-address IN   PTR   hostname
    

    For detailed information on DNS administration, refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).


Example 7–15 DNS Reverse Zone File

This example shows an IPv6 address in the reverse zone file.


$ORIGIN	ip6.int.	
8.2.5.0.2.1.e.f.f.f.9.2.0.0.a.0.6.5.2.9.0.0.0.0.0.0.0.0.2.0.0.0 \
	IN		PTR		vallejo.Eng.apex.COM.

Adding IPv6 Addresses to NIS

In Solaris 10 11/06 and earlier releases, two maps were added for NIS : ipnodes.byname and ipnodes.byaddr. These maps contained both IPv4 and IPv6 host name and address associations. Tools that are aware of IPv6 used the ipnodes NIS maps. The hosts.byname and hosts.byaddr maps contained only IPv4 host name and address associations. These maps are unchanged so that they can facilitate existing applications. Administration of the ipnodes maps is similar to the administration of the hosts.byname and hosts.byaddr maps. For Solaris 10 11/06, it is important that when you update the hosts maps with IPv4 addresses, the ipnode maps are also updated with the same information.


Note –

Subsequent releases of Oracle Solaris 10 do not use the ipnodes maps. The IPv6 functionality of the ipnodes maps is now maintained in the hosts maps.


For instructions on administering NIS maps, refer to Chapter 5, Setting Up and Configuring NIS Service, in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

ProcedureHow to Display IPv6 Name Service Information

You can use the nslookup command to display IPv6 name service information.

  1. Under your user account, run the nslookup command.


    % /usr/sbin/nslookup
    

    The default server name and address appear, followed by the nslookup command's angle bracket prompt.

  2. View information about a particular host by typing the following commands at the angle bracket prompt:


    >set q=any
    >host-name
    
  3. Type the following command to view only AAAA records:


    >set q=AAAA
    hostname
    
  4. Quit the nslookup command by typing exit.


Example 7–16 Using nslookup to Display IPv6 Information

This example shows the results of nslookup in an IPv6 network environment.


%  /usr/sbin/nslookup
Default Server:  dnsserve.local.com
Address:  10.10.50.85
> set q=AAAA
> host85
Server:  dnsserve.local.com
Address:  10.10.50.85

host85.local.com      IPv6 address = 2::9256:a00:fe12:528
> exit

ProcedureHow to Verify That DNS IPv6 PTR Records Are Updated Correctly

In this procedure, you use the nslookup command to display PTR records for DNS IPv6.

  1. Under your user account, run the nslookup command.


    % /usr/sbin/nslookup
    

    The default server name and address display, followed by the nslookup command's angle bracket prompt.

  2. Type the following at the angle bracket prompt to see the PTR records:


    >set q=PTR
    
  3. Quit the command by typing exit.


Example 7–17 Using nslookup to Display PTR Records

The following example shows the PTR record display from the nslookup command.


%  /usr/sbin/nslookup
Default Server:  space1999.Eng.apex.COM
Address:  192.168.15.78
> set q=PTR
> 8.2.5.0.2.1.e.f.f.f.0.2.0.0.a.0.6.5.2.9.0.0.0.0.0.0.0.0.2.0.0.0.ip6.int

8.2.5.0.2.1.e.f.f.f.0.2.0.0.a.0.6.5.2.9.0.0.0.0.0.0.0.0.2.0.0.0.ip6.int name = 
vallejo.ipv6.Eng.apex.COM
ip6.int nameserver = space1999.Eng.apex.COM
> exit

ProcedureHow to Display IPv6 Information Through NIS

In this procedure, you use the ypmatch command to display IPv6 information through NIS:

  1. Under your user account, type the following to display IPv6 addresses in NIS:


    % ypmatch hostname hosts ipnodes.byname
    

    The information about the specified hostname is displayed.


    Note –

    Oracle Solaris releases after Solaris 10 11/06 no longer include the ipnodes maps. The IPv6 functionality of ipnodes is now maintained in the hosts maps.



Example 7–18 IPv6 Addresses Output by the ypmatch Command

For Solaris 10 11/06 and earlier releases, the following sample shows the results of a ypmatch operation on the ipnodes.byname database.


% ypmatch farhost hosts ipnodes.byname
2001:0db8:3c4d:15:a00:20ff:fe12:5286       farhost

ProcedureHow to Display IPv6 Information Independent of the Name Service

This procedure can be used for Solaris 10 11/06 and earlier releases only. For subsequent releases, you can perform the same operation on the hosts database.

  1. Under your user account, type the following command:


    % getent ipnodes hostname
    

    The information about the specified host-name is displayed.


Example 7–19 Displaying IPv6 Information in the ipnodes Database

The following sample shows the output of the getent command:


% getent ipnodes vallejo

2001:0db8:8512:2:56:a00:fe87:9aba    myhost myhost
fe80::56:a00:fe87:9aba     myhost myhost

Chapter 8 Administering a TCP/IP Network (Tasks)

This chapter contains tasks for administering a TCP/IP network. The following topics are covered:

The tasks assume that you have an operational TCP/IP network at your site, either IPv4-only or dual-stack IPv4/IPv6. If you want to implement IPv6 at your site but have not done so, refer to following chapters for more information:

Major TCP/IP Administrative Tasks (Task Map)

The following table lists other miscellaneous tasks to administer the network after initial configuration, such as displaying network information. The table includes a description of what each task accomplishes and the section in the current documentation where the specific steps to perform the task are detailed.

Task 

Description 

For Information 

Display configuration information about an interface. 

Determine the current configuration of each interface on a system. 

How to Get Information About a Specific Interface

Display interface address assignments. 

Determine the address assignments for all interfaces on the local system. 

How to Display Interface Address Assignments

Display statistics on a per-protocol basis. 

Monitor the performance of the network protocols on a particular system. 

How to Display Statistics by Protocol

Display network status. 

Monitor your system by displaying all sockets and routing table entries. The output includes the inet address family for IPv4 and inet6 address family for IPv6.  

How to Display the Status of Sockets

Display the status of network interfaces. 

Monitor the performance of network interfaces, which is useful for troubleshooting transmission problems. 

How to Display Network Interface Status

Display packet transmission status. 

Monitor the state of packets as they are sent over the wire. 

How to Display the Status of Transmissions for Packets of a Specific Address Type

Control the display output of IPv6-related commands. 

Controls the output of the ping, netstat, ifconfig, and traceroute commands. Creates a file that is named inet_type. Sets the DEFAULT_IP variable in this file.

How to Control the Display Output of IP-Related Commands

Monitor network traffic. 

Displays all IP packets by using the snoop command.

How to Monitor IPv6 Network Traffic

Trace all routes that are known to the network's routers. 

Uses the traceroute command to show all routes.

How to Trace All Routes

Monitoring the Interface Configuration With the ifconfig Command

You use the ifconfig command to manually assign IP addresses to interfaces and to manually configure interface parameters. In addition, Oracle Solaris startup scripts run ifconfig to configure pseudo interfaces, such as 6to4 tunnel endpoints.

This book contains many tasks that use the various options of the versatile ifconfig command. For a complete description of this command, its options, and its variables, refer to the ifconfig(1M) man page. The basic syntax of ifconfig follows:

ifconfig interface [protocol-family]

ProcedureHow to Get Information About a Specific Interface

Use the ifconfig command to determine basic information about the interfaces of a particular system. For example, a simple ifconfig query can tell you the following:

The following procedure shows how to use the ifconfig command to obtain basic configuration information about a system's interfaces.

  1. On the local host, assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Obtain information about a particular interface.


    # ifconfig interface
    

    The output from the ifconfig command has the following format:

    • Status line

      The first line in the ifconfig command output includes the interface name and status flags currently associated with the interface. Also, the status line includes the maximum transmission unit (MTU) that is configured for the particular interface and an index number. Use the status line to determine the current state of the interface.

    • IP address information line

      The second line of the ifconfig output includes the IPv4 address or IPv6 address that is configured for the interface. For an IPv4 address, the configured netmask and broadcast address are also displayed.

    • MAC address line

      When you run the ifconfig command as superuser or with a similar role, the ifconfig output contains a third line. For an IPv4 address, the third line shows the MAC address (Ethernet layer address) that is assigned to the interface. For an IPv6 address, the third line in the output shows the link-local address that the IPv6 in.ndpd daemon generates from the MAC address.


Example 8–1 Basic Interface Information From the ifconfig Command

The following example shows how to obtain information about the eri interface on a particular host by using the ifconfig command.


# ifconfig eri
eri0: flags=863<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 1
      inet 10.0.0.112 netmask ffffff80 broadcast 10.8.48.127
      ether 8:0:20:b9:4c:54 
	

The next table describes the variable information in an ifconfig query and also includes the description of how the variable might be displayed on the screen and the type of information that is being provided. The preceding output is used as an example.

Variable 

Screen Output 

Description 

Interface name 

eri0

Indicates the device name of the interface whose status was requested in the ifconfig command.

Interface status 

flags=863<UP

Displays the status of the interface, including any flags that are currently associated with the interface. Here you can determine whether the interface is currently initialized (UP) or not initialized (DOWN).

Broadcast status 

BROADCAST

Indicates that the interface supports IPv4 broadcasts. 

Transmission status 

RUNNING

Indicates that the system is transmitting packets through the interface. 

Multicast status 

MULTICAST, IPv4

Shows that the interface supports multicast transmissions. The example interface supports IPv4 multicast transmissions. 

Maximum transmission unit 

mtu 1500

Shows that this interface has a maximum transfer size of 1500 octets. 

IP address 

inet 10.0.0.112

Displays the IPv4 or IPv6 address that is assigned to the interface. Example interface eri0 has the IPv4 address 10.0.0.112.

Netmask 

netmask ffffff80

Displays the IPv4 netmask of the particular interface. Note that IPv6 addresses do not use netmasks. 

MAC address 

ether 8:0:20:b9:4c:54

Shows the interface's Ethernet layer address. 


ProcedureHow to Display Interface Address Assignments

Routers and multihomed hosts have more than one interface and, often, more than one IP address assigned to each interface. You can use the ifconfig command to display all addresses that are assigned to the interfaces of a system. You can also use the ifconfig command to display only IPv4 or IPv6 address assignments. To additionally display the MAC addresses of the interfaces, you must first log in as superuser or assume the appropriate role.

For more information on the ifconfig command, see the ifconfig(1M) man page.

  1. On the local system, assume the Network Management role or become superuser.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Obtain information about all interfaces.

    You can use variations of the ifconfig -a command to do the following:

    • View all addresses of all interfaces on the system.


      # ifconfig -a
      
    • View all IPv4 addresses that are assigned to a system's interfaces.


      # ifconfig -a4
      
    • If the local system is IPv6-enabled, display all IPv6 addresses that are assigned to a system's interfaces.


      ifconfig -a6
      

Example 8–2 Displaying Addressing Information for All Interfaces

This example shows entries for a host with solely a primary network interface, qfe0. Nevertheless, the ifconfig output shows that three forms of addresses are currently assigned to qfe0: loopback (lo0), IPv4 (inet), and IPv6 (inet6). In the IPv6 section of the output, note that the line for interface qfe0 displays the link-local IPv6 address. The second address for qfe0 is displayed on the qfe0:1 line.


% ifconfig -a
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000 
qfe0: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 
        inet 10.0.0.112 netmask ffffff80 broadcast 10.0.0.127
        ether 8:0:20:b9:4c:54 
lo0: flags=2000849 <UP,RUNNING,MULTICAST,IPv6> mtu 8252 index 1
        inet6 ::1/128 
qfe0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
        ether 8:0:20:b9:4c:54 
        inet6 fe80::a00:20ff:feb9:4c54/10 
qfe0:1: flags=2080841 <UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
        inet6 2001:db8:3c4d:48:a00:20ff:feb9:4c54/64 


Example 8–3 Displaying Addressing Information for All IPv4 Interfaces

This example shows the IPv4 address that is configured for a multihomed host. You do not need to be logged in as superuser to run this form of the ifconfig command.


% ifconfig -a4
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
qfe0: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.0.0.112 netmask ffffff80 broadcast 10.0.0.127
        ether 8:0:20:b9:4c:54 
qfe1: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.0.0.118 netmask ffffff80 broadcast 10.0.0.127
        ether 8:0:20:6f:5e:17


Example 8–4 Displaying Addressing Information for All IPv6 Interfaces

This example shows only the IPv6 addresses that are configured for a particular host. You do not need to be logged in as superuser to run this form of the ifconfig command.


% ifconfig -a6
lo0: flags=2000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1
        inet6 ::1/128 
qfe0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
        ether 8:0:20:b9:4c:54 
        inet6 fe80::a00:20ff:feb9:4c54/10
qfe0:1: flags=2080841 <UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2
        inet6 2001:db8:3c4d:48:a00:20ff:feb9:4c54/64 

This output from ifconfig shows the following three types of IPv6 address forms that are assigned to the single interface of a host:

lo0

IPv6 loopback address.

inet6 fe80::a00:20ff:feb9:4c54/10

Link-local address that is assigned to the primary network interface.

inet6 2001:db8:3c4d:48:a00:20ff:feb9:4c54/64

IPv6 address, including subnet prefix. The term ADDRCONF in the output indicates that this address was autoconfigured by the host.


Monitoring Network Status With the netstat Command

The netstat command generates displays that show network status and protocol statistics. You can display the status of TCP, SCTP, and UDP endpoints in table format. You can also display routing table information and interface information.

The netstat command displays various types of network data, depending on the selected command-line option. These displays are the most useful for system administration. The basic syntax for netstat follows:

netstat [-m] [-n] [-s] [-i | -r] [-faddress-family]

This section describes the most commonly used options of the netstat command. For a detailed description of all netstat options, refer to the netstat(1M) man page.

ProcedureHow to Display Statistics by Protocol

The netstat -s option displays protocol statistics for the UDP, TCP, SCTP, ICMP, and IP protocols.


Note –

You can use your Oracle Solaris user account to obtain output from the netstat command.


  1. Display the protocol status.


    $ netstat -s
    

Example 8–5 Network Protocol Statistics

The following example shows the output of the netstat -s command. Parts of the output have been truncated. The output can indicate areas where a protocol is having problems. For example, statistical information from ICMPv4 and ICMPv6 can indicate where the ICMP protocol has found errors.


RAWIP
        rawipInDatagrams    =  4701     rawipInErrors       =     0
        rawipInCksumErrs    =     0     rawipOutDatagrams   =     4
        rawipOutErrors      =     0

UDP
        udpInDatagrams      = 10091     udpInErrors         =     0
        udpOutDatagrams     = 15772     udpOutErrors        =     0

TCP     tcpRtoAlgorithm     =     4     tcpRtoMin           =   400
        tcpRtoMax           = 60000     tcpMaxConn          =    -1
        .
        .
        tcpListenDrop       =     0     tcpListenDropQ0     =     0
        tcpHalfOpenDrop     =     0     tcpOutSackRetrans   =     0

IPv4    ipForwarding        =     2     ipDefaultTTL        =   255
        ipInReceives        =300182     ipInHdrErrors       =     0
        ipInAddrErrors      =     0     ipInCksumErrs       =     0
        .
        .
        ipsecInFailed       =     0     ipInIPv6            =     0
        ipOutIPv6           =     3     ipOutSwitchIPv6     =     0

IPv6    ipv6Forwarding      =     2     ipv6DefaultHopLimit =   255
        ipv6InReceives      = 13986     ipv6InHdrErrors     =     0
        ipv6InTooBigErrors  =     0     ipv6InNoRoutes      =     0
        .
        .
        rawipInOverflows    =     0     ipv6InIPv4          =     0
 
       ipv6OutIPv4         =     0     ipv6OutSwitchIPv4   =     0

ICMPv4  icmpInMsgs          = 43593     icmpInErrors        =     0
        icmpInCksumErrs     =     0     icmpInUnknowns      =     0
        .
        .
        icmpInOverflows     =     0

ICMPv6  icmp6InMsgs         = 13612     icmp6InErrors       =     0
        icmp6InDestUnreachs =     0     icmp6InAdminProhibs =     0
        .
        .
        icmp6OutGroupQueries=     0     icmp6OutGroupResps  =     2
        icmp6OutGroupReds   =     0

IGMP:
      12287 messages received
          0 messages received with too few bytes
          0 messages received with bad checksum
      12287 membership queries received
SCTP  sctpRtoAlgorithm     =  vanj    
      sctpRtoMin           =  1000 
      sctpRtoMax           = 60000
      sctpRtoInitial       =  3000
      sctpTimHearBeatProbe =     2
      sctpTimHearBeatDrop  =     0
      sctpListenDrop       =     0
      sctpInClosed         =     0 

ProcedureHow to Display the Status of Transport Protocols

You can display the status of the transport protocols through the netstat command. For detailed information, refer to the netstat(1M) man page.

  1. Display the status of the TCP and SCTP transport protocols on a system.


    $ netstat
    
  2. Display the status of a particular transport protocol on a system.


    $ netstat -P transport-protocol
    

    Values for the transport-protocol variable are tcp, sctp, or udp.


Example 8–6 Displaying the Status of the TCP and SCTP Transport Protocols

This example shows the output of the basic netstat command. Note that IPv4-only information is displayed.


$ netstat

TCP: IPv4
   Local Address     Remote Address    Swind Send-Q  Rwind Recv-Q      State
----------------- -------------------- ----- ------  ----- ------     -------
lhost-1.login      abc.def.local.Sun.COM.980 49640      0     49640    0 ESTABLISHED
lhost-1.login      ghi.jkl.local.Sun.COM.1020 49640     1     49640    0 ESTABLISHED
remhost-1.1014     mno.pqr.remote.Sun.COM.nfsd 49640    0     49640    0 TIME_WAIT
SCTP:                  
Local Address    Remote Address  Swind  Send-Q  Rwind  Recv-Q StrsI/O  State 
---------------- --------------  -----  ------ ------ ------  ------   -------
 *.echo            0.0.0.0            0       0 102400      0   128/1   LISTEN
 *.discard         0.0.0.0            0       0 102400      0   128/1   LISTEN
 *.9001            0.0.0.0            0       0 102400      0   128/1   LISTEN


Example 8–7 Displaying the Status of a Particular Transport Protocol

This example shows the results when you specify the -P option of netstat.


$ netstat -P tcp
   
TCP: IPv4
   Local Address     Remote Address    Swind Send-Q  Rwind Recv-Q      State
----------------- -------------------- ----- ------  ----- ------     -------
lhost-1.login      abc.def.local.Sun.COM.980 49640      0     49640    0 ESTABLISHED
lhost.login        ghi.jkl.local.Sun.COM.1020 49640     1     49640    0 ESTABLISHED
remhost.1014       mno.pqr.remote.Sun.COM.nfsd 49640    0     49640    0 TIME_WAIT

TCP: IPv6
 Local Address    Remote Address        Swind Send-Q Rwind Recv-Q   State If 
---------------- ---------------------- ------ ----- ------ ----------- -----
localhost.38983   localhost.32777       49152      0 49152      0 ESTABLISHED      
localhost.32777   localhost.38983       49152      0 49152      0 ESTABLISHED      
localhost.38986   localhost.38980       49152      0 49152      0 ESTABLISHED      

ProcedureHow to Display Network Interface Status

The i option of the netstat command shows the state of the network interfaces that are configured on the local system. With this option, you can determine the number of packets a system transmits and receives on each network.

  1. Display the status of interfaces on the network.


    $ netstat -i
    

Example 8–8 Network Interface Status Display

The next example shows the status of IPv4 and IPv6 packet flow through the host's interfaces.

For example, the input packet count (Ipkts) that is displayed for a server can increase each time a client tries to boot, while the output packet count (Opkts) remains steady. This outcome suggests that the server is seeing the boot request packets from the client. However, the server does not know to respond to them. This confusion might be caused by an incorrect address in the hosts, ipnodes, or ethers database.

However, if the input packet count is steady over time, then the machine does not see the packets at all. This outcome suggests a different type of failure, possibly a hardware problem.


Name  Mtu  Net/Dest      Address        Ipkts  Ierrs Opkts  Oerrs Collis Queue 
lo0   8232 loopback      localhost      142    0     142    0     0      0     
hme0  1500 host58        host58        1106302 0     52419  0     0      0     

Name  Mtu  Net/Dest      Address                    Ipkts  Ierrs Opkts  Oerrs Collis
lo0   8252 localhost     localhost                   142    0     142    0     0     
hme0  1500 fe80::a00:20ff:feb9:4c54/10 fe80::a00:20ff:feb9:4c54 1106305 0 52422 0  0

ProcedureHow to Display the Status of Sockets

The -a option of the netstat command enables you to view the status of sockets on the local host.

  1. Type the following to display the status of sockets and routing table entries:

    You can use your user account to run this option of netstat.


    % netstat -a  
    

Example 8–9 Displaying All Sockets and Routing Table Entries

The output of the netstat -a command shows extensive statistics. The following example shows portions of typical netstat -a output.


UDP: IPv4
   Local Address         Remote Address     State
-------------------- -------------------- -------
      *.bootpc                              Idle
host85.bootpc                               Idle
      *.*                                   Unbound
      *.*                                   Unbound
      *.sunrpc                              Idle
      *.*                                   Unbound
      *.32771                               Idle
      *.sunrpc                              Idle
      *.*                                   Unbound
      *.32775                               Idle
      *.time                                Idle
       .
       .
      *.daytime                             Idle
      *.echo                                Idle
      *.discard                             Idle
      
UDP: IPv6
   Local Address                     Remote Address                   State      If  
--------------------------------- --------------------------------- ---------- -----
      *.*                                                           Unbound   
      *.*                                                           Unbound   
      *.sunrpc                                                      Idle      
      *.*                                                           Unbound   
      *.32771                                                       Idle      
      *.32778                                                       Idle      
      *.syslog                                                      Idle      
      .
      .
TCP: IPv4
   Local Address        Remote Address    Swind Send-Q Rwind Recv-Q  State
-------------------- -------------------- ----- ------ ----- ------ -------
      *.*                  *.*                0      0 49152      0 IDLE
localhost.4999             *.*                0      0 49152      0 LISTEN
      *.sunrpc             *.*                0      0 49152      0 LISTEN
      *.*                  *.*                0      0 49152      0 IDLE
      *.sunrpc             *.*                0      0 49152      0 LISTEN
      .
      .
      *.printer            *.*                0      0 49152      0 LISTEN
      *.time               *.*                0      0 49152      0 LISTEN
      *.daytime            *.*                0      0 49152      0 LISTEN
      *.echo               *.*                0      0 49152      0 LISTEN
      *.discard            *.*                0      0 49152      0 LISTEN
      *.chargen            *.*                0      0 49152      0 LISTEN
      *.shell              *.*                0      0 49152      0 LISTEN
      *.shell              *.*                0      0 49152      0 LISTEN
      *.kshell             *.*                0      0 49152      0 LISTEN
      *.login  
       .
       .
            *.*                0      0 49152      0 LISTEN
   *TCP: IPv6
 Local Address            Remote Address        Swind Send-Q Rwind Recv-Q   State If
----------------------- ----------------------- ----- ------ ----- ------    ----
   *.*                         *.*                0      0 49152      0      IDLE
   *.sunrpc                    *.*                0      0 49152      0      LISTEN
   *.*                         *.*                0      0 49152      0      IDLE
   *.32774                     *.*                0      0 49152

ProcedureHow to Display the Status of Transmissions for Packets of a Specific Address Type

Use the -f option of the netstat command to view statistics related to packet transmissions of a particular address family.

  1. View statistics for transmissions of either IPv4 or IPv6 packets.


    $ netstat -f inet  |  inet6
    

    To view IPv4 transmission information, type inet as the argument to netstat -f. Use inet6 as the argument to netstat -f to view IPv6 information.


Example 8–10 Status of IPv4 Packet Transmission

The following example shows output from the netstat -f inet command.


TCP: IPv4
   Local Address        Remote Address    Swind Send-Q Rwind Recv-Q  State
-------------------- -------------------- ----- ------ ----- ------ -------
host58.734         host19.nfsd       49640      0 49640      0 ESTABLISHED
host58.38063       host19.32782      49640      0 49640      0 CLOSE_WAIT
host58.38146       host41.43601      49640      0 49640      0 ESTABLISHED
host58.996         remote-host.login 49640      0 49206      0 ESTABLISHED


Example 8–11 Status of IPv6 Packet Transmission

The following example shows output from the netstat -f inet6 command.


TCP: IPv6
 Local Address          Remote Address        Swind Send-Q Rwind Recv-Q   State    If
------------------ ------------------------- ----- ------ ----- ------ --------- -----
localhost.38065         localhost.32792       49152   0 49152      0    ESTABLISHED  
localhost.32792         localhost.38065       49152   0 49152      0    ESTABLISHED 
localhost.38089         localhost.38057       49152   0 49152      0    ESTABLISHED 

ProcedureHow to Display the Status of Known Routes

The -r option of the netstat command displays the routing table for the local host. This table shows the status of all routes that the host knows about. You can run this option of netstat from your user account.

  1. Display the IP routing table.


    $ netstat -r
    

Example 8–12 Routing Table Output by the netstat Command

The following example shows output from the netstat -r command.


Routing Table: IPv4
  Destination           Gateway           Flags  Ref   Use   Interface
-------------------- -------------------- ----- ----- ------ ---------
host15               myhost               U         1  31059  hme0
10.0.0.14            myhost               U         1      0  hme0
default              distantrouter        UG        1      2  hme0
localhost            localhost            UH        42019361  lo0

Routing Table: IPv6
  Destination/Mask            Gateway                   Flags Ref   Use   If  
--------------------------- --------------------------- ----- --- ------ -----
2002:0a00:3010:2::/64    2002:0a00:3010:2:1b2b:3c4c:5e6e:abcd U  1      0 hme0:1
fe80::/10                fe80::1a2b:3c4d:5e6f:12a2    U       1     23 hme0 
ff00::/8                 fe80::1a2b:3c4d:5e6f:12a2    U       1      0 hme0 
default                  fe80::1a2b:3c4d:5e6f:12a2    UG      1      0 hme0 
localhost                localhost                   UH      9  21832 lo0 

The following table describes the meaning of the various parameters of the screen output of the netstat —r command.

Parameter 

Description 

Destination

Destination/Mask

Specifies the host that is the destination endpoint of the route. Note that the IPv6 routing table shows the prefix for a 6to4 tunnel endpoint (2002:0a00:3010:2::/64) as the route destination endpoint.

Gateway

Specifies the gateway to use for forwarding packets. 

Flags

Indicates the current status of the route. The U flag indicates that the route is up. The G flag indicates that the route is to a gateway.

Use

Shows the number of packets sent. 

Interface

Indicates the particular interface on the local host that is the source endpoint of the transmission. 


Probing Remote Hosts With the ping Command

You can use the ping command to determine the status of a remote host. When you run ping, the ICMP protocol sends a datagram to the host that you specify, asking for a response. ICMP is the protocol responsible for error handling on a TCP/IP network. When you use ping, you can find out whether an IP connection exists for the specified remote host.

The following is the basic syntax of ping:

/usr/sbin/ping host [timeout]

In this syntax, host is the name of the remote host. The optional timeout argument indicates the time in seconds for the ping command to continue trying to reach the remote host. The default is 20 seconds. For additional syntax and options, refer to the ping(1M) man page.

ProcedureHow to Determine if a Remote Host Is Running

  1. Type the following form of the ping command:


    $ ping hostname
    

    If host hostname is accepting ICMP transmissions, this message is displayed:


    hostname is alive

    This message indicates that hostname responded to the ICMP request. However, if hostname is down or cannot receive the ICMP packets, you receive the following response from the ping command:


    no answer from hostname
    

ProcedureHow to Determine if a Host Is Dropping Packets

Use the -s option of the ping command to determine if a remote host is running but nevertheless losing packets.

  1. Type the following form of the ping command:


    $ ping -s hostname
    

Example 8–13 ping Output for Detecting Packet Dropping

The ping -s hostname command continually sends packets to the specified host until you send an interrupt character or a time out occurs. The responses on your screen resemble the following:


& ping -s host1.domain8
PING host1.domain8 : 56 data bytes
64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=0. time=1.67 ms
64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=1. time=1.02 ms
64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=2. time=0.986 ms
64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=3. time=0.921 ms
64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=4. time=1.16 ms
64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=5. time=1.00 ms
64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=5. time=1.980 ms

^C

----host1.domain8  PING Statistics----
7 packets transmitted, 7 packets received, 0% packet loss
round-trip (ms)  min/avg/max/stddev = 0.921/1.11/1.67/0.26

The packet-loss statistic indicates whether the host has dropped packets. If ping fails, check the status of the network that is reported by the ifconfig and netstat commands. Refer to Monitoring the Interface Configuration With the ifconfig Command and Monitoring Network Status With the netstat Command.


Administering and Logging Network Status Displays

The following tasks show how to check the status of the network by using well-known networking commands.

ProcedureHow to Control the Display Output of IP-Related Commands

You can control the output of the netstat and ifconfig commands to display IPv4 information only, or both IPv4 and IPv6 information.

  1. Create the /etc/default/inet_type file.

  2. Add one of the following entries to /etc/default/inet_type, as required for your network:

    • To display IPv4 information only:


      DEFAULT_IP=IP_VERSION4
    • To display both IPv4 and IPv6 information:


      DEFAULT_IP=BOTH

      Or


      DEFAULT_IP=IP_VERSION6

      For more information about the inet_type file, see the inet_type(4) man page.


    Note –

    The -4 and -6 flags in the ifconfig command override the values set in the inet_type file. The -f flag in the netstat command also overrides the values set in the inet_type file.



Example 8–14 Controlling Output to Select IPv4 and IPv6 Information


ProcedureHow to Log Actions of the IPv4 Routing Daemon

If you suspect a malfunction of routed, the IPv4 routing daemon, you can start a log that traces the daemon's activity. The log includes all packet transfers when you start the routed daemon.

  1. On the local host, assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Create a log file of routing daemon actions:


    # /usr/sbin/in.routed /var/log-file-name
    

    Caution – Caution –

    On a busy network, this command can generate almost continuous output.



Example 8–15 Network Log for the in.routed Daemon

The following example shows the beginning of the log that is created by the procedure How to Log Actions of the IPv4 Routing Daemon.


-- 2003/11/18 16:47:00.000000 --
Tracing actions started
RCVBUF=61440
Add interface lo0  #1   127.0.0.1      -->127.0.0.1/32   
   <UP|LOOPBACK|RUNNING|MULTICAST|IPv4> <PASSIVE> 
Add interface hme0 #2   10.10.48.112    -->10.10.48.0/25   
    <UP|BROADCAST|RUNNING|MULTICAST|IPv4> 
turn on RIP
Add    10.0.0.0        -->10.10.48.112      metric=0  hme0  <NET_SYN>
Add    10.10.48.85/25  -->10.10.48.112      metric=0  hme0  <IF|NOPROP>

ProcedureHow to Trace the Activities of the IPv6 Neighbor Discovery Daemon

If you suspect a malfunction of the IPv6 in.ndpd daemon, you can start a log that traces the daemon's activity. This trace is displayed on the standard output until terminated. This trace includes all packet transfers when you start the in.ndpd daemon.

  1. Assume the Primary Administrator role, or become superuser, on the local IPv6 node.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Start a trace of the in.ndpd daemon.


    # /usr/lib/inet/in.ndpd -t
    
  3. Terminate the trace as needed by typing Control-C.


Example 8–16 Trace of the in.ndpd Daemon

The following output shows the beginning of a trace of in.ndpd.


# /usr/lib/inet/in.ndpd -t
Nov 18 17:27:28 Sending solicitation to  ff02::2 (16 bytes) on hme0
Nov 18 17:27:28         Source LLA: len 6 <08:00:20:b9:4c:54>
Nov 18 17:27:28 Received valid advert from fe80::a00:20ff:fee9:2d27 (88 bytes) on hme0
Nov 18 17:27:28         Max hop limit: 0
Nov 18 17:27:28         Managed address configuration: Not set
Nov 18 17:27:28         Other configuration flag: Not set
Nov 18 17:27:28         Router lifetime: 1800
Nov 18 17:27:28         Reachable timer: 0
Nov 18 17:27:28         Reachable retrans timer: 0
Nov 18 17:27:28         Source LLA: len 6 <08:00:20:e9:2d:27>
Nov 18 17:27:28         Prefix: 2001:08db:3c4d:1::/64
Nov 18 17:27:28                 On link flag:Set
Nov 18 17:27:28                 Auto addrconf flag:Set
Nov 18 17:27:28                 Valid time: 2592000
Nov 18 17:27:28                 Preferred time: 604800
Nov 18 17:27:28         Prefix: 2002:0a00:3010:2::/64
Nov 18 17:27:28                 On link flag:Set
Nov 18 17:27:28                 Auto addrconf flag:Set
Nov 18 17:27:28                 Valid time: 2592000
Nov 18 17:27:28                 Preferred time: 604800

Displaying Routing Information With the traceroute Command

The traceroute command traces the route an IP packet follows to a remote system. For technical details about traceroute, see the traceroute(1M) man page.

You use the traceroute command to uncover any routing misconfiguration and routing path failures. If a particular host is unreachable, you can use traceroute to see what path the packet follows to the remote host and where possible failures might occur.

The traceroute command also displays the round trip time for each gateway along the path to the target host. This information can be useful for analyzing where traffic is slow between the two hosts.

ProcedureHow to Find Out the Route to a Remote Host

  1. Type the following to discover the route to a remote system:


    % traceroute destination-hostname
    

    You can run this form of the traceroute command from your user account.


Example 8–17 Using the traceroute Command to Show the Route to a Remote Host

The following output from the traceroute command shows the seven–hop path a packet follows from the local system nearhost to the remote system farhost. The output also shows the times for a packet to traverse each hop.


istanbul% traceroute farhost.faraway.com
	traceroute to farhost.faraway.com (172.16.64.39), 30 hops max, 40 byte packets
	 1  frbldg7c-86 (172.16.86.1)  1.516 ms  1.283 ms  1.362 ms
	 2  bldg1a-001 (172.16.1.211)  2.277 ms  1.773 ms  2.186 ms
	 3  bldg4-bldg1 (172.16.4.42)  1.978 ms  1.986 ms  13.996 ms
	 4  bldg6-bldg4 (172.16.4.49)  2.655 ms  3.042 ms  2.344 ms
	 5  ferbldg11a-001 (172.16.1.236)  2.636 ms  3.432 ms  3.830 ms
	 6  frbldg12b-153 (172.16.153.72)  3.452 ms  3.146 ms  2.962 ms
	 7  sanfrancisco (172.16.64.39)  3.430 ms  3.312 ms  3.451 ms

ProcedureHow to Trace All Routes

This procedure uses the -a option of the traceroute command to trace all routes.

  1. Type the following command on the local system:


    % traceroute -ahost-name
    

    You can run this form of the traceroute command from your user account.


Example 8–18 Tracing All Routes to a Dual-Stack Host

This example shows all possible routes to a dual-stack host.


% traceroute -a v6host.remote.com
traceroute: Warning: Multiple interfaces found; using 2::56:a0:a8 @ eri0:2
traceroute to v6host (2001:db8:4a3b::102:a00:fe79:19b0),30 hops max, 60 byte packets
 1  v6-rout86 (2001:db8:4a3b:56:a00:fe1f:59a1)  35.534 ms  56.998 ms * 
 2  2001:db8::255:0:c0a8:717  32.659 ms  39.444 ms *
 3  farhost.faraway.COM (2001:db8:4a3b::103:a00:fe9a:ce7b)  401.518 ms  7.143 ms *
 4  distant.remote.com (2001:db8:4a3b::100:a00:fe7c:cf35)  113.034 ms  7.949 ms *
 5  v6host (2001:db8:4a3b::102:a00:fe79:19b0)  66.111 ms *  36.965 ms

traceroute to v6host.remote.com  (192.168.10.75),30 hops max,40 byte packets
 1  v6-rout86 (172.16.86.1)  4.360 ms  3.452 ms  3.479 ms
 2  flrmpj17u.here.COM (172.16.17.131)  4.062 ms  3.848 ms  3.505 ms
 3  farhost.farway.com (10.0.0.23)  4.773 ms *  4.294 ms
 4  distant.remote.com (192.168.10.104)  5.128 ms  5.362 ms *
 5  v6host  (192.168.15.85)  7.298 ms  5.444 ms *
 

Monitoring Packet Transfers With the snoop Command

You can use the snoop command to monitor the state of data transfers. snoop captures network packets and displays their contents in the format that you specify. Packets can be displayed as soon as they are received, or saved to a file. When snoop writes to an intermediate file, packet loss under busy trace conditions is unlikely. snoop itself is then used to interpret the file.

To capture packets to and from the default interface in promiscuous mode, you must assume the Network Management role or become superuser. In summary form, snoop displays only the data that pertains to the highest-level protocol. For example, an NFS packet only displays NFS information. The underlying RPC, UDP, IP, and Ethernet frame information is suppressed but can be displayed if either of the verbose options is chosen.

Use snoop frequently and consistently to become familiar with normal system behavior. For assistance in analyzing packets, look for a recent white paper and RFC, and seek the advice of an expert in a particular area, such as NFS or NIS. For details on using snoop and its options, refer to the snoop(1M) man page.

ProcedureHow to Check Packets From All Interfaces

  1. On the local host, assume the Network Management role or become superuser.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Print information about the interfaces that are attached to the system.


    # ifconfig -a
    

    The snoop command normally uses the first non-loopback device, typically the primary network interface.

  3. Begin packet capture by typing snoop without arguments, as shown in Example 8–19.

  4. Use Control-C to halt the process.


Example 8–19 Output From the snoop Command

The basic snoop command returns output that resembles the following, for a dual-stack host.


% snoop
Using device /dev/hme (promiscuous mode)
farhost.remote.com -> myhost       RLOGIN C port=993 
    myhost -> farhost.remote.com   RLOGIN R port=993 Using device /dev/hme
router5.local.com -> router5.local.com ARP R 10.0.0.13, router5.local.com is
    0:10:7b:31:37:80
router5.local.com -> BROADCAST     TFTP Read "network-confg" (octet)
farhost.remote.com -> myhost       RLOGIN C port=993 
    myhost ->   nisserve2          NIS C MATCH 10.0.0.64 in ipnodes.byaddr
nisserve2 ->    myhost             NIS R MATCH No such key
    blue-112 -> slave-253-2        NIS C MATCH 10.0.0.112 in ipnodes.byaddr
myhost -> DNSserver.local.com      DNS C 192.168.10.10.in-addr.arpa. Internet PTR ?
DNSserver.local.com  myhost        DNS R 192.168.10.10.in-addr.arpa. Internet PTR 
   niserve2.
.
.
farhost.remote.com-> myhost        RLOGIN C port=993 
    myhost -> farhost.remote.com   RLOGIN R port=993 fe80::a00:20ff:febb:
.
fe80::a00:20ff:febb:e09 -> ff02::9 RIPng R (5 destinations)

The packets that are captured in this output show a remote login section, including lookups to the NIS and DNS servers for address resolution. Also included are periodic ARP packets from the local router and advertisements of the IPv6 link-local address to in.ripngd.


ProcedureHow to Capture snoop Output Into a File

  1. On the local host, assume the Network Management role or become superuser.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Capture a snoop session into a file.


    # snoop -o filename
    

    For example:


    # snoop -o /tmp/cap
    Using device /dev/eri (promiscuous mode)
    30 snoop: 30 packets captured

    In the example, 30 packets have been captured in a file named /tmp/cap. The file can be in any directory with enough disk space. The number of packets that are captured is displayed on the command line, enabling you to press Control-C to abort at any time.

    snoop creates a noticeable networking load on the host machine, which can distort the results. To see the actual results, run snoop from a third system.

  3. Inspect the snoop output captures file.


    # snoop -i filename
    

Example 8–20 Contents of a snoop Output Captures File

The following output shows a variety of captures such as you might receive as output from the snoop -i command.


# snoop -i /tmp/cap
1   0.00000 fe80::a00:20ff:fee9:2d27 -> fe80::a00:20ff:fecd:4375 
    ICMPv6 Neighbor advertisement
2   0.16198 farhost.com   -> myhost     RLOGIN C port=985 
3   0.00008 myhost -> farhost.com       RLOGIN R port=985 
10  0.91493    10.0.0.40 -> (broadcast)  ARP C Who is 10.0.0.40, 10.0.0.40 ?
34  0.43690 nearserver.here.com  -> 224.0.1.1  IP  D=224.0.1.1 S=10.0.0.40 LEN=28, 
      ID=47453, TO =0x0, TTL=1
35  0.00034  10.0.0.40 -> 224.0.1.1    IP  D=224.0.1.1 S=10.0.0.40 LEN=28, ID=57376, 
     TOS=0x0, TTL=47  

ProcedureHow to Check Packets Between an IPv4 Server and a Client

  1. Establish a snoop system off a hub that is connected to either the client or the server.

    The third system (the snoop system) checks all the intervening traffic, so the snoop trace reflects what is actually happening on the wire.

  2. On the snoop system, assume the Network Management role or become superuser.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  3. Type snoop with options and save the output to a file.

  4. Inspect and interpret the output.

    Refer to RFC 1761, Snoop Version 2 Packet Capture File Format for details of the snoop capture file.

ProcedureHow to Monitor IPv6 Network Traffic

You can use the snoop command to display only IPv6 packets.

  1. On the local node, assume the Network Management role or become superuser.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Capture IPv6 packets.


    # snoop ip6
    

    For more information on the snoop command, see the snoop(1M) man page.


Example 8–21 Displaying Only IPv6 Network Traffic

The following example shows typical output such as you might receive from running the snoop ip6 command on a node.


# snoop ip6
fe80::a00:20ff:fecd:4374 -> ff02::1:ffe9:2d27 ICMPv6 Neighbor solicitation
fe80::a00:20ff:fee9:2d27 -> fe80::a00:20ff:fecd:4375 ICMPv6 Neighbor 
      solicitation
fe80::a00:20ff:fee9:2d27 -> fe80::a00:20ff:fecd:4375 ICMPv6 Neighbor 
      solicitation
fe80::a00:20ff:febb:e09 -> ff02::9      RIPng R (11 destinations)
fe80::a00:20ff:fee9:2d27 -> ff02::1:ffcd:4375 ICMPv6 Neighbor solicitation

Administering Default Address Selection

Oracle Solaris enables a single interface to have multiple IP addresses. For example, technologies, such as network multipathing (IPMP) enable multiple network interface cards (NICs) to connect to the same IP link layer. That link can have one or more IP addresses. Additionally, interfaces on IPv6-enabled systems have a link-local IPv6 address, at least one IPv6 routing address, and an IPv4 address for at least one interface.

When the system initiates a transaction, an application makes a call to the getaddrinfo socket. getaddrinfo discovers the possible address in use on the destination system. The kernel then prioritizes this list to find the best destination to use for the packet. This process is called destination address ordering. The Oracle Solaris kernel then selects the appropriate format for the source address, given the best destination address for the packet. The process is known as address selection. For more information on destination address ordering, see the getaddrinfo(3SOCKET) man page.

Both IPv4-only and dual-stack IPv4/IPv6 systems must perform default address selection. In most circumstances, you do not need to change the default address selection mechanisms. However, you might need to change the priority of address formats to support IPMP or to prefer 6to4 address formats, for example.

ProcedureHow to Administer the IPv6 Address Selection Policy Table

The following procedure explains how to modify the address selection policy table. For conceptual information about IPv6 default address selection, refer to ipaddrsel Command.


Caution – Caution –

Do not change the IPv6 address selection policy table, except for the reasons shown in the next task. You can cause problems on the network with a badly constructed policy table. Be sure to save a backup copy of the policy table, as is done in the next procedure.


  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Review the current IPv6 address selection policy table.


    # ipaddrsel
    # Prefix                  Precedence Label
    ::1/128                           50 Loopback
    ::/0                              40 Default
    2002::/16                         30 6to4
    ::/96                             20 IPv4_Compatible
    ::ffff:0.0.0.0/96                 10 IPv4
  3. Make a backup copy of the default address policy table.


    # cp /etc/inet/ipaddrsel.conf /etc/inet/ipaddrsel.conf.orig
    
  4. Use a text editor to add your customizations to /etc/inet/ipaddrsel.conf.

    Use the following syntax for entries in /etc/inet/ipaddrsel:


    prefix/prefix-length precedence label [# comment ] 
    

    Here are some common modifications that you might want to make to your policy table:

    • Give the highest priority to 6to4 addresses.


      2002::/16                         50 6to4
      ::1/128                           45 Loopback

      The 6to4 address format now has the highest priority, 50. Loopback, which previously had a 50 precedence, now has a 45 precedence. The other addressing formats remain the same.

    • Designate a specific source address to be used in communications with a specific destination address.


      ::1/128                           50 Loopback
      2001:1111:1111::1/128             40 ClientNet
      2001:2222:2222::/48               40 ClientNet
      ::/0                              40 Default

      This particular entry is useful for hosts with only one physical interface. Here 2001:1111:1111::1/128 is preferred as the source address on all packets that are bound for destinations within network 2001:2222:2222::/48. The 40 priority gives higher precedence to the source address 2001:1111:1111::1/128 than to other address formats configured for the interface.

    • Favor IPv4 addresses over IPv6 addresses.


      ::ffff:0.0.0.0/96                 60 IPv4
      ::1/128                           50 Loopback
      .
      .

      The IPv4 format ::ffff:0.0.0.0/96 has its precedence changed from the default 10 to 60, the highest priority in the table.

  5. Load the modified policy table into the kernel.


    ipaddrsel -f /etc/inet/ipaddrsel.conf
    
  6. If the modified policy table has problems, restore the default IPv6 address selection policy table.


    # ipaddrsel -d
    

ProcedureHow to Modify the IPv6 Address Selection Table for the Current Session Only

When you edit the /etc/inet/ipaddrsel.conf, file, any modifications that you make persist across reboots. If you want the modified policy table to exist only in the current session, follow this procedure.

  1. Assume the Primary Administrator role, or become superuser.

    The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Copy the contents of /etc/inet/ipaddrsel into filename, where filename represents a name of your choice.


    # cp /etc/inet/ipaddrsel filename
    
  3. Edit the policy table in filename to your specifications.

  4. Load the modified policy table into the kernel.


    # ipaddrsel -f filename
    

    The kernel uses the new policy table until you reboot the system.

Chapter 9 Troubleshooting Network Problems (Tasks)

This chapter contains solutions for common problems that might occur on your network. The following topics are covered:

What's New in Troubleshooting Network Problems

In Solaris 10 7/07, the /etc/inet/ipnodes file becomes obsolete. Use /etc/inet/ipnodes only for earlier Oracle Solaris 10 releases, as explained in the individual procedures.

General Network Troubleshooting Tips

One of the first signs of trouble on a network is a loss of communications by one or more hosts. If a host does not to come up at all the first time that the host is added to the network, the problem might be in one of the configuration files. The problem might also be a faulty network interface card. If a single host suddenly develops a problem, the network interface might be the cause. If the hosts on a network can communicate with each other but not with other networks, the problem could lie with the router. Or, the problem could be in another network.

You can use the ifconfig command to obtain information on network interfaces. Use the netstat command to display routing tables and protocol statistics. Third-party network diagnostic programs provide a number of troubleshooting tools. Refer to third-party documentation for information.

Less obvious are the causes of problems that degrade performance on the network. For example, you can use tools such as ping to quantify problems such as the loss of packets by a host.

Running Basic Diagnostic Checks

If the network has problems, you can run a series of software checks to diagnose and fix basic, software-related problems.

ProcedureHow to Perform Basic Network Software Checking

  1. On the local system, assume the Network Management role or become superuser.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Use the netstat command to display network information.

    For syntax and information about the netstat command, refer to Monitoring Network Status With the netstat Command and the netstat(1M) man page.

  3. Check the hosts database (and, in Solaris 10 11/06 and previous releases, theipnodes database, if you are using IPv6) to ensure that the entries are correct and current.

    For information about the /etc/inet/hosts database, refer to hosts Database and the hosts(4) man page. For information about the /etc/inet/ipnodes database, refer to ipnodes Database and the ipnodes(4) man page.

  4. If you are running the Reverse Address Resolution Protocol (RARP), check the Ethernet addresses in the ethers database to ensure that the entries are correct and current.

  5. Try to connect to the local host by using the telnet command.

    For syntax and information about telnet, refer to the telnet(1) man page.

  6. Ensure that the network daemon inetd is running.

    # ps -ef | grep inetd

    The following output verifies that the inetd daemon is running:


    root 57 1 0 Apr 04 ? 3:19 /usr/sbin/inetd -s
  7. If IPv6 is enabled on your network, verify that the IPv6 daemon in.ndpd is running:


    # ps -ef | grep in.ndpd
    

    The following output verifies that the in.ndpd daemon is running:


    root 123  1 0  Oct 27 ?  0:03 /usr/lib/inet/in.ndpd

Common Problems When Deploying IPv6

This section describes issues and problems that you might encounter while planning and deploying IPv6 at your site. For actual planning tasks, refer to Chapter 4, Planning an IPv6 Network (Tasks).

IPv4 Router Cannot Be Upgraded to IPv6

If your existing equipment cannot be upgraded, you might have to purchase IPv6-ready equipment. Check the manufacturers' documentation for any equipment-specific procedures you might have to perform to support IPv6.

Certain IPv4 routers cannot be upgraded for IPv6 support. If this situation applies to your topology, physically wire an IPv6 router next to the IPv4 router. Then, you can tunnel from the IPv6 router over the IPv4 router. For tasks for configuring tunnels, refer to Tasks for Configuring Tunnels for IPv6 Support (Task Map).

Problems After Upgrading Services to IPv6

You might encounter the following situations when preparing services for IPv6 support:

Current ISP Does Not Support IPv6

If you want to deploy IPv6 but your current ISP does not offer IPv6 addressing, consider the following alternatives to changing ISPs:

Security Issues When Tunneling to a 6to4 Relay Router

By nature, a tunnel between a 6to4 router and a 6to4 relay router is insecure. Security problems, such as the following, are inherent in such a tunnel:

These problems and other security issues that are inherent with 6to4 relay routers are explained in the Internet Draft, Security Considerations for 6to4. Generally, you should consider enabling support for 6to4 relay routers for the following reasons only:

Known Issues With a 6to4 Router

The following known bugs affect 6to4 configuration:

Implementing Static Routes at the 6to4 Site (Bug ID 4709338)

The following issue occurs on 6to4 sites with routers that are internal to the 6to4 boundary router. When you configure the 6to4 pseudo-interface, the static route 2002::/16 is automatically added to the routing table on the 6to4 router. Bug 4709338 describes a limitation in the Oracle Solaris RIPng routing protocol that prevents this static route from being advertised to the 6to4 site.

Either of the following workarounds are available for Bug 4709338.

Configuring Tunnels with the Same Source Address (Bug ID 4152864)

Bug ID 4152864 describes problems that occur when two tunnels are configured with the same tunnel source address, which is a serious issue for 6to4 tunnels.


Caution – Caution –

Do not configure a 6to4 tunnel and an automatic tunnel (atun) with the same tunnel source address. For information about automatics and the atun command, refer to the tun(7M) man page.


Chapter 10 TCP/IP and IPv4 in Depth (Reference)

This chapter provides TCP/IP network reference information about network configuration files, including the types, their purpose, and the format of the file entries. The existing network databases are also described in detail. The chapter also shows how the structure of IPv4 addresses are derived, based on defined network classifications and subnet numbers.

This chapter contains the following information:

What's New in TCP/IP and IPv4 in Depth

In the Solaris 10 7/07, the /etc/inet/ipnodes file becomes obsolete. Use /etc/inet/ipnodes only for earlier Oracle Solaris 10 releases, as explained in the individual procedures.

TCP/IP Configuration Files

Each system on the network obtains its TCP/IP configuration information from the following TCP/IP configuration files and network databases:

The Oracle Solaris installation program creates these files as part of the installation process. You can also edit the files manually, as explained in this section. The hosts and netmasks databases are two of the network databases read by the name services available on Oracle Solaris networks. Network Databases and the nsswitch.conf File describes in detail the concept of network databases. In Solaris 10 11/06 and earlier releases, for information on the ipnodes file, see ipnodes Database.

/etc/hostname.interface File

This file defines the physical network interfaces on the local host. At least one /etc/hostname.interface file should exist on the local system. The Oracle Solaris installation program creates an /etc/hostname.interface file for the first interface that is found during the installation process. This interface usually has the lowest device number, for example eri0, and is referred to as the primary network interface. If the installation programs finds additional interfaces, you optionally can configure them, as well, as part of the installation process.


Note –

If you create alternate hostname files for the same interface, the alternate files must also follow the naming format hostname.[0–9]*, such as hostname.qfe0.a123. Names such as hostname.qfe0.bak or hostname.qfe0.old are invalid and will be ignored by scripts during system boot.

Note, too, that a given interface must have only one corresponding hostname file. If you create an alternate hostname file for an interface with a valid filename, such as /etc/hostname.qfe and /etc/hostname.qfe.a123, the boot scripts will attempt to configure by referencing the contents of both hostname files and would therefore generate errors. To prevent these errors, provide an invalid file name to the hostname file that you do not want to use in a given configuration.


If you add a new network interface to your system after installation, you must create an /etc/hostname.interface file for that interface, as explained in How to Configure a Physical Interface After System Installation. Also, for the Oracle Solaris software to recognize and use the new network interface, you need to load the interface's device driver into the appropriate directory. Refer to the documentation that comes with the new network interface for the appropriate interface name and device driver instructions.

The basic /etc/hostname.interface file contains one entry: the host name or IPv4 address that is associated with the network interface. The IPv4 address can be expressed in traditional dotted decimal format or in CIDR notation. If you use a host name as the entry for the /etc/hostname.interface file, that host name must also exist in the /etc/inet/hosts file.

For example, suppose smc0 is the primary network interface for a system that is called tenere. The /etc/hostname.smc0 file could have as its entry an IPv4 address in dotted decimal notation or in CIDR notation, or the host name tenere.


Note –

IPv6 uses the /etc/hostname6.interface file for defining network interfaces. For more information, refer to IPv6 Interface Configuration File.


/etc/nodename File

This file should contain one entry: the host name of the local system. For example, on system timbuktu, the file /etc/nodename would contain the entry timbuktu.

/etc/defaultdomain File

This file should contain one entry: the fully qualified domain name of the administrative domain to which the local host's network belongs. You can supply this name to the Oracle Solaris installation program or edit the file at a later date. For more information on network domains, refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

/etc/defaultrouter File

This file can contain an entry for each router that is directly connected to the network. The entry should be the name for the network interface that functions as a router between networks. The presence of the /etc/defaultrouter file indicates that the system is configured to support static routing.

hosts Database

The hosts database contains the IPv4 addresses and host names of systems on your network. If you use the NIS or DNS name service, or the LDAP directory service, the hosts database is maintained in a database that is designated for host information. For example, on a network that runs NIS, the hosts database is maintained in the hostsbyname file.

If you use local files for the name service, the hosts database is maintained in the /etc/inet/hosts file. This file contains the host names and IPv4 addresses of the primary network interface, other network interfaces that are attached to the system, and any other network addresses that the system must check for.


Note –

For compatibility with BSD-based operating systems, the /etc/hosts file is a symbolic link to /etc/inet/hosts.


/etc/inet/hosts File Format

The /etc/inet/hosts file uses the basic syntax that follows. Refer to the hosts(4) man page for complete syntax information.

IPv4-address hostname [nicknames] [#comment]

IPv4-address

Contains the IPv4 address for each interface that the local host must recognize.

hostname

Contains the host name that is assigned to the system at setup, plus the host names that are assigned to additional network interfaces that the local host must recognize.

[nickname]

Is an optional field that contains a nickname for the host.

[#comment]

Is an optional field for a comment.

Initial /etc/inet/hosts File

When you run the Oracle Solaris installation program on a system, the program configures the initial /etc/inet/hosts file. This file contains the minimum entries that the local host requires. The entries include the loopback address, the host IPv4 address, and the host name.

For example, the Oracle Solaris installation program might create the following /etc/inet/hosts file for system tenere shown in Figure 5–1:


Example 10–1 /etc/inet/hosts File for System tenere


127.0.0.1     localhost         loghost    #loopback address
192.168.200.3   tenere                      #host name

Loopback Address

In Example 10–1, the IPv4 address 127.0.0.1 is the loopback address. The loopback address is the reserved network interface that is used by the local system to allow interprocess communication. This address enables the host to send packets to itself. The ifconfig command uses the loopback address for configuration and testing, as explained in Monitoring the Interface Configuration With the ifconfig Command. Every system on a TCP/IP network must use the IP address 127.0.0.1 for IPv4 loopback on the local host.

Host Name

The IPv4 address 192.168.200.1 and the name tenere are the address and host name of the local system. They are assigned to the system's primary network interface.

Multiple Network Interfaces

Some systems have more than one network interface, because they are either routers or multihomed hosts. Each network interface that is attached to the system requires its own IP address and associated name. During installation, you must configure the primary network interface. If a particular system has multiple interfaces at installation time, the Oracle Solaris installation program also prompts you about these additional interfaces. You can optionally configure one or more additional interfaces at this time, or manually, at a later date.

After the Oracle Solaris installation, you can configure additional interfaces for a router or multihomed host by adding interface information to the systems' /etc/inet/hosts file. For more information on configuring routers and multihomed hosts refer to Configuring an IPv4 Router and Configuring Multihomed Hosts.

Example 10–2 shows the /etc/inet/hosts file for system timbuktu that is shown in Figure 5–1.


Example 10–2 /etc/inet/hosts File for System timbuktu


127.0.0.1        localhost     loghost
192.168.200.70   timbuktu      #This is the local host name
192.168.201.10   timbuktu-201  #Interface to network 192.9.201

With these two interfaces, timbuktu connects networks 192.168.200 and 192.168.201 as a router.

How Name Services Affect the hosts Database

The NIS and DNS name services, and LDAP directory service, maintain host names and addresses on one or more servers. These servers maintain hosts databases that contain information for every host and router (if applicable) on the servers' network. Refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) for more information about these services.

When Local Files Provide the Name Service

On a network that uses local files for the name service, systems that run in local files mode consult their individual /etc/inet/hosts files for IPv4 addresses and host names of other systems on the network. Therefore, these system's /etc/inet/hosts files must contain the following:

Figure 10–1 shows the /etc/inet/hosts file for system tenere. This system runs in local files mode. Notice that the file contains the IPv4 addresses and host names for every system on the 192.9.200 network. The file also contains the IPv4 address and interface name timbuktu-201. This interface connects the 192.9.200 network to the 192.9.201 network.

A system that is configured as a network client uses the local /etc/inet/hosts file for its loopback address and IPv4 address.

Figure 10–1 /etc/inet/hosts File for a System Running in Local Files Mode

Shows what the hosts file might look like for a system
that is running in local files mode.

ipnodes Database


Note –

The ipnodes database is no longer included in releases after Solaris 10 11/06. In these subsequent releases, the IPv6 features of ipnodes migrate into the hosts database.


The /etc/inet/ipnodes file stores both IPv4 and IPv6 addresses. Moreover, you can store IPv4 addresses in either traditional dotted decimal or CIDR notation. This file serves as a local database that associates the names of hosts with their IPv4 and IPv6 addresses. Do 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. For more information on /etc/inet/hosts, refer to hosts Database. See the ipnodes(4) man page for a description of the ipnodes file.

IPv6-enabled applications use the /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-enabled applications use the existing hosts database.


Note –

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



Example 10–3 /etc/inet/ipnodes File

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


#
# Internet IPv6 host table
# with both IPv4 and IPv6 addresses
#
::1     localhost
2001:db8:3b4c:114:a00:20ff:fe78:f37c   farsite.com farsite farsite-v6
fe80::a00:20ff:fe78:f37c     farsite-11.com farsitell
192.168.85.87   				 farsite.com farsite farsite-v4
2001:db8:86c0:32:a00:20ff:fe87:9aba   nearsite.com nearsite nearsite-v6
fe80::a00:20ff:fe87:9aba     nearsite-11.com nearsitell
10.0.0.177  				 nearsite.com nearsite nearsite-v4 loghost

netmasks Database

You need to edit the netmasks database as part of network configuration only if you have set up subnetting on your network. The netmasks database consists of a list of networks and their associated subnet masks.


Note –

When you create subnets, each new network must be a separate physical network. You cannot apply subnetting to a single physical network.


What Is Subnetting?

Subnetting is a method for maximizing the limited 32-bit IPv4 addressing space and reducing the size of the routing tables in a large internetwork. With any address class, subnetting provides a means of allocating a part of the host address space to network addresses, which lets you have more networks. The part of the host address space that is allocated to new network addresses is known as the subnet number.

In addition to making more efficient use of the IPv4 address space, subnetting has several administrative benefits. Routing can become very complicated as the number of networks grows. A small organization, for example, might give each local network a class C number. As the organization grows, the administration of a number of different network numbers could become complicated. A better idea is to allocate a few class B network numbers to each major division in an organization. For example, you could allocate one Class B network to Engineering, one Class B to Operations, and so on. Then, you could divide each class B network into additional networks, using the additional network numbers gained by subnetting. This division can also reduce the amount of routing information that must be communicated among routers.

Creating the Network Mask for IPv4 Addresses

As part of the subnetting process, you need to select a network-wide netmask. The netmask determines how many and which bits in the host address space represent the subnet number and how many and which bits represent the host number. Recall that the complete IPv4 address consists of 32 bits. Depending on the address class, as many as 24 bits and as few as 8 bits can be available for representing the host address space. The netmask is specified in the netmasks database.

If you plan to use subnets, you must determine your netmask before you configure TCP/IP. If you plan to install the operating system as part of network configuration, the Oracle Solaris installation program requests the netmask for your network.

As described in Designing an IPv4 Addressing Scheme, 32-bit IP addresses consist of a network part and a host part. The 32 bits are divided into 4 bytes. Each byte is assigned to either the network number or the host number, depending on the network class.

For example, in a class B IPv4 address, the 2 bytes on the left are assigned to the network number, and the 2 bytes on the right are assigned to the host number. In the class B IPv4 address 172.16.10, you can assign the 2 bytes on the right to hosts.

If you are to implement subnetting, you need to use some of the bits in the bytes that are assigned to the host number to apply to subnet addresses. For example, a 16-bit host address space provides addressing for 65,534 hosts. If you apply the third byte to subnet addresses and the fourth byte to host addresses, you can address up to 254 networks, with up to 254 hosts on each network.

The bits in the host address bytes that are applied to subnet addresses and those applied to host addresses are determined by a subnet mask. Subnet masks are used to select bits from either byte for use as subnet addresses. Although netmask bits must be contiguous, they need not align on byte boundaries.

The netmask can be applied to an IPv4 address by using the bitwise logical AND operator. This operation selects out the network number and subnet number positions of the address.

Netmasks can be explained in terms of their binary representation. You can use a calculator for binary-to-decimal conversion. The following examples show both the decimal and binary forms of the netmask.

If a netmask 255.255.255.0 is applied to the IPv4 address 172.16.41.101, the result is the IPv4 address of 172.16.41.0.

172.16.41.101 & 255.255.255.0 = 172.16.41.0

In binary form, the operation is as follows:

10000001.10010000.00101001.01100101 (IPv4 address)

ANDed with

11111111.11111111.11111111.00000000 (netmask)

Now the system looks for a network number of 172.16.41 instead of a network number of 172.16. If your network has the number 172.16.41, that number is what the system checks for and finds. Because you can assign up to 254 values to the third byte of the IPv4 address space, subnetting lets you create address space for 254 networks, where previously space was available for only one.

If you are providing address space for only two additional networks, you can use the following subnet mask:

255.255.192.0

This netmask provides the following result:

11111111.11111111.1100000.00000000

This result still leaves 14 bits available for host addresses. Because all 0s and 1s are reserved, at least 2 bits must be reserved for the host number.

/etc/inet/netmasks File

If your network runs NIS or LDAP, the servers for these name services maintain netmasks databases. For networks that use local files for the name service, this information is maintained in the /etc/inet/netmasks file.


Note –

For compatibility with BSD-based operating systems, the /etc/netmasks file is a symbolic link to /etc/inet/netmasks.


The following example shows the /etc/inet/netmasks file for a class B network.


Example 10–4 /etc/inet/netmasks File for a Class B Network


 # The netmasks file associates Internet Protocol (IPv4) address
 # masks with IPv4 network numbers.
 #
 # 	network-number	netmask
 #
 # Both the network-number and the netmasks are specified in
 # “decimal dot” notation, e.g:
 #
 #        128.32.0.0   255.255.255.0
 192.168.0.0  255.255.255.0

If the /etc/netmasks file does not exist, create it with a text editor. Use the following syntax:

network-number	netmask-number

Refer to the netmasks(4) man page for complete details.

When creating netmask numbers, type the network number that is assigned by the ISP or Internet Registry (not the subnet number) and the netmask number in /etc/inet/netmasks. Each subnet mask should be on a separate line.

For example:


128.78.0.0	    255.255.248.0

You can also type symbolic names for network numbers in the /etc/inet/hosts file. You can then use these network names instead of the network numbers as parameters to commands.

inetd Internet Services Daemon

The inetd daemon starts up Internet standard services when a system boots, and can restart a service while a system is running. Use the Service Management Facility (SMF) to modify the standard Internet services or to have additional services started by the inetd daemon.

Use the following SMF commands to manage services started by inetd:

svcadm

For administrative actions on a service, such as enabling, disabling, or restarting. For details, refer to the svcadm(1M) man page.

svcs

For querying the status of a service. For details, refer to the svcs(1) man page.

inetadm

For displaying and modifying the properties of a service. For details, refer to the inetadm(1M) man page.

The proto field value in the inetadm profile for a particular service indicates the transport layer protocol on which the service runs. If the service is IPv4-only, the proto field must be specified as tcp, udp, or sctp.

Network Databases and the nsswitch.conf File

The network databases are files that provide information that is needed to configure the network. The network databases follow:

As part of the configuration process, you edit the hosts database and the netmasks database, if your network is subnetted. Two network databases, bootparams and ethers, are used to configure systems as network clients. The remaining databases are used by the operating system and seldom require editing.

Although nsswitch.conf file is not a network database, you need to configure this file along with the relevant network databases. nsswitch.conf specifies which name service to use for a particular system: local files, NIS, DNS, or LDAP.

How Name Services Affect Network Databases

The format of your network database depends on the type of name service you select for your network. For example, the hosts database contains, at least the host name and IPv4 address of the local system and any network interfaces that are directly connected to the local system. However, the hosts database could contain other IPv4 addresses and host names, depending on the type of name service on your network.

The network databases are used as follows:


Note –

DNS boot and data files do not correspond directly to the network databases.


The following figure shows the forms of the hosts database that are used by these name services.

Figure 10–2 Forms of the hosts Database Used by Name Services

This figure shows the various how the DNS, NIS,
NIS+ name services and local files store the hosts database.

The following table lists the network databases and their corresponding local files and NIS maps.


Note –

The ipnodes database is removed from Oracle Solaris releases after Solaris 10 11/06.


Table 10–1 Network Databases and Corresponding Name Service Files

Network Database 

Local Files 

NIS Maps 

hosts

/etc/inet/hosts

hosts.byaddr hosts.byname

ipnodes

/etc/inet/ipnodes

ipnodes.byaddr ipnodes.byname

netmasks

/etc/inet/netmasks

netmasks.byaddr

ethers

/etc/ethers

ethers.byname ethers.byaddr

bootparams

/etc/bootparams

bootparams

protocols

/etc/inet/protocols

protocols.byname protocols.bynumber

services

/etc/inet/services

services.byname

networks

/etc/inet/networks

networks.byaddr networks.byname

This book discusses network databases as they are viewed by networks that use local files for name services.

Refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) for information on network databases correspondences in NIS, DNS, and LDAP.

nsswitch.conf File

The /etc/nsswitch.conf file defines the search order of the network databases. The Oracle Solaris installation program creates a default /etc/nsswitch.conf file for the local system, based on the name service you indicate during the installation process. If you selected the “None” option, indicating local files for name service, the resulting nsswitch.conf file resembles the following example.


Example 10–5 nsswitch.conf for Networks Using Files for Name Service


# /etc/nsswitch.files:
#
# An example file that could be copied over to /etc/nsswitch.conf;
# it does not use any naming service.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file contains "switch.so" as a
# nametoaddr library for "inet" transports.

passwd:          files
group:           files
hosts:           files
networks:        files
protocols:       files
rpc:             files
ethers:          files
netmasks:        files
bootparams:      files
publickey:       files
# At present there isn't a 'files' backend for netgroup; the
# system will figure it out pretty quickly,
# and won't use netgroups at all.
netgroup:        files
automount:       files
aliases:         files
services:        files
sendmailvars:    files

The nsswitch.conf(4) man page describes the file in detail. The basic syntax is shown here:

database name-service-to-search

The database field can list one of many types of databases that are searched by the operating system. For example, the field could indicate a database that affects users, such as passwd or aliases, or a network database. The parameter name-service-to-search can have the values files , nis, or nis+ for the network databases. The hosts database can also have dns as a name service to search. You can also list more than one name service, such as nis+ and files.

In Example 10–5, the only search option that is indicated is files. Therefore, the local system obtains security and automounting information, in addition to network database information, from files that are located in its /etc and /etc/inet directories.

Changing nsswitch.conf

The /etc directory contains the nsswitch.conf file that is created by the Oracle Solaris installation program. This directory also contains template files for the following name services:

If you want to change from one name service to another name service, you can copy the appropriate template to nsswitch.conf. You can also selectively edit the nsswitch.conf file, and change the default name service to search for individual databases.

For example, on a network that runs NIS, you might have to change the nsswitch.conf file on network clients. The search path for the bootparams and ethers databases must list files as the first option, and then nis. The following example shows the correct search paths.


Example 10–6 nsswitch.conf for a Client on a Network Running NIS


# /etc/nsswitch.conf:#
.
.
passwd:        files nis
group:         files nis

# consult /etc "files" only if nis is down.
hosts:         nis    [NOTFOUND=return] files
networks:      nis    [NOTFOUND=return] files
protocols:     nis    [NOTFOUND=return] files
rpc:           nis    [NOTFOUND=return] files
ethers:        files  [NOTFOUND=return] nis
netmasks:      nis    [NOTFOUND=return] files	
bootparams:    files  [NOTFOUND=return] nis
publickey:     nis    
netgroup:      nis

automount:     files nis
aliases:       files nis

# for efficient getservbyname() avoid nis
services:      files nis
sendmailvars:  files

For complete details on the name service switch, refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

bootparams Database

The bootparams database contains information that is used by systems that are configured to boot in network client mode. You need to edit this database if your network has network clients. See Configuring Network Clients for the procedures. The database is built from information that is entered into the /etc/bootparams file.

The bootparams(4) man page contains the complete syntax for this database. Basic syntax is shown here:

system-name file-key-server-name:pathname

For each network client system, the entry might contain the following information: the name of the client, a list of keys, the names of servers, and path names. The first item of each entry is the name of the client system. All items but the first item are optional. An example follows.


Example 10–7 bootparams Database


myclient   root=myserver : /nfsroot/myclient  \
swap=myserver : /nfsswap//myclient \
dump=myserver : /nfsdump/myclient

In this example, the term dump= tells client hosts not to look for a dump file.

Wildcard Entry for bootparams

In most instances, use the wildcard entry when editing the bootparams database to support clients. This entry follows:

*  root=server:/path dump=:

The asterisk (*) wildcard indicates that this entry applies to all clients that are not specifically named within the bootparams database.

ethers Database

The ethers database is built from information that is entered into the /etc/ethers file. This database associates host names to their Media Access Control (MAC) addresses. You need to create an ethers database only if you are running the RARP daemon. That is, you need to create this database if you are configuring network clients.

RARP uses the file to map MAC addresses to IP addresses. If you are running the RARP daemon in.rarpd, you need to set up the ethers file and maintain this file on all hosts that are running the daemon to reflect changes to the network.

The ethers(4) man page contains the complete syntax for this database. The basic syntax is shown here:


MAC-address   hostname   #comment
MAC-address

MAC address of the host

hostname

Official name of the host

#comment

Any note that you want to append to an entry in the file

The equipment manufacturer provides the MAC address. If a system does not display the MAC address during the system booting process, see your hardware manuals for assistance.

When adding entries to the ethers database, ensure that host names correspond to the primary names in the hosts and, for Solaris 10 11/06 and earlier releases, the ipnodes database, not to the nicknames, as follows.


Example 10–8 Entries in the ethers Database


8:0:20:1:40:16  fayoum
8:0:20:1:40:15  nubian 
8:0:20:1:40:7   sahara    # This is a comment
8:0:20:1:40:14  tenere 

Other Network Databases

The remaining network databases seldom need to be edited.

networks database

The networks database associates network names with network numbers, enabling some applications to use and display names rather than numbers. The networks database is based on information in the /etc/inet/networks file. This file contains the names of all networks to which your network connects through routers.

The Oracle Solaris installation program configures the initial networks database. However, if you add a new network to your existing network topology, you must update this database.

The networks(4) man page contains the complete syntax for /etc/inet/networks. The basic format is shown here:


network-name  network-number  nickname(s)  #comment
network-name

Official name for the network

network-number

Number assigned by the ISP or Internet Registry

nickname

Any other name by which the network is known

#comment

Any note that you want to append to an entry in the file

You must maintain the networks file. The netstat program uses the information in this database to produce status tables.

A sample /etc/networks file follows.


Example 10–9 /etc/networks File


#ident	"@(#)networks	1.4	92/07/14 SMI"	/* SVr4.0 1.1	*/
#
# The networks file associates Internet Protocol (IP) network
# numbers with network names. The format of this file is:
#
# 	network-name		 	 network-number		 	 nicnames . . .

# The loopback network is used only for intra-machine communication
loopback		 	 127

#
# Internet networks
#
arpanet     10	   arpa  # Historical
#
# local networks

eng   192.168.9 #engineering
acc   192.168.5 #accounting
prog  192.168.2 #programming

protocols Database

The protocols database lists the TCP/IP protocols that are installed on your system and their protocol numbers. The Oracle Solaris installation program automatically creates the database. This file seldom requires any administration.

The protocols(4) man page describes the syntax of this database. An example of the /etc/inet/protocols file follows.


Example 10–10 /etc/inet/protocols File


#
# Internet (IP) protocols
#
ip    0   IP    # internet protocol, pseudo protocol number
icmp  1   ICMP  # internet control message protocol
tcp   6   TCP   # transmission control protocol
udp  17   UDP   # user datagram protocol

services Database

The services database lists the names of TCP and UDP services and their well-known port numbers. This database is used by programs that call network services. The Oracle Solaris installation automatically creates the services database. Generally, this database does not require any administration.

The services(4) man page contains complete syntax information. An excerpt from a typical /etc/inet/services file follows.


Example 10–11 /etc/inet/services File


#
# Network services
#
echo      7/udp
echo      7/tcp
echo      7/sctp6
discard   9/udp     sink null
discard   11/tcp
daytime   13/udp
daytime   13/tcp
netstat   15/tcp
ftp-data  20/tcp
ftp       21/tcp
telnet    23/tcp
time      37/tcp    timeserver
time      37/udp    timeserver
name      42/udp    nameserver
whois     43/tcp    nickname

Routing Protocols in Oracle Solaris

This section describes two routing protocols supported in Oracle Solaris 10: Routing Information Protocol (RIP) and ICMP Router Discovery (RDISC). RIP and RDISC are both standard TCP/IP protocols. For complete lists of routing protocols available in Oracle Solaris 10, refer to Table 5–1 and Table 5–2.

Routing Information Protocol (RIP)

RIP is implemented by in.routed, the routing daemon, which automatically starts when the system boots. When run on a router with the s option specified, in.routed fills the kernel routing table with a route to every reachable network and advertises “reachability” through all network interfaces.

When run on a host with the q option specified, in.routed extracts routing information but does not advertise reachability. On hosts, routing information can be extracted in two ways:

ICMP Router Discovery (RDISC) Protocol

Hosts use RDISC to obtain routing information from routers. Thus, when hosts are running RDISC, routers must also run another protocol, such as RIP, in order to exchange router information.

RDISC is implemented by in.routed, which should run on both routers and hosts. On hosts, in.routed uses RDISC to discover default routes from routers that advertise themselves through RDISC. On routers, in.routed uses RDISC to advertise default routes to hosts on directly-connected networks. See the in.routed(1M) man page and the gateways(4) man page.

Network Classes


Note –

Class-based network numbers are no longer available from the IANA, though many older networks are still class-based.


This section provides details about IPv4 network classes. Each class uses the 32-bit IPv4 address space differently, providing more or fewer bits for the network part of the address. These classes are class A, class B, and class C.

Class A Network Numbers

A class A network number uses the first 8 bits of the IPv4 address as its “network part.” The remaining 24 bits contain the host part of the IPv4 address, as the following figure illustrates.

Figure 10–3 Byte Assignment in a Class A Address

Diagram shows bits 0-7 is network part and remaining
24 bits are host part of a 32 bit IPv4 Class A address.

The values that are assigned to the first byte of class A network numbers fall within the range 0–127. Consider the IPv4 address 75.4.10.4. The value 75 in the first byte indicates that the host is on a class A network. The remaining bytes, 4.10.4, establish the host address. Only the first byte of a class A number is registered with the IANA. Use of the remaining three bytes is left to the discretion of the owner of the network number. Only 127 class A networks exist. Each one of these numbers can accommodate a maximum of 16,777,214 hosts.

Class B Network Numbers

A class B network number uses 16 bits for the network number and 16 bits for host numbers. The first byte of a class B network number is in the range 128–191. In the number 172.16.50.56, the first two bytes, 172.16, are registered with the IANA, and compose the network address. The last two bytes, 50.56, contain the host address, and are assigned at the discretion of the owner of the network number. The following figure graphically illustrates a class B address.

Figure 10–4 Byte Assignment in a Class B Address

Diagram shows bits 0-15 is network part and remaining
16 bits are host part of a 32 bit IPv4 Class B address.

Class B is typically assigned to organizations with many hosts on their networks.

Class C Network Numbers

Class C network numbers use 24 bits for the network number and 8 bits for host numbers. Class C network numbers are appropriate for networks with few hosts—the maximum being 254. A class C network number occupies the first three bytes of an IPv4 address. Only the fourth byte is assigned at the discretion of the network owners. The following figure graphically represents the bytes in a class C address.

Figure 10–5 Byte Assignment in a Class C Address

Diagram shows bits 0-23 is network part and remaining
8 bits are host part of a 32 bit IPv4 Class C address.

The first byte of a class C network number covers the range 192–223. The second and third bytes each cover the range 1– 255. A typical class C address might be 192.168.2.5. The first three bytes, 192.168.2, form the network number. The final byte in this example, 5, is the host number.

Chapter 11 IPv6 in Depth (Reference)

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

For an overview of IPv6, refer to Chapter 3, Introducing IPv6 (Overview). For tasks on configuring an IPv6-enabled network, refer to Chapter 7, Configuring an IPv6 Network (Tasks).

What's New in IPv6 in Depth

In the Solaris 10 7/07, the /etc/inet/ipnodes file becomes obsolete. Use /etc/inet/ipnodes only for earlier Oracle Solaris 10 releases, as explained in the individual procedures.

IPv6 Addressing Formats Beyond the Basics

Chapter 3, Introducing IPv6 (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, Introducing IPv6 (Overview):

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 11–1 Parts of a 6to4 Site Prefix

This figure shows the format of a 6to4 site prefix and
shows a site prefix example. The cited tables explain the information in the
figure.

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 11–2 Parts of a 6to4 Subnet Prefix

This figure shows the format of a 6to4 prefix and shows
a prefix example. The following context explains the information in the figure.

This table explains the parts of a 6to4 subnet prefix, their respective lengths, and their definitions.

Part 

Length 

Definition 

Prefix 

16 bits 

6to4 prefix label 2002 (0x2002). 

IPv4 address 

32 bits 

Unique IPv4 address that is already configured on the 6to4 interface. For the advertisement, you specify the hexadecimal representation of the IPv4 address, rather than the IPv4 dotted-decimal representation. 

Subnet ID 

16 bits 

Subnet ID, which must be a value that is unique for the link at your 6to4 site. 

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, their lengths and the information they provide.

Address Part 

Length 

Definition 

prefix

16 bits 

2002, which is the 6to4 prefix

IPv4-address

32 bits 

8192:56bb, which is the IPv4 address, in hexadecimal notation, for the 6to4 pseudo-interface that is configured on the 6to4 router

subnet-ID

16 bits 

9258, which is the address of the subnet of which this host is a member

interface-ID

64 bits 

a00:20ff:fea9:4521, which is the interface ID of the host interface that is configured for 6to4

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.

Table 11–1 IPv6 Multicast Address Format

8 bits 

4 bits 

4 bits 

8 bits 

8 bits 

64 bits 

32 bits 

11111111

FLGS

SCOP

Reserved

Plen

Network prefix

Group ID

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

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 11–3 IPv6 Basic Header Format

Diagram shows that the 128 bit IPv6 header consist of
eight fields, including the source and destination addresses.

The following list describes the function of each header field.

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:

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.

Oracle Solaris is dual-stack, meaning that Oracle Solaris 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 11–4 shows how the IPv4 and IPv6 protocols work as a dual-stack throughout the various layers of the Internet protocol suite.

Figure 11–4 Dual-Stack Protocol Architecture

Illustrates IPv4 and IPv6 protocols work as a dual-stack
through the various OSI layers.

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.

Oracle Solaris 10 IPv6 Implementation

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

IPv6 Configuration Files

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

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.

Table 11–2 /etc/inet/ndpd.conf Keywords

Variable 

Description 

ifdefault

Specifies the router behavior for all interfaces. Use the following syntax to set router parameters and corresponding values: 

ifdefault [variable-value]

prefixdefault

Specifies the default behavior for prefix advertisements. Use the following syntax to set router parameters and corresponding values: 

prefixdefault [variable-value]

if

Sets per-interface parameters. Use the following syntax: 

if interface [variable-value]

prefix

Advertises per-interface prefix information. Use the following syntax: 

prefix prefix/length interface [variable-value]

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 11–3 /etc/inet/ndpd.conf Interface Configuration Variables

Variable 

Default 

Definition 

AdvRetransTimer

Specifies the value in the Retrans Timer field in the advertisement messages sent by the router. 

AdvCurHopLimit

Current diameter of the Internet 

Specifies the value to be placed in the current hop limit in the advertisement messages sent by the router. 

AdvDefaultLifetime

3 + MaxRtrAdvInterval

Specifies the default lifetime of the router advertisements. 

AdvLinkMTU

Specifies a maximum transmission unit (MTU) value to be sent by the router. The zero indicates that the router does not specify MTU options. 

AdvManaged Flag

False 

Indicates the value to be placed in the Manage Address Configuration flag in the router advertisement. 

AdvOtherConfigFlag

False 

Indicates the value to be placed in the Other Stateful Configuration flag in the router advertisement. 

AdvReachableTime

Specifies the value in the Reachable Time field in the advertisement messages sent by the router. 

AdvSendAdvertisements

False 

Indicates whether the node should send out advertisements and respond to router solicitations. You need to explicitly set this variable to “TRUE” in the ndpd.conf file to turn on router advertisement functions. For more information, refer to How to Configure an IPv6-Enabled Router.

DupAddrDetect

Transmits

Defines the number of consecutive neighbor solicitation messages that the Neighbor Discovery protocol should send during duplicate address detection of the local node's address. 

MaxRtrAdvInterval

600 seconds 

Specifies the maximum time to wait between sending unsolicited multicast advertisements. 

MinRtrAdvInterval

200 seconds 

Specifies the minimum time to wait between sending unsolicited multicast advertisements. 

StatelessAddrConf

True 

Controls whether the node configures its IPv6 address through stateless address autoconfiguration. If False is declared in ndpd.conf, then the address must be manually configured. For more information, refer to How to Configure a User-Specified IPv6 Token.

TmpAddrsEnabled

False 

Indicates whether a temporary address should be created for all interfaces or for a particular interface of a node. For more information, refer to How to Configure a Temporary Address.

TmpMaxDesyncFactor

600 seconds 

Specifies a random value to be subtracted from the preferred lifetime variable TmpPreferredLifetime when in.ndpd starts. The purpose of the TmpMaxDesyncFactor variable is to prevent all the systems on your network from regenerating their temporary addresses at the same time. TmpMaxDesyncFactor allows you to change the upper bound on that random value.

TmpPreferredLifetime

False 

Sets the preferred lifetime of a temporary address. For more information, refer to How to Configure a Temporary Address.

TmpRegenAdvance

False 

Specifies the lead time in advance of address deprecation for a temporary address. For more information, refer to How to Configure a Temporary Address.

TmpValidLifetime

False 

Sets the valid lifetime for a temporary address. For more information, refer to How to Configure a Temporary Address.

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

Table 11–4 /etc/inet/ndpd.conf Prefix Configuration Variables

Variable 

Default 

Definition 

AdvAutonomousFlag

True 

Specifies the value to be placed in the Autonomous Flag field in the Prefix Information option.  

AdvOnLinkFlag

True 

 

Specifies the value to be placed in the on-link flag (“L-bit”) in the Prefix Information option. 

AdvPreferredExpiration

Not set 

Specifies the preferred expiration date of the prefix. 

AdvPreferredLifetime

604800 seconds 

Specifies the value to be placed in the preferred lifetime in the Prefix Information option.  

AdvValidExpiration

Not set 

Specifies the valid expiration date of the prefix. 

AdvValidLifetime

2592000 seconds 

Specifies the valid lifetime of the prefix that is being configured. 


Example 11–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 Oracle 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 Oracle Solaris installation. You create/etc/hostname6.interface files for the new interfaces. For instructions for manually configuring interfaces, refer to Administering Interfaces in Solaris 10 3/05 or Chapter 6, Administering Network Interfaces (Tasks).

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 11–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 Oracle Solaris with IPv6 enabled, this file contains the contents that are shown in Table 11–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 Oracle 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 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 11–5 IPv6 Address Selection Policy Table

Prefix 

Precedence 

Definition 

::1/128

50 

Loopback 

::/0

40 

Default 

2002::/16

30 

6to4 

::/96

20 

IPv4 Compatible 

::ffff:0:0/96

10 

IPv4 

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:

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 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 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 Oracle Solaris.

-h

Displays help for 6to4relay.

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


Example 11–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 Oracle Solaris implementation of IPv6.


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


Example 11–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 11–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 7, Configuring an IPv6 Network (Tasks) provides IPv6 configuration procedures.


Example 11–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 11–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 11–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 11–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 11–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 11–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.

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

To configure an IPv6 service, you must ensure that the proto field value in the inetadm profile for that service lists the appropriate value:

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.

Considerations When Configuring a Service for IPv6

When you add or modify a service for IPv6, keep in mind the following caveats:

IPv6 Neighbor Discovery Protocol

IPv6 introduces the Neighbor Discovery protocol, as described in RFC 2461, Neighbor Discovery for IP Version 6 (IPv6). For an overview of major Neighbor Discovery features, refer to IPv6 Neighbor Discovery Protocol Overview.

This section discusses the following features of the Neighbor Discovery protocol:

ICMP Messages From Neighbor Discovery

Neighbor Discovery defines five new Internet Control Message Protocol (ICMP) messages. The messages serve the following purposes:

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.

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:

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 11–5 IPv6 Tunneling Mechanism

Illustrates how IPv6 packets that are placed inside IPv4
packets are tunneled through routers that use IPv4.

The Oracle Solaris IPv6 implementation includes two types of tunneling mechanisms:

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 11–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 11–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

Note –

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 11–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 11–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 11–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

Oracle Solaris 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:

The following table describes additional tasks to configure 6to4 tunnels and the resources to obtain additional useful information.

Task or Detail 

For Information 

Tasks for configuring a 6to4 tunnel 

How to Configure a 6to4 Tunnel

6to4-related RFC 

RFC 3056, "Connection of IPv6 Domains via IPv4 Clouds"

Detailed information about the 6to4relay command, which enables support for tunnels to a 6to4 relay router

6to4relay(1M)

6to4 security issues 

Security Considerations for 6to4

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 11–6 Tunnel Between Two 6to4 Sites

The figure shows a 6to4 tunnel, which is described in
the following context.

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 11–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, Oracle Solaris 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 11–7 Tunnel From a 6to4 Site to a 6to4 Relay Router

This figure shows a tunnel between a 6to4 router and
6to4 relay router. The following context further describes the figure.

In Figure 11–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 11–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 Oracle 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 Oracle 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

For Solaris 10 11/06 and previous releases, in addition to the capability of looking up IPv6 addresses through /etc/inet/ipnodes, 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.


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

Note –

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. In Solaris 10 11/06 and previous releases, 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 checks the database that is specified in the hosts entry in the nsswitch.conf file.

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

Diagram shows the relationship between NIS,
NIS+, Files, and DNS database and the nsswitch.conf file.

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

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