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.

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.

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:

The network topology, the layout, and connections of the network
hardware

The number of host systems your network can support

The types of hosts that the network supports

The types of servers that you might need

The type of network media to use: Ethernet, Token Ring, FDDI,
and so on

Whether you need bridges or routers extend this media or connect
the local network to external networks

Whether some systems need separately purchased interfaces
in addition to their built in interfaces

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 type of IP address that you want to use: IPv4 or IPv6

The number of potential systems on your network

The number of systems that are multihomed or routers, which
require an IP address for each interface

Whether to use private addresses on your network

Whether to have a DHCP server that manages pools of IPv4 addresses

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.

A unique network number that is assigned by either an ISP,
an IR, or, for older networks, registered by the IANA. If you plan to use
private addresses, the network numbers you devise must be unique within your
organization.

Unique IPv4 addresses for the interfaces of every system on
the network.

A network mask.

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

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

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.

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.

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.

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

.com – Commercial companies (international
in scope)

.edu – Educational institutions
(international in scope)

.gov – U.S. government agencies

.fr – France

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:

How large is the network?

A single administrative division can handle a single network of several
hundred hosts, all in the same physical location and requiring the same administrative
services. However, sometimes you should establish several administrative subdivisions.
Subdivisions are particularly useful if you have a small network with subnets
and the network is scattered over an extensive geographical area.

Do users on the network have similar
needs?

For example, you might have a network that is confined to a single
building and supports a relatively small number of machines. These machines
are divided among a number of subnetworks. Each subnetwork supports groups
of users with different needs. In this example, you might use an administrative
subdivision for each subnet.

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.

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

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

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

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:

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.

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

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.

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

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.

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:

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

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

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:

Global unicast address

Link-local address

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:

Public topology

Site (private) topology

Interface ID

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

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

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.

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:

Prefix discovery –
Enables nodes to discover the known subnet prefixes that have been allocated
to a link. Nodes use prefixes to distinguish destinations that are on the
local link from those destinations that are only reachable through a router.

Address
resolution – Helps nodes to determine the link-local address
of a neighbor, given only the destinations's IP address.

Next-hop determination – Uses an algorithm to determine the IP address of a packet
recipient one hop that is beyond the local link. The next-hop can be a router
or the destination node.

Neighbor unreachability detection – Aids nodes to determine
if a neighbor is no longer reachable. For both routers and hosts, address
resolution can be repeated.

Duplicate address
detection – Enables a node to determine if an address that
the node wants to use is not already in use.

Redirection – Enables
a router to inform a host of a better first-hop node to use to reach a particular
destination.

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

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:

Creates a link-local address for each interface, which does
not require a router on the link.

Verifies the address's uniqueness on a link, which does not
require a router on the link.

Determines if the global addresses should be obtained through
the stateless mechanism, the stateful mechanism, or both mechanisms. (Requires
a router on the link.)

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:

A manually configured tunnel between two IPv6 networks, over
an IPv4 network. The IPv4 network can be the Internet or a local network within
an enterprise.

A manually configured tunnel between two IPv4 networks, over
an IPv6 network, usually within an enterprise.

A dynamically configured automatic 6to4 tunnel between two
IPv6 networks, over an IPv4 network at an enterprise or over the Internet.

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.

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.

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

Subnet 1 is the internal network backbone 192.168.1.

Subnet 2 is the internal network 192.168.2,
with LDAP, sendmail, and DNS servers.

Subnet 3 is the internal network 192.168.3,
with the enterprise's NFS servers.

Subnet 4 is the internal network 192.168.4,
which contains hosts for the enterprise's employees.

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:

Routers

Firewalls

Servers

Switches

Note –

All procedures in the this Part assume that your equipment, particularly
routers, can 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:

sendmail

NFS

HTTP (Apache 2.x or Orion)

DNS

LDAP

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.

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.

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

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.

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

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:

The ISP from which you purchase IPv6 service allows you to
create a tunnel from your site's boundary router to the ISP network. Figure 4–1 shows such
a tunnel. In such a case, you would run a manual, IPv6 over IPv4 tunnel.

You manage a large, distributed network with IPv4 connectivity.
To connect the distributed sites that use IPv6, you can run an automatic 6to4
tunnel from the edge router of each subnet.

