This part contains tasks and conceptual information for configuring, administering, and troubleshooting TCP/IP networks.
This chapter introduces the Solaris implementation of the TCP/IP network protocol suite. The information is intended for system and network administrators who are unfamiliar with basic TCP/IP concepts. The remaining parts of this book assume that you are familiar with these concepts.
This chapter contains the following information:
Starting with Solaris Express Developer Edition 9/07, the Mobile IP feature is no longer available in the Solaris Express Developer's releases. See the Solaris Express Developer Edition 9/07 Release Notes for more information.
This section presents an in-depth introduction to the protocols that are included in TCP/IP. Although the information is conceptual, you should learn the names of the protocols. You should also learn what each protocol does.
“TCP/IP” is the acronym that is commonly used for the set of network protocols that compose the Internet Protocol suite. Many texts use the term “Internet” to describe both the protocol suite and the global wide area network. In this book, “TCP/IP” refers specifically to the Internet protocol suite. “Internet” refers to the wide area network and the bodies that govern the Internet.
To interconnect your TCP/IP network with other networks, you must obtain a unique IP address for your network. At the time of this writing, you obtain this address from an Internet service provider (ISP).
If hosts on your network are to participate in the Internet Domain Name System (DNS), you must obtain and register a unique domain name. The InterNIC coordinates the registration of domain names through a group of worldwide registries. For more information on DNS, refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
Most network protocol suites are structured as a series of layers, sometimes collectively referred to as a protocol stack. Each layer is designed for a specific purpose. Each layer exists on both the sending and receiving systems. A specific layer on one system sends or receives exactly the same object that another system's peer process sends or receives. These activities occur independently from activities in layers above or below the layer under consideration. In essence, each layer on a system acts independently of other layers on the same system. Each layer acts in parallel with the same layer on other systems.
Most network protocol suites are structured in layers. The International Organization for Standardization (ISO) designed the Open Systems Interconnection (OSI) Reference Model that uses structured layers. The OSI model describes a structure with seven layers for network activities. One or more protocols is associated with each layer. The layers represent data transfer operations that are common to all types of data transfers among cooperating networks.
The OSI model lists the protocol layers from the top (layer 7) to the bottom (layer 1). The following table shows the model.
Table 1–1 Open Systems Interconnection Reference Model
Layer No. |
Layer Name |
Description |
---|---|---|
7 |
Consists of standard communication services and applications that everyone can use. |
|
6 |
Ensures that information is delivered to the receiving system in a form that the system can understand. |
|
5 |
Manages the connections and terminations between cooperating systems. |
|
4 |
Manages the transfer of data. Also assures that the received data are identical to the transmitted data. |
|
3 |
Manages data addressing and delivery between networks. |
|
2 |
Handles the transfer of data across the network media. |
|
1 |
Defines the characteristics of the network hardware. |
The OSI model defines conceptual operations that are not unique to any particular network protocol suite. For example, the OSI network protocol suite implements all seven layers of the OSI model. TCP/IP uses some of OSI model layers. TCP/IP also combines other layers. Other network protocols, such as SNA, add an eighth layer.
The OSI model describes idealized network communications with a family of protocols. TCP/IP does not directly correspond to this model. TCP/IP either combines several OSI layers into a single layer, or does not use certain layers at all. The following table shows the layers of the Solaris implementation of TCP/IP. The table lists the layers from the topmost layer (application) to the bottommost layer (physical network).
Table 1–2 TCP/IP Protocol Stack
OSI Ref. Layer No. |
OSI Layer Equivalent |
TCP/IP Layer |
TCP/IP Protocol Examples |
---|---|---|---|
5,6,7 |
Application, session, presentation |
NFS, NIS, DNS, LDAP, telnet, ftp, rlogin, rsh, rcp, RIP, RDISC, SNMP, and others |
|
4 |
Transport |
TCP, UDP, SCTP |
|
3 |
Network |
IPv4, IPv6, ARP, ICMP |
|
2 |
Data link |
PPP, IEEE 802.2 |
|
1 |
Physical |
Ethernet (IEEE 802.3), Token Ring, RS-232, FDDI, and others |
The table shows the TCP/IP protocol layers and the OSI model equivalents. Also shown are examples of the protocols that are available at each level of the TCP/IP protocol stack. Each system that is involved in a communication transaction runs a unique implementation of the protocol stack.
The physical network layer specifies the characteristics of the hardware to be used for the network. For example, physical network layer specifies the physical characteristics of the communications media. The physical layer of TCP/IP describes hardware standards such as IEEE 802.3, the specification for Ethernet network media, and RS-232, the specification for standard pin connectors.
The data-link layer identifies the network protocol type of the packet, in this instance TCP/IP. The data-link layer also provides error control and “framing.” Examples of data-link layer protocols are Ethernet IEEE 802.2 framing and Point-to-Point Protocol (PPP) framing.
The Internet layer, also known as the network layer or IP layer, accepts and delivers packets for the network. This layer includes the powerful Internet Protocol (IP), the Address Resolution Protocol (ARP), and the Internet Control Message Protocol (ICMP).
The IP protocol and its associated routing protocols are possibly the most significant of the entire TCP/IP suite. IP is responsible for the following:
IP addressing – The IP addressing conventions are part of the IP protocol. Designing an IPv4 Addressing Scheme introduces IPv4 addressing and IPv6 Addressing Overview introduces IPv6 addressing.
Host-to-host communications – IP determines the path a packet must take, based on the receiving system's IP address.
Packet formatting – IP assembles packets into units that are known as datagrams. Datagrams are fully described in Internet Layer: Where Packets Are Prepared for Delivery.
Fragmentation – If a packet is too large for transmission over the network media, IP on the sending system breaks the packet into smaller fragments. IP on the receiving system then reconstructs the fragments into the original packet.
The Solaris OS supports both IPv4 and IPv6 addressing formats, which are described in this book. To avoid confusion when addressing the Internet Protocol, one of the following conventions is used:
When the term “IP” is used in a description, the description applies to both IPv4 and IPv6.
When the term “IPv4” is used in a description, the description applies only to IPv4.
When the term “IPv6” is used in a description, the description applies only to IPv6.
The Address Resolution Protocol (ARP) conceptually exists between the data-link and Internet layers. ARP assists IP in directing datagrams to the appropriate receiving system by mapping Ethernet addresses (48 bits long) to known IP addresses (32 bits long).
The Internet Control Message Protocol (ICMP) detects and reports network error conditions. ICMP reports on the following:
Dropped packets – Packets that arrive too fast to be processed
Connectivity failure – A destination system cannot be reached
Redirection – Redirecting a sending system to use another router
Chapter 7, Administering a TCP/IP Network (Tasks) contains more information on the Solaris OS commands that use ICMP for error detection.
The TCP/IP transport layer ensures that packets arrive in sequence and without error, by swapping acknowledgments of data reception, and retransmitting lost packets. This type of communication is known as end-to-end. Transport layer protocols at this level are Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Stream Control Transmission Protocol (SCTP). TCP and SCTP provide reliable, end-to-end service. UDP provides unreliable datagram service.
TCP enables applications to communicate with each other as though they were connected by a physical circuit. TCP sends data in a form that appears to be transmitted in a character-by-character fashion, rather than as discrete packets. This transmission consists of the following:
Starting point, which opens the connection
Entire transmission in byte order
Ending point, which closes the connection.
TCP attaches a header onto the transmitted data. This header contains many parameters that help processes on the sending system connect to peer processes on the receiving system.
TCP confirms that a packet has reached its destination by establishing an end-to-end connection between sending and receiving hosts. TCP is therefore considered a “reliable, connection-oriented” protocol.
SCTP is a reliable, connection-oriented transport layer protocol that provides the same services to applications that are available from TCP. Moreover, SCTP can support connections between systems that have more than one address, or multihomed. The SCTP connection between sending and receiving system is called an association. Data in the association is organized in chunks. Because SCTP supports multihoming, certain applications, particularly applications used by the telecommunications industry, need to run over SCTP, rather than TCP.
UDP provides datagram delivery service. UDP does not verify connections between receiving and sending hosts. Because UDP eliminates the processes of establishing and verifying connections, applications that send small amounts of data use UDP.
The application layer defines standard Internet services and network applications that anyone can use. These services work with the transport layer to send and receive data. Many application layer protocols exist. The following list shows examples of application layer protocols:
Standard TCP/IP services such as the ftp, tftp, and telnet commands
UNIX “r” commands, such as rlogin and rsh
Name services, such as NIS and the domain name system (DNS)
Directory services (LDAP)
File services, such as the NFS service
Simple Network Management Protocol (SNMP), which enables network management
Router Discovery Server protocol (RDISC) and Routing Information Protocol (RIP) routing protocols
FTP and Anonymous FTP – The File Transfer Protocol (FTP) transfers files to and from a remote network. The protocol includes the ftp command and the in.ftpd daemon. FTP enables a user to specify the name of the remote host and file transfer command options on the local host's command line. The in.ftpd daemon on the remote host then handles the requests from the local host. Unlike rcp, ftp works even when the remote computer does not run a UNIX based operating system. A user must log in to the remote system to make an ftp connection, unless the remote system has been configured to allow anonymous FTP.
You can obtain an enormous amount of material from anonymous FTP servers that are connected to the Internet. Universities and other institutions set up these servers to offer software, research papers, and other information to the public domain. When you log in to this type of server, you use the login name anonymous, hence the term “anonymous FTP server.”
Using anonymous FTP and setting up anonymous FTP servers is outside the scope of this manual. However, many books, such as The Whole Internet User's Guide & Catalog, discuss anonymous FTP in detail. Instructions for using FTP are in System Administration Guide: Network Services. The ftp(1) man page describes all ftp command options that are invoked through the command interpreter. The ftpd(1M) man page describes the services that are provided by the in.ftpd daemon.
Telnet – The Telnet protocol enables terminals and terminal-oriented processes to communicate on a network that runs TCP/IP. This protocol is implemented as the telnet program on local systems and the in.telnetd daemon on remote machines. Telnet provides a user interface through which two hosts can communicate on a character-by-character or line-by-line basis. Telnet includes a set of commands that are fully documented in the telnet(1) man page.
TFTP – The Trivial File Transfer Protocol (tftp) provides functions that are similar to ftp, but the protocol does not establish ftp's interactive connection. As a result, users cannot list the contents of a directory or change directories. A user must know the full name of the file to be copied. The tftp(1)man page describes the tftp command set.
The UNIX “r” commands enable users to issue commands on their local machines that run on the remote host. These commands include the following:
rcp
rlogin
rsh
Instructions for using these commands are in the rcp(1), rlogin(1), and rsh(1) man pages.
The Solaris OS provides the following name services:
DNS – The domain name system (DNS) is the name service provided by the Internet for TCP/IP networks. DNS provides host names to the IP address service. DNS also serves as a database for mail administration. For a complete description of this service, see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP). See also the resolver(3RESOLV) man page.
/etc files – The original host-based UNIX name system was developed for standalone UNIX machines and then adapted for network use. Many old UNIX operating systems and computers still use this system, but it is not well suited for large complex networks.
NIS – Network Information Service (NIS) was developed independently of DNS and has a slightly different focus. Whereas DNS focuses on making communication simpler by using machine names instead of numerical IP addresses, NIS focuses on making network administration more manageable by providing centralized control over a variety of network information. NIS stores information about machine names and addresses, users, the network itself, and network services. NIS name space information is stored in NIS maps. For more information on NIS Architecture and NIS Administration, see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
The Solaris OS supports LDAP (Lightweight Directory Access Protocol) in conjunction with the Sun Open Net Environment (Sun ONE) Directory Server, as well as other LDAP directory servers. The distinction between a name service and a directory service is in the differing extent of functionality. A directory service provides the same functionality of a naming service, but provides additional functionalities as well. See System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
The NFS application layer protocol provides file services for the Solaris OS. You can find complete information about the NFS service in System Administration Guide: Network Services.
The Simple Network Management Protocol (SNMP) enables you to view the layout of your network and the status of key machines. SNMP also enables you to obtain complex network statistics from software that is based on a graphical user interface (GUI). Many companies offer network management packages that implement SNMP.
The Routing Information Protocol (RIP) and the Router Discovery Server Protocol (RDISC) are two available routing protocols for TCP/IP networks. For complete lists of available routing protocols for the Solaris 10 OS, refer to Table 5–1 and Table 5–2.
When a user issues a command that uses a TCP/IP application layer protocol, a series of events is initiated. The user's command or message passes through the TCP/IP protocol stack on the local system. Then, the command or message passes across the network media to the protocols on the remote system. The protocols at each layer on the sending host add information to the original data.
Protocols on each layer of the sending host also interact with their peers on the receiving host. Figure 1–1 shows this interaction.
The packet is the basic unit of information that is transferred across a network. The basic packet consists of a header with the sending and receiving systems' addresses, and a body, or payload, with the data to be transferred. As the packet travels through the TCP/IP protocol stack, the protocols at each layer either add or remove fields from the basic header. When a protocol on the sending system adds data to the packet header, the process is called data encapsulation. Moreover, each layer has a different term for the altered packet, as shown in the following figure.
This section summarizes the life cycle of a packet. The life cycle starts when you issue a command or send a message. The life cycle finishes when the appropriate application on the receiving system receives the packet.
The packet's history begins when a user on one system sends a message or issues a command that must access a remote system. The application protocol formats the packet so that the appropriate transport layer protocol, TCP or UDP, can handle the packet.
Suppose the user issues an rlogin command to log in to the remote system, as shown in Figure 1–1. The rlogin command uses the TCP transport layer protocol. TCP expects to receive data in the form of a stream of bytes that contain the information in the command. Therefore, rlogin sends this data as a TCP stream.
When the data arrives at the transport layer, the protocols at the layer start the process of data encapsulation. The transport layer encapsulates the application data into transport protocol data units.
The transport layer protocol creates a virtual flow of data between the sending and receiving application, differentiated by the transport port number. The port number identifies a port, a dedicated location in memory for receiving or sending data. In addition, the transport protocol layer might provide other services, such as reliable, in order data delivery. The end result depends on whether TCP, SCTP, or UDP handles the information.
TCP is often called a “connection-oriented” protocol because TCP ensures the successful delivery of data to the receiving host. Figure 1–1 shows how the TCP protocol receives the stream from the rlogin command. TCP then divides the data that is received from the application layer into segments and attaches a header to each segment.
Segment headers contain sending and receiving ports, segment ordering information, and a data field that is known as a checksum. The TCP protocols on both hosts use the checksum data to determine if the data transfers without error.
TCP uses segments to determine whether the receiving system is ready to receive the data. When the sending TCP wants to establish connections, TCP sends a segment that is called a SYN to the TCP protocol on the receiving host. The receiving TCP returns a segment that is called an ACK to acknowledge the successful receipt of the segment. The sending TCP sends another ACK segment, then proceeds to send the data. This exchange of control information is referred to as a three-way handshake.
UDP is a “connectionless” protocol. Unlike TCP, UDP does not check that data arrived at the receiving host. Instead, UDP formats the message that is received from the application layer into UDP packets. UDP attaches a header to each packet. The header contains the sending and receiving ports, a field with the length of the packet, and a checksum.
The sending UDP process attempts to send the packet to its peer UDP process on the receiving host. The application layer determines whether the receiving UDP process acknowledges the reception of the packet. UDP requires no notification of receipt. UDP does not use the three-way handshake.
The transport protocols TCP, UDP, and SCTP pass their segments and packets down to the Internet layer, where the IP protocol handles the segments and packets. IP prepares them for delivery by formatting them into units called IP datagrams. IP then determines the IP addresses for the datagrams, so that they can be delivered effectively to the receiving host.
IP attaches an IP header to the segment or packet's header, in addition to the information that is added by TCP or UDP. Information in the IP header includes the IP addresses of the sending and receiving hosts, the datagram length, and the datagram sequence order. This information is provided if the datagram exceeds the allowable byte size for network packets and must be fragmented.
Data-link layer protocols, such as PPP, format the IP datagram into a frame. These protocols attach a third header and a footer to “frame” the datagram. The frame header includes a cyclic redundancy check (CRC) field that checks for errors as the frame travels over the network media. Then, the data-link layer passes the frame to the physical layer.
The physical network layer on the sending host receives the frames and converts the IP addresses into the hardware addresses appropriate to the network media. The physical network layer then sends the frame out over the network media.
When the packet arrives on the receiving host, the packet travels through the TCP/IP protocol stack in the reverse order from which it was sent. Figure 1–1 illustrates this path. Moreover, each protocol on the receiving host strips off header information that is attached to the packet by its peer on the sending host. The following process occurs:
The physical network layer receives the packet in its frame form. The physical network layer computes the CRC of the packet, then sends the frame to the data link layer.
The data-link layer verifies that the CRC for the frame is correct and strips off the frame header and the CRC. Finally, the data-link protocol sends the frame to the Internet layer.
The Internet layer reads information in the header to identify the transmission. Then, the Internet layer determines if the packet is a fragment. If the transmission is fragmented, IP reassembles the fragments into the original datagram. IP then strips off the IP header and passes the datagram on to transport layer protocols.
The transport layer (TCP, SCTP, and UDP) reads the header to determine which application layer protocol must receive the data. Then, TCP, SCTP, or UDP strips off its related header. TCP, SCTP, or UDP sends the message or stream to the receiving application.
The application layer receives the message. The application layer then performs the operation that the sending host requested.
TCP/IP provides internal trace support by logging TCP communication when an RST packet terminates a connection. When an RST packet is transmitted or received, information on as many as 10 packets, which were just transmitted, is logged with the connection information.
Information about TCP/IP and the Internet is widely available. If you require specific information that is not covered in this text, you can probably find what you need in the sources cited next.
Many trade books about TCP/IP and the Internet are available from your local library or computer bookstore. The following two books are considered the classic texts on TCP/IP:
Craig Hunt. TCP/IP Network Administration – This book contains some theory and much practical information for managing a heterogeneous TCP/IP network.
W. Richard Stevens. TCP/IP Illustrated, Volume I – This book is an in-depth explanation of the TCP/IP protocols. This book is ideal for network administrators who require a technical background in TCP/IP and for network programmers.
The Internet has a wealth of web sites and user groups that are devoted to TCP/IP protocols and their administration. Many manufacturers, including Sun Microsystems, offer web-based resources for general TCP/IP information. The following are helpful web resources for TCP/IP information and general system administration information.
Web Site |
Description |
---|---|
The IETF is the body responsible for the architecture and governance of the Internet. The IETF web site contains information about the various activities of this organization. The site also includes links to the major publications of the IETF. |
|
BigAdmin provides information for administering Sun computers. The site offers FAQs, resources, discussions, links to documentation, and other materials that pertain to Solaris OS administration, including networking. |
The Internet Engineering Task Force (IETF) working groups publish standards documents that are known as Requests for Comments (RFCs). Standards that are under development are published in Internet Drafts. The Internet Architecture Board (IAB) must approve all RFCs before they are placed in the public domain. Typically RFCs and Internet drafts are directed to developers and other highly technical readers. However, a number of RFCs that deal with TCP/IP topics contain valuable information for system administrators. These RFCs are cited in various places throughout this book.
Generally, For Your Information (FYI) documents appear as a subset of the RFCs. FYIs contain information that does not deal with Internet standards. FYIs contain Internet information of a more general nature. For example, FYI documents include a bibliography that list introductory TCP/IP books and papers. FYI documents provide an exhaustive compendium of Internet-related software tools. Finally, FYI documents include a glossary of Internet and general networking terms.
You will find references to relevant RFCs throughout this guide and other books in the Solaris System Administrator Collection.
This chapter describes the issues you must resolve in order to create your network in an organized, cost-effective manner. After you resolve these issues, you can devise a network plan as you configure and administer your network in the future.
This chapter contains the following information:
For tasks for configuring a network, refer to Chapter 5, Configuring TCP/IP Network Services and IPv4 Addressing (Tasks).
Task |
Description |
For Information |
---|---|---|
1. Plan your hardware requirements and network topology |
Determine the types of equipment that you need and the layout of this equipment at your site. |
|
2. Obtain a registered IP address for your network |
Your network must have a unique IP address if you plan to communicate outside your local network, for example, over the Internet. |
Refer to Obtaining Your Network's IP Number. |
3. Devise an IP addressing scheme for your systems, based on your IPv4 network prefix or IPv6 site prefix. |
Determine how addresses are to be deployed at your site. |
Refer to Designing an IPv4 Addressing Scheme or refer to Preparing an IPv6 Addressing Plan. |
4. Create a list that contains the IP addresses and host names of all machines on your network. |
Use the list to build network databases |
Refer to Network Databases |
5. Determine which name service to use on your network. |
Decide whether to use NIS, LDAP, DNS, or the network databases in the local /etc directory. | |
6. Establish administrative subdivisions, if appropriate for your network |
Decide if your site requires that you divide your network into administrative subdivisions |
Refer to Administrative Subdivisions |
7. Determine where to place routers in the network design. |
If your network is large enough to require routers, create a network topology that supports them. |
Refer to Planning for Routers on Your Network |
8. If required, design a strategy for subnets. |
You might need to create subnets for administering your IP address space or to make more IP addresses available for users. |
For IPv4 subnet planning, refer to What Is Subnetting? For IPv6 subnet planning, refer to Creating a Numbering Scheme for Subnets |
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.
How you plan the network hardware is outside the scope of this manual. For assistance, refer to the manuals that come with your hardware.
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.
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.
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.
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 Solaris DHCP service to manage your site's IP addresses, or a portion of the addresses. For more information, refer to Chapter 11, About Solaris DHCP (Overview).
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. The Solaris OS 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.
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.
Private IPv4 addresses are also reserved for documentation purposes. The examples in this book use private IPv4 addresses and the reserved IPv6 documentation prefix.
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.
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.
For IPv6 address planning information, refer to Preparing an IPv6 Addressing Plan.
This section gives an overview IPv4 addressing to aid you in designing an IPv4 addressing plan. For information on IPv6 addresses, see IPv6 Addressing Overview. For information on DHCP addresses, see Chapter 11, About Solaris DHCP (Overview).
Each IPv4-based network must have the following:
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.
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.
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
Network part, which consists of the IPv4 network number that is received from an ISP or IR.
Host part, which you assign to an interface on a system.
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.
A Solaris-based network can combine standard IPv4 addresses, CIDR format IPv4 addresses, DHCP addresses, IPv6 addresses, and private IPv4 addresses.
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 |
---|---|---|---|
0–127 |
xxx |
xxx.xxx.xxx |
|
128–191 |
xxx.xxx |
xxx.xxx |
|
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 |
---|---|---|---|---|
0–127 |
1–254 |
1–254 |
1–254 |
|
128–191 |
Preassigned by IANA |
1–254 |
1–254 |
|
192–223 |
Preassigned by IANA |
Preassigned by IANA |
1–254 |
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.
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 Solaris 10 commands recognize the CIDR prefix designation of a network's subnet mask. However, the 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:
For technical details on CIDR, refer to RFC 1519, Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy.
More general information about CIDR is available from Pacific Bell Internet at Classless Inter-Domain Routing (CIDR) Overview.
Another CIDR overview can be found in the Wikipedia article,"Classless inter-domain routing".
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.
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 |
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 Solaris installation, you must supply the IP address for the first interface that the installation program finds. Usually that interface has the name device-name0, for example eri0 or hme0. This interface is considered the primary network interface.
If you add a second network interface to a host, that interface also must have its own unique IP address. When you add the second network interface, the host then becomes multihomed. By contrast, when you add a second network interface to a host and enable IP forwarding, that host becomes a router. See Configuring an IPv4 Router for an explanation.
Each network interface has a device name, a device driver, and an associated device file in the /devices directory. The network interface might have a device name such as eri or smc0, which are device names for two commonly used Ethernet interfaces.
For information and tasks related to interfaces, refer to Part I, Administering Single Interfaces, in System Administration Guide: Network Interfaces and Network Virtualization.
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.
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 the Solaris OS) 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.
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.
The Solaris OS enables you to use three types of name services: local files, NIS, and DNS. Name services maintain critical information about the machines on a network, such as the host names, IP addresses, Ethernet addresses, and so forth. The Solaris OS also gives you the option of using the LDAP directory service in addition to or instead of a name service. For an introduction to name services on Solaris, refer to Part I, About Naming and Directory Services, in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
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 Solaris installation program adds this information into the hosts 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.
The NIS and DNS name services maintain network databases on several servers on the network. System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) describes these name services and explains how to configure the databases. In addition, the guide explain the “namespace” and “administrative domain” concepts in detail.
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.
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.
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.
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.
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.
For complete details and tasks for router configuration on IPv4 networks, refer to Packet Forwarding and Routing on IPv4 Networks. For complete details and tasks for router configuration on IPv6 networks, refer to Configuring an IPv6 Router.
Network topology 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.
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.
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.
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.
This chapter presents an overview of the 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 Solaris networking environment. Systems that are configured with IPv6 addresses retain their IPv4 addresses, if these addresses already exist. Operations that involve IPv6 addresses do not adversely affect IPv4 operations, and vice versa.
The following major topics are discussed:
For more detailed information about IPv6, consult the following chapters.
IPv6 network planning – Chapter 4, Planning an IPv6 Network (Tasks)
IPv6-related tasks – Chapter 6, Enabling IPv6 on a Network (Tasks) andChapter 7, Administering a TCP/IP Network (Tasks).
IPv6 details – Chapter 10, IPv6 in Depth (Reference)
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.
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.
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.
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.
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.
Many critical Solaris network services recognize and support IPv6 addresses, for example:
Name services, such as DNS, LDAP, and NIS. For more information on IPv6 support by these name services, see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
Authentication and privacy applications, such as IP Security Architecture (IPsec) and Internet Key Exchange (IKE). For more information, see Part III, IP Security.
Differentiated services, as provided by IP Quality of Service (IPQoS). For more information, see Part IV, IP Quality of Service (IPQoS).
Failover detection, as provided by IP network multipathing (IPMP). For more information, see Failure and Repair Detection in IPMP in System Administration Guide: Network Interfaces and Network Virtualization.
In addition to this Part, you can obtain information about IPv6 from the sources that are listed in the following sections.
Many RFCs are available regarding IPv6. The following table lists the major IPv6 articles and their Internet Engineering Task Force (IETF) web locations as of this writing.
Table 3–1 IPv6–Related RFCs and Internet Drafts
RFC or Internet Draft |
Subject |
Location |
---|---|---|
RFC 2461, Neighbor Discovery for IP Version 6 (IPv6) |
Describes the features and functions of IPv6 Neighbor Discovery protocol | |
RFC 3306, Unicast—Prefix—Based IPv6 Multicast Addresses |
Describes the format and types of IPv6 multicast addresses | |
RFC 3484: Default Address Selection for Internet Protocol version 6 (IPv6) |
Describes the algorithms used in IPv6 default address selection | |
RFC 3513, Internet Protocol version 6 (IPv6) Addressing Architecture |
Contains complete details about the types of IPv6 addresses and includes many examples | |
RFC 3587, IPv6 Global Unicast Address Format |
Defines the standard format for IPv6 unicast addresses |
The following web sites provide useful information about IPv6.
Table 3–2 IPv6–Related Web Sites
Web Site |
Description |
Location |
---|---|---|
IPv6 Forum |
Links to IPv6–related presentations, events, classes, and implementations worldwide are available from this society's web site | |
Internet Educational Task Force IPv6 Working Group |
Links to all relevant IPv6 RFCs and Internet Drafts are on the home page of this IETF working group |
This section introduces terms that are fundamental to the IPv6 network topology. The following figure shows the basic parts 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.
Any system with an IPv6 address and interface that is configured for IPv6 support. This generic term applies to both hosts and routers.
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.
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.
A single, contiguous network medium that is bounded on either end by a router.
An IPv6 node that is on the same link as the local node.
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.
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.
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 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.
For complete technical information about the IPv6 address format, go to RFC 2374, IPv6 Global Unicast Address Format
IPv6 defines three address types:
Identifies an interface of an individual node.
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.
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.
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.
The leftmost three fields (48 bits) contain the site prefix. The prefix describes the public topology that is usually allocated to your site by an ISP or Regional Internet Registry (RIR).
The next field is the 16-bit subnet ID, which you (or another administrator) allocate for your site. The subnet ID describes the private topology, also known as the site topology, because it is internal to your site.
The rightmost four fields (64 bits) contain the interface ID, also referred to as a token. The interface ID is either automatically configured from the interface's MAC address or manually configured in EUI-64 format.
Consider again the address in Figure 3–2:
2001:0db8:3c4d:0015:0000:0000:1a2f:1a2b
This example shows all 128 bits of an IPv6 address. The first 48 bits, 2001:0db8:3c4d, contain the site prefix, representing the public topology. The next 16 bits, 0015, contain the subnet ID, representing the private topology for the site. The lower order, rightmost 64 bits, 0000:0000:1a2f:1a2b, contain the interface ID.
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::.
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
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:
Indicates that a 6to4 routing prefix follows.
Indicates that a link-local address follows.
Indicates that a multicast address follows.
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
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.
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).
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.
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.
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.
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.
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
Hexadecimal representation of the 10-bit binary prefix 1111111010. This prefix identifies the type of IPv6 address as link local.
Hexadecimal address of the interface, which is usually derived from the 48-bit MAC address.
When you enable IPv6 during 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.
IPv6 supports the use of multicast addresses. The multicast address identifies a multicast group, which is a group of interfaces, usually on different nodes. An interface can belong to any number of multicast groups. If the first 16 bits of an IPv6 address is ff00n, the address is a multicast address.
Multicast addresses are used for sending information or services to all interfaces that are defined as members of the multicast group. For example, one use of multicast addresses is to communicate with all IPv6 nodes on the local link.
When an interface's IPv6 unicast address is created, the kernel automatically makes the interface a member of certain multicast groups. For example, the kernel makes each node a member of the Solicited Node multicast group, which is used by the Neighbor Discovery protocol to detect reachability. The kernel also automatically makes a node a member of the All-Nodes or All Routers multicast groups.
For detailed information about multicast addresses, refer to IPv6 Multicast Addresses in Depth. For technical information, see RFC 3306, Unicast-Prefix-based IPv6 Multicast Addresses, which explains the multicast address format. For more information about the proper use of multicast addresses and groups, RFC 3307, Allocation Guidelines for IPv6 Multicast Addresses.
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.
The Solaris Operating System (Solaris OS) implementation of IPv6 does not support the creation of anycast addresses and groups. However, Solaris IPv6 nodes can send packets to anycast addresses. For more information, see Considerations for Tunnels to a 6to4 Relay Router.
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:
Router discovery – Aids hosts in locating routers on the local link.
Address autoconfiguration – Enables a node to automatically configure IPv6 addresses for its interfaces.
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:
Router solicitation
Router advertisement
Neighbor solicitation
Neighbor advertisement
Redirection
For detailed information on Neighbor Discovery messages and other Neighbor Discovery protocol topics, refer to IPv6 Neighbor Discovery Protocol. For technical information on Neighbor Discovery, see RFC 2461, Neighbor Discovery for IP Version 6 (IPv6).
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 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.
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.
For most enterprises, the introduction of IPv6 to an existing IPv4 network must occur on a gradual, step-by-step basis. The 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 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.
For detailed information about IPv6 tunnels, refer to IPv6 Tunnels. For information about IPv4- to-IPv4 tunnels and VPN, refer to Virtual Private Networks and IPsec.
Deploying IPv6 on a new network or an existing network requires a major planning effort. This chapter contains the planning tasks that are necessary before you can configure IPv6 at your site. For existing networks, IPv6 deployment should be phased in gradually. The topics in this chapter help you phase in IPv6 onto an otherwise IPv4-only network.
The following topics are discussed in this chapter:
For an introduction to IPv6 concepts, refer to Chapter 3, Planning an IPv6 Addressing Scheme (Overview). For detailed information, refer to Chapter 10, IPv6 in Depth (Reference).
Complete the tasks in the next task map in sequential order to accomplish the planning tasks necessary for IPv6 deployment.
Task |
Description |
For Instructions |
---|---|---|
1. Prepare your hardware to support IPv6. |
Ensure that your hardware can be upgraded to IPv6. | |
2. Get an ISP that supports IPv6. |
Ensure that your current ISP supports IPv6. Otherwise, find an ISP who can support IPv6. You can use two ISPs, one ISP for IPv6 and one for ISP IPv4 communications. |
|
3. Ensure that your applications are IPv6 ready. |
Verify that your applications can run in an IPv6 environment. | |
4. Get a site prefix. |
Obtain a 48-bit site prefix for your site from your ISP or from the nearest RIR. | |
5. Create a subnet addressing plan. |
You need to plan the overall IPv6 network topology and addressing scheme before you can configure IPv6 on the various nodes in your network. | |
6. Design a plan for tunnel usage. |
Determine which routers should run tunnels to other subnets or external networks. | |
7. Create an addressing plan for entities on the network. |
Your plan for addressing servers, routers, and hosts should be in place before IPv6 configuration. | |
8. Develop an IPv6 security policy. |
Investigate IP Filter, IP security architecture (IPsec), Internet Key Exchange (IKE), and other Solaris security features as you develop an IPv6 security policy. | |
9. (Optional) Set up a DMZ. |
For security purposes, you need an addressing plan for the DMZ and its entities before you configure IPv6. | |
10. Enable the nodes to support IPv6. |
Configure IPv6 on all routers and hosts. | |
11. Turn on network services. |
Make sure that existing servers can support IPv6. | |
12. Update name servers for IPv6 support. |
Make sure that DNS, NIS, and LDAP servers are updated with the new IPv6 addresses. |
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.
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.
The 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.
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
All procedures in the this Part assume that your equipment, particularly routers, can be upgraded to IPv6.
Some router models cannot be upgraded to IPv6. For more information and a workaround, refer to IPv4 Router Cannot Be Upgraded to IPv6.
The following typical IPv4 network services in the current 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.
Some issues can arise after you upgrade services to IPv6. For details, see Problems After Upgrading Services to IPv6.
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.
Update the following network services to support IPv6:
Mail servers
NIS servers
NFS
LDAP supports IPv6 without requiring IPv6-specific configuration tasks.
Verify that your firewall hardware is IPv6 ready.
Refer to the appropriate firewall-related documentation for instructions.
Verify that other services on your network have been ported to IPv6.
For more information, refer to marketing collateral and associated documentation for the software.
If your site deploys the following services, make sure that you have taken the appropriate measures for these services:
Firewalls
Consider strengthening the policies that are in place for IPv4 to support IPv6. For more security considerations, see Security Considerations for the IPv6 Implementation.
In the MX records for DNS, consider adding the IPv6 address of your mail server.
DNS
For DNS-specific considerations, see How to Prepare DNS for IPv6 Support.
IPQoS
Use the same Diffserv policies on a host that were used for IPv4. For more information, see Classifier Module.
Audit any network services that are offered by a node prior to converting that node to IPv6.
The current Solaris release supports DNS resolution on both the client side and the server side. Do the following to prepare DNS services for IPv6.
For more information that is related to DNS support for IPv6, refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
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.
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.
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.
For procedures for configuring tunnels, refer to Tasks for Configuring Tunnels for IPv6 Support (Task Map). For conceptual information regarding tunnels, refer to IPv6 Tunnels.
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.
The IP security architecture (IPsec) feature enables you to provide cryptographic protection for IPv6 packets. For more information, refer to Chapter 18, IP Security Architecture (Overview).
The Internet Key Exchange (IKE) feature enables you to use public key authentication for IPv6 packets. For more information, refer to Chapter 21, Internet Key Exchange (Overview).
A major part of the transition from IPv4 to IPv6 includes the development of an addressing plan. This task involves the following preparations:
Before you configure IPv6, you must obtain a site prefix. The site prefix is used to derive IPv6 addresses for all the nodes in your IPv6 implementation. For an introduction to site prefixes, refer to Prefixes in IPv6.
Any ISP that supports IPv6 can provide your organization with a 48-bit IPv6 site prefix. If your current ISP only supports IPv4, you can use another ISP for IPv6 support while retaining your current ISP for IPv4 support. In such an instance, you can use one of several workarounds. For more information, see Current ISP Does Not Support IPv6.
If your organization is an ISP, then you obtain site prefixes for your customers from the appropriate Internet registry. For more information, see the Internet Assigned Numbers Authority (IANA).
Unless your proposed IPv6 network is entirely new, use your existing IPv4 topology as the basis for the IPv6 numbering scheme.
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 |
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.
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 6, Enabling IPv6 on a Network (Tasks).
This chapter contains the following information:
In Solaris Express Developer Edition 9/07 and subsequent releases, you can configure and manage routing through the Service Management Facility (SMF) as an alternative to using the routeadm command. For instructions, refer to the procedures and examples in Packet Forwarding and Routing on IPv4 Networksand the routeadm(1M) man page.
Before you configure TCP/IP, complete the tasks that are listed in the following table.
Task |
Description |
For Instructions |
---|---|---|
1. Design the network topology. |
Determine the physical layout of the network. |
Network Topology Overview and IPv4 Autonomous System Topology |
2. Obtain a network number from your ISP or Regional Internet Registry (RIR). |
Get a registered network number, which enables systems at your site to communicate externally. | |
3. Plan the IPv4 addressing scheme for the network. If applicable, include subnet addressing. |
Use the network number as the basis for your addressing plan. | |
4. Assemble the network hardware depending on the network topology. Assure that the hardware is functioning properly. |
Set up the systems, network media, routers, switches, hubs and bridges that you outlined in the network topology design. |
The hardware manuals and Network Topology Overview. |
5. Assign IPv4 addresses and host names to all systems in the network. |
Assign the IPv4 addresses during Solaris OS installation or post installation, in the appropriate files. |
Designing Your IPv4 Addressing Scheme and How to Change the IPv4 Address and Other Network Configuration Parameters |
6. Run configuration software that is required by network interfaces and routers, if applicable. |
Configure routers and multihomed hosts. |
Planning for Routers on Your Network and Configuring an IPv4 Router for information on routers. |
7. Determine which name service or directory service your network uses: NIS, LDAP, DNS, or local files. |
Configure your selected name service and/or directory service. |
System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP). |
8. Select domain names for your network, if applicable. |
Choose a domain name for your network and register it with the InterNIC. |
System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) |
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.
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 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.
TFTP – The Trivial File Transfer Protocol (TFTP) is an application that transfers files between remote systems. The in.tftpd daemon executes TFTP services, enabling file transfer between network configuration servers and their network clients. Refer to the in.tftpd(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.
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.
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.
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.
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 information in this section applies to IPv4 subnets only. For information on planning IPv6 subnets, refer to Preparing the Network Topology for IPv6 Support and Creating a Numbering Scheme for Subnets.
Task |
Description |
For Instructions |
---|---|---|
1. Determine if your network topology requires subnets. |
Decide on the new subnet topology, including where to locate routers and hosts on the subnets. |
Planning for Routers on Your Network, What Is Subnetting?, and Network Classes |
2. Assign the IP addresses with the new subnet number to the systems to become members of the subnet. |
Configure IP addresses that use the new subnet number, either during Solaris OS installation or later, in the /etc/hostname.interface file. | |
3. Configure the network mask of the subnet on all prospective systems in the subnet. |
Modify the /etc/inet/netmasks file, if you are manually configuring network clients. Or, supply the netmask to the Solaris installation program. |
netmasks Database and Creating the Network Mask for IPv4 Addresses |
4. Edit the network databases with the new IP addresses of all systems in the subnet. |
Modify /etc/inet/hosts on all hosts to reflect the new host addresses. | |
5. Reboot all systems. |
Task |
Description |
For Instructions |
---|---|---|
Configure a host for local files mode |
Involves editing the nodename, hostname, hosts, defaultdomain, defaultrouter, and netmasks files | |
Set up a network configuration server |
Involves turning on the in.tftp daemon, and editing the hosts, ethers, and bootparams files | |
Configure a host for network client mode |
Involves creating the hostname file, editing the hosts file, and deleting the nodename and defaultdomain files, if they exist | |
Specify a routing strategy for the network client |
Involves determining whether to use static routing or dynamic routing on the host. |
How to Enable Static Routing on a Single-Interface Host and How to Enable Dynamic Routing on a Single-Interface Host. |
Modify the existing network configuration |
Involves changing the host name, IP address, and other parameters that were set at installation or configured at a later time. |
How to Change the IPv4 Address and Other Network Configuration Parameters |
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 the Solaris OS.
Subnet mask (required only for networks with subnets).
If the Solaris installation program detects more one interface on the system, you can optionally configure the additional interfaces during installation. For complete instructions, see Solaris Express Installation Guide: Basic Installations.
This chapter contains information on creating and editing local configuration files. See System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) for information on working with name service databases.
Use this procedure for configuring TCP/IP on a host that runs in local files mode.
Assume the Primary Administrator role, or become superuser
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Change to the /etc directory.
Verify that the correct host name is set in the /etc/nodename file.
When you specify the host name of a system during 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.
For file syntax and basic information about the /etc/hostname.interface file, refer to Part I, Administering Single Interfaces, in System Administration Guide: Network Interfaces and Network Virtualization.
The 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 Solaris installation. However, if you later want to add more interfaces to the system, you must manually configure them.
For steps for manually configuring interfaces, refer to How to Configure an IP Interface After System Installation in System Administration Guide: Network Interfaces and Network Virtualization.
Verify that the entries in the /etc/inet/hosts file are current.
The 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.
Type the router's name in the /etc/defaultrouter file.
See /etc/defaultrouter File for information about this file.
Type the name of the default router and its IP addresses in the /etc/inet/hosts file.
Additional routing options are available, as discussed in How to Configure Hosts for Network Client Mode. You can apply these options to a local files mode configuration.
Add the network mask for your network, if applicable:
If the host gets its IP address from a DHCP server, you do not have to specify the network mask.
If you have set up a NIS server on the same network as this client, you can add netmask information into the appropriate database on the server.
For all other conditions, do the following:
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:
netmasks: files nis |
Information for setting up installation servers and boot servers is found in Solaris Express Installation Guide: Basic Installations.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
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 |
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 16, Managing Services (Overview), in System Administration Guide: Basic Administration.
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.
Do the following procedure on each host to be configured in network client mode.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Search the /etc directory for the nodename file.
If such a file exists, delete it.
Eliminating /etc/nodename causes the system to use the hostconfig program to obtain the host name, domain name, and router addresses from the network configuration server. See Configuring Systems on the Local Network.
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.
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.
The instructions apply specifically to changing the IPv4 address of the primary network interface. To add another interface to the system, refer to How to Configure an IP Interface After System Installation in System Administration Guide: Network Interfaces and Network Virtualization.
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.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
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.
Here is an example:
# vi hostname.eri0 10.0.2.5 netmask 255.0.0.0 |
IPv4 address, expressed in CIDR notation, if appropriate for your network configuration.
IPv4 address/network prefix |
Here is an example:
# vi hostname.eri0 10.0.2.5/8 |
The CIDR prefix designates the appropriate netmask for the IPv4 address. For example, the /8 above indicates the netmask 255.0.0.0.
Host name.
To use the system's host name in the /etc/hostname.interface file, be sure that the host name and associated IPv4 address are also in the hosts database.
If the subnet mask has changed, modify the subnet entries in the following files:
/etc/netmasks
(Optional) /etc/hostname.interface
If the subnet address has changed, change the IP address of the default router in /etc/defaultrouter to that of the new subnet's default router.
Reboot the system.
# reboot -- -r |
This example shows how to change the following network parameters of a system that is moved to another subnet:
IP address for the primary network interface eri0 changes from 10.0.0.14 to 192.168.55.14.
Host name changes from myhost to mynewhostname.
Netmask changes from 255.0.0.0 to 255.255.255.0.
Default router address changes to 192.168.55.200.
Check the system's current status:
# hostname myhost # ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.14 netmask ff000000 broadcast 10.255.255.255 ether 8:0:20:c1:8b:c3 |
Next, change the system's host name and the IP address of eri0 in the appropriate files:
# vi /etc/nodename mynewhostname In Solaris 10 11/06 and earlier Solaris 10 releases only, do the following: # vi /etc/inet/ipnodes 192.168.55.14 mynewhostname #moved system to 192.168.55 net # vi /etc/inet/hosts # # Internet host table # 127.0.0.1 localhost 192.168.55.14 mynewhostname loghost # vi /etc/hostname.eri0 192.168.55.14 netmask 255.255.255.0 |
Finally, change the netmask and the IP address of the default router.
# vi /etc/netmasks. . . 192.168.55.0 255.255.255.0 # vi /etc/defaultrouter 192.168.55.200 #moved system to 192.168.55 net # |
After making these changes, reboot the system.
# reboot -- -r |
Verify that the configuration you just set is maintained after the reboot:
# hostname mynewhostname # ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.55.14 netmask ffffff00 broadcast 10.255.255.255 ether 8:0:20:c1:8b:c3 |
This example shows how to change a host's name, IP address of the primary network interface, and subnet mask for the current session only. If you reboot, the system reverts to its previous IP address and subnet mask. The IP address for the primary network interface eri0 changes from 10.0.0.14 to 192.168.34.100.
# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.14 netmask ff000000 broadcast 10.255.255.255 ether 8:0:20:c1:8b:c3 # ifconfig eri0 192.168.34.100 netmask 255.255.255.0 broadcast + up # vi /etc/nodename mynewhostname # ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.34.100 netmask ffffff00 broadcast 10.255.255.255 ether 8:0:20:c1:8b:c3 # hostname mynewhostname |
This example shows how to change a host name and IP address for the current session only, using CIDR notation. If you reboot, the system reverts to its previous IP address and subnet mask. The IP address for the primary network interface, eri0, changes from 10.0.0.14 to 192.168.6.25/27.
# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.14 netmask ff000000 broadcast 10.255.255.255 ether 8:0:20:c1:8b:c3 # ifconfig eri0 192.168.6.25/27 broadcast + up # vi /etc/nodename mynewhostname # ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.06.25 netmask ffffffe0 broadcast 10.255.255.255 ether 8:0:20:c1:8b:c3 # hostname mynewhostname |
When you use CIDR notation for the IPv4 address, you do not have to specify the netmask. ifconfig uses the network prefix designation to determine the netmask. For example, for the 192.168.6.0/27 network, ifconfig sets the netmask ffffffe0. If you had used the more common /24 prefix designation, the resulting netmask is ffffff00. Using the /24 prefix designation is the equivalent of specifying the netmask 255.255.255.0 to ifconfig when configuring a new IP address.
To change the IP address of an interface other than the primary network interface, refer to System Administration Guide: Basic Administration and How to Configure an IP Interface After System Installation in System Administration Guide: Network Interfaces and Network Virtualization.
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 the Solaris OS.
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 a 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 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 Solaris routing protocols and the location of each protocol's associated documentation.
Table 5–1 Solaris Routing Protocols
Protocol |
Associated Daemon |
Description |
For Instructions |
---|---|---|---|
Routing Information Protocol (RIP) |
in.routed |
IGP that routes IPv4 packets and maintains a routing table | |
Internet Control Message Protocol (ICMP) Router Discovery |
in.routed |
Used by hosts to discover the presence of a router on the network |
How to Enable Static Routing on a Single-Interface Host and How to Enable Dynamic Routing on a Single-Interface Host |
Routing Information Protocol, next generation (RIPng) Protocol |
in.ripngd |
IGP that routes IPv6 packets and maintains a routing table | |
Neighbor Discovery (ND) Protocol |
in.ndpd |
Advertises the presence of an IPv6 router and discovers the presence of IPv6 hosts on a network |
The Solaris 10 OS 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 main Solaris distribution. The following table lists the Quagga protocols:
Table 5–2 OpenSolaris Quagga Protocols
Protocol |
Daemon |
Description |
---|---|---|
RIP protocol |
ripd |
IPv4 distance vectoring IGP that routes IPv4 packets and advertises its routing table to neighbors. |
RIPng |
ripngd |
IPv6 distance vectoring IGP. Routes IPv6 packets and maintains a routing table. |
Open Shortest Path First (OSPF) protocol |
ospfd |
IPv4 link state IGP for packet routing and high availability networking |
Border Gateway Protocol (BGP) |
bgpd |
IPv4 and IPv6 EGP for routing across administrative domains. |
The following figure shows an autonomous system that uses the Quagga routing protocols:
The figure shows a corporate network autonomous system that is subdivided into two routing domains, A and B. Arouting domain is an internetwork with a cohesive routing policy, either for administrative purposes or because the domain uses a single routing protocol. Both domains in the figure run routing protocols from the Quagga protocol suite.
Routing Domain A is an OSPF domain, which is administered under a single OSPF domain ID. All systems within this domain run OSPF as their interior gateway protocol. In addition to internal hosts and routers, Domain A includes two border routers.
Border router R1 connects the Corporate Network to an ISP and ultimately the Internet. To facilitate communications between the Corporate Network and the outside world, R1 runs BGP over its externally facing network interface. The border router R5 connects Domain A with Domain B. All systems on Domain B are administered with RIP as their interior gateway protocol. Therefore, border router R5 must run OSPF on the Domain A facing interface and RIP on the Domain B facing interface.
For more information on the Quagga protocols, refer to the Open Solaris Quagga. For configuration procedures for these protocols, go to the documentation for quagga.
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.
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.
For information on configuring a border router, refer to the Open Source Quagga documentationfor BGP information.
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.
For an example of configuring a default router, refer to Example 5–4.
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 the Solaris OS. 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.
Single interface hosts rely on the local routers, not only for packet forwarding but also for receiving valuable configuration information. Figure 5–3 includes Host A on the 192.168.5 network, which implements dynamic routing, and Host B on the 172.20.1 network, which implements static routing. To configure a host to run dynamic routing, refer to How to Enable Dynamic Routing on a Single-Interface Host. To configure a host to run static routing, refer to How to Enable Static Routing on a Single-Interface Host.
This section contains a procedure and example for configuring an IPv4 router. To configure an IPv6-enabled router, refer to How to Configure an IPv6-Enabled Router.
Because a router provides the interface between two or more networks, you must assign a unique name and IP address to each of the router's physical network interfaces. Thus, each router has a host name and an IP address that are associated with its primary network interface, in addition to a minimum of one more unique name and IP address for each additional network interface.
You can also use the following procedure to configure a system with only one physical interface (by default, a host) to be a router. You might configure a single interface system as a router if the system serves as one endpoint on a PPP link, as explained in Planning a Dial-up PPP Link in System Administration Guide: Network Services.
You can configure all interfaces of a router during Solaris system installation. For instructions, see Solaris Express Installation Guide: Basic Installations.
The following instructions assume that you are configuring interfaces for the router after installation.
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.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
use the dladm show-link command to determine which interfaces are physically installed on the router.
# dladm show-link |
The following example output from dladm show-link indicates that a qfe NIC with four interfaces and two bge interfaces are physically available on the system.
THIS IS CHANGED SECTION LINK CLASS MTU STATE OVER qfe0 phys 1500 up -- qfe1 phys 1500 up -- qfe2 phys 1500 up -- qfe3 phys 1500 up -- bge0 phys 1500 up -- bge1 phys 1500 up -- |
Review which interfaces on the router were configured and plumbed during installation.
# ifconfig -a |
The following example output from ifconfig -a shows that the interface qfe0 was configured during installation. This interface is on the 172.16.0.0 network. The remaining interfaces on the qfe NIC, qfe1 - qfe3, and the bge interfaces have not been configured.
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 qfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 172.16.26.232 netmask ffff0000 broadcast 172.16.26.255 ether 0:3:ba:11:b1:15 |
Configure and plumb another interface.
# ifconfig interface plumb up |
For example, for qfe1, you would type:
# ifconfig qfe1 plumb up |
Interfaces that are explicitly configured with the ifconfig command do not persist across reboots.
Assign an IPv4 address and a netmask to the interface.
You can configure an IPv4 routers to receive its IP address through DHCP, but this is recommended only for very experienced DHCP system administrators.
# ifconfig interface IPv4-address netmask+netmask |
For example, to assign the IP address 192.168.84.3 to qfe1, do either of the following:
Using traditional IPv4 notation, type the following:
# ifconfig qfe1 192.168.84.3 netmask + 255.255.255.0 |
Using CIDR notation, type the following:
# ifconfig qfe1 192.168.84.3/24 |
The prefix /24 automatically assigns the 255.255.255.0 netmask to qfe1. For a table of CIDR prefixes and their dotted-decimal netmask equivalents, refer to Figure 2–2.
(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 an IP Interface After System Installation in System Administration Guide: Network Interfaces and Network Virtualization.
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.
For example:
172.16.26.232 deadsea #interface for network 172.16.0.0 192.168.200.20 timbuktu #interface for network 192.168.200 192.168.201.20 timbuktu-201 #interface for network 192.168.201 192.168.200.9 gobi 192.168.200.10 mojave 192.168.200.110 saltlake 192.168.200.12 chilean |
The interfaces timbuktu and timbuktu-201 are on the same system. Notice that the network address for timbuktu-201 is different from the network interface for timbuktu. The difference exists because the physical network media for network 192.168.201 is connected to the timbuktu-201 network interface while the media for network 192.168.200 is connected to the timbuktu interface.
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.
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.
# dladm show-link LINK CLASS MTU STATE OVER ce0 phys 1500 up -- bge0 phys 1500 up -- bge1 phys 1500 up -- # ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 172.20.1.10 netmask ffff0000 broadcast 172.20.10.100 ether 8:0:20:c1:1b:c6 |
The output of dladm show-link indicates that three links are available on the system. Only the ce0 interface has been plumbed. You would begin default router configuration by physically connecting the bge0 interface to the 10.0.5.0 network. Then, you would plumb the interface and make it persist across reboots.
# ifconfig bge0 plumb up # ifconfig bge0 10.0.5.10 # ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 172.20.1.10 netmask ffff0000 broadcast 172.255.255.255 ether 8:0:20:c1:1b:c6 bge0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.5.10 netmask ff000000 broadcast 10.255.255.255 ether 8:0:20:e5:95:c4 # vi /etc/hostname.bge0 10.0.5.10 255.0.0.0 |
Reboot the system, using the reconfiguration boot command:
# reboot -- -r |
Continue by configuring the following network databases with information about the newly plumbed interface and the network to which it is connected:
# vi /etc/inet/hosts 127.0.0.1 localhost 172.20.1.10 router2 #interface for network 172.20.1 10.0.5.10 router2-out #interface for network 10.0.5 # vi /etc/inet/netmasks 172.20.1.0 255.255.0.0 10.0.5.0 255.0.0.0 |
Finally, use SMF to enable packet forwarding and then enable the in.routed routing daemon.
# svcadm enable ipv4-forwarding # svcadm enable route:default |
Now IPv4 packet forwarding and dynamic routing through RIP are enabled on Router 2. However, the default router configuration for network 172.20.1.0 is not yet complete. You would need to do the following:
Modify each host on 172.10.1.10 so that the host gets its routing information from the new default router. For more information, refer to How to Enable Static Routing on a Single-Interface Host.
Define a static route to the border router in the routing table of Router 2. For more details, refer to Routing Tables and Routing Types.
Both routers and hosts maintain a routing table. The routing daemon on each system updates the table with all known routes. The system's kernel reads the routing table before forwarding packets to the local network. The routing table lists the IP addresses of networks that the system knows about, including the system's local, default network. The table also lists the IP address of a gateway system for each known network. The gateway is a system that can receive outgoing packets and forward them one hop beyond the local network. The following is a simple routing table for a system on an IPv4-only network:
Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- default 172.20.1.10 UG 1 532 ce0 224.0.0.0 10.0.5.100 U 1 0 bge0 10.0.0.0 10.0.5.100 U 1 0 bge0 127.0.0.1 127.0.0.1 UH 1 57 lo0 |
You can configure two types of routing on a 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 AS that is shown is Figure 5–3 combines both static and dynamic routing.
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.
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 7, Introducing IPMP, in System Administration Guide: Network Interfaces and Network Virtualization.
View the current state of the routing table.
Use your regular user account to run the following form of the netstat command:
% netstat -rn |
Your output would resemble the following:
Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- 192.168.5.125 192.168.5.10 U 1 5879 ipge0 224.0.0.0 198.168.5.10 U 1 0 ipge0 default 192.168.5.10 UG 1 91908 127.0.0.1 127.0.0.1 UH 1 811302 lo0 |
Assume the Primary Administrator role or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
(Optional) Flush the existing entries in the routing table.
# route flush |
Add a route that persists across system reboots.
# route -p add -net network-address -gateway gateway-address |
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.
Indicates that you are about to add the following route.
Specifies that the route goes to the network with the address in network-address.
Indicates that the gateway system for the specified route has the IP address gateway-address.
The following example shows how to add a static route to a system. The system is Router 2, the default router for the 172.20.1.0 network that is shown in Figure 5–3. In Example 5–4, Router 2 is configured for dynamic routing. To better serve as the default router for the hosts on network 172.20.1.0, Router 2 additionally needs a static route to the AS's border router, 10.0.5.150.
To view the routing table on Router 2, you would do the following:
# netstat -rn Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- default 172.20.1.10 UG 1 249 ce0 224.0.0.0 172.20.1.10 U 1 0 ce0 10.0.5.0 10.0.5.20 U 1 78 bge0 127.0.0.1 127.0.0.1 UH 1 57 lo0 |
The routing table indicates two routes that Router 2 knows about. The default route uses Router 2's 172.20.1.10 interface as its gateway. The second route, 10.0.5.0, was discovered by the in.routed daemon running on Router 2. The gateway for this route is Router 1, with the IP address 10.0.5.20.
To add a second route to network 10.0.5.0, which has its gateway as the border router, you would do the following:
# route -p add -net 10.0.5.0/24 -gateway 10.0.5.150/24 add net 10.0.5.0: gateway 10.0.5.150 |
Now the routing table has a route for the border router, which has the IP address 10.0.5.150/24.
# netstat -rn Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- default 172.20.1.10 UG 1 249 ce0 224.0.0.0 172.20.1.10 U 1 0 ce0 10.0.5.0 10.0.5.20 U 1 78 bge0 10.0.5.0 10.0.5.150 U 1 375 bge0 127.0.0.1 127.0.0.1 UH 1 57 lo0 |
In the Solaris OS, 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.
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.
On the prospective multihomed host, assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Configure and plumb each additional network interface that was not configured as part of the Solaris OS installation.
Verify that IP forwarding is not enabled on the multihomed host.
# routeadm |
The routeadm command without options reports the state of the routing daemons. The following output from routeadm shows that IPv4 forwarding is enabled:
Configuration Current Current Option Configuration System State --------------------------------------------------------------- IPv4 routing disabled disabled IPv6 routing disabled disabled IPv4 forwarding enabled disabled IPv6 forwarding disabled disabled Routing services "route:default ripng:default" |
Turn off packet forwarding, if it is enabled on the system.
Use either of the following commands:
For the routeadm command, type the following:
# routeadm -d ipv4-forwarding -u |
To use SMF, type the following:
# svcadm disable ipv4-forwarding |
(Optional) Turn on dynamic routing for the multihomed host.
Use either of the following commands to enable the in.routed daemon:
For the routeadm command, type the following:
# routeadm -e ipv4-routing -u |
To use SMF, type the following:
# svcadm enable route:default |
The following example shows how to configure the multihomed host that is shown in Figure 5–3. In the example, the system has the host name hostc. This host has two interfaces, which are both connected to network 192.168.5.0.
To begin, you would display the status of the system's interfaces.
# dladm show-link LINK CLASS MTU STATE OVER hme0 phys 1500 up -- qfe0 phys 1500 up -- qfe1 phys 1500 up -- qfe2 phys 1500 up -- qfe3 phys 1500 up --# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 hme0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.5.82 netmask ff000000 broadcast 192.255.255.255 ether 8:0:20:c1:1b:c6 |
The dladm show-link command reports that hostc has two interfaces with a total of five possible links. However, only hme0 has been plumbed. To configure hostc as a multihomed host, you must add qfe0 or another link on the qfe NIC. First, you would physically connect the qfe0 interface to the 192.168.5.0 network. Then you would plumb the qfe0 interface, and make the interface persist across reboots.
# ifconfig qf0 plumb up # ifconfig qfe0 192.168.5.85 # ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 hme0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.5.82 netmask ff0000 broadcast 192.255.255.255 ether 8:0:20:c1:1b:c6 qfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.5.85 netmask ff000000 broadcast 192.255.255.255 ether 8:0:20:e1:3b:c4 # vi /etc/hostname.qfe0 192.168.5.85 255.0.0.0 |
Reboot the system, using the reconfiguration command:
# reboot -- -r |
Next, you would add the qfe0 interface to the hosts database:
# vi /etc/inet/hosts 127.0.0.1 localhost 192.168.5.82 host3 #primary network interface for host3 192.168.5.85 host3-2 #second interface |
Then, you would check the state of packet forwarding and routing on host3:
# routeadm Configuration Current Current Option Configuration System State --------------------------------------------------------------- IPv4 routing enabled enabled IPv6 routing disabled disabled IPv4 forwarding enabled enabled IPv6 forwarding disabled disabled Routing services "route:default ripng:default" |
The routeadm command reports that dynamic routing through the in.routed daemon and packet forwarding are currently enabled. However, you would need to disable packet forwarding:
# svcadm disable ipv4-forwarding |
You can also use the routeadm commands as shown in How to Create a Multihomed Host to turn off packet forwarding. When packet forwarding is disabled, host3 becomes a multihomed host.
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.
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.
You can also use the following procedure to configure static routing on a multihomed host.
For information about the /etc/defaultrouter file, see /etc/defaultrouter File. For information about static routing and the routing table, refer to Routing Tables and Routing Types.
On the single interface host, assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Verify whether the /etc/defaultrouter file is present on the host.
# cd /etc # ls | grep defaultrouter |
Open a text editor to create or modify the /etc/defaultrouter file
Add an entry for the default router.
# vi /etc/defaultrouter router-IP |
where router-IP indicates the IP address of the default router for the host to use.
Verify that routing and packet forwarding are not running on the host.
# routeadm Configuration Current Current Option Configuration System State --------------------------------------------------------------- IPv4 routing disabled disabled IPv6 routing disabled disabled IPv4 forwarding disabled disabled IPv6 forwarding disabled disabled Routing services "route:default ripng:default" |
Add an entry for the default router in the local /etc/inet/hosts file.
For information about configuring /etc/inet/hosts, refer to How to Change the IPv4 Address and Other Network Configuration Parameters.
The following example shows how to configure static routing for hostb, a single-interface host on the network 172.20.1.0 that is shown in Figure 5–3. hostb needs to use Router 2 as its default router.
First, you would log in to hostb as superuser, or assume an equivalent role. Then, you would determine whether the /etc/defaultrouter file is present on the host:
# cd /etc # ls | grep defaultrouter |
No response from grep indicates that you need to create the /etc/defaultrouter file.
# vi /etc/defaultrouter 172.20.1.10 |
The entry in the /etc/defaultrouter file is the IP address of the interface on Router 2, which is attached to the 172.20.1.0 network. Next, you verify whether the host currently enables packet forwarding or routing.
# routeadm Configuration Current Current Option Configuration System State --------------------------------------------------------------- IPv4 routing disabled disabled IPv6 routing disabled disabled IPv4 forwarding enabled enabled IPv6 forwarding disabled disabled Routing services "route:default ripng:default" |
Packet forwarding is enabled for this particular host. You would turn it off as follows:
# svcadm disable ipv4-forwarding |
Lastly, you would make sure that the host's /etc/inet/hosts file has an entry for the new default router.
# vi /etc/inet/hosts 127.0.0.1 localhost 172.20.1.18 host2 #primary network interface for host2 172.20.1.10 router2 #default router for host2 |
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.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Verify whether the /etc/defaultrouter file exists.
# cd /etc # ls | grep defaultrouter |
If /etc/defaultrouter exists, delete any entry that you find there.
An empty /etc/defaultrouter file forces the host to use dynamic routing.
Verify whether packet forwarding and routing are enabled on the host.
# routeadm Configuration Current Current Option Configuration System State --------------------------------------------------------------- IPv4 routing disabled disabled IPv6 routing disabled disabled IPv4 forwarding enabled enabled IPv6 forwarding disabled disabled Routing services "route:default ripng:default" |
If packet forwarding is enabled, turn it off
Use either of the following commands:
For the routeadm command, type the following:
# routeadm -d ipv4-forwarding -u |
To use SMF, type the following:
# svcadm disable ipv4-forwarding |
Enable routing protocols on the host.
Use either of the following commands:
For the routeadm command, type the following:
# routeadm -e ipv4-routing -u |
To use SMF, type the following:
# svcadm enable route:default |
Now IPv4 dynamic routing is enabled. The host's routing table is dynamically maintained by the in.routed daemon.
The following example shows how to configure dynamic routing for hosta, a single-interface host on the network 192.168.5.0 that is shown in Figure 5–3. hosta currently uses Router 1 as its default router. However, hosta now needs to run dynamic routing.
First, you would log in to hosta as superuser or assume an equivalent role. Then, you would determine whether the /etc/defaultrouter file is present on the host:
# cd /etc # ls | grep defaultrouter defaultrouter |
The response from grep indicates that a /etc/defaultrouter file exists for hosta.
# vi /etc/defaultrouter 192.168.5.10 |
The file has the entry 192.168.5.10, which is the IP address for Router 1. You would delete this entry to enable static routing. Next, you would need to verify whether packet forwarding and routing are already enabled for the host.
# routeadm Configuration Current Current Option Configuration System State --------------------------------------------------------------- IPv4 routing disabled disabled IPv6 routing disabled disabled IPv4 forwarding disabled disabled IPv6 forwarding disabled disabled Routing services "route:default ripng:default" |
Both routing and packet forwarding are turned off for hosta. Turn on routing to complete the configuration of dynamic routing for hosta, as follows:
# svcadm enable route:default |
The transport layer protocols TCP, SCTP, and UDP are part of the standard Solaris OS 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 16, 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.
On the local system, assume the Network Management role or become superuser.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Set TCP tracing to enabled for all services managed by inetd.
# inetadm -M tcp_trace=TRUE |
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 Solaris OS 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.
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.
For information about SMF commands, refer to SMF Command-Line Administrative Utilities in System Administration Guide: Basic Administration.
For syntactical information, refer to the man pages for the SMF commands, as cited in the procedure.
For detailed information about SMF refer to the smf(5) man page.
Before you perform the following procedure, create a manifest file for the service. The procedure uses as an example a manifest for the echo service that is called echo.sctp.xml.
Log in to the local system with a user account that has write privileges for system files.
Edit the /etc/services file and add a definition for the new service.
Use the following syntax for the service definition.
service-name |port/protocol | aliases |
Add the new service.
Go to the directory where the service manifest is stored and type the following:
# cd dir-name # svccfg import service-manifest-name |
For a complete syntax of svccfg, refer to the svccfg(1M) man page.
Suppose you want to add a new SCTP echo service using the manifest echo.sctp.xml that is currently located in the service.dir directory. You would type the following:
# cd service.dir # svccfg import echo.sctp.xml |
Verify that the service manifest has been added:
# svcs FMRI |
For the FMRI argument, use the Fault Managed Resource Identifier (FMRI) of the service manifest. For example, for the SCTP echo service, you would use the following command:
# svcs svc:/network/echo:sctp_stream |
Your output should resemble the following:
STATE STIME FMRI disabled 16:17:00 svc:/network/echo:sctp_stream |
For detailed information about the svcs command, refer to the svcs(1) man page.
The output indicates that the new service manifest is currently disabled.
List the properties of the service to determine if you must make modifications.
# inetadm -l FMRI |
For detailed information about the inetadm command, refer to the inetadm(1M) man page.
For example, for the SCTP echo service, you would type the following:
# inetadm -l svc:/network/echo:sctp_stream SCOPE NAME=VALUE name="echo" endpoint_type="stream" proto="sctp" isrpc=FALSE wait=FALSE exec="/usr/lib/inet/in.echod -s" . . default tcp_trace=FALSE default tcp_wrappers=FALSE |
Enable the new service:
# inetadm -e FMRI |
Verify that the service is enabled:
For example, for the new echo service, you would type the following:
# inetadm | grep sctp_stream . . enabled online svc:/network/echo:sctp_stream |
The following example shows the commands to use and the file entries required to have the echo service use the SCTP transport layer protocol.
$ cat /etc/services . . echo 7/tcp echo 7/udp echo 7/sctp # cd service.dir # svccfg import echo.sctp.xml # svcs network/echo* STATE STIME FMRI disabled 15:46:44 svc:/network/echo:dgram disabled 15:46:44 svc:/network/echo:stream disabled 16:17:00 svc:/network/echo:sctp_stream # inetadm -l svc:/network/echo:sctp_stream SCOPE NAME=VALUE name="echo" endpoint_type="stream" proto="sctp" isrpc=FALSE wait=FALSE exec="/usr/lib/inet/in.echod -s" user="root" default bind_addr="" default bind_fail_max=-1 default bind_fail_interval=-1 default max_con_rate=-1 default max_copies=-1 default con_rate_offline=-1 default failrate_cnt=40 default failrate_interval=60 default inherit_env=TRUE default tcp_trace=FALSE default tcp_wrappers=FALSE # inetadm -e svc:/network/echo:sctp_stream # inetadm | grep echo disabled disabled svc:/network/echo:stream disabled disabled svc:/network/echo:dgram enabled online svc:/network/echo:sctp_stream |
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.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Set TCP wrappers to enabled.
# inetadm -M tcp_wrappers=TRUE |
Configure the TCP wrappers access control policy as described in the hosts_access(3) man page.
This man page can be found in the /usr/sfw/man directory on the SFW CD-ROM, which is packaged along with the Solaris OS CD-ROM.
This chapter contains tasks for configuring IPv6 on a network. The following major topics are covered:
For an overview of IPv6 concepts, refer to Chapter 3, Planning an IPv6 Addressing Scheme (Overview). For IPv6 planning tasks, refer to Chapter 4, Planning an IPv6 Network (Tasks). To find reference information about the tasks in this chapter, refer to Chapter 10, IPv6 in Depth (Reference).
The initial step in IPv6 configuration is enabling IPv6 on an interface. You can enable IPv6 support during the Solaris 10 installation process or by configuring IPv6 on the interfaces of an installed system.
During the 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.
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.
Task |
Description |
For Instructions |
---|---|---|
Enable IPv6 on an interface on a system that has already been installed with the Solaris 10 OS. |
Use this task for enabling IPv6 on an interface after the Solaris 10 OS has been installed. | |
Make the IPv6-enabled interface persist across reboots. |
Use this task to make the IPv6 address of the interface permanent. | |
Turn off IPv6 address autoconfiguration. |
Use this task if you need to manually configure the interface ID portion of the IPv6 address. |
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.
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 Solaris 10 installation.
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 Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Enable IPv6 on an interface.
# ifconfig inet6 interface plumb up |
Start the IPv6 daemonin.ndpd.
# /usr/lib/inet/in.ndpd |
You can display the status of a node's IPv6-enabled interfaces by using the ifconfig-a6 command.
This example shows how to enable IPv6 on the qfe0 interface. Before you begin, check the status of all interfaces configured on the system.
# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 qfe0: flags=1000863 <UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 172.16.27.74 netmask ffffff00 broadcast 172.16.27.255 ether 0:3:ba:13:14:e1 |
Only the qfe0 interface is currently configured for this system. Enable IPv6 on this interface as follows:
# ifconfig inet6 qfe0 plumb up # /usr/lib/inet/in.ndpd # ifconfig -a6 lo0: flags=2000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1 inet6 ::1/128 qfe0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 ether 0:3:ba:13:14:e1 inet6 fe80::203:baff:fe13:14e1/10 |
The example shows the status of the system's interface before and after qfe0becomes IPv6-enabled. The -a6 option of ifconfig shows just the IPv6 information for qfe0 and the loopback interface. Note that the output indicates that only a link-local address was configured for qfe0, fe80::203:baff:fe13:14e1/10. This address indicates that as of yet no router on the node's local link advertises a site prefix.
After IPv6 is enabled, you can use the ifconfig -a command to display both IPv4 and IPv6 addresses for all interfaces on a system.
To configure the IPv6 node as a router, go to Configuring an IPv6 Router.
To maintain the IPv6 interface configuration across reboots, see How to Enable Persistent IPv6 Interfaces.
To disable address autoconfiguration on the node, see How to Turn Off IPv6 Address Autoconfiguration.
To tailor the node as a server, see the suggestions in Administering IPv6-Enabled Interfaces on Servers.
This procedure explains how to enable IPv6 interfaces with autoconfigured IPv6 addresses that persist across subsequent reboots.
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.
Log in to the IPv6 node as Primary Administrator or as superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Create IPv6 addresses for interfaces that were added after installation.
# touch /etc/hostname6.interface |
(Optional) Create an /etc/inet/ndpd.conf file that defines parameters for interface variables on the node.
If you need to create temporary addresses for the host's interface, refer to Using Temporary Addresses for an Interface. For details about /etc/inet/ndpd.conf, refer to the ndpd.conf(4) man page and ndpd.conf Configuration File.
Reboot the node.
# reboot -- -r |
The reboot process sends router discovery packets. If a router responds with a site prefix, the node can configure any interface with a corresponding /etc/hostname6.interface file with a global IPv6 address. Otherwise, the IPv6-enabled interfaces are configured solely with link-local addresses. Rebooting also restarts in.ndpd and other network daemons in IPv6 mode.
This example shows how to make the IPv6 configuration for the qfe0 interface persist across reboots. In this example, a router on the local link advertises the site prefix and subnet ID 2001:db8:3c4d:15/64.
First, check the status of the system's interfaces.
# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 qfe0: flags=1000863 <UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 172.16.27.74 netmask ffffff00 broadcast 172.16.27.255 ether 0:3:ba:13:14:e1 |
# touch /etc/hostname6.qfe0 # reboot -- -r |
Verify that the IPv6 address you configured is still applied to the qfe0 interface.
# ifconfig -a6 qfe0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 ether 0:3:ba:13:14:e1 inet6 fe80::203:baff:fe13:14e1/10 qfe0:1: flags=2180841 <UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2 inet6 2001:db8:3c4d:15:203:baff:fe13:14e1/64 |
The output of ifconfig -a6 shows two entries for qfe0. The standard qfe0 entry includes the MAC address and the link-local address. A second entry, qfe0:1, indicates that a pseudo-interface was created for the additional IPv6 address on the qfe0 interface. The new, global IPv6 address, 2001:db8:3c4d:15:203:baff:fe13:14e1/64, includes the site prefix and subnet ID advertised by the local router.
To configure the new IPv6 node as a router, go to Configuring an IPv6 Router.
To disable address autoconfiguration on the node, see How to Turn Off IPv6 Address Autoconfiguration.
To tailor the new node as a server, see the suggestions in Administering IPv6-Enabled Interfaces on Servers.
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.
Log in to the IPv6 node as Primary Administrator or as superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Create an /etc/inet/ndpd.conf file for the node.
The /etc/inet/ndpd.conf file defines interface variables for the particular node. This file should have the following contents in order to turn off address autoconfiguration for all of the server's interfaces:
if-variable-name StatelessAddrConf false |
For details about /etc/inet/ndpd.conf, refer to the ndpd.conf(4) man page and ndpd.conf Configuration File.
Update the IPv6 daemon with your changes.
# pkill -HUP in.ndpd |
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.
Perform the next tasks in the order that is shown in the table.
Task |
Description |
For Instructions |
---|---|---|
1. Ensure that you have completed the required prerequisites before you begin IPv6 configuration. |
You must complete planning tasks and Solaris installation with IPv6 enabled interfaces before you configure an IPv6-enabled router. |
Chapter 4, Planning an IPv6 Network (Tasks) and Configuring an IPv6 Interface. |
2. Configure a router. |
Define the site prefix for the network. | |
3. Configure tunnel interfaces on the router. |
Set up a manual tunnel or a 6to4 tunnel interface on the router. The local IPv6 network needs tunnels to communicate with other, isolated IPv6 networks. | |
4. Configure the switches on the network. |
If your network configuration includes switches, configure them for IPv6 at this point in the configuration process. |
Refer to switch manufacturer's documentation. |
5. Configure any hubs on your network. |
If your network configuration includes hubs, configure them for IPv6 at this point in the configuration process. |
Refer to hub manufacturer's documentation. |
6. Configure the network name service for IPv6. |
Configure your primary name service (DNS, NIS, or LDAP) to recognize IPv6 addresses after the router is configured for IPv6. | |
7. (Optional) Modify the addresses for the IPv6-enabled interfaces on hosts and servers. |
After IPv6 router configuration, make further modifications on IPv6-enabled hosts and servers. |
Modifying an IPv6 Interface Configuration for Hosts and Servers |
Configure applications to support IPv6 |
Different applications might require different actions in order to support IPv6. |
Refer to applications' documentation |
This procedure assumes that all interfaces of the router were configured for IPv6 during Solaris installation.
On the system that will become the IPv6 router, assume the Primary Administrator role or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Review which interfaces on the router were configured for IPv6 during installation.
# ifconfig -a |
Check the output to ensure that the interfaces that you wanted to configure for IPv6 are now plumbed with link-local addresses. The following sample command output of ifconfig -a shows the IPv4 and IPv6 addresses that were configured for the router's interfaces.
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 dmfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 172.16.26.232 netmask ffffff00 broadcast 172.16.26.255 ether 0:3:ba:11:b1:15 dmfe1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 3 inet 172.16.26.220 netmask ffffff00 broadcast 172.16.26.255 ether 0:3:ba:11:b1:16 lo0: flags=2000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1 inet6 ::1/128 dmfe0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 ether 0:3:ba:11:b1:15 inet6 fe80::203:baff:fe11:b115/10 dmfe1: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 3 ether 0:3:ba:11:b1:16 inet6 fe80::203:baff:fe11:b116/10 |
The output also shows that the primary network interface dmfe0 and the additional interface dmfe1 were configured during installation with the IPv6 link–local addresses fe80::203:baff:fe11:b115/10 and fe80::203:baff:fe11:b116/10.
Configure IPv6 packet forwarding on all interfaces of the router.
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 |
The in.ripngd daemon handles IPv6 routing.
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.
For a list of variables and allowable values, refer to ndpd.conf Configuration File and the ndpd.conf(4)man page.
Type the following text into the /etc/inet/ndpd.conf file:
ifdefault AdvSendAdvertisements true prefixdefault AdvOnLinkFlag on AdvAutonomousFlag on |
This text tells the in.ndpd daemon to send out router advertisements over all interfaces of the router that are configured for IPv6.
Add additional text to the /etc/inet/ndpd.conf file to configure the site prefix on the various interfaces of the router.
The text should have the following format:
prefix global-routing-prefix:subnet ID/64 interface |
The following sample /etc/inet/ndpd.conf file configures the router to advertise the site prefix 2001:0db8:3c4d::/48 over the interfaces dmfe0 and dmfe1.
ifdefault AdvSendAdvertisements true prefixdefault AdvOnLinkFlag on AdvAutonomousFlag on if dmfe0 AdvSendAdvertisements 1 prefix 2001:0db8:3c4d:15::0/64 dmfe0 if dmfe1 AdvSendAdvertisements 1 prefix 2001:0db8:3c4d:16::0/64 dmfe1 |
Reboot the system.
The IPv6 router begins advertising on the local link any site prefix that is in the ndpd.conf file.
The following example shows output from the ifconfig -a command such as you would receive after you finish the Configuring an IPv6 Router procedure.
lo0: flags=1000849 <UP LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 dmfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 172.16.15.232 netmask ffffff00 broadcast 172.16.26.255 ether 0:3:ba:11:b1:15 dmfe1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 3 inet 172.16.16.220 netmask ffffff00 broadcast 172.16.26.255 ether 0:3:ba:11:b1:16 lo0: flags=2000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1 inet6 ::1/128 dmfe0: flags=2100841 <UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 2 ether 0:3:ba:11:b1:15 inet6 fe80::203:baff:fe11:b115/10 dmfe0:1: flags=2180841 <UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2 inet6 2001:db8:3c4d:15:203:baff:fe11:b115/64 dmfe1: flags=2100841 <UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 3 ether 0:3:ba:11:b1:16 inet6 fe80::203:baff:fe11:b116/10 dmfe1:1: flags=2180841 <UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 3 inet6 2001:db8:3c4d:16:203:baff:fe11:b116/64 |
In this example, each interface that was configured for IPv6 now has two addresses. The entry with the name of the interface, such as dmfe0, shows the link-local address for that interface. The entry with the form interface:n, such as dmfe0:1, shows a global IPv6 address. This address includes the site prefix that you configured in the /etc/ndpd.conf file, in addition to the interface ID.
To configure any tunnels from the routers that you have identified in your IPv6 network topology, refer to Configuring Tunnels for IPv6 Support.
For information about configuring switches and hubs on your network, refer to the manufacturer's documentation.
To configure IPv6 hosts, refer to Modifying an IPv6 Interface Configuration for Hosts and Servers.
To improve IPv6 support on servers, refer to Administering IPv6-Enabled Interfaces on Servers.
For detailed information about IPv6 commands, files, and daemons, refer to Solaris 10 IPv6 Implementation.
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.
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. | |
Create a temporary address for a host. |
Hide a host's interface ID by configuring a randomly created temporary address that is used as the lower 64 bits of the address. | |
Configure a token for the interface ID of a system. |
Create a 64-bit token to be used as the interface ID in an IPv6 address. |
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:
Time span in which the temporary address exists, after which the address is deleted from the host.
Elapsed time before the temporary address is deprecated. This time span should be shorter than the valid lifetime.
Duration of time before the expiration of the preferred lifetime, during which the host should generate a new temporary address.
You express the duration of time for temporary addresses as follows:
n number of seconds, which is the default
n number of hours (h)
n number of days (d)
Log in to the IPv6 host as Primary Administrator or as superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
If necessary, enable IPv6 on the host's interfaces
Refer to How to Enable an IPv6 Interface for the Current Session.
Edit the /etc/inet/ndpd.conf file to turn on temporary address generation.
(Optional) Specify the valid lifetime for the temporary address.
ifdefault TmpValidLifetime duration |
This syntax specifies the valid lifetime for all interfaces on a host. The value for duration should be in seconds, hours, or days. The default valid lifetime is 7 days. You can also use TmpValidLifetime with the if interface keywords to specify the valid lifetime for a temporary address of a particular interface.
(Optional) Specify a preferred lifetime for the temporary address, after which the address is deprecated.
if interface TmpPreferredLifetime duration |
This syntax specifies the preferred lifetime for the temporary address of a particular interface. The default preferred lifetime is one day. You can also use TmpPreferredLifetime with the ifdefault keyword to specify the preferred lifetime for the temporary addresses on all interfaces of a host.
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 TmpRegenAdvance duration |
This syntax specifies the lead time in advance of address deprecation for the temporary addresses of all interfaces on a host. The default is 5 seconds.
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 6–5.
The output from ifconfig should have the word TEMPORARY in the same line as the interface definition.
The following example shows a segment of an /etc/inet/ndpd.conf file with temporary addresses enabled for the primary network interface.
ifdefault TmpAddrsEnabled true ifdefault TmpValidLifetime 14d ifdefault TmpPreferredLifetime 7d ifdefault TmpRegenAdvance 6s |
This example shows the output of the ifconfig command after temporary addresses are created.
# ifconfig -a6 lo0: flags=2000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1 inet6 ::1/128 hme0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 ether 8:0:20:b9:4c:54 inet6 fe80::a00:20ff:feb9:4c54/10 hme0:1: flags=2080841 <UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2 inet6 2001:db8:3c4d:15:a00:20ff:feb9:4c54/64 hme0:2: flags=802080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6,TEMPORARY> mtu 1500 index 2 inet6 2001:db8:3c4d:15:7c37:e7d1:fc9c:d2cb/64 |
Note that the line following interface hme0:2 includes the word TEMPORARY. This designation indicates that the address 2001:db8:3c4d:15:7c37:e7d1:fc9c:d2cb/64 has a temporary interface ID.
To set up name service support for IPv6 addresses, see Configuring Name Service Support for IPv6.
To configure IPv6 addresses for a server, see How to Configure a User-Specified IPv6 Token.
To monitor activities on IPv6 nodes, see Chapter 7, Administering a TCP/IP Network (Tasks).
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.
The difference between user-specified tokens and temporary addresses is that temporary addresses are randomly generated, rather than explicitly created by a user.
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.
Assume the Primary Administrator role or become superuser on the node.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Verify that the interface you want to configure with a token is plumbed.
An interface must be plumbed before you can configure a token for its IPv6 address.
# ifconfig -a6 |
qfe0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 ether 0:3:ba:13:14:e1 inet6 fe80::203:baff:fe13:14e1/10 |
This output shows that the network interface qfe0 is plumbed and has the link-local address fe80::203:baff:fe13:14e1/10. This address was automatically configured during installation.
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 |
In the following example, the interface bge0:1 has an autoconfigured IPv6 address. The subnet prefix 2001:db8:3c4d:152:/64 is advertised by a router on the node's local link. The interface ID 2c0:9fff:fe56:8255 is generated from bge0:1's MAC address.
# ifconfig -a6 lo0: flags=2002000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1 inet6 ::1/128 bge0: flags=2100801 <UP,MULTICAST,IPv6> mtu 1500 index 5 inet6 fe80::2c0:9fff:fe56:8255/10 ether 0:c0:9f:56:82:55 bge0:1: flags=2180801 <UP, MULTICAST,ADDRCONF,IPv6>mtu 1500 index 5 inet6 2001:db8:3c4d:152:c0:9fff:fe56:8255/64 # ifconfig bge0 inet6 token ::1a:2b:3c:4d/64 # vi /etc/hostname6.bge0 token ::1a:2b:3c:4d/64 # pkill -HUP -in.ndpd # ifconfig -a6 lo0: flags=2002000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1 inet6 ::1/128 bge0: flags=2100801 <UP,MULTICAST,IPv6> mtu 1500 index 5 inet6 fe80::2c0:9fff:fe56:8255/10 ether 0:c0:9f:56:82:55 bge0:1: flags=2180801 <UP, MULTICAST,ADDRCONF,IPv6>mtu 1500 index 5 inet6 2001:db8:3c4d:152:1a:2b:3c:4d/64 |
After the token is configured, the global address on the second status line of bge0:1 now has 1a:2b:3c:4dconfigured for its interface ID.
To update the name services with the IPv6 addresses of the server, see Configuring Name Service Support for IPv6.
To monitor server performance, see Chapter 7, Administering a TCP/IP Network (Tasks).
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.
The next procedure assumes the following:
Solaris 10 OS is already installed on the server.
You enabled IPv6 on the server's interfaces either during Solaris OS 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.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Ensure that an IPv6 subnet prefix is configured on a router on the same link as the server.
For more information, refer to Configuring an IPv6 Router.
Use the appropriate strategy for the interface ID for the server's IPv6-enabled interfaces.
By default, IPv6 address autoconfiguration uses the MAC address of an interface when creating the interface ID portion of the IPv6 address. If the IPv6 address of the interface is well known, swapping one interface for another interface can cause problems. The MAC address of the new interface will be different. During address autoconfiguration, a new interface ID is generated.
For an IPv6-enabled interface that you do not plan to replace, use the autoconfigured IPv6 address, as introduced in IPv6 Address Autoconfiguration.
For IPv6-enabled interfaces that must appear anonymous outside the local network, consider using a randomly generated token for the interface ID. For instructions and an example, refer to How to Configure a Temporary Address.
For IPv6-enabled interfaces that you plan to swap on a regular basis, create tokens for the interface IDs. For instructions and an example, refer to How to Configure a User-Specified IPv6 Token.
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. | |
Manually configure IPv6 over IPv6 tunnels. |
Manually configures an IPv6 tunnel over an IPv6 network, typically used within a large enterprise network. | |
Manually configure IPv4 over IPv6 tunnels. |
Manually configures an IPv4 tunnel over an IPv6 network, useful for large networks with both IPv4 and IPv6 networks. | |
Automatically configure IPv6 over IPv4 tunnels (6to4 tunnels). |
Create an automatic, 6to4 tunnel, a solution for reaching an external IPv6 site over the Internet. | |
Configure a tunnel between a 6to4 router and a 6to4 relay router. |
Enables a tunnel to a 6to4 relay router by using the 6to4relay command. |
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 Solaris IPv6 implementation supports the following types of tunnel encapsulation:
IPv6 over IPv4 tunnels
IPv6 over IPv6 tunnels
IPv4 over IPv6 tunnels
6to4 tunnels
For conceptual descriptions of tunnels, see IPv6 Tunnels.
This procedure describes how to set up a tunnel from an IPv6 node to a remote IPv6 node over an IPv4 network.
Log in to the local tunnel endpoint as Primary Administrator or as superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Create the /etc/hostname6.ip.tunn file.
where n represents the tunnel number, beginning at zero for the first tunnel. Then, add entries by following these substeps:
Add the tunnel source address and the tunnel destination address.
tsrc IPv4-source-address tdst IPv4-destination-address up |
(Optional) Add a logical interface for the source IPv6 address and the destination IPv6 addresses.
addif IPv6-source-address IPv6-destination-address |
Omit this substep if you want the address autoconfigured for this interface. You do not need to configure link-local addresses for your tunnel.
Reboot the system.
Repeat this task on the opposite endpoint of the tunnel.
This sample /etc/hostname6.ip.tun file shows a tunnel for which global source addresses and global destination addresses are manually configured.
tsrc 192.168.8.20 tdst 192.168.7.19 up addif 2001:db8:3c4d:8::fe12:528 2001:db8:3c4d:7:a00:20ff:fe12:1234 up |
These parameters are the equivalent of the following in ifconfig:
# ifconfig ip.tun0 inet6 plumb # ifconfig ip.tun0 inet6 tsrc 192.168.8.20 tdst 192.168.7.19 up # ifconfig ip.tun0 inet6 addif 2001:db8:3c4d:8::fe12:528 \ 2001:db8:3c4d:7:a00:20ff:fe12:1234 up |
This procedure describes how to set up a tunnel from an IPv6 node to a remote IPv6 node over an IPv6 network.
Log in to the local tunnel endpoint as Primary Administrator or as superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Create the /etc/hostname6.ip6.tun n file.
Use the values 0, 1, 2, and so on, for n. Then, add entries by following these substeps.
Add the tunnel source address and the tunnel destination address.
tsrc IPv6-source-address tdst IPv6-destination-address IPv6-packet-source-address IPv6-packet-destination-address up |
(Optional) Add a logical interface for the source IPv6 address and destination IPv6 address.
addif IPv6-source-address IPv6-destination-address up |
Omit this step if you want the address autoconfigured for this interface. You do not need to configure link-local addresses for your tunnel.
Reboot the system.
Repeat this procedure at the opposite endpoint of the tunnel.
This example shows the entry for an IPv6 over IPv6 tunnel.
tsrc 2001:db8:3c4d:22:20ff:0:fe72:668c tdst 2001:db8:3c4d:103:a00:20ff:fe9b:a1c3 fe80::4 fe80::61 up |
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.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Create the /etc/hostname.ip6.tunn file.
Use the values 0, 1, 2, and so on, for n. Then, add entries by following these steps:
Reboot the local host.
Repeat this procedure at the opposite endpoint of the tunnel.
This example shows the entry for an IPv4 over IPv6 tunnel.
tsrc 2001:db8:3c4d:114:a00:20ff:fe72:668c tdst 2001:db8:3c4d:103:a00:20ff:fe9b:a1c3 10.0.0.4 10.0.0.61 up |
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 configure 6to4 routing on an IPv6 network, you must have done the following:
Configured IPv6 on all appropriate nodes at the prospective 6to4 site, as described in Modifying an IPv6 Interface Configuration for Hosts and Servers.
Selected at least one router with a connection to an IPv4 network to become the 6to4 router.
Configured a globally unique IPv4 address for the prospective 6to4 router's interface to the IPv4 network. The IPv4 address must be static.
Do not use a dynamically allocated IPv4 address, as described in Chapter 11, About Solaris DHCP (Overview). Global dynamically allocated addresses might change over time, which can adversely affect your IPv6 addressing plan.
Log in to the prospective 6to4 router as Primary Administrator or as superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
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:
Indicates that this interface is used as a tunnel source.
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.
Specifies the 6to4 prefix.
Specifies, in hexadecimal notation, the IPv4 address of the pseudo-interface.
Specifies, in hexadecimal notation, a subnet ID other than 0.
Specifies an interface ID other than 1.
Indicates that the 6to4 prefix has a length of 64 bits.
Configures the 6to4 interface as “up.”
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:
ip.6to4tun0: flags=2200041<UP,RUNNING,NONUD,IPv6>mtu 1480 index 11 inet tunnel src 111.222.33.44 tunnel hop limit 60 inet6 2002:6fde:212c:10:/64 |
Edit the /etc/inet/ndpd.conf file to advertise 6to4 routing.
For detailed information, refer to the ndpd.conf(4) man page.
Specify the subnet to receive the advertisement in the first line.
Create an if entry with the following format:
if subnet-interface AdvSendAdvertisements 1 |
For example, to advertise 6to4 routing to the subnet that is connected to interface hme0, replace subnet-interface with hme0.
if hme0 AdvSendAdvertisements 1 |
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.
For instructions, go to Configuring Name Service Support for IPv6.
The following is an example of the short form of /etc/hostname6.ip.6to4tun0:
# cat /etc/hostname6.ip.6to4tun0 tsrc 111.222.33.44 up |
Here is an example of the long form of /etc/hostname6.ip.6to4tun0:
# cat /etc/hostname6.ip.6to4tun0 tsrc 111.222.33.44 2002:6fde:212c:20:1/64 up |
The following sample shows output of the ifconfig command for a 6to4 pseudo-interface:
# ifconfig ip.6to4tun0 inet6 ip.6to4tun0: flags=2200041<UP,RUNNING,NONUD,IPv6> mtu 1480 index 11 inet tunnel src 192.168.87.188 tunnel hop limit 60 inet6 2002:c0a8:57bc::1/64 |
The following sample /etc/inet/ndpd.conf file advertises 6to4 routing on two subnets:
if qfe0 AdvSendAdvertisements 1 prefix 2002:c0a8:57bc:10::/64 qfe0 if qfe1 AdvSendAdvertisements 1 prefix 2002:c0a8:57bc:2::/64 qfe1 |
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.
Because of major security issues, by default, 6to4 relay router support is disabled in the Solaris OS. See Security Issues When Tunneling to a 6to4 Relay Router.
Before you enable a tunnel to a 6to4 relay router, you must have completed the following tasks:
Configured a 6to4 router at your site, as explained in How to Configure a 6to4 Tunnel
Reviewed the security issues that are involved in tunneling to a 6to4 relay router
Log in to the 6to4 router as Primary Administrator or as superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Enable a tunnel to the 6to4 relay router by using either of the following formats:
Enable a tunnel to an anycast 6to4 relay router.
# /usr/sbin/6to4relay -e |
The -e option sets up a tunnel between the 6to4 router and an anycast 6to4 relay router. Anycast 6to4 relay routers have the well-known IPv4 address 192.88.99.1. The anycast relay router that is physically nearest to your site becomes the endpoint for the 6to4 tunnel. This relay router then handles packet forwarding between your 6to4 site and a native IPv6 site.
For detailed information about anycast 6to4 relay routers, refer to RFC 3068, "An Anycast Prefix for 6to4 Relay Routers".
Enable a tunnel to a specific 6to4 relay router.
# /usr/sbin/6to4relay -e -a relay-router-address |
The -a option indicates that a specific router address is to follow. Replace relay-router-address with the IPv4 address of the specific 6to4 relay router with which you want to enable a tunnel.
The tunnel to the 6to4 relay router remains active until you remove the 6to4 tunnel pseudo-interface.
Delete the tunnel to the 6to4 relay router, when the tunnel is no longer needed:
# /usr/sbin/6to4relay -d |
(Optional) Make the tunnel to the 6to4 relay router persistent across reboots.
Your site might have a compelling reason to have the tunnel to the 6to4 relay router reinstated each time the 6to4 router reboots. To support this scenario, you must do the following:
Edit the/etc/default/inetinit file.
The line that you need to modify is at the end of the file.
Change the “NO” value in the line ACCEPT6TO4RELAY=NO to “YES”.
(Optional) Create a tunnel to a specific 6to4 relay router that persists across reboots.
For the parameter RELAY6TO4ADDR, change the address 192.88.99.1 to the IPv4 address of the 6to4 relay router that you want to use.
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 the Solaris OS:
# /usr/sbin/6to4relay 6to4relay: 6to4 Relay Router communication support is disabled. |
When support for 6to4 relay routers is enabled, you receive the following output:
# /usr/sbin/6to4relay 6to4relay: 6to4 Relay Router communication support is enabled. IPv4 destination address of Relay Router=192.88.99.1 |
This section describes how to configure the DNS and NIS name services to support IPv6 services.
LDAP supports IPv6 without requiring IPv6-specific configuration tasks.
For full details for administering DNS, NIS, and LDAP, refer to the System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
Log in to the primary or secondary DNS server as Primary Administrator or as superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Edit the appropriate DNS zone file by adding AAAA records for each IPv6-enabled node:
host-name IN AAAA host-address |
Edit the DNS reverse zone file and add PTR records:
host-address IN PTR hostname |
For detailed information on DNS administration, refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
This example shows an IPv6 address in the reverse zone file.
$ORIGIN ip6.int. 8.2.5.0.2.1.e.f.f.f.9.2.0.0.a.0.6.5.2.9.0.0.0.0.0.0.0.0.2.0.0.0 \ IN PTR vallejo.Eng.apex.COM. |
You can use the nslookup command to display IPv6 name service information.
Under your user account, run the nslookup command.
% /usr/sbin/nslookup |
The default server name and address appear, followed by the nslookup command's angle bracket prompt.
View information about a particular host by typing the following commands at the angle bracket prompt:
>set q=any >host-name |
Type the following command to view only AAAA records:
>set q=AAAA hostname |
Quit the nslookup command by typing exit.
This example shows the results of nslookup in an IPv6 network environment.
% /usr/sbin/nslookup Default Server: dnsserve.local.com Address: 10.10.50.85 > set q=AAAA > host85 Server: dnsserve.local.com Address: 10.10.50.85 host85.local.com IPv6 address = 2::9256:a00:fe12:528 > exit |
In this procedure, you use the nslookup command to display PTR records for DNS IPv6.
Under your user account, run the nslookup command.
% /usr/sbin/nslookup |
The default server name and address display, followed by the nslookup command's angle bracket prompt.
Type the following at the angle bracket prompt to see the PTR records:
>set q=PTR |
Quit the command by typing exit.
The following example shows the PTR record display from the nslookup command.
% /usr/sbin/nslookup Default Server: space1999.Eng.apex.COM Address: 192.168.15.78 > set q=PTR > 8.2.5.0.2.1.e.f.f.f.0.2.0.0.a.0.6.5.2.9.0.0.0.0.0.0.0.0.2.0.0.0.ip6.int 8.2.5.0.2.1.e.f.f.f.0.2.0.0.a.0.6.5.2.9.0.0.0.0.0.0.0.0.2.0.0.0.ip6.int name = vallejo.ipv6.Eng.apex.COM ip6.int nameserver = space1999.Eng.apex.COM > exit |
In this procedure, you use the ypmatch command to display IPv6 information through NIS:
Under your user account, type the following to display IPv6 addresses in NIS:
% ypmatch hostname hosts .byname |
The information about the specified hostname displays.
This chapter contains tasks for administering a TCP/IP network. The following topics are covered:
The tasks assume that you have an operational TCP/IP network at your site, either IPv4-only or dual-stack IPv4/IPv6. If you want to implement IPv6 at your site but have not done so, refer to following chapters for more information:
To plan an IPv6 implementation, refer to Chapter 4, Planning an IPv6 Network (Tasks).
To configure IPv6 and create a dual-stack network environment, refer to Chapter 6, Enabling IPv6 on a Network (Tasks).
Task |
Description |
For Information |
---|---|---|
Display configuration information about an interface. |
Determine the current configuration of each interface on a system. | |
Display interface address assignments. |
Determine the address assignments for all interfaces on the local system. | |
Display statistics on a per-protocol basis. |
Monitor the performance of the network protocols on a particular system. | |
Display network status. |
Monitor your system by displaying all sockets and routing table entries. The output includes the inet address family for IPv4 and inet6 address family for IPv6. | |
Display the status of network interfaces. |
Monitor the performance of network interfaces, which is useful for troubleshooting transmission problems. | |
Display packet transmission status. |
Monitor the state of packets as they are sent over the wire. |
How to Display the Status of Transmissions for Packets of a Specific Address Type |
Control the display output of IPv6-related commands. |
Controls the output of the ping, netstat, ifconfig, and traceroute commands. Creates a file that is named inet_type. Sets the DEFAULT_IP variable in this file. | |
Monitor network traffic. |
Displays all IP packets by using the snoop command. | |
Trace all routes that are known to the network's routers. |
Uses the traceroute command to show all routes. |
You use the ifconfig command to manually assign IP addresses to interfaces and to manually configure interface parameters. In addition, the Solaris startup scripts run ifconfig to configure pseudo interfaces, such as 6to4 tunnel endpoints.
This book contains many tasks that use the various options of the versatile ifconfig command. For a complete description of this command, its options, and its variables, refer to the ifconfig(1M) man page. The basic syntax of ifconfig follows:
ifconfig interface [protocol-family]
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 Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Obtain information about a particular interface.
# ifconfig interface |
The output from the ifconfig command has the following format:
Status line
The first line in the ifconfig command output includes the interface name and status flags currently associated with the interface. Also, the status line includes the maximum transmission unit (MTU) that is configured for the particular interface and an index number. Use the status line to determine the current state of the interface.
IP address information line
The second line of the ifconfig output includes the IPv4 address or IPv6 address that is configured for the interface. For an IPv4 address, the configured netmask and broadcast address are also displayed.
MAC address line
When you run the ifconfig command as superuser or with a similar role, the ifconfig output contains a third line. For an IPv4 address, the third line shows the MAC address (Ethernet layer address) that is assigned to the interface. For an IPv6 address, the third line in the output shows the link-local address that the IPv6 in.ndpd daemon generates from the MAC address.
The following example shows how to obtain information about the eri interface on a particular host by using the ifconfig command.
# ifconfig eri eri0: flags=863<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 1 inet 10.0.0.112 netmask ffffff80 broadcast 10.8.48.127 ether 8:0:20:b9:4c:54 |
The next table describes the variable information in an ifconfig query. The preceding output is used as an example.
Variable |
Screen Output |
Description |
---|---|---|
Interface name |
eri0 |
Indicates the device name of the interface whose status was requested in the ifconfig command. |
Interface status |
flags=863<UP |
Displays the status of the interface, including any flags that are currently associated with the interface. Here you can determine whether the interface is currently initialized (UP) or not initialized (DOWN). |
Broadcast status |
BROADCAST |
Indicates that the interface supports IPv4 broadcasts. |
Transmission status |
RUNNING |
Indicates that the system is transmitting packets through the interface. |
Multicast status |
MULTICAST, IPv4 |
Shows that the interface supports multicast transmissions. The example interface supports IPv4 multicast transmissions. |
Maximum transmission unit |
mtu 1500 |
Shows that this interface has a maximum transfer size of 1500 octets. |
IP address |
inet 10.0.0.112 |
Displays the IPv4 or IPv6 address that is assigned to the interface. Example interface eri0 has the IPv4 address 10.0.0.112. |
Netmask |
netmask ffffff80 |
Displays the IPv4 netmask of the particular interface. Note that IPv6 addresses do not use netmasks. |
MAC address |
ether 8:0:20:b9:4c:54 |
Shows the interface's Ethernet layer address. |
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.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Obtain information about all interfaces.
You can use variations of the ifconfig -a command to do the following:
View all addresses of all interfaces on the system.
# ifconfig -a |
View all IPv4 addresses that are assigned to a system's interfaces.
# ifconfig -a4 |
If the local system is IPv6-enabled, display all IPv6 addresses that are assigned to a system's interfaces.
ifconfig -a6 |
This example shows entries for a host with solely a primary network interface, qfe0. Nevertheless, the ifconfig output shows that three forms of addresses are currently assigned to qfe0: loopback (lo0), IPv4 (inet), and IPv6 (inet6). In the IPv6 section of the output, note that the line for interface qfe0 displays the link-local IPv6 address. The second address for qfe0 is displayed on the qfe0:1 line.
% ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 qfe0: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.112 netmask ffffff80 broadcast 10.0.0.127 ether 8:0:20:b9:4c:54 lo0: flags=2000849 <UP,RUNNING,MULTICAST,IPv6> mtu 8252 index 1 inet6 ::1/128 qfe0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 ether 8:0:20:b9:4c:54 inet6 fe80::a00:20ff:feb9:4c54/10 qfe0:1: flags=2080841 <UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2 inet6 2001:db8:3c4d:48:a00:20ff:feb9:4c54/64 |
This example shows the IPv4 address that is configured for a multihomed host. You do not need to be logged in as superuser to run this form of the ifconfig command.
% ifconfig -a4 lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 qfe0: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.112 netmask ffffff80 broadcast 10.0.0.127 ether 8:0:20:b9:4c:54 qfe1: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.118 netmask ffffff80 broadcast 10.0.0.127 ether 8:0:20:6f:5e:17 |
This example shows only the IPv6 addresses that are configured for a particular host. You do not need to be logged in as superuser to run this form of the ifconfig command.
% ifconfig -a6 lo0: flags=2000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1 inet6 ::1/128 qfe0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 ether 8:0:20:b9:4c:54 inet6 fe80::a00:20ff:feb9:4c54/10 qfe0:1: flags=2080841 <UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2 inet6 2001:db8:3c4d:48:a00:20ff:feb9:4c54/64 |
This output from ifconfig shows the following three types of IPv6 address forms that are assigned to the single interface of a host:
IPv6 loopback address.
Link-local address that is assigned to the primary network interface.
IPv6 address, including subnet prefix. The term ADDRCONF in the output indicates that this address was autoconfigured by the host.
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.
The netstat -s option displays protocol statistics for the UDP, TCP, SCTP, ICMP, and IP protocols.
You can use your Solaris user account to obtain output from the netstat command.
The following example shows the output of the netstat -s command. Parts of the output have been truncated. The output can indicate areas where a protocol is having problems. For example, statistical information from ICMPv4 and ICMPv6 can indicate where the ICMP protocol has found errors.
RAWIP rawipInDatagrams = 4701 rawipInErrors = 0 rawipInCksumErrs = 0 rawipOutDatagrams = 4 rawipOutErrors = 0 UDP udpInDatagrams = 10091 udpInErrors = 0 udpOutDatagrams = 15772 udpOutErrors = 0 TCP tcpRtoAlgorithm = 4 tcpRtoMin = 400 tcpRtoMax = 60000 tcpMaxConn = -1 . . tcpListenDrop = 0 tcpListenDropQ0 = 0 tcpHalfOpenDrop = 0 tcpOutSackRetrans = 0 IPv4 ipForwarding = 2 ipDefaultTTL = 255 ipInReceives =300182 ipInHdrErrors = 0 ipInAddrErrors = 0 ipInCksumErrs = 0 . . ipsecInFailed = 0 ipInIPv6 = 0 ipOutIPv6 = 3 ipOutSwitchIPv6 = 0 IPv6 ipv6Forwarding = 2 ipv6DefaultHopLimit = 255 ipv6InReceives = 13986 ipv6InHdrErrors = 0 ipv6InTooBigErrors = 0 ipv6InNoRoutes = 0 . . rawipInOverflows = 0 ipv6InIPv4 = 0 ipv6OutIPv4 = 0 ipv6OutSwitchIPv4 = 0 ICMPv4 icmpInMsgs = 43593 icmpInErrors = 0 icmpInCksumErrs = 0 icmpInUnknowns = 0 . . icmpInOverflows = 0 ICMPv6 icmp6InMsgs = 13612 icmp6InErrors = 0 icmp6InDestUnreachs = 0 icmp6InAdminProhibs = 0 . . icmp6OutGroupQueries= 0 icmp6OutGroupResps = 2 icmp6OutGroupReds = 0 IGMP: 12287 messages received 0 messages received with too few bytes 0 messages received with bad checksum 12287 membership queries received SCTP sctpRtoAlgorithm = vanj sctpRtoMin = 1000 sctpRtoMax = 60000 sctpRtoInitial = 3000 sctpTimHearBeatProbe = 2 sctpTimHearBeatDrop = 0 sctpListenDrop = 0 sctpInClosed = 0 |
You can display the status of the transport protocols through the netstat command. For detailed information, refer to the netstat(1M) man page.
Display the status of the TCP and SCTP transport protocols on a system.
$ netstat |
Display the status of a particular transport protocol on a system.
$ netstat -P transport-protocol |
Values for the transport-protocol variable are tcp, sctp, or udp.
This example shows the output of the basic netstat command. Note that IPv4-only information is displayed.
$ netstat TCP: IPv4 Local Address Remote Address Swind Send-Q Rwind Recv-Q State ----------------- -------------------- ----- ------ ----- ------ ------- lhost-1.login abc.def.local.Sun.COM.980 49640 0 49640 0 ESTABLISHED lhost-1.login ghi.jkl.local.Sun.COM.1020 49640 1 49640 0 ESTABLISHED remhost-1.1014 mno.pqr.remote.Sun.COM.nfsd 49640 0 49640 0 TIME_WAIT SCTP: Local Address Remote Address Swind Send-Q Rwind Recv-Q StrsI/O State ---------------- -------------- ----- ------ ------ ------ ------ ------- *.echo 0.0.0.0 0 0 102400 0 128/1 LISTEN *.discard 0.0.0.0 0 0 102400 0 128/1 LISTEN *.9001 0.0.0.0 0 0 102400 0 128/1 LISTEN |
This example shows the results when you specify the -P option of netstat.
$ netstat -P tcp TCP: IPv4 Local Address Remote Address Swind Send-Q Rwind Recv-Q State ----------------- -------------------- ----- ------ ----- ------ ------- lhost-1.login abc.def.local.Sun.COM.980 49640 0 49640 0 ESTABLISHED lhost.login ghi.jkl.local.Sun.COM.1020 49640 1 49640 0 ESTABLISHED remhost.1014 mno.pqr.remote.Sun.COM.nfsd 49640 0 49640 0 TIME_WAIT TCP: IPv6 Local Address Remote Address Swind Send-Q Rwind Recv-Q State If ---------------- ---------------------- ------ ----- ------ ----------- ----- localhost.38983 localhost.32777 49152 0 49152 0 ESTABLISHED localhost.32777 localhost.38983 49152 0 49152 0 ESTABLISHED localhost.38986 localhost.38980 49152 0 49152 0 ESTABLISHED |
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.
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, or ethers database.
However, if the input packet count is steady over time, then the machine does not see the packets at all. This outcome suggests a different type of failure, possibly a hardware problem.
Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue lo0 8232 loopback localhost 142 0 142 0 0 0 hme0 1500 host58 host58 1106302 0 52419 0 0 0 Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis lo0 8252 localhost localhost 142 0 142 0 0 hme0 1500 fe80::a00:20ff:feb9:4c54/10 fe80::a00:20ff:feb9:4c54 1106305 0 52422 0 0 |
The -a option of the netstat command enables you to view the status of sockets on the local host.
Type the following to display the status of sockets and routing table entries:
You can use your user account to run this option of netstat.
% netstat -a |
The output of the netstat -a command shows extensive statistics. The following example shows portions of typical netstat -a output.
UDP: IPv4 Local Address Remote Address State -------------------- -------------------- ------- *.bootpc Idle host85.bootpc Idle *.* Unbound *.* Unbound *.sunrpc Idle *.* Unbound *.32771 Idle *.sunrpc Idle *.* Unbound *.32775 Idle *.time Idle . . *.daytime Idle *.echo Idle *.discard Idle UDP: IPv6 Local Address Remote Address State If --------------------------------- --------------------------------- ---------- ----- *.* Unbound *.* Unbound *.sunrpc Idle *.* Unbound *.32771 Idle *.32778 Idle *.syslog Idle . . TCP: IPv4 Local Address Remote Address Swind Send-Q Rwind Recv-Q State -------------------- -------------------- ----- ------ ----- ------ ------- *.* *.* 0 0 49152 0 IDLE localhost.4999 *.* 0 0 49152 0 LISTEN *.sunrpc *.* 0 0 49152 0 LISTEN *.* *.* 0 0 49152 0 IDLE *.sunrpc *.* 0 0 49152 0 LISTEN . . *.printer *.* 0 0 49152 0 LISTEN *.time *.* 0 0 49152 0 LISTEN *.daytime *.* 0 0 49152 0 LISTEN *.echo *.* 0 0 49152 0 LISTEN *.discard *.* 0 0 49152 0 LISTEN *.chargen *.* 0 0 49152 0 LISTEN *.shell *.* 0 0 49152 0 LISTEN *.shell *.* 0 0 49152 0 LISTEN *.kshell *.* 0 0 49152 0 LISTEN *.login . . *.* 0 0 49152 0 LISTEN *TCP: IPv6 Local Address Remote Address Swind Send-Q Rwind Recv-Q State If ----------------------- ----------------------- ----- ------ ----- ------ ---- *.* *.* 0 0 49152 0 IDLE *.sunrpc *.* 0 0 49152 0 LISTEN *.* *.* 0 0 49152 0 IDLE *.32774 *.* 0 0 49152 |
Use the -f option of the netstat command to view statistics related to packet transmissions of a particular address family.
View statistics for transmissions of either IPv4 or IPv6 packets.
$ netstat -f inet | inet6 |
To view IPv4 transmission information, type inet as the argument to netstat -f. Use inet6 as the argument to netstat -f to view IPv6 information.
The following example shows output from the netstat -f inet command.
TCP: IPv4 Local Address Remote Address Swind Send-Q Rwind Recv-Q State -------------------- -------------------- ----- ------ ----- ------ ------- host58.734 host19.nfsd 49640 0 49640 0 ESTABLISHED host58.38063 host19.32782 49640 0 49640 0 CLOSE_WAIT host58.38146 host41.43601 49640 0 49640 0 ESTABLISHED host58.996 remote-host.login 49640 0 49206 0 ESTABLISHED |
The following example shows output from the netstat -f inet6 command.
TCP: IPv6 Local Address Remote Address Swind Send-Q Rwind Recv-Q State If ------------------ ------------------------- ----- ------ ----- ------ --------- ----- localhost.38065 localhost.32792 49152 0 49152 0 ESTABLISHED localhost.32792 localhost.38065 49152 0 49152 0 ESTABLISHED localhost.38089 localhost.38057 49152 0 49152 0 ESTABLISHED |
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 example shows output from the netstat -r command.
Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- host15 myhost U 1 31059 hme0 10.0.0.14 myhost U 1 0 hme0 default distantrouter UG 1 2 hme0 localhost localhost UH 42019361 lo0 Routing Table: IPv6 Destination/Mask Gateway Flags Ref Use If --------------------------- --------------------------- ----- --- ------ ----- 2002:0a00:3010:2::/64 2002:0a00:3010:2:1b2b:3c4c:5e6e:abcd U 1 0 hme0:1 fe80::/10 fe80::1a2b:3c4d:5e6f:12a2 U 1 23 hme0 ff00::/8 fe80::1a2b:3c4d:5e6f:12a2 U 1 0 hme0 default fe80::1a2b:3c4d:5e6f:12a2 UG 1 0 hme0 localhost localhost UH 9 21832 lo0 |
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. |
You can use the ping command to determine the status of a remote host. When you run ping, the ICMP protocol sends a datagram to the host that you specify, asking for a response. ICMP is the protocol responsible for error handling on a TCP/IP network. When you use ping, you can find out whether an IP connection exists for the specified remote host.
The following is the basic syntax of ping:
/usr/sbin/ping host [timeout]
In this syntax, host is the name of the remote host. The optional timeout argument indicates the time in seconds for the ping command to continue trying to reach the remote host. The default is 20 seconds. For additional syntax and options, refer to the ping(1M) man page.
Type the following form of the ping command:
$ ping hostname |
If host hostname is accepting ICMP transmissions, this message is displayed:
hostname is alive |
This message indicates that hostname responded to the ICMP request. However, if hostname is down or cannot receive the ICMP packets, you receive the following response from the ping command:
no answer from hostname |
Use the -s option of the ping command to determine if a remote host is running but nevertheless losing packets.
The ping -s hostname command continually sends packets to the specified host until you send an interrupt character or a time out occurs. The responses on your screen resemble the following:
& ping -s host1.domain8 PING host1.domain8 : 56 data bytes 64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=0. time=1.67 ms 64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=1. time=1.02 ms 64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=2. time=0.986 ms 64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=3. time=0.921 ms 64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=4. time=1.16 ms 64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=5. time=1.00 ms 64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=5. time=1.980 ms ^C ----host1.domain8 PING Statistics---- 7 packets transmitted, 7 packets received, 0% packet loss round-trip (ms) min/avg/max/stddev = 0.921/1.11/1.67/0.26 |
The packet-loss statistic indicates whether the host has dropped packets. If ping fails, check the status of the network that is reported by the ifconfig and netstat commands. Refer to Monitoring the Interface Configuration With the ifconfig Command and Monitoring Network Status With the netstat Command.
The following tasks show how to check the status of the network by using well-known networking commands.
You can control the output of the netstat and ifconfig commands to display IPv4 information only, or both IPv4 and IPv6 information.
Create the /etc/default/inet_type file.
Add one of the following entries to /etc/default/inet_type, as required for your network:
To display IPv4 information only:
DEFAULT_IP=IP_VERSION4 |
To display both IPv4 and IPv6 information:
DEFAULT_IP=BOTH |
Or
DEFAULT_IP=IP_VERSION6 |
For more information about the inet_type file, see the inet_type(4) man page.
The -4 and -6 flags in the ifconfig command override the values set in the inet_type file. The -f flag in the netstat command also overrides the values set in the inet_type file.
When you specify the DEFAULT_IP=BOTH or DEFAULT_IP=IP_VERSION6 variable in the inet_type file, you should have the following output:
% ifconfig -a lo0: flags=1000849 mtu 8232 index 1 inet 10.10.0.1 netmask ff000000 qfe0: flags=1000843 mtu 1500 index 2 inet 10.46.86.54 netmask ffffff00 broadcast 10.46.86.255 ether 8:0:20:56:a8 lo0: flags=2000849 mtu 8252 index 1 inet6 ::1/128 qfe0: flags=2000841 mtu 1500 index 2 ether 8:0:20:56:a8 inet6 fe80::a00:fe73:56a8/10 qfe0:1: flags=2080841 mtu 1500 index 2 inet6 2001:db8:3c4d:5:a00:fe73:56a8/64 |
When you specify the DEFAULT_IP=IP_VERSION4 or DEFAULT_IP=IP_VERSION6 variable in the inet_type file, you should have the following output:
% ifconfig -a lo0: flags=849 mtu 8232 inet 10.10.0.1 netmask ff000000 qfe0: flags=843 mtu 1500 inet 10.46.86.54 netmask ffffff00 broadcast 10.46.86.255 ether 8:0:20:56:a8 |
If you suspect a malfunction of routed, the IPv4 routing daemon, you can start a log that traces the daemon's activity. The log includes all packet transfers when you start the routed daemon.
On the local host, assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Create a log file of routing daemon actions:
# /usr/sbin/in.routed /var/log-file-name |
On a busy network, this command can generate almost continuous output.
The following example shows the beginning of the log that is created by the procedure How to Log Actions of the IPv4 Routing Daemon.
-- 2003/11/18 16:47:00.000000 -- Tracing actions started RCVBUF=61440 Add interface lo0 #1 127.0.0.1 -->127.0.0.1/32 <UP|LOOPBACK|RUNNING|MULTICAST|IPv4> <PASSIVE> Add interface hme0 #2 10.10.48.112 -->10.10.48.0/25 <UP|BROADCAST|RUNNING|MULTICAST|IPv4> turn on RIP Add 10.0.0.0 -->10.10.48.112 metric=0 hme0 <NET_SYN> Add 10.10.48.85/25 -->10.10.48.112 metric=0 hme0 <IF|NOPROP> |
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.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Start a trace of the in.ndpd daemon.
# /usr/lib/inet/in.ndpd -t |
Terminate the trace as needed by typing Control-C.
The following output shows the beginning of a trace of in.ndpd.
# /usr/lib/inet/in.ndpd -t Nov 18 17:27:28 Sending solicitation to ff02::2 (16 bytes) on hme0 Nov 18 17:27:28 Source LLA: len 6 <08:00:20:b9:4c:54> Nov 18 17:27:28 Received valid advert from fe80::a00:20ff:fee9:2d27 (88 bytes) on hme0 Nov 18 17:27:28 Max hop limit: 0 Nov 18 17:27:28 Managed address configuration: Not set Nov 18 17:27:28 Other configuration flag: Not set Nov 18 17:27:28 Router lifetime: 1800 Nov 18 17:27:28 Reachable timer: 0 Nov 18 17:27:28 Reachable retrans timer: 0 Nov 18 17:27:28 Source LLA: len 6 <08:00:20:e9:2d:27> Nov 18 17:27:28 Prefix: 2001:08db:3c4d:1::/64 Nov 18 17:27:28 On link flag:Set Nov 18 17:27:28 Auto addrconf flag:Set Nov 18 17:27:28 Valid time: 2592000 Nov 18 17:27:28 Preferred time: 604800 Nov 18 17:27:28 Prefix: 2002:0a00:3010:2::/64 Nov 18 17:27:28 On link flag:Set Nov 18 17:27:28 Auto addrconf flag:Set Nov 18 17:27:28 Valid time: 2592000 Nov 18 17:27:28 Preferred time: 604800 |
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.
Type the following to discover the route to a remote system:
% traceroute destination-hostname |
You can run this form of the traceroute command from your user account.
The following output from the traceroute command shows the seven–hop path a packet follows from the local system nearhost to the remote system farhost. The output also shows the times for a packet to traverse each hop.
istanbul% traceroute farhost.faraway.com traceroute to farhost.faraway.com (172.16.64.39), 30 hops max, 40 byte packets 1 frbldg7c-86 (172.16.86.1) 1.516 ms 1.283 ms 1.362 ms 2 bldg1a-001 (172.16.1.211) 2.277 ms 1.773 ms 2.186 ms 3 bldg4-bldg1 (172.16.4.42) 1.978 ms 1.986 ms 13.996 ms 4 bldg6-bldg4 (172.16.4.49) 2.655 ms 3.042 ms 2.344 ms 5 ferbldg11a-001 (172.16.1.236) 2.636 ms 3.432 ms 3.830 ms 6 frbldg12b-153 (172.16.153.72) 3.452 ms 3.146 ms 2.962 ms 7 sanfrancisco (172.16.64.39) 3.430 ms 3.312 ms 3.451 ms |
This procedure uses the -a option of the traceroute command to trace all routes.
Type the following command on the local system:
% traceroute -ahost-name |
You can run this form of the traceroute command from your user account.
This example shows all possible routes to a dual-stack host.
% traceroute -a v6host.remote.com traceroute: Warning: Multiple interfaces found; using 2::56:a0:a8 @ eri0:2 traceroute to v6host (2001:db8:4a3b::102:a00:fe79:19b0),30 hops max, 60 byte packets 1 v6-rout86 (2001:db8:4a3b:56:a00:fe1f:59a1) 35.534 ms 56.998 ms * 2 2001:db8::255:0:c0a8:717 32.659 ms 39.444 ms * 3 farhost.faraway.COM (2001:db8:4a3b::103:a00:fe9a:ce7b) 401.518 ms 7.143 ms * 4 distant.remote.com (2001:db8:4a3b::100:a00:fe7c:cf35) 113.034 ms 7.949 ms * 5 v6host (2001:db8:4a3b::102:a00:fe79:19b0) 66.111 ms * 36.965 ms traceroute to v6host.remote.com (192.168.10.75),30 hops max,40 byte packets 1 v6-rout86 (172.16.86.1) 4.360 ms 3.452 ms 3.479 ms 2 flrmpj17u.here.COM (172.16.17.131) 4.062 ms 3.848 ms 3.505 ms 3 farhost.farway.com (10.0.0.23) 4.773 ms * 4.294 ms 4 distant.remote.com (192.168.10.104) 5.128 ms 5.362 ms * 5 v6host (192.168.15.85) 7.298 ms 5.444 ms * |
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.
On the local host, assume the Network Management role or become superuser.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Print information about the interfaces that are attached to the system.
# ifconfig -a |
The snoop command normally uses the first non-loopback device, typically the primary network interface.
Begin packet capture by typing snoop without arguments, as shown in Example 7–19.
Use Control-C to halt the process.
The basic snoop command returns output that resembles the following, for a dual-stack host.
% snoop Using device /dev/hme (promiscuous mode) farhost.remote.com -> myhost RLOGIN C port=993 myhost -> farhost.remote.com RLOGIN R port=993 Using device /dev/hme router5.local.com -> router5.local.com ARP R 10.0.0.13, router5.local.com is 0:10:7b:31:37:80 router5.local.com -> BROADCAST TFTP Read "network-confg" (octet) myhost -> DNSserver.local.com DNS C 192.168.10.10.in-addr.arpa. Internet PTR ? DNSserver.local.com myhost DNS R 192.168.10.10.in-addr.arpa. Internet PTR niserve2. . . farhost.remote.com-> myhost RLOGIN C port=993 myhost -> farhost.remote.com RLOGIN R port=993 fe80::a00:20ff:febb: . fe80::a00:20ff:febb:e09 -> ff02::9 RIPng R (5 destinations) |
The packets that are captured in this output show a remote login section, including lookups to the NIS and DNS servers for address resolution. Also included are periodic ARP packets from the local router and advertisements of the IPv6 link-local address to in.ripngd.
On the local host, assume the Network Management role or become superuser.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Capture a snoop session into a file.
# snoop -o filename |
For example:
# snoop -o /tmp/cap Using device /dev/eri (promiscuous mode) 30 snoop: 30 packets captured |
In the example, 30 packets have been captured in a file named /tmp/cap. The file can be in any directory with enough disk space. The number of packets that are captured is displayed on the command line, enabling you to press Control-C to abort at any time.
snoop creates a noticeable networking load on the host machine, which can distort the results. To see the actual results, run snoop from a third system.
Inspect the snoop output captures file.
# snoop -i filename |
The following output shows a variety of captures such as you might receive as output from the snoop -i command.
# snoop -i /tmp/cap 1 0.00000 fe80::a00:20ff:fee9:2d27 -> fe80::a00:20ff:fecd:4375 ICMPv6 Neighbor advertisement 2 0.16198 farhost.com -> myhost RLOGIN C port=985 3 0.00008 myhost -> farhost.com RLOGIN R port=985 10 0.91493 10.0.0.40 -> (broadcast) ARP C Who is 10.0.0.40, 10.0.0.40 ? 34 0.43690 nearserver.here.com -> 224.0.1.1 IP D=224.0.1.1 S=10.0.0.40 LEN=28, ID=47453, TO =0x0, TTL=1 35 0.00034 10.0.0.40 -> 224.0.1.1 IP D=224.0.1.1 S=10.0.0.40 LEN=28, ID=57376, TOS=0x0, TTL=47 |
Establish a snoop system off a hub that is connected to either the client or the server.
The third system (the snoop system) checks all the intervening traffic, so the snoop trace reflects what is actually happening on the wire.
On the snoop system, assume the Network Management role or become superuser.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Type snoop with options and save the output to a file.
Inspect and interpret the output.
Refer to RFC 1761, Snoop Version 2 Packet Capture File Format for details of the snoop capture file.
You can use the snoop command to display only IPv6 packets.
On the local node, assume the Network Management role or become superuser.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Capture IPv6 packets.
# snoop ip6 |
For more information on the snoop command, see the snoop(1M) man page.
The following example shows typical output such as you might receive from running the snoop ip6 command on a node.
# snoop ip6 fe80::a00:20ff:fecd:4374 -> ff02::1:ffe9:2d27 ICMPv6 Neighbor solicitation fe80::a00:20ff:fee9:2d27 -> fe80::a00:20ff:fecd:4375 ICMPv6 Neighbor solicitation fe80::a00:20ff:fee9:2d27 -> fe80::a00:20ff:fecd:4375 ICMPv6 Neighbor solicitation fe80::a00:20ff:febb:e09 -> ff02::9 RIPng R (11 destinations) fe80::a00:20ff:fee9:2d27 -> ff02::1:ffcd:4375 ICMPv6 Neighbor solicitation |
IP layer devices are introduced in the Solaris OS to enhance IP observability. These devices provide access to all packets with addresses that are associated with the system's network interface. The addresses include local addresses as well as addresses that are hosted on non-loopback interfaces or logical interfaces. The observable traffic can be both IPv4 and IPv6 addresses. Thus, you can monitor all traffic that is destined to the system. The traffic can be loopback IP traffic, packets from remote machines, packets that are being sent from the system, or all forwarded traffic.
With IP layer devices, an administrator for a global zone can monitor traffic between zones as well as within a zone. An administrator of a non-global zone can also observe traffic that is sent and received by that zone.
To monitor traffic on the IP layer, a new option, -I, is added to the snoop command. This option specifies for the command to use the new IP layer devices instead of the underlying link-layer device to display traffic data.
To understand the distinctions between layers, see Data Encapsulation and the TCP/IP Protocol Stack
On the local node, assume the Network Management role or become superuser.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
If necessary, print the information about the interfaces that are attached to the system.
# ifconfig -a |
Capture IP traffic on a specific interface.
# snoop -I interface [-V | -v] |
All the examples are based on the following system configuration:
# ifconfig -a lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 lo0:1: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 zone sandbox inet 127.0.0.1 netmask ff000000 lo0:2: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 zone toybox inet 127.0.0.1 netmask ff000000 hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 129.156.211.94 netmask fffff800 broadcast 129.156.215.255 ether 8:0:20:f7:d5:79 hme0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 zone sandbox inet 172.0.0.3 netmask ffff0000 broadcast 172.0.255.255 hme0:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 zone toybox inet 172.0.0.1 netmask ffff0000 broadcast 172.0.255.255 # |
The output shows three interfaces in the system:
Interfaces |
Address |
Zone |
---|---|---|
lo0 |
127.0.0.1 |
Global |
lo0:1 |
127.0.0.1 |
Zone 1 (sandbox) |
lo0:2 |
127.0.0.1 |
Zone 2 (toybox) |
hme0 |
129.156.211.94 |
Global |
hme0:1 |
172.0.0.3 |
Zone 1 (sandbox) |
hme0:2 |
172.0.0.1 |
Zone 2 (toybox) |
You can issue the snoop -I command on the different interfaces on the system. The packet information that is displayed depends on whether you are an administrator for the global zone or for the non-global zone.
# snoop -I lo0 Using device ipnet/lo0 (promiscuous mode) localhost -> localhost ICMP Echo request (ID: 5550 Sequence number: 0) localhost -> localhost ICMP Echo reply (ID: 5550 Sequence number: 0) |
To generate a verbose output, use the -v option.
# snoop -v -I lo0 Using device ipnet/lo0 (promiscuous mode) IPNET: ----- IPNET Header ----- IPNET: IPNET: Packet 1 arrived at 10:40:33.68506 IPNET: Packet size = 108 bytes IPNET: dli_version = 1 IPNET: dli_type = 4 IPNET: dli_srczone = 0 IPNET: dli_dstzone = 0 IPNET: IP: ----- IP Header ----- IP: IP: Version = 4 IP: Header length = 20 bytes ... |
This support for observing packets on the IP layer introduces a new ipnet header that precedes the packets that are being observed. Both the source and destination IDs are indicated. The '0' ID indicates that the traffic is being generated from the global zone.
# snoop -I hme0 Using device ipnet/hme0 (promiscuous mode) toybox -> sandbox TCP D=22 S=62117 Syn Seq=195630514 Len=0 Win=49152 Options=<mss sandbox -> toybox TCP D=62117 S=22 Syn Ack=195630515 Seq=195794440 Len=0 Win=49152 toybox -> sandbox TCP D=22 S=62117 Ack=195794441 Seq=195630515 Len=0 Win=49152 sandbox -> toybox TCP D=62117 S=22 Push Ack=195630515 Seq=195794441 Len=20 Win=491 |
The output shows traffic that occurs in the different zones within the system. You can see all packets that are associated with the hme0 IP addresses, including packets that are locally delivered to other zones. If you generate a verbose output, you can see the zones that are involved in the flow of packets.
# snoop -I hme0 -v port 22 IPNET: ----- IPNET Header ----- IPNET: IPNET: Packet 5 arrived at 15:16:50.85262 IPNET: Packet size = 64 bytes IPNET: dli_version = 1 IPNET: dli_type = 0 IPNET: dli_srczone = 0 IPNET: dli_dstzone = 1 IPNET: IP: ----- IP Header ----- IP: IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx. .... = 0 (precedence) IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: .... ..0. = not ECN capable transport IP: .... ...0 = no ECN congestion experienced IP: Total length = 40 bytes IP: Identification = 22629 IP: Flags = 0x4 IP: .1.. .... = do not fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 64 seconds/hops IP: Protocol = 6 (TCP) IP: Header checksum = 0000 IP: Source address = 172.0.0.1, 172.0.0.1 IP: Destination address = 172.0.0.3, 172.0.0.3 IP: No options IP: TCP: ----- TCP Header ----- TCP: TCP: Source port = 46919 TCP: Destination port = 22 TCP: Sequence number = 3295338550 TCP: Acknowledgement number = 3295417957 TCP: Data offset = 20 bytes TCP: Flags = 0x10 TCP: 0... .... = No ECN congestion window reduced TCP: .0.. .... = No ECN echo TCP: ..0. .... = No urgent pointer TCP: ...1 .... = Acknowledgement TCP .... 0... = No push TCP .... .0.. = No reset TCP: .... ..0. = No Syn TCP: .... ...0 = No Fin TCP: Window = 49152 TCP: Checksum = 0x0014 TCP: Urgent pointer = 0 TCP: No options TCP: |
The ipnet header indicates that the packet is coming from the global zone (ID 0) to Sandbox (ID 1).
# snoop -I hme0 zone 1 Using device ipnet/hme0 (promiscuous mode) toybox -> sandbox TCP D=22 S=61658 Syn Seq=374055417 Len=0 Win=49152 Options=<mss sandbox -> toybox TCP D=61658 S=22 Syn Ack=374055418 Seq=374124525 Len=0 Win=49152 toybox -> sandbox TCP D=22 S=61658 Ack=374124526 Seq=374055418 Len=0 Win=49152 # |
The ability to observe packets by identifying zone is useful in systems that have multiple zones. Currently, you can only identify zone by using the zone ID. Using snoop with zone names is not supported.
The Solaris OS 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 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.
The following procedure explains how to modify the address selection policy table. For conceptual information about IPv6 default address selection, refer to ipaddrsel Command.
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.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Review the current IPv6 address selection policy table.
# ipaddrsel # Prefix Precedence Label ::1/128 50 Loopback ::/0 40 Default 2002::/16 30 6to4 ::/96 20 IPv4_Compatible ::ffff:0.0.0.0/96 10 IPv4 |
Make a backup copy of the default address policy table.
# cp /etc/inet/ipaddrsel.conf /etc/inet/ipaddrsel.conf.orig |
Use a text editor to add your customizations to /etc/inet/ipaddrsel.conf.
Use the following syntax for entries in /etc/inet/ipaddrsel:
prefix/prefix-length precedence label [# comment ] |
Here are some common modifications that you might want to make to your policy table:
Give the highest priority to 6to4 addresses.
2002::/16 50 6to4 ::1/128 45 Loopback |
The 6to4 address format now has the highest priority, 50. Loopback, which previously had a 50 precedence, now has a 45 precedence. The other addressing formats remain the same.
Designate a specific source address to be used in communications with a specific destination address.
::1/128 50 Loopback 2001:1111:1111::1/128 40 ClientNet 2001:2222:2222::/48 40 ClientNet ::/0 40 Default |
This particular entry is useful for hosts with only one physical interface. Here 2001:1111:1111::1/128 is preferred as the source address on all packets that are bound for destinations within network 2001:2222:2222::/48. The 40 priority gives higher precedence to the source address 2001:1111:1111::1/128 than to other address formats configured for the interface.
Favor IPv4 addresses over IPv6 addresses.
::ffff:0.0.0.0/96 60 IPv4 ::1/128 50 Loopback . . |
The IPv4 format ::ffff:0.0.0.0/96 has its precedence changed from the default 10 to 60, the highest priority in the table.
Load the modified policy table into the kernel.
ipaddrsel -f /etc/inet/ipaddrsel.conf |
If the modified policy table has problems, restore the default IPv6 address selection policy table.
# ipaddrsel -d |
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.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Copy the contents of /etc/inet/ipaddrsel into filename, where filename represents a name of your choice.
# cp /etc/inet/ipaddrsel filename |
Edit the policy table in filename to your specifications.
Load the modified policy table into the kernel.
# ipaddrsel -f filename |
The kernel uses the new policy table until you reboot the system.
This chapter contains solutions for common problems that might occur on your network. The following topics are covered:
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.
If the network has problems, you can run a series of software checks to diagnose and fix basic, software-related problems.
On the local system, assume the Network Management role or become superuser.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Use the netstat command to display network information.
For syntax and information about the netstat command, refer to Monitoring Network Status With the netstat Command and the netstat(1M) man page.
Check the hosts database to ensure that the entries are correct and current.
For information about the /etc/inet/hosts database, refer to hosts Database and the hosts(4) man page.
If you are running the Reverse Address Resolution Protocol (RARP), check the Ethernet addresses in the ethers database to ensure that the entries are correct and current.
Try to connect to the local host by using the telnet command.
For syntax and information about telnet, refer to the telnet(1) man page.
Ensure that the network daemon inetd is running.
# ps -ef | grep inetd
The following output verifies that the inetd daemon is running:
root 57 1 0 Apr 04 ? 3:19 /usr/sbin/inetd -s |
If IPv6 is enabled on your network, verify that the IPv6 daemon in.ndpd is running:
# ps -ef | grep in.ndpd |
The following output verifies that the in.ndpd daemon is running:
root 123 1 0 Oct 27 ? 0:03 /usr/lib/inet/in.ndpd |
This section describes issues and problems that you might encounter while planning and deploying IPv6 at your site. For actual planning tasks, refer to Chapter 4, Planning an IPv6 Network (Tasks).
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).
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.
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.
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.
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
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 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.
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.
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.
This chapter provides TCP/IP network reference information about network configuration files, including the types, their purpose, and the format of the file entries. The existing network databases are also described in detail. The chapter also shows how the structure of IPv4 addresses are derived, based on defined network classifications and subnet numbers.
This chapter contains the following information:
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
netmasks database (optional)
The 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 Solaris networks. Network Databases and the nsswitch.conf File describes in detail the concept of network databases. .
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 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.
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 an IP Interface After System Installation in System Administration Guide: Network Interfaces and Network Virtualization. Also, for the 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.
IPv6 uses the /etc/hostname6.interface file for defining network interfaces. For more information, refer to IPv6 Interface Configuration File.
This file should contain one entry: the host name of the local system. For example, on system timbuktu, the file /etc/nodename would contain the entry timbuktu.
This file should contain one entry: the fully qualified domain name of the administrative domain to which the local host's network belongs. You can supply this name to the Solaris installation program or edit the file at a later date. For more information on network domains, refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
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.
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.
For compatibility with BSD-based operating systems, the /etc/hosts file is a symbolic link to /etc/inet/hosts.
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]
Contains the IPv4 address for each interface that the local host must recognize.
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.
Is an optional field that contains a nickname for the host.
Is an optional field for a comment.
When you run the 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 Solaris installation program might create the following /etc/inet/hosts file for system tenere shown in Figure 5–1:
127.0.0.1 localhost loghost #loopback address 192.168.200.3 tenere #host name |
In Example 9–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.
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.
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 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 Solaris installation, you can configure additional interfaces for a router or multihomed host by adding interface information to the systems' /etc/inet/hosts file. For more information on configuring routers and multihomed hosts refer to Configuring an IPv4 Router and Configuring Multihomed Hosts.
Example 9–2 shows the /etc/inet/hosts file for system timbuktu that is shown in Figure 5–1.
127.0.0.1 localhost loghost 192.168.200.70 timbuktu #This is the local host name 192.168.201.10 timbuktu-201 #Interface to network 192.9.201 |
With these two interfaces, timbuktu connects networks 192.168.200 and 192.168.201 as a router.
The NIS and DNS name services, and LDAP directory service, maintain host names and addresses on one or more servers. These servers maintain hosts databases that contain information for every host and router (if applicable) on the servers' network. Refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) for more information about these services.
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 9–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.
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.
When you create subnets, each new network must be a separate physical network. You cannot apply subnetting to a single physical network.
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.
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 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.
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.
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.
# The netmasks file associates Internet Protocol (IPv4) address # masks with IPv4 network numbers. # # network-number netmask # # Both the network-number and the netmasks are specified in # “decimal dot” notation, e.g: # # 128.32.0.0 255.255.255.0 192.168.0.0 255.255.255.0 |
If the /etc/netmasks file does not exist, create it with a text editor. Use the following syntax:
network-number netmask-number
Refer to the netmasks(4) man page for complete details.
When creating netmask numbers, type the network number that is assigned by the ISP or Internet Registry (not the subnet number) and the netmask number in /etc/inet/netmasks. Each subnet mask should be on a separate line.
For example:
128.78.0.0 255.255.248.0 |
You can also type symbolic names for network numbers in the /etc/inet/hosts file. You can then use these network names instead of the network numbers as parameters to commands.
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:
For administrative actions on a service, such as enabling, disabling, or restarting. For details, refer to the svcadm(1M) man page.
For querying the status of a service. For details, refer to the svcs(1) man page.
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.
For instructions on using the SMF commands, refer to SMF Command-Line Administrative Utilities in System Administration Guide: Basic Administration.
For a task that uses the SMF commands to add a service that runs over SCTP, refer to How to Add Services That Use the SCTP Protocol.
For information on adding services that handle both IPv4 requests and IPv6 requests, refer to inetd Internet Services Daemon
The network databases are files that provide information that is needed to configure the network. The network databases follow:
hosts
ipnodes
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.
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.
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.
The following table lists the network databases and their corresponding local files and NIS maps.
The ipnodes database is removed from Solaris releases after Solaris 10 11/06.
Network Database |
Local Files |
NIS Maps |
---|---|---|
/etc/inet/hosts |
hosts.byaddr hosts.byname |
|
ipnodes |
/etc/inet/ipnodes |
ipnodes.byaddr ipnodes.byname |
/etc/inet/netmasks |
netmasks.byaddr |
|
/etc/ethers |
ethers.byname ethers.byaddr |
|
/etc/bootparams |
bootparams |
|
/etc/inet/protocols |
protocols.byname protocols.bynumber |
|
/etc/inet/services |
services.byname |
|
/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.
Information about the hosts database is in hosts Database.
Information about the netmasks database is in netmasks Database.
Refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) for information on network databases correspondences in NIS, DNS, and LDAP.
The /etc/nsswitch.conf file defines the search order of the network databases. The 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.
# /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 9–4, 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.
The /etc directory contains the nsswitch.conf file that is created by the Solaris installation program. This directory also contains template files for the following name services:
nsswitch.files
nsswitch.nis
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.
# /etc/nsswitch.conf:# . . passwd: files nis group: file nis # consult /etc "files" only if nis is down. hosts: nis [NOTFOUND=return] files networks: nis [NOTFOUND=return] files protocols: nis [NOTFOUND=return] files rpc: nis [NOTFOUND=return] files ethers: files [NOTFOUND=return] nis netmasks: nis [NOTFOUND=return] files bootparams: files [NOTFOUND=return] nis publickey: nis netgroup: nis automount: files nis aliases: files nis # for efficient getservbyname() avoid nis services: files nis sendmailvars: files |
For complete details on the name service switch, refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
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.
myclient root=myserver : /nfsroot/myclient \ swap=myserver : /nfsswap//myclient \ dump=myserver : /nfsdump/myclient |
In this example, the term dump= tells client hosts not to look for a dump file.
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.
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 of the host
Official name of the host
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 not to the nicknames, as follows.
8:0:20:1:40:16 fayoum 8:0:20:1:40:15 nubian 8:0:20:1:40:7 sahara # This is a comment 8:0:20:1:40:14 tenere |
The remaining network databases seldom need to be edited.
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 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 |
Official name for the network
Number assigned by the ISP or Internet Registry
Any other name by which the network is known
Any note that you want to append to an entry in the file
You must maintain the networks file. The netstat program uses the information in this database to produce status tables.
A sample /etc/networks file follows.
#ident "@(#)networks 1.4 92/07/14 SMI" /* SVr4.0 1.1 */ # # The networks file associates Internet Protocol (IP) network # numbers with network names. The format of this file is: # # network-name network-number nicnames . . . # The loopback network is used only for intra-machine communication loopback 127 # # Internet networks # arpanet 10 arpa # Historical # # local networks eng 192.168.9 #engineering acc 192.168.5 #accounting prog 192.168.2 #programming |
The protocols database lists the TCP/IP protocols that are installed on your system and their protocol numbers. The 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.
# # Internet (IP) protocols # ip 0 IP # internet protocol, pseudo protocol number icmp 1 ICMP # internet control message protocol tcp 6 TCP # transmission control protocol udp 17 UDP # user datagram protocol |
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 Solaris installation automatically creates the services database. Generally, this database does not require any administration.
The services(4) man page contains complete syntax information. An excerpt from a typical /etc/inet/services file follows.
# # Network services # echo 7/udp echo 7/tcp echo 7/sctp6 discard 9/udp sink null discard 11/tcp daytime 13/udp daytime 13/tcp netstat 15/tcp ftp-data 20/tcp ftp 21/tcp telnet 23/tcp time 37/tcp timeserver time 37/udp timeserver name 42/udp nameserver whois 43/tcp nickname |
This section describes two routing protocols supported in the Solaris 10 OS: Routing Information Protocol (RIP) and ICMP Router Discovery (RDISC). RIP and RDISC are both standard TCP/IP protocols. For complete lists of routing protocols available in the Solaris 10 OS, refer to Table 5–1 and Table 5–2.
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.
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.
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.
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.
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.
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.
Class B is typically assigned to organizations with many hosts on their networks.
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.
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.
This chapter contains the following reference information about the Solaris 10 IPv6 implementation.
For an overview of IPv6, refer to Chapter 3, Planning an IPv6 Addressing Scheme (Overview). For tasks on configuring an IPv6-enabled network, refer to Chapter 6, Enabling IPv6 on a Network (Tasks).
Chapter 3, Planning an IPv6 Addressing Scheme (Overview) introduces the most common IPv6 addressing formats: unicast site address and link-local address. This section includes in-depth explanations of addressing formats that are not covered in detail in Chapter 3, Planning an IPv6 Addressing Scheme (Overview):
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.
The next figure shows the parts of a subnet prefix for a 6to4 site, such as you would include in the ndpd.conf file.
This table explains the parts of a 6to4 subnet prefix.
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. |
When an IPv6 host receives the 6to4-derived prefix by way of a router advertisement, the host automatically reconfigures a 6to4-derived address on an interface. The address has the following format:
prefix:IPv4-address:subnet-ID:interface-ID/64 |
The output from the ifconfig -a command on a host with a 6to4 interface might resemble the following:
qfe1:3: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 7 inet6 2002:8192:56bb:9258:a00:20ff:fea9:4521/64 |
In this output, the 6to4-derived address follows inet6.
This table explains the parts of the 6to4-derived address.
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 |
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 10–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.
For complete details about the multicast format, refer to RFC 3306, "Unicast-Prefix-based IPv6 Multicast Addresses.
Some IPv6 multicast addresses are permanently assigned by the Internet Assigned Numbers Authority (IANA). Some examples are the All Nodes Multicast Addresses and All Routers Multicast Addresses that are required by all IPv6 hosts and IPv6 routers. IPv6 multicast addresses can also be dynamically allocated. For more information about the proper use of multicast addresses and groups, see RFC 3307, "Allocation Guidelines for IPv6 Multicast Addresses".
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.
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 options are placed in separate extension headers that are located between the IPv6 header and the transport-layer header in a packet. Most IPv6 extension headers are not examined or processed by any router along a packet's delivery path until the packet arrives at its final destination. This feature provides a major improvement in router performance for packets that contain options. In IPv4, the presence of any options requires the router to examine all options.
Unlike IPv4 options, IPv6 extension headers can be of arbitrary length. Also, the number of options that a packet carries is not limited to 40 bytes. This feature, in addition to the manner in which IPv6 options are processed, permits IPv6 options to be used for functions that are not practical in IPv4.
To improve performance when handling subsequent option headers, and the transport protocol that follows, IPv6 options are always an integer multiple of 8 octets long. The integer multiple of 8 octets retains the alignment of subsequent headers.
The following IPv6 extension headers are currently defined:
Routing – Extended routing, such as IPv4 loose source route
Fragmentation – Fragmentation and reassembly
Authentication – Integrity and authentication, and security
Encapsulating Security Payload – Confidentiality
Hop-by-Hop options – Special options that require hop-by-hop processing
Destination options – Optional information to be examined by the destination node
The term dual-stack normally refers to a complete duplication of all levels in the protocol stack from applications to the network layer. One example of complete duplication is a system that runs both the OSI and TCP/IP protocols.
The Solaris OS is dual-stack, meaning that the Solaris OS implements both IPv4 and IPv6 protocols. When you install the operating system, you can choose to enable the IPv6 protocols in the IP layer or use only the default IPv4 protocols. The remainder of the TCP/IP stack is identical. Consequently, the same transport protocols, TCP UDP and SCTP, can run over both IPv4 and IPv6. Also, the same applications can run over both IPv4 and IPv6. Figure 10–4 shows how the IPv4 and IPv6 protocols work as a dual-stack throughout the various layers of the Internet protocol suite.
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.
This section describes the files, commands, and daemons that enable IPv6 in the Solaris OS.
This section describes the configuration files that are part of an IPv6 implementation:
The /etc/inet/ndpd.conf file is used to configure options that are used by the in.ndpd Neighbor Discovery daemon. For a router, you primarily use ndpd.conf to configure the site prefix to be advertised to the link. For a host, you use ndpd.conf to turn off address autoconfiguration or to configure temporary addresses.
The next table shows the keywords that are used in the ndpd.conf file.
Table 10–2 /etc/inet/ndpd.conf Keywords
Variable |
Description |
---|---|
ifdefault |
Specifies the router behavior for all interfaces. Use the following syntax to set router parameters and corresponding values: ifdefault [variable-value] |
prefixdefault |
Specifies the default behavior for prefix advertisements. Use the following syntax to set router parameters and corresponding values: prefixdefault [variable-value] |
if |
Sets per-interface parameters. Use the following syntax: if interface [variable-value] |
prefix |
Advertises per-interface prefix information. Use the following syntax: prefix prefix/length interface [variable-value] |
In the ndpd.conf file, you use the keywords in this table with a set of router configuration variables. These variables are defined in detail in RFC 2461, Neighbor Discovery for IP Version 6 (IPv6).
The next table shows the variables for configuring an interface, along with brief definitions.
Table 10–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. |
TmpPreferredLifetime |
False |
Sets the preferred lifetime of a temporary address. For more information, refer to How to Configure a Temporary Address. |
TmpRegenAdvance |
False |
Specifies the lead time in advance of address deprecation for a temporary address. For more information, refer to How to Configure a Temporary Address. |
TmpValidLifetime |
False |
Sets the valid lifetime for a temporary address. For more information, refer to How to Configure a Temporary Address. |
The next table shows the variables that are used for configuring IPv6 prefixes.
Table 10–4 /etc/inet/ndpd.conf Prefix Configuration Variables
Variable |
Default |
Definition |
---|---|---|
AdvAutonomousFlag |
True |
Specifies the value to be placed in the Autonomous Flag field in the Prefix Information option. |
AdvOnLinkFlag |
True
|
Specifies the value to be placed in the on-link flag (“L-bit”) in the Prefix Information option. |
AdvPreferredExpiration |
Not set |
Specifies the preferred expiration date of the prefix. |
AdvPreferredLifetime |
604800 seconds |
Specifies the value to be placed in the preferred lifetime in the Prefix Information option. |
AdvValidExpiration |
Not set |
Specifies the valid expiration date of the prefix. |
AdvValidLifetime |
2592000 seconds |
Specifies the valid lifetime of the prefix that is being configured. |
The following example shows how the keywords and configuration variables are used in the ndpd.conf file. Remove the comment (#) to activate the variable.
# ifdefault [variable-value ]* # prefixdefault [variable-value ]* # if ifname [variable-value ]* # prefix prefix/length ifname # # Per interface configuration variables # #DupAddrDetectTransmits #AdvSendAdvertisements #MaxRtrAdvInterval #MinRtrAdvInterval #AdvManagedFlag #AdvOtherConfigFlag #AdvLinkMTU #AdvReachableTime #AdvRetransTimer #AdvCurHopLimit #AdvDefaultLifetime # # Per Prefix: AdvPrefixList configuration variables # # #AdvValidLifetime #AdvOnLinkFlag #AdvPreferredLifetime #AdvAutonomousFlag #AdvValidExpiration #AdvPreferredExpiration ifdefault AdvReachableTime 30000 AdvRetransTimer 2000 prefixdefault AdvValidLifetime 240m AdvPreferredLifetime 120m if qe0 AdvSendAdvertisements 1 prefix 2:0:0:56::/64 qe0 prefix fec0:0:0:56::/64 qe0 if qe1 AdvSendAdvertisements 1 prefix 2:0:0:55::/64 qe1 prefix fec0:0:0:56::/64 qe1 if hme1 AdvSendAdvertisements 1 prefix 2002:8192:56bb:1::/64 qfe0 if hme1 AdvSendAdvertisements 1 prefix 2002:8192:56bb:2::/64 hme1 |
IPv6 uses the /etc/hostname6.interface file at start up to automatically define IPv6 logical interfaces. When you select the IPv6 Enabled option during Solaris installation, the installation program creates an /etc/hostname6.interface file for the primary network interface, in addition to the /etc/hostname.interface file.
If more than one physical interface is detected during installation, you are prompted as to whether you want to configure these interfaces. The installation program creates IPv4 physical interface configuration files and IPv6 logical interface configuration files for each additional interface that you indicate.
As with IPv4 interfaces, you can also configure IPv6 interfaces manually, after Solaris installation. You create/etc/hostname6.interface files for the new interfaces. For instructions for manually configuring interfaces, refer to Part I, Administering Single Interfaces, in System Administration Guide: Network Interfaces and Network Virtualization.
The network interface configuration file names have the following syntax:
hostname.interface hostname6.interface |
The interface variable has the following syntax:
dev[.module[.module ...]]PPA |
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.
Lists one or more STREAMS modules to be pushed onto the device when the device is plumbed.
Indicates the physical point of attachment.
The syntax [.[.]] is also accepted.
The following are examples of valid IPv6 configuration file names:
hostname6.qfe0 hostname.ip.tun0 hostname.ip6.tun0 hostname6.ip6to4tun0 hostname6.ip.tun0 hostname6.ip6.tun0 |
The /etc/inet/ipaddrsel.conf file contains the IPv6 default address selection policy table. When you install the Solaris OS with IPv6 enabled, this file contains the contents that are shown in Table 10–5.
You can edit the contents of /etc/inet/ipaddrsel.conf. However, in most cases, you should refrain from modifying this file. If modification is necessary, refer to the procedure How to Administer the IPv6 Address Selection Policy Table. For more information on ippaddrsel.conf, refer to Reasons for Modifying the IPv6 Address Selection Policy Table and the ipaddrsel.conf(4) man page.
This section describes commands that are added with the Solaris IPv6 implementation. The text also describes modifications to existing commands to support IPv6.
The ipaddrsel command enables you to modify the IPv6 default address selection policy table.
The Solaris kernel uses the IPv6 default address selection policy table to perform destination address ordering and source address selection for an IPv6 packet header. The /etc/inet/ipaddrsel.conf file contains the policy table.
The following table lists the default address formats and their priorities for the policy table. You can find technical details for IPv6 address selection in the inet6(7P) man page.
Table 10–5 IPv6 Address Selection Policy Table
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.
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.
6to4 tunneling enables communication between isolated 6to4 sites. However, to transfer packets with a native, non-6to4 IPv6 site, the 6to4 router must establish a tunnel with a 6to4 relay router. The 6to4 relay router then forwards the 6to4 packets to the IPv6 network and ultimately, to the native IPv6 site. If your 6to4-enabled site must exchange data with a native IPv6 site, you use the 6to4relay command to enable the appropriate tunnel.
Because the use of relay routers is insecure, tunneling to a relay router is disabled by default in the Solaris OS. Carefully consider the issues that are involved in creating a tunnel to a 6to4 relay router before deploying this scenario. For detailed information on 6to4 relay routers, refer to Considerations for Tunnels to a 6to4 Relay Router. If you decide to enable 6to4 relay router support, you can find the related procedures in How to Configure a 6to4 Tunnel.
The 6to4relay command has the following syntax:
6to4relay -e [-a IPv4-address] -d -h |
Enables support for tunnels between the 6to4 router and an anycast 6to4 relay router. The tunnel endpoint address is then set to 192.88.99.1, the default address for the anycast group of 6to4 relay routers.
Enables support for tunnels between the 6to4 router and a 6to4 relay router with the specified IPv4-address.
Disables support for tunneling to the 6to4 relay router, the default for the Solaris OS.
Displays help for 6to4relay.
For more information, refer to the 6to4relay(1M) man page.
The 6to4relay command, without arguments, shows the current status of 6to4 relay router support. This example shows the default for the Solaris OS implementation of IPv6.
# /usr/sbin/6to4relay 6to4relay:6to4 Relay Router communication support is disabled |
If relay router support is enabled, 6to4relay displays the following output:
# /usr/sbin/6to4relay 6to4relay:6to4 Relay Router communication support is enabled IPv4 destination address of Relay Router=192.88.99.1 |
If you specify the -a option and an IPv4 address to the 6to4relay command, the IPv4 address that you give with -a is displayed instead of 192.88.99.1.
6to4relay does not report successful execution of the -d, -e, and-a IPv4 address options. However, 6to4relay does display any error messages that might be generated when you run these options.
The 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.
Sets the interface index.
Sets the tunnel source or destination.
Creates the next available logical interface.
Deletes a logical interface with a specific IP address.
Sets the point-to-point destination address for an interface.
Sets an address, netmask, or both for an interface.
Sets the subnet address of an interface.
Enables or disables packet transmission on an interface.
Chapter 6, Enabling IPv6 on a Network (Tasks) provides IPv6 configuration procedures.
The following form of the ifconfig command creates the hme0:3 logical interface:
# ifconfig hme0 inet6 addif up Created new logical interface hme0:3 |
This form of ifconfig verifies the creation of the new interface:
# ifconfig hme0:3 inet6 hme0:3: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 inet6 inet6 fe80::203:baff:fe11:b321/10 |
The following form of the ifconfig command removes the hme0:3 logical interface.
# ifconfig hme0:3 inet6 down # ifconfig hme0 inet6 removeif 1234::5678 |
# ifconfig ip.tun0 inet6 plumb index 13 |
Opens the tunnel to be associated with the physical interface name.
# ifconfig ip.tun0 inet6 ip.tun0: flags=2200850<POINTOPOINT,RUNNING,MULTICAST,NONUD, #IPv6> mtu 1480 index 13 inet tunnel src 0.0.0.0 inet6 fe80::/10 --> :: |
Configures the streams that are needed for TCP/IP to use the tunnel device and report the status of the device.
# ifconfig ip.tun0 inet6 tsrc 120.46.86.158 tdst 120.46.86.122 |
Configures the source and the destination address for the tunnel.
# ifconfig ip.tun0 inet6 ip.tun0: flags=2200850<POINTOPOINT,RUNNING,MULTICAST,NONUD, IPv6> mtu 1480 index 13 inet tunnel src 120.46.86.158 tunnel dst 120.46.86.122 inet6 fe80::8192:569e/10 --> fe80::8192:567a |
Reports the new status of the device after the configuration.
This example of a 6to4 pseudo-interface configuration uses the subnet ID of 1 and specifies the host ID, in hexadecimal form.
# ifconfig ip.6to4tun0 inet6 plumb # ifconfig ip.6to4tun0 inet tsrc 129.146.86.187 \ 2002:8192:56bb:1::8192:56bb/64 up |
# ifconfig ip.6to4tun0 inet6 ip.6to4tun0: flags=2200041<UP,RUNNING,NONUD,IPv6>mtu 1480 index 11 inet tunnel src 129.146.86.187 tunnel hop limit 60 inet6 2002:8192:56bb:1::8192:56bb/64 |
This example shows the short form for configuring a 6to4 tunnel.
# ifconfig ip.6to4tun0 inet6 plumb # ifconfig ip.6to4tun0 inet tsrc 129.146.86.187 up |
# ifconfig ip.6to4tun0 inet6 ip.6to4tun0: flags=2200041<UP,RUNNING,NONUD,IPv6>mtu 1480 index 11 inet tunnel src 129.146.86.187 tunnel hop limit 60 inet6 2002:8192:56bb::1/64 |
The netstat command displays both IPv4 and IPv6 network status. You can choose which protocol information to display by setting the DEFAULT_IP value in the /etc/default/inet_type file or by using the -f command-line option. With a permanent setting of DEFAULT_IP, you can ensure that netstat displays only IPv4 information. You can override this setting by using the -f option. For more information on the inet_type file, see the inet_type(4) man page.
The -p option of the netstat command displays the net-to-media table, which is the ARP table for IPv4 and the neighbor cache for IPv6. See the netstat(1M) man page for details. See How to Display the Status of Sockets for descriptions of procedures that use this command.
The snoop command can capture both IPv4 and IPv6 packets. This command can display IPv6 headers, IPv6 extension headers, ICMPv6 headers, and Neighbor Discovery protocol data. By default, the snoop command displays both IPv4 and IPv6 packets. If you specify the ip or ip6 protocol keyword, the snoop command displays only IPv4 or IPv6 packets. The IPv6 filter option enables you to filter through all packets, both IPv4 and IPv6, displaying only the IPv6 packets. See the snoop(1M) man page for details. See How to Monitor IPv6 Network Traffic for procedures that use the snoop command.
The route command operates on both IPv4 and IPv6 routes, with IPv4 routes as the default. If you use the -inet6 option on the command line immediately after the route command, operations are performed on IPv6 routes. See the route(1M) man page for details.
The ping command can use both IPv4 and IPv6 protocols to probe target hosts. Protocol selection depends on the addresses that are returned by the name server for the specific target host. By default, if the name server returns an IPv6 address for the target host, the ping command uses the IPv6 protocol. If the server returns only an IPv4 address, the ping command uses the IPv4 protocol. You can override this action by using the -A command-line option to specify which protocol to use.
For detailed information, see the ping(1M) man page. For procedures that use ping, refer to Probing Remote Hosts With the ping Command.
You can use the traceroute command to trace both the IPv4 and IPv6 routes to a specific host. From a protocol perspective, traceroute uses the same algorithm as ping. Use the -A command-line option to override this selection. You can trace each individual route to every address of a multihomed host by using the -a command-line option.
For detailed information, see the traceroute(1M) man page. For procedures that use traceroute, refer to Displaying Routing Information With the traceroute Command.
This section discusses the IPv6-related daemons.
Thein.ndpd daemon implements the IPv6 Neighbor Discovery protocol and router discovery. The daemon also implements address autoconfiguration for IPv6. The following shows the supported options of in.ndpd.
Turns on debugging.
Turns on debugging for specific events.
Specifies a file to read configuration data from, instead of the default /etc/inet/ndpd.conf file.
Prints related information for each interface.
Does not loop back router advertisements.
Ignores received packets.
Specifies verbose mode, reporting various types of diagnostic messages.
Turns on packet tracing.
The in.ndpd daemon is controlled by parameters that are set in the /etc/inet/ndpd.conf configuration file and any applicable parameters in the /var/inet/ndpd_state.interface startup file.
When the /etc/inet/ndpd.conf file exists, the file is parsed and used to configure a node as a router. Table 10–2 lists the valid keywords that might appear in this file. When a host is booted, routers might not be immediately available. Advertised packets by the router might be dropped. Also, advertised packets might not reach the host.
The /var/inet/ndpd_state.interface file is a state file. This file is updated periodically by each node. When the node fails and is restarted, the node can configure its interfaces in the absence of routers. This file contains the interface address, the last time that the file was updated, and how long the file is valid. This file also contains other parameters that are “learned” from previous router advertisements.
You do not need to alter the contents of state files. The in.ndpd daemon automatically maintains state files.
See the in.ndpd(1M) man page and the ndpd.conf(4) man page for lists of configuration variables and allowable values.
The in.ripngd daemon implements the Routing Information Protocol next-generation for IPv6 routers (RIPng). RIPng defines the IPv6 equivalent of RIP. When you configure an IPv6 router with the routeadm command and turn on IPv6 routing, the in.ripngd daemon implements RIPng on the router.
The following shows the supported options of RIPng.
n specifies the alternate port number that is used to send or receive RIPnG packets.
Suppresses routing information.
Forces routing information even if the daemon is acting as a router.
Suppresses use of poison reverse.
If in.ripngd does not act as a router, the daemon enters only a default route for each router.
An IPv6-enabled server application can handle both IPv4 requests and IPv6 requests, or IPv6 requests only. The server always handles requests through an IPv6 socket. Additionally, the server uses the same protocol that the corresponding client uses. To add or modify a service for IPv6, use the commands available from the Service Management Facility (SMF).
For information about the SMF commands, refer to SMF Command-Line Administrative Utilities in System Administration Guide: Basic Administration.
For an example task that uses SMF to configure an IPv4 service manifest that runs over SCTP, refer to How to Add Services That Use the SCTP Protocol.
To configure an IPv6 service, you must ensure that the proto field value in the inetadm profile for that service lists the appropriate value:
For a service that handles both IPv4 and IPv6 requests, choose tcp6, udp6, or sctp. A proto value of tcp6, udp6, or sctp6 causes inetd to pass on an IPv6 socket to the server. The server contains an IPv4-mapped address in case a IPv4 client has a request.
For a service that handles only IPv6 requests, choose tcp6only or udp6only. With either of these values for proto, inetd passes the server an IPv6 socket.
If you replace a Solaris command with another implementation, you must verify that the implementation of that service supports IPv6. If the implementation does not support IPv6, then you must specify the proto value as either tcp, udp, or sctp.
Here is a profile that results from running inetadm for an echo service manifest that supports both IPv4 and IPv6 and runs over SCTP:
# inetadm -l svc:/network/echo:sctp_stream SCOPE NAME=VALUE name="echo" endpoint_type="stream" proto="sctp6" isrpc=FALSE wait=FALSE exec="/usr/lib/inet/in.echod -s" user="root" default bind_addr="" default bind_fail_max=-1 default bind_fail_interval=-1 default max_con_rate=-1 default max_copies=-1 default con_rate_offline=-1 default failrate_cnt=40 default failrate_interval=60 default inherit_env=TRUE default tcp_trace=FALSE default tcp_wrappers=FALSE |
To change the value of the proto field, use the following syntax:
# inetadm -m FMRI proto="transport-protocols" |
All servers that are provided with Solaris software require only one profile entry that specifies proto as tcp6, udp6, or sctp6. However, the remote shell server (shell) and the remote execution server (exec) now are composed of a single service instance, which requires a proto value containing both the tcp and tcp6only values. For example, to set the proto value for shell, you would issue the following command:
# inetadm -m network/shell:default proto="tcp,tcp6only" |
See IPv6 extensions to the Socket API in Programming Interfaces Guide for more details on writing IPv6-enabled servers that use sockets.
When you add or modify a service for IPv6, keep in mind the following caveats:
You need to specify the proto value as tcp6, sctp6, or udp6 to enable both IPv4 or IPv6 connections. If you specify the value for proto as tcp, sctp, or udp, the service uses only IPv4.
Though you can add a service instance that uses one-to-many style SCTP sockets for inetd, this is not recommended. inetd does not work with one-to-many style SCTP sockets.
If a service requires two entries because its wait-status or exec properties differ, then you must create two instances/services from the original service.
IPv6 introduces the Neighbor Discovery protocol, as described in RFC 2461, Neighbor Discovery for IP Version 6 (IPv6). For an overview of major Neighbor Discovery features, refer to IPv6 Neighbor Discovery Protocol Overview.
This section discusses the following features of the Neighbor Discovery protocol:
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
The functionality of the IPv6 Neighbor Discovery protocol corresponds to a combination of the IPv4 protocols: Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP) Router Discovery, and ICMP Redirect. IPv4 does not have a generally agreed on protocol or mechanism for neighbor unreachability detection. However, host requirements do specify some possible algorithms for dead gateway detection. Dead gateway detection is a subset of the problems that neighbor unreachability detection solves.
The following list compares the Neighbor Discovery protocol to the related set of IPv4 protocols.
Router discovery is part of the base IPv6 protocol set. IPv6 hosts do not need to snoop the routing protocols to find a router. IPv4 uses ARP, ICMP router discovery, and ICMP redirect for router discovery.
IPv6 router advertisements carry link-local addresses. No additional packet exchange is needed to resolve the router's link-local address.
Router advertisements carry site prefixes for a link. A separate mechanism is not needed to configure the netmask, as is the case with IPv4.
Router advertisements enable address autoconfiguration. Autoconfiguration is not implemented in IPv4.
Neighbor Discovery enables IPv6 routers to advertise an MTU for hosts to use on the link. Consequently, all nodes use the same MTU value on links that lack a well-defined MTU. IPv4 hosts on the same network might have different MTUs.
Unlike IPv4 broadcast addresses, IPv6 address resolution multicasts are spread over 4 billion (2^32) multicast addresses, greatly reducing address resolution-related interrupts on nodes other than the target. Moreover, non-IPv6 machines should not be interrupted at all.
IPv6 redirects contain the link-local address of the new first hop. Separate address resolution is not needed on receiving a redirect.
Multiple site prefixes can be associated with the same IPv6 network. By default, hosts learn all local site prefixes from router advertisements. However, routers can be configured to omit some or all prefixes from router advertisements. In such instances, hosts assume that destinations are on remote networks. Consequently, hosts send the traffic to routers. A router can then issue redirects, as appropriate.
Unlike IPv4, the recipient of an IPv6 redirect message assumes that the new next-hop is on the local network. In IPv4, a host ignores redirect messages that specify a next-hop that is not on the local network, according to the network mask. The IPv6 redirect mechanism is analogous to the XRedirect facility in IPv4. The redirect mechanism is useful on non-broadcast and shared media links. On these networks, nodes should not check for all prefixes for local link destinations.
IPv6 neighbor unreachability detection improves packet delivery in the presence of failing routers. This capability improves packet delivery over partially failing or partitioned links. This capability also improves packet delivery over nodes that change their link-local addresses. For example, mobile nodes can move off the local network without losing any connectivity because of stale ARP caches. IPv4 has no corresponding method for neighbor unreachability detection.
Unlike ARP, Neighbor Discovery detects half-link failures by using neighbor unreachability detection. Neighbor Discovery avoids sending traffic to neighbors when two-way connectivity is absent.
By using link-local addresses to uniquely identify routers, IPv6 hosts can maintain the router associations. The ability to identify routers is required for router advertisements and for redirect messages. Hosts need to maintain router associations if the site uses new global prefixes. IPv4 does not have a comparable method for identifying routers.
Because Neighbor Discovery messages have a hop limit of 255 upon receipt, the protocol is immune to spoofing attacks originating from off-link nodes. In contrast, IPv4 off-link nodes can send ICMP redirect messages. IPv4 off-link nodes can also send router advertisement messages.
By placing address resolution at the ICMP layer, Neighbor Discovery becomes more media independent than ARP. Consequently, standard IP authentication and security mechanisms can be used.
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.
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 advertisements contain a list of subnet prefixes that is used to determine if a host is on the same link (on-link) as the router. The list of prefixes is also used for autonomous address configuration. Flags that are associated with the prefixes specify the intended uses of a particular prefix. Hosts use the advertised on-link prefixes to build and maintain a list that is used to decide when a packet's destination is on-link or beyond a router. A destination can be on-link even though the destination is not covered by any advertised on-link prefix. In such instances, a router can send a redirect. The redirect informs the sender that the destination is a neighbor.
Router advertisements, and per-prefix flags, enable routers to inform hosts how to perform stateless address autoconfiguration.
Router advertisement messages 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.
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.”
The Solaris IPv6 implementation includes two types of tunneling mechanisms:
Configured tunnels between two routers, as in Figure 10–5
Automatic tunnels that terminate at the endpoint hosts
A configured tunnel is currently used on the Internet for other purposes, for example, on the MBONE, the IPv4 multicast backbone. Operationally, the tunnel consists of two routers that are configured to have a virtual point-to-point link between the two routers over the IPv4 network. This kind of tunnel is likely to be used on some parts of the Internet for the foreseeable future.
Automatic tunnels require IPv4-compatible addresses. Automatic tunnels can be used to connect IPv6 nodes when IPv6 routers are not available. These tunnels can originate either on a dual-stack host or on a dual-stack router by configuring an automatic tunneling network interface. The tunnels always terminate on the dual-stack host. These tunnels work by dynamically determining the destination IPv4 address, which is the endpoint of the tunnel, by extracting the address from the IPv4-compatible destination address.
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.
The following is an example of entries in the hostname6.ip.tun0 file:
tsrc 10.10.10.23 tdst 172.16.7.19 up addif 2001:db8:3b4c:1:5678:5678::2 up |
In this example, the IPv4 source and destination addresses are used as tokens to autoconfigure IPv6 link-local addresses. These addresses are the source and destination for the ip.tun0 interface. Two interfaces are configured. The ip.tun0 interface is configured. A logical interface, ip.tun0:1, is also configured. The logical interface has the source and destination IPv6 addresses specified by the addif command.
The contents of these configuration files are passed to ifconfig without change when the system is started in multiuser mode. The entries in Example 10–11 are equivalent to the following:
# ifconfig ip.tun0 inet6 plumb # ifconfig ip.tun0 inet6 tsrc 10.0.0.23 tdst 172.16.7.19 up # ifconfig ip.tun0 inet6 addif 2001:db8:3b4c:1:5678:5678::2 up |
The following shows the output of ifconfig -a for this tunnel.
ip.tun0: flags=2200850<UP,POINTOPOINT,RUNNING,MULTICAST, NONUD,IPv6> mtu 1480 index 6 inet tunnel src 10.0.0.23 tunnel dst 172.16.7.19 inet6 fe80::c0a8:6417/10 --> fe80::c0a8:713 ip.tun0:1: flags=2200850<UP,POINTOPOINT,RUNNING,MULTICAST,NONUD,IPv6> mtu 1480 index 5 inet6 2001:db8:3b4c:1:5678:5678::2 |
You can configure more logical interfaces by adding lines to the configuration file by using the following syntax:
addif IPv6-source IPv6-destination up |
When either end of the tunnel is an IPv6 router that advertises one or more prefixes over the tunnel, you do not need addif commands in the tunnel configuration files. Only tsrc and tdst might be required because all other addresses are autoconfigured.
In some situations, specific source and destination link-local addresses need to be manually configured for a particular tunnel. Change the first line of the configuration file to include these link-local addresses. The following line is an example:
tsrc 10.0.0.23 tdst 172.16.7.19 fe80::1/10 fe80::2 up |
Notice that the source link-local address has a prefix length of 10. In this example, the ip.tun0 interface resembles the following:
ip.tun0: flags=2200850<UP,POINTOPOINT,RUNNING,MULTICAST,NONUD,IPv6> mtu 1480 index 6 inet tunnel src 10.0.0.23 tunnel dst 172.16.7.19 inet6 fe80::1/10 --> fe80::2 |
To create a tunnel to encapsulate IPv6 packets over an IPv6 network, IPv6 over IPv6, you create the following file name:
/etc/hostname6.ip6.tun0 |
The following is an example of entries in the hostname6.ip6.tun0 file for IPv6 encapsulation over an IPv6 network:
tsrc 2001:db8:3b4c:114:a00:20ff:fe72:668c tdst 2001:db8:15fa:25:a00:20ff:fe9b:a1c3 fe80::4 fe80::61 up |
To create a tunnel to encapsulate IPv4 packets over an IPv6 network, IPv4 over IPv6, you would create the following file name:
/etc/hostname.ip6.tun0 |
The following is an example of entries in the hostname.ip6.tun0 file for IPv4 encapsulation over an IPv6 network:
tsrc 2001:db8:3b4c:114:a00:20ff:fe72:668c tdst 2001:db8:15fa:25:a00:20ff:fe9b:a1c3 10.0.0.4 10.0.0.61 up |
To create a tunnel to encapsulate IPv4 packets over an IPv4 network, IPv4 over IPv4, you would create the following file name:
/etc/hostname.ip.tun0 |
The following is an example of entries in the hostname.ip.tun0 file for IPv4 encapsulation over an IPv4 network:
tsrc 172.16.86.158 tdst 192.168.86.122 10.0.0.4 10.0.0.61 up |
For specific information about tun, see the tun(7M) man page. .For a general description of tunneling concepts during the transition to IPv6, see Overview of IPv6 Tunnels. For a description of procedures for configuring tunnels, see Tasks for Configuring Tunnels for IPv6 Support (Task Map).
The Solaris OS includes 6to4 tunnels as a preferred interim method for making the transition from IPv4 to IPv6 addressing. 6to4 tunnels enable isolated IPv6 sites to communicate across an automatic tunnel over an IPv4 network that does not support IPv6. To use 6to4 tunnels, you must configure a boundary router on your IPv6 network as one endpoint of the 6to4 automatic tunnel. Thereafter, the 6to4 router can participate in a tunnel to another 6to4 site, or, if required, to a native IPv6, non-6to4 site.
This section provides reference materials on the following 6to4 topics:
Topology of a 6to4 tunnel
6to4 addressing, including the format of the advertisement
Description of the packet flow across a 6to4 tunnel
Topology of a tunnel between a 6to4 router and a 6to4 relay router
Points to consider before you configure 6to4 relay router support
More information about 6to4 routing is available from the following sources.
Task or Detail |
For Information |
---|---|
Tasks for configuring a 6to4 tunnel | |
6to4-related RFC | |
Detailed information about the 6to4relay command, which enables support for tunnels to a 6to4 relay router | |
6to4 security issues |
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.
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.
This section describes the flow of packets from a host at one 6to4 site to a host at a remote 6to4 site. This scenario uses the topology that is shown in Figure 10–6. Moreover, the scenario assumes that the 6to4 routers and the 6to4 hosts are already configured.
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.
6to4 relay routers function as endpoints for tunnels from 6to4 routers that need to communicate with native IPv6, non-6to4 networks. Relay routers are essentially bridges between the 6to4 site and native IPv6 sites. Because this solution might be insecure, by default, the Solaris OS does not enable 6to4 relay router support. However, if your site requires such a tunnel, you can use the 6to4relay command to enable the following tunneling scenario.
In Figure 10–7, 6to4 Site A needs to communicate with a node at the native IPv6 Site B. The figure shows the path of traffic from Site A onto a 6to4 tunnel over an IPv4 network. The tunnel has 6to4 Router A and a 6to4 relay router as its endpoints. Beyond the 6to4 relay router is the IPv6 network, to which IPv6 Site B is connected.
This section describes the flow of packets from a 6to4 site to a native IPv6 site. This scenario uses the topology that is shown in Figure 10–7.
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.
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 decapsulates the IPv4 header from the 6to4 packets, revealing the native IPv6 destination 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.
This section describes naming changes that were introduced by the implementation of IPv6. You can store IPv6 addresses in any of the Solaris naming services, NIS, LDAP, DNS, and files. You can also use NIS over IPv6 RPC transports to retrieve any NIS data.
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.
IPv6 support has been added to the NIS, LDAP, and DNS name services. Consequently, the nsswitch.conf file has been modified to support IPv6 lookups.
The following diagram shows the new relationship between the nsswitch.conf file and the new name services databases for applications that use the gethostbyname and getipnodebyname commands. Items in italics are new. The gethostbyname command checks only for IPv4 addresses that are stored in /etc/inet/hosts. If the lookup fails, then the command checks the database that is specified in the hosts entry in the nsswitch.conf file.
For more information on name services, see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
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 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.
The Solaris OS supports IPv6 over ATM, permanent virtual circuits (PVC), and static switched virtual circuits (SVC).