Sometimes, a router in your infrastructure cannot be upgraded
to IPv6. In this case, you can create a manual tunnel over the IPv4 router,
with two IPv6 routers as endpoints.

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:

The same amount of filtering is required for both IPv6 packets
and IPv4 packets.

IPv6 packets are often tunneled through a firewall. Therefore,
you should implement either of the following scenarios:

Have the firewall do content inspection inside the tunnel.

Put an IPv6 firewall with similar rules at the opposite tunnel
endpoint.

Some transition mechanisms exist that use IPv6 over UDP over
IPv4 tunnels. These mechanisms might prove dangerous by short-circuiting the
firewall.

IPv6 nodes are globally reachable from outside the enterprise
network. If your security policy prohibits public access, you must establish
stricter rules for the firewall. For example, consider configuring a stateful
firewall.

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

Preparing an IPv6 Addressing Plan

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.

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

Give servers meaningful and stable interface IDs. One strategy
is to use a sequential numbering scheme for interface IDs. For example, the
internal interface of the LDAP server in Figure 4–1 might become 2001:db8:3c4d:2::2.

Alternatively, if you do not regularly renumber your IPv4
network, consider using the existing IPv4 addresses of the routers and servers
as their interface IDs. In Figure 4–1, suppose Router 1's interface to the DMZ has the IPv4 address 123.456.789.111. You can convert the IPv4 address to hexadecimal and use the result
as the interface ID. The new interface ID would be ::7bc8:156F.

Only use this approach if you own the registered IPv4 address, rather
than having obtained the address from an ISP. If you use an IPv4 address that
was given to you by an ISP, you create a dependency that would create problems
if you change ISPs.

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.

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

The /etc/inet/ipnodes file becomes obsolete.
Use /etc/inet/ipnodes only for earlier Oracle Solaris 10 releases,
as explained in the individual procedures.

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.

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:

Host name of each system

IP address of each system

Domain name to which each system belongs

Default router

IPv4 netmask in use on each system's network

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:

Network configuration servers

NFS servers

Name servers that supply NIS, LDAP, or DNS services

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

RARP – Reverse Address Resolution Protocol (RARP) maps Ethernet
addresses (48 bits) to IPv4 addresses (32 bits), which is the reverse of ARP.
When you run RARP on a network configuration server, hosts that are running
in network client mode obtain their IP addresses and TCP/IP configuration
files from the server. The in.rarpd daemon enables RARP
services. Refer to the in.rarpd(1M) man
page for details.

Bootparams –
The Bootparams protocol supplies parameters for booting that are required
by clients that boot off the network. The rpc.bootparamd daemon
executes these services. Refer to the bootparamd(1M) man page for details.

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

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.

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.

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.

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:

The IP address of each network interface on every system.

The host names of each system on the network. You can type
the host name in a local file or a name service database.

The NIS, LDAP, or DNS domain name in which the system resides,
if applicable.

The default router addresses. You supply this information if you
have a simple network topology with only one router attached to each network.
You also supply this information if your routers do not run routing protocols
such as the Router Discovery Server Protocol (RDISC) or the Router Information
Protocol (RIP). For more information on default routers, refer to Packet Forwarding and Routing on IPv4 Networks See Table 5–1 for a list of routing protocols
supported in Oracle Solaris.

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.

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

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

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.

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

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

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

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.

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:

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

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

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

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.

Create a symbolic link to the directory.

# ln -s /tftpboot/. /tftpboot/tftpboot

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.

Edit the hosts database.

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

Edit the ethers database.

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

Edit the bootparams database.

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

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

# /usr/sbin/inetconv

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.

How to Configure Hosts for Network Client Mode

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

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.

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.

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

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.

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

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

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.

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, nicknamesIP-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.

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

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

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.

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.

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.

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.

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.

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:

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

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.

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

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:

Border routers connect an AS to an external
network, such as the Internet. Border routers interconnect with networks external
to the IGP running on the local AS. A border router can run an EGP, such as
Border Gateway Protocol (BGP), to exchange information with external routers,
for example, the routers at the ISP. In Figure 5–3, the border router's interfaces connect to internal network 10.0.5.0 and to a high-speed router to a service provider.

If you plan to use BGP to connect your AS to the Internet, you
should obtain an autonomous system number (ASN) from the Internet Registry
for your locale. Regional registries, such as the American Registry for Internet
Numbers (ARIN), offer guidelines on how to obtain an ASN. For example, the ARIN Number
Resource Policy Manual contains instructions for getting an ASN for
autonomous systems in the United States and Canada. Alternatively, your ISP
might be able to obtain an ASN for you.

Default routers maintain routing information
about all the systems on the local network. These routers typically run IGPs
such as RIP. In Figure 5–3, Router
1s interfaces are connected to internal network 10.0.5.0 and
internal network 192.168.5. Router 1 also serves as the
default router for 192.168.5. Router 1 maintains routing
information for all systems on 192.168.5 and routes to
other routers, such as the border router. Router 2s interfaces connect to
internal network 10.0.5.0 and internal network 172.20.1.

Packet-forwarding routers forward
packets but do not run routing protocols. This type of router receives packets
from one of its interfaces that is connected to a single network. These packets
are then forwarded through another interface on the router to another local
network. In Figure 5–3, Router
3 is a packet-forwarding router with connections to networks 172.20.1 and 192.168.5.

Multihomed hosts have
two or more interfaces that are connected to the same network segment. A multihomed
host can forward packets, which is the default for all systems that run Oracle Solaris. Figure 5–3 shows a multihomed host with
both interfaces connected to network 192.168.5. For an
example of configuring a multihomed host, refer to Example 5–6.

Configuring an IPv4 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.

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

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

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.

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

Assign an IPv4 address and a netmask to the interface.

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.

# ifconfiginterface IPv4-addressnetmask+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.

(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

Add the host name and
IP address of each interface to the /etc/inet/hosts file.

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.

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.

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

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.

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

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.

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:

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

How to Add a Static Route to the Routing Table

View the current state
of the routing table.

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

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.

-netnetwork-address

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

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

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:

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:

NFS servers, particularly those servers that function as large
data centers, can be attached to more than one network in order to share files
among a large pool of users. These servers do not need to maintain routing
tables.

Database servers can have multiple network interfaces to provide
resources to a large pool of users, just like NFS servers.

Firewall gateways are systems that provide the connection
between a company's network and public networks such as the Internet. Administrators
set up firewalls as a security measure. When configured as a firewall, the
host does not pass packets between the networks that are attached to the host's
interfaces. However, the host can still provide standard TCP/IP services,
such as ssh to authorized users.

Note –

When multihomed hosts have different types
of firewalls on any of their interfaces, take care to avoid unintentional
disruption of the host's packets. This problem arises particularly with stateful
firewalls. One solution might be to configure stateless firewalling. For more
information about firewalls, refer to Firewall Systems in System Administration Guide: Security Services or
the documentation for your third-party firewall.

How to Create a Multihomed Host

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

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.

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.

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.

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

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/defaultrouter172.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.

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

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

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.

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:

Logging of all incoming TCP connections

Adding services that run over a transport layer protocol,
using SCTP as an example

Configuring the TCP wrappers facility for access control

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

How to Log the IP Addresses of All Incoming TCP
Connections

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

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

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

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

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, qfe0 – qfe3. 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:

You want to upgrade the system to become a multihomed host.
For more information about multihomed hosts, refer to Configuring Multihomed Hosts.

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.

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.

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

How 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

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
PPAce123000 = 1000*123 + 0

For example: hostname.ce123000

VLAN logical PPA = 1000 * VID + Device
PPAce11000 = 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.

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:

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.

To add an interface to an IPMP group. For instructions on
configuring an IPMP group, refer to Configuring IPMP Groups

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:

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

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

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.

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

How to Configure a Physical Interface After
System Installation

Before You Begin

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

Ensure that the physical interface to be configured has been
physically installed onto the system. For information about installing separately
purchased NIC hardware, refer to the manufacturer's instructions that accompany
the NIC.

If you have just installed the interface, perform a reconfiguration
boot before proceeding with the next task.

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

(Optional) To make the interface configuration persist across
reboots, perform the following steps:

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.

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.

SPARC: 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.

For link aggregations, you should use the factory-set MAC
addresses of the interfaces in the aggregation configuration.

For IPMP groups, each interface in the group must have a unique
MAC address. These interfaces must use their factory-installed MAC addresses.

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.

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

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.

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.

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.

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.

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.

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:

Legacy interfaces –
These interfaces are DLPI interfaces and GLDv2 interfaces. Some legacy interface
types are eri, qfe, and ce.
When you check interface status with the dladm show-link command,
these interfaces are reported as “legacy.”

Non-VLAN interfaces –
These interfaces are GLDv3 interfaces.

Note –

Currently GLDv3 is supported on the following interface types: bge, xge, and e1000g.

Administering Virtual Local Area Networks

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:

Create a logical division of workgroups.

For example,
suppose all hosts on a floor of a building are connected on one switched-based
local network. You could create a separate VLAN for each workgroup on the
floor.

Enforce differing security policies for the workgroups.

For example, the security needs of a Finance department and an Information
Technologies department are quite different. If systems for both departments
share the same local network, you could create a separate VLAN for each department.
Then, you could enforce the appropriate security policy on a per-VLAN basis.

Split workgroups into manageable broadcast domains.

The
use of VLANs reduces the size of broadcast domains and improves network efficiency.

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

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

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.

How to Plan a VLAN Configuration

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

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:

Increased bandwidth –
The capacity of multiple links is combined into one logical link.

Automatic failover/failback –
Traffic from a failed link is failed over to working links in the aggregation.

Load balancing –
Both inbound and outbound traffic is distributed according to user selected
load-balancing policies, such as source and destination MAC or IP addresses.

Support for redundancy –
Two systems can be configured with parallel aggregations.

Improved administration –
All interfaces are administered as a single unit.

Less drain on the network address
pool – The entire aggregation can be assigned one IP address.

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:

For systems that run an application with distributed heavy
traffic, you can dedicate an aggregation to that application's traffic.

For sites with limited IP address space that nevertheless
require large amounts of bandwidth, you need only one IP address for a large
aggregation of interfaces.

For sites that need to hide the existence of internal interfaces,
the IP address of the aggregation hides its interfaces from external applications.

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

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

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

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:

L2 – Determines the
outgoing link by hashing the MAC (L2) header of each packet

L3 – Determines the
outgoing link by hashing the IP (L3) header of each packet

L4 – Determines the
outgoing link by hashing the TCP, UDP, or other ULP (L4) header of each packet

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:

Off mode – The default
mode for aggregations. LACP packets, which are called LACPDUs are
not generated.

Active mode – The
system generates LACPDUs at regular intervals, which you can specify.

Passive mode – The
system generates an LACPDU only when it receives an LACPDU from the switch.
When both the aggregation and the switch are configured in passive mode, they
cannot exchange LACPDUs.

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:

You must use the dladm command to configure
aggregations.

An interface that has been plumbed cannot become a member
of an aggregation.

Interfaces must be of the GLDv3 type: xge, e1000g, and bge.

All interfaces in the aggregation must run at the same speed
and in full-duplex mode.

Example 6–7 How to Delete an Aggregation

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

If a link aggregation has already been previously created, obtain
that aggregation's key.

# dladm show-aggr

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.

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.

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:

Each interface that was enabled for IPv6 now has an associated /etc/hostname6.interface file, such
as hostname6.dmfe0.

For Solaris 10 11/06 and earlier releases, the /etc/inet/ipnodes file
has been created. After installation, this file typically contains only the
IPv6 and IPv4 loopback addresses.

The /etc/nsswitch.conf file has been
modified to accommodate lookups using IPv6 addresses.

The IPv6 address selection policy table is created. This table
prioritizes the IP address format to use for transmissions over an IPv6-enabled
interface.

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

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

Log in to the prospective IPv6 node as Primary
Administrator or as superuser.

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.

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

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.

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.

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

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:

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.

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.

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.

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

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.

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.

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.

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.

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.

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:

ifinterfaceTmpAddrsEnabled true

(Optional) Specify the valid lifetime
for the temporary address.

ifdefault TmpValidLifetimeduration

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 ifinterface keywords
to specify the valid lifetime for a temporary address of a particular interface.

(Optional) Specify a preferred
lifetime for the temporary address, after which the address is deprecated.

ifinterfaceTmpPreferredLifetimeduration

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.

(Optional) Specify the lead time
in advance of address deprecation, during which the host should generate a
new temporary address.

ifdefault TmpRegenAdvanceduration

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.

Change the configuration of the in.ndpd daemon.

# pkill -HUP in.ndpd
# /usr/lib/inet/in.ndpd

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.

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.

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

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.

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.

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.

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.

(Optional) Make the new IPv6 address
persist across reboots.

Edit or create an /etc/hostname6.interface file for each interface you configured with a token.

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.

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.

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.

How to Enable IPv6 on a Server's Interfaces

Before You Begin

The next procedure assumes the following:

Oracle Solaris 10 is already installed on the server.

You enabled IPv6 on the server's interfaces either during Oracle Solaris installation
or later, using the procedures in Configuring an IPv6 Interface.

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.

On
the server, assume the Primary Administrator role or become superuser.

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

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.

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:

Example 7–8 Entry in the /etc/hostname6.ip6.tun File
for an IPv6 Over IPv6 Tunnel

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

Log in to the local IPv4 tunnel endpoint as Primary Administrator
or as superuser.

Example 7–9 Entry in the /etc/hostname6.ip6.tun for
an IPv4 Over IPv6 Tunnel

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

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.

(Optional) Create additional 6to4 pseudo-interfaces on the router.

Each prospective 6to4 pseudo-interface must have an already configured,
globally unique IPv4 address.

Reboot the 6to4 router.

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:

For example, to advertise 6to4 routing to the subnet that is connected
to interface hme0, replace subnet-interface with hme0.

if hme0 AdvSendAdvertisements 1

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

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.

Add the new 6to4-derived addresses of the nodes to the name service
that is used at the 6to4 site.

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.

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.

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:

Example 7–15 DNS Reverse Zone File

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.

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.

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:

ifconfiginterface [protocol-family]

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

Device names of all interfaces on a system

All IPv4 and, if applicable, all IPv6 addresses that are assigned
to the interfaces

Whether these interfaces are currently configured

The following procedure shows how to use the ifconfig command
to obtain basic configuration information about a system's interfaces.

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

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.

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.

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.

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

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

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.

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.

How to Display Statistics by Protocol

You can use your Oracle Solaris user account to obtain output from
the netstat command.

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.

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

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.

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

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/pinghost [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.

How to Determine if a Remote Host Is
Running

Type the following form of the ping command:

$ pinghostname

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

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

Type the following form of the ping command:

$ ping -shostname

Example 8–13 ping Output for Detecting Packet Dropping

The ping -shostname 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:

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

Assume
the Primary Administrator role, or become superuser, on the local IPv6 node.

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.

How to Find Out the Route to a Remote
Host

Type the following to discover the route to a remote system:

% traceroutedestination-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.

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.

How to Check Packets From All Interfaces

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

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.

How to Capture snoop Output Into
a File

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

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.

Inspect the snoop output captures file.

# snoop -ifilename

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.

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.

How 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 –

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.

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.

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

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.

How to Perform Basic Network Software
Checking

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

Common Problems When Deploying IPv6

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:

Certain applications, even after they are ported to IPv6,
do not turn on IPv6 support by default. You might have to configure these
applications to turn on IPv6.

A server that runs multiple services, some of which are IPv4
only, and others that are both IPv4 and IPv6, can experience problems. Some
clients might need to use both types of services, which leads to confusion
on the server side.

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:

Hire an ISP to provide a second line for IPv6 communications
from your site. This solution is expensive.

Get a virtual ISP. A virtual ISP provides
your site with IPv6 connectivity but no link. Instead, you create a tunnel
from your site, over your IPv4 ISP, to the virtual ISP.

Use a 6to4 tunnel over your ISP to other IPv6 sites. For an
address, use the registered IPv4 address of the 6to4 router as the public
topology part of the IPv6 address.

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:

Though 6to4 relay routers do encapsulate and decapsulate packets,
these routers do not check the data that is contained within the packets.

Address spoofing is a major issue on tunnels to a 6to4 relay
router. For incoming traffic, the 6to4 router is unable to match the IPv4
address of the relay router with the IPv6 address of the source. Therefore,
the address of the IPv6 host can easily be spoofed. The address of the 6to4
relay router can also be spoofed.

By default, no trust mechanism exists between 6to4 routers
and 6to4 relay routers. Thus, a 6to4 router cannot identify whether the 6to4
relay router is to be trusted, or even if it is a legitimate 6to4 relay router.
A trust relationship between the 6to4 site and the IPv6 destination must exist,
or both sites leave themselves open to possible attacks.

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:

Your 6to4 site intends to communicate with a private, trusted
IPv6 network. For example, you might enable 6to4 relay router support on a
campus network that consists of isolated 6to4 sites and native IPv6 sites.

Your 6to4 site has a compelling business reason to communicate
with certain native IPv6 hosts.

You have implemented the checks and trust models that are
suggested in the Internet Draft, Security Considerations for 6to4.

Known Issues With a 6to4 Router

The
following known bugs affect 6to4 configuration:

4709338 – Need a RIPng implementation which recognizes
static routes

4152864 – Configuring two tunnels with the same tsrc/tdst
pair works

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.

Add the 2002::/16static route to the routing
tables of all intrasite routers within the 6to4 site.

Use a routing protocol other than RIPng on the 6to4 site's
internal router.

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 –

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.

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:

/etc/hostname.interface file

/etc/nodename file

/etc/defaultdomain file

/etc/defaultrouter file (optional)

hosts database

In Solaris 10 11/06 and earlier releases, ipnodes database

netmasks database (optional)

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.

/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

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.

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:

Loopback address

IPv4 address and host name of the local system (primary network
interface)

IPv4 address and host name of additional network interfaces
that are attached to this system, if applicable

IPv4 addresses and host names of all hosts on the local network

IPv4 addresses and host names of any routers that this system
must know about, if applicable

IPv4 address of any system your system wants to refer to by
its host name

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

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.

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.

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:

hosts

netmasks

ethers database

bootparams

protocols

services

networks

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:

Networks that use local
files for their name service rely on files in the /etc/inet and /etc directories.

NIS uses databases that are called NIS maps.

DNS uses records with
host information.

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

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.

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:

nsswitch.files

nsswitch.nis

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.

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

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

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.

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.

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.

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:

Do not specify the S flag (capital “S”: “Space-saving
mode”). in.routed builds a full routing table exactly
as it does on a router.

Specify the S flag. in.routed creates a minimal kernel table, containing a single default route
for each available router.

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

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

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

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.

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

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

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.

11111111 – Identifies the address
as a multicast address.

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

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

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

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

Reserved - Reserved value of zero.

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

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

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

The following list describes the function of each header field.

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

Traffic class – 8-bit
traffic class field.

Flow label – 20-bit
field.

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

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

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

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

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

IPv6 Extension Headers

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

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

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

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

Dual-Stack Protocols

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

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

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:

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

0

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

0

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

0

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

1

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.

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.

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.

Example 11–2 IPv6 Interface Configuration Files

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

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:

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

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

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

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

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

6to4relay Command

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

Because the use of relay routers is insecure, tunneling to a relay router
is disabled by default in 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.

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

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

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.

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.

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.

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.

-pn

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:

For a service that handles both IPv4 and IPv6 requests, choose tcp6, udp6, or sctp. A proto value of tcp6, udp6, or sctp6 causes inetd to pass on an IPv6 socket
to the server. The server contains an IPv4-mapped address in case a IPv4
client has a request.

For a service that handles only IPv6 requests, choose tcp6only or udp6only. With either of these values for proto, inetd passes the server an IPv6 socket.

If you replace an Oracle Solaris command with another implementation,
you must verify that the implementation of that service supports IPv6. If
the implementation does not support IPv6, then you must specify the proto value as either tcp, udp,
or sctp.

Here is a profile that results from running inetadm for
an echo service manifest that supports both IPv4 and IPv6
and runs over SCTP:

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:

ICMP Messages From Neighbor Discovery

Neighbor Discovery defines five new Internet Control Message Protocol
(ICMP) messages. The messages serve the following purposes:

Router solicitation –
When an interface becomes enabled, hosts can send router solicitation messages.
The solicitations request routers to generate router advertisements immediately,
rather than at their next scheduled time.

Router advertisement – Routers advertise their presence, various link parameters,
and various Internet parameters. Routers advertise either periodically, or
in response to a router solicitation message. Router advertisements contain
prefixes that are used for on-link determination or address configuration,
a suggested hop-limit value, and so on.

Neighbor solicitation – Nodes send neighbor solicitation messages to determine
the link-layer address of a neighbor. Neighbor solicitation messages are also
sent to verify that a neighbor is still reachable by a cached link-layer address.
Neighbor solicitations are also used for duplicate address detection.

Neighbor advertisement –
A node sends neighbor advertisement messages in response to a neighbor solicitation
message. The node can also send unsolicited neighbor advertisements to announce
a link-layer address change.

Redirect – Routers use
redirect messages to inform hosts of a better first hop for a destination,
or that the destination is on the same link.

Autoconfiguration Process

This section
provides an overview of the typical steps that are performed by an interface
during autoconfiguration. Autoconfiguration is performed only on multicast-capable
links.

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

The node begins the autoconfiguration process by generating
a link-local address for the interface.

The link-local address
is formed from the Media Access Control (MAC) address of the interface.

The node sends a neighbor solicitation message that contains
the tentative link-local address as the target.

The purpose of
the message is to verify that the prospective address is not already in use
by another node on the link. After verification, the link-local address can
be assigned to an interface.

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

If another node is also attempting to use the same address,
the node also sends a neighbor solicitation for the target.

The
number of neighbor solicitation transmissions or retransmissions, and the
delay between consecutive solicitations, are link specific. You can set these
parameters, if necessary.

If a node determines that its prospective link-local address
is not unique, autoconfiguration stops. At that point, you must manually configure
the link-local address of the interface.

To simplify recovery,
you can supply an alternate interface ID that overrides the default identifier.
Then, the autoconfiguration mechanism can resume by using the new, presumably
unique, interface ID.

When a node determines that its prospective link-local address
is unique, the node assigns the address to the interface.

At this
point, the node has IP-level connectivity with neighboring nodes. The remaining
autoconfiguration steps are performed only by hosts.

Obtaining a Router Advertisement

The next phase of autoconfiguration involves obtaining
a router advertisement or determining that no routers are present. If routers
are present, the routers send router advertisements that specify what type
of autoconfiguration a host should perform.

Routers send router advertisements periodically. However, the
delay between successive advertisements is generally longer than a host that
performs autoconfiguration can wait. To quickly obtain an advertisement, a
host sends one or more router solicitations to the all-routers multicast group.

Prefix Configuration Variables

Router
advertisements also contain prefix variables with information that stateless
address autoconfiguration uses to generate prefixes. The Stateless Address
Autoconfiguration field in router advertisements are processed independently.
One option field that contains prefix information, the Address Autoconfiguration
flag, indicates whether the option even applies to stateless autoconfiguration.
If the option field does apply, additional option fields contain a subnet
prefix with lifetime values. These values indicate the length of time that
addresses created from the prefix remain preferred and valid.

Because routers periodically generate router advertisements, hosts continually
receive new advertisements. IPv6-enabled hosts process the information that
is contained in each advertisement. Hosts add to the information. They also
refresh the information that is received in previous advertisements.

Address Uniqueness

For security reasons,
all addresses must be tested for uniqueness prior to their assignment to an
interface. The situation is different for addresses that are created through
stateless autoconfiguration. The uniqueness of an address is determined primarily
by the portion of the address that is formed from an interface ID. Thus,
if a node has already verified the uniqueness of a link-local address, additional
addresses need not be tested individually. The addresses must be created from
the same interface ID. In contrast, all addresses that are obtained manually
should be tested individually for uniqueness. System administrators at some
sites believe that the overhead of performing duplicate address detection
outweighs its benefits. For these sites, the use of duplicate address detection
can be disabled by setting a per-interface configuration flag.

To accelerate the autoconfiguration process, a host can generate its
link-local address, and verify its uniqueness, while the host waits for a
router advertisement. A router might delay a response to a router solicitation
for a few seconds. Consequently, the total time necessary to complete autoconfiguration
can be significantly longer if the two steps are done serially.

Neighbor Solicitation and Unreachability

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

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

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

Duplicate Address Detection Algorithm

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

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

Proxy Advertisements

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

Inbound Load Balancing

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

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

Link-Local Address Change

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

Comparison of Neighbor Discovery to ARP and
Related IPv4 Protocols

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

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

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

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

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

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

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

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

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

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

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

IPv6 Routing

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

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

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

Host mobility, route to current location

Auto-readdressing, route to new address

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

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

Router Advertisement

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

Router Advertisement Prefixes

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

Router 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

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

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:

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:

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:

Topology of a 6to4 tunnel

6to4 addressing, including the format of the advertisement

Description of the packet flow across a 6to4 tunnel

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

Points to consider before you configure 6to4 relay router
support

The following table describes additional tasks to configure 6to4 tunnels
and the resources to obtain additional useful information.

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

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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

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.