Use the following syntax to represent IPv6 addresses as text strings:

x:x:x:x:x:x:x:x

The x is a hexadecimal value of a 16-bit piece of the address. For example, the following addresses are IPv6 addresses:

FEDC:BA98:7654:3210:FEDC:BA98:7654:3210

1070:0:0:0:0:800:200C:417B

IPv6 addresses can contain long strings of zero (0) bits. To make it easier to write these addresses, you can use a double colon (::) once in an address to represent one or more 16-bit groups of zeros. For example, you can compress the second IPv6 address example in the following way:

1070::800:200C:417B

Alternately, you can use the following syntax to represent IPv6 addresses in an environment of both IPv4 and IPv6 nodes:

x:x:x:x:x:x:d.d.d.d

In this case, x is a hexadecimal value of a 16-bit piece of the address (six high-order pieces) and d is a decimal value of an 8-bit piece of address (four low-order pieces) in standard, dotted-quad IPv4 form. For example, the following are IPv6 addresses:

0:0:0:0:0:0:13.1.68.3

0:0:0:0:0:FFFF:129.144.52.38

When compressed, these addresses are as follows:

::13.1.68.3

::FFFF:129.144.52.38

Like IPv4 address prefixes, IPv6 address prefixes are represented using the Classless Inter-Domain Routing (CIDR) notation. This notation has the following format:

ipv6-address/prefix-length

For example, you can represent the 60-bit hexadecimal prefix 12AB00000000CD3 in any of the following ways:

12AB:0000:0000:CD30:0000:0000:0000:0000/60

12AB::CD30:0:0:0:0/60

12AB:0:0:CD30::/60

There are three types of IPv6 addresses:

The following sections describe the unicast, anycast, and multicast address types.

1.2.2.1. Unicast Addresses

A unicast address is an identifier for an interface. Packets sent to a unicast address are delivered to the node containing the interface that is identified by the address.

Figure 1.1, “Unicast Addresses” shows the format of unicast addresses.

This address typically consists of a 64-bit prefix followed by a 64-bit interface ID, as shown in Figure 1.2, “64-Bit Prefix Plus 64-Bit Interface ID”.

An interface ID identifies an interface on a link. The interface ID is required to be unique on a link, but it may also be unique over a broader scope. In many cases, the interface ID is derived from its Link layer address. The same interface ID can be used on multiple interfaces on a single node.

According to RFC2373, most prefixes must have 64-bit interface identifiers. For a 48-bit MAC addresses, the interface identifier is created by inserting the hexadecimal values of 0xFF and 0xFE in the middle of the address and inverting the universal/local bit (bit 7) in the resulting 64-bit address. Figure 1.3, “Creating an Interface ID from a MAC Address” shows how this process works.

The following list describes commonly used unicast addresses and their values:

• Unspecified address

  Indicates the absence of an address and is never assigned to an interface. The unspecified address has the following value:
  

  0:0:0:0:0:0:0:0 (normal form)
  
  :: (compressed form)

• Loopback address

  Used by a node to send IP datagrams to itself and is typically assigned to the loopback interface.

  The IPv6 loopback address has the following value:
  

  0:0:0:0:0:0:0:1 (normal form)
  
  ::1 (compressed form)

• Global unicast addresses

  These addresses are globally routable.

  Figure 1.4, “IPv6 Global Unicast Address” shows the format of the global unicast address.

  

  RFC 2374 defined aggregatable global unicast address formats that included Top Level Aggregator (TLA) and Next Level Aggregator (NLA). RFC 3587 replaces RFC 2374, and makes it and the TLS/NLA structure historic.

• IPv6 addresses with embedded IPv4 addresses

  Used in mixed IPv4 and IPv6 environments and can be either of the following:

  • IPv4-compatible IPv6 address

    Used by IPv6 nodes to tunnel IPv6 packets across an IPv4 routing infrastructure. The IPv4 address is carried in the low-order 32 bits. Figure 1.5, “IPv4-Compatible IPv6 Address” shows the format of the IPV4-compatible IPV6 address.

    

    Note

    Do not use IPv4-compatible IPv6 addresses in DNS or in TCPIP$ETC:IPNODES.

  • IPv4-mapped IPv6 address

    Used to represent an IPv4 address and to identify nodes that do not support IPv6. This address is not used in an IPv6 packet. Figure 1.6, “IPv4-Mapped IPv6 Address” shows the format of the IPv4-mapped IPv6 address.

    

• Local-use IPv6 unicast addresses can be either of the following:

  • Link-local

    Used for addressing on a single link when performing address autoconfiguration or neighbor discovery or when no routers are present. Figure 1.7, “IPv6 Link-Local Unicast Address” shows the format of the link-local address.

    

  • Site-localUsed for sites or organizations that are not connected to the global Internet. Figure 1.8, “IPv6 Site-Local Unicast Address” shows the format of the site-local address.

    

    If you plan to use site-local addresses, be aware of the following guidelines:
    

    • Do not connect a single node to multiple sites.

    • Do not use site-local addresses in the global DNS (the addresses should not be visible outside the site).

    • Dynamic DNS updates for site-local addresses are not supported.

    • Do not advertise or propagate routes containing site-local prefixes outside the site.

Interfaces typically have multiple IPv6 addresses. After IPv6 is configured and the system boots, the LAN and configured tunnel interfaces are automatically assigned a link-local address. If a router is on the link, the system also autoconfigures a global unicast address on the interfaces.

1.2.2.2. Anycast Addresses

An anycast address is an identifier for a set of interfaces typically belonging to different nodes. Packets sent to an anycast address are delivered to one of the interfaces identified as the "nearest" address, according to the routing protocol's measure of distance.

Anycast addresses are allocated from the unicast address space, and cannot be distinguished from unicast addresses. Only the subnet-router anycase address and addresses defined in RFC 2526 are easily identified. Packets sent to the subnet-router anycast address are delivered to the router closest to the originating host only. Figure 1.9, “Anycast Address” shows the format of anycast addresses.

1.2.2.3. Multicast Address

A multicast address is an identifier for a group of nodes. It is similar to an IPv4 multicast address. Figure 1.10, “IPv6 Multicast Address” shows the format for multicast addresses.

In the multicast address format, the fields have the following definitions:

11..11	Identifies the address as multicast.
Flags	Can be either of the following values: 0000, which indicates a permanently assigned (well-known) multicast address, 0001, which indicates a nonpermanently assigned (transient) multicast address.
Scope	Indicates the scope of the multicast group. The following table lists the scope values:
	Value (hex)	Scope
	0	Reserved
	1	Interface-local scope
	2	Link-local scope
	3	Reserved
	4	Admin-local scope
	5	Site-local scope
	6	(unassigned)
	7	(unassigned)
	8	Organization-local scope
	9	(unassigned)
	A	(unassigned)
	B	(unassigned)
	C	(unassigned)
	D	(unassigned)
	E	Global scope
	F	Reserved
Group ID	Identifies the multicast group within the specified scope.

Table 1.1, “Well-Known Multicast Addresses” lists some well-known multicast addresses.

Multicast Address	Meaning
FF01::1	All nodes (interface-local)
FF02::1	All nodes (link-local)
FF01::2	All routers (interface-local)
FF02::2	All routers (link-local)
FF05::2	All routers (site-local)
FF02::1:FFxx:xxxx	Solicited-node address

Each IPv6 address has a unique pattern of leading (high-order) bits that indicates its address type. Table 1.2, “IPv6 Address Types and Prefixes” lists some IPv6 address types and their prefixes.

The BIND resolver has been updated as described in the following RFC draft:

draft-ietf-ipngwg-scoping-arch-04.txt

This change allows the specification of an IPv6 nonglobal address without ambiguity by also specifying an intended scope zone. The format is as follows:

address%zone_id

The format of the nonglobal address includes the following:

For example, the following specifies a nonglobal address on interface WE0:

fe80::1234%WE0

The IPv6 address changes have led to the following definitions for configuring addresses:

In the stateless model, nodes learn address prefixes by listening for Router Advertisement packets. Addresses are formed by combining the prefix with a data link-specific interface token, which is typically derived from the data link address of the interface. This model is favored by administrators who do not need tight control over address configuration. See RFC 2462 for more information.

In DHCPv6, hosts may request addresses, configuration information and services from dedicated configuration servers. This model is favored by administrators who want to delegate addresses based on a client/server model.

In both cases, the resulting addresses have associated lifetimes, and systems must be able to acquire new addresses and release expired addresses. Combined with the ability to register updated address information with Domain Name System (DNS) servers, these mechanisms provide a path towards network renumbering and provide network administrators with control over the use of network addresses without manual intervention on each host on the network.

The Domain Name System (DNS) provides support for mapping names to IP addresses and mapping IP addresses back to their corresponding names. Because of the increased size of the IPv6 address, the DNS has the following new features:

An IPv6 automatic tunnel is the simplest tunnel to configure and deploy. This mechanism enables hosts with a globally unique IPv4 address to automatically create a tunnel over an IPv4 network. The tunnel is created as a virtual interface (TN0) and is configured with an IPv4-compatible IPv6 address, which is derived from the IPv4 address. The destination address of the packet determines the tunnel destination endpoint. See Section 1.2.2.1, “Unicast Addresses” for more information about IPv4-compatible IPv6 addresses.

This mechanism is good for introducing hosts to IPv6 because it permits application porting, testing, and experimentation with the IPv6 protocol. However, an automatic tunnel has the following limitations:

A 6to4 tunnel is a type of automatic tunnel, but it offers greater connectivity. This mechanism enables a special IPv6 site, called a 6to4 site, with a single, globally unique IPv4 address to automatically create a tunnel over an IPv4 network to communicate with other 6to4 sites. The tunnel is created as a virtual interface (TNn) on a node at the IPv4 network attachment point. This node is either an individual host or a router called a border router. The tunnel is configured with a special 6to4 address that is derived from the IPv4 address. The destination address of the packet determines the tunnel destination endpoint.

Within the 6to4 site, the border router creates the 6to4 site prefix from its globally unique IPv4 address and advertises the prefix to all nodes in the 6to4 site. Each node automatically configures its 6to4 address based on the 6to4 prefix; no special configuration is necessary. Nodes within the 6to4 site communicate with each other using native IPv6. Any traffic that is addressed outside the site is forwarded to the border router.

This mechanism is easy to configure and can be deployed in a production environment. However, a 6to4 tunnel has the following limitations:

A configured tunnel is the most complex tunnel to configure and deploy. There are two types of configured tunnels:

A configured tunnel is created as a virtual interface (ITn) and uses IPv4 addresses (IPv4 configured tunnel) or IPv6 addresses (IPv6 configured tunnel) as the source and destination endpoints. If you want to send IPv6 traffic through any configured tunnel, you configure an IPv6 address on the tunnel interface. If you want to send IPv4 traffic through any configured tunnel, you configure an IPv4 address on the tunnel interface.

This mechanism is the most powerful tunneling mechanism, but has the following limitations:

The TCPIP$ND6HOST process receives and processes IPv6 router advertisement (RA) packets of the neighbor discovery protocol. This enables a system to autoconfigure itself without manual intervention.

The TCPIP$ND6HOST process performs the following functions, based on the contents of IPv6 router advertisements it receives:

After you configure the system as an IPv6 router, the TCPIP$IP6RTRD process sends out periodic router advertisements for the following reasons:

At startup, the TCPIP$IP6RTRD process reads its configuration file for startup information. See Section 2.6.2, “TCPIP$IP6RTRD.CONF Configuration File” for more information on the router configuration file.

In a simple host-to-host configuration (shown in Figure 1.11, “Host-to-Host Configuration with No Router”), host A and host B use IPv6 link-local addresses. By default, the TCPIP$IP6_SETUP command procedure configures the hosts automatically with a link-local address for your system. Figure 2.2, “Simple Host-to-Host Configuration” shows the completed worksheet for host A.

After you configure IPv6 on host A, add a link-local address for host B to the TCPIP$ETC:IPNODES.DAT file. The configuration process for host B in this configuration is similar to that for host A.

In this configuration, no global address prefix is advertised on the LAN. If you want to advertise a global address prefix, you can either configure one of the hosts as a router by using TCPIP$IP6_SETUP or add an IPv6 router to the LAN configuration. An IPv6 router advertises a global prefix on the link.

You can use the netstat -in command to view a local node's link-local and global addresses.

The following TELNET command connects host A to host B using host B's link-local address:

$ TELNET fe80::0a00:2bff:fee2:1e11

Alternately, you can place the address and node name in the TCPIP$ETC:IPNODES.DAT file. Then use the node name as the argument to the TELNET command.

In a host-to-host with router configuration (shown in Figure 1.12, “Host-to-Host Configuration with Router”), host A and host B are on a LAN with router A. In this case, router A advertises the global address prefix dec:1:1::/64 on the LAN. Host A and host B use this address prefix to create global IPv6 addresses. (See Chapter 1 for information about obtaining experimental testing addresses.) Figure 2.3, “Host-to-Host with Router Configuration” shows the completed worksheet for router A.

After you configure IPv6 on router A, add the global addresses for the other hosts to the TCPIP$ETC:IPNODES.DAT file. Repeat this step on host A and host B. Alternatively, you could establish DNS/BIND in your network using the global addresses.

In an IPv6 network-to-IPv6 network with router configuration (shown in Figure 1.13, “IPv6 Network to IPv6 Network with Router Configuration”), two IPv6 networks are connected to each other through router A and its two interfaces. Figure 2.4, “IPv6 Network-to-IPv6 Network with Router Configuration” shows the completed worksheet for router A.

In this example configuration (shown in Figure 1.14, “Multiple IPv6 Networks and Multiple Routers Configuration”), four IPv6 networks are connected to each other using three routers. In this configuration, the routers must exchange routing information in order to learn the routes to other subnets in the network. To accomplish this, each router must run the RIPng protocol. Figure 2.5, “Multiple IPv6 Networks and Multiple Routers Configuration” shows the completed worksheet for router A.

The completed worksheets for router B and C would be similar.

In a host-to-host over tunnel configuration (shown in Figure 1.15, “Host-to-Host Configuration over Tunnel”), two IPv6 systems communicate with each other over a configured tunnel through an IPv4 network and use IPv6 link-local addresses. Figure 2.6, “Host-to-Host over IPv4 Configured Tunnel Configuration” shows the completed worksheet for host A.

After you configure IPv6 on host A, add the link-local address for host B to the TCPIP$ETC:IPNODES.DAT file. The configuration process for host B in this configuration is similar to that for host A.

With this configuration, no global address prefix is advertised on the tunnel. If you want to advertise a global address prefix, you can configure one of the hosts as a router by using TCPIP$IP6_SETUP. An IPv6 router advertises a global prefix on the link.

To view a local node's link-local and global addresses, use the netstat -in command.

The following TELNET command connects host A to host B:

$ telnet fe80::5.6.7.8

Alternately, you can place the address and node name in the TCPIP$ETC:IPNODES.DAT file. Then use the Node name as the argument to the TELNET command.

In a host-to-router over tunnel configuration (shown in Figure 1.16, “Host-to-Router Configuration over Tunnel”), host X communicates with host B over a configured tunnel through an IPv4 network; both nodes use IPv6 addresses. The tunnel in this case is between host X and router A. Figure 2.7, “Host-to-Router over IPv4 Configured Tunnel Configuration” shows the completed worksheet for host X when router A is advertising itself as the default router for the tunnel link and is advertising a global address prefix on the tunnel link.

If router A is not advertising a global address prefix on the tunnel link, the value dec:3:1::/64 would be in the Address prefix field in the Configured Tunnel section of the host X worksheet. If router A is not advertising itself as the default router for the tunnel link, the information shown in Figure 2.8, “Router Not Advertising a Global Address Prefix” would also be on the host X worksheet:

Figure 2.9, “Router Advertising a Global Address Prefix” shows the completed worksheet for router A when router A is advertising a global address prefix on the tunnel link.

If router A is not advertising a global prefix on the tunnel link, the information shown in Figure 2.10, “Router A Not Advertising a Global Prefix on the Tunnel Link” would be on the router A worksheet. Note the manual route to host X. Instead of specifying a destination network prefix, you specify the host route, dec:3:1::5.6.7.8, to host X. The next hop is the link-local IPv6 address of host X's tunnel interface, fe80::5.6.7.8.

In an IPv6 to IPv6 network over tunnel configuration (shown in Figure 1.17, “IPv6 Network-to-IPv6 Network Configuration over Tunnel”), host A communicates with host F over a configured tunnel through an IPv4 network. The host configuration is similar to that of host A (Section 2.3.1, “Simple Host-to-Host Configuration”). All hosts automatically use their default router in order to communicate with hosts on other networks. Figure 2.11, “IPv6 Network to IPv6 Network over IPv4 Configured Tunnel Configuration” shows the worksheet for router A.

You do not have to run RIPng on the WE0 and WE1 interfaces because no routers are attached to the interfaces.

The configuration of router B is similar, except that the source and destination addresses for the configured tunnel would be switched and the address prefixes advertised on WE0 and WE1 would be dec:2:1::/64 and dec:2:2::/64, respectively.

In a 6to4 tunnel configuration (shown in Figure 1.18, “IPv6 Network-to-IPv6 Network Configuration over Tunnel”), host E is the only node in a 6to4 site. It communicates with host B over a 6to4 tunnel through an IPv4 network: both nodes use IPv6 6to4 addresses. The tunnel in this case is betwen host E and router B. IPv6 is not configured on the host E physical interface because it is connected to an IPv4 network. IPv6, however, is configured on the 6to4 tunnel. Figure 2.12, “6to4 Tunnel Host E Configuration” shows the worksheet for host E.

Router B is the border router for another 6to4 site, and is also the IPv6 router for that site. Router B is advertising a 6to4 prefix on each subnet. The upper 48 bits of each 6to4 prefix are identical to the 6to4 site prefix. Figure 2.13, “6to4 Tunnel Host E Configuration” shows the worksheet for router B.

Figure 2.14, “6to4 Tunnel Host E Configuration” shows the worksheet for host B. Because router B is advertising a 6to4 address prefix on the subnet, host B autoconfigures its own 6to4 address as part of its participation in the site; it does not need to configure any 6to4 tunnel interfaces.

To configure your system as an IPv6 host, do the following:

After you shut down TCP/IP Services and before you restart it, you can use the TCPIP$ND6HOST process to register the host's domain name and address in the DNS.

The TCPIP$ND6HOST process receives and processes IPv6 router advertisement (RA) packets of the neighbor discovery protocol. This enables a system to autoconfigure itself without manual intervention. With this version of TCP/IP Services, you can also enable DNS registration.

To enable host name and address registration, enter the following command:

$ DEFINE /SYSTEM TCPIP$ND6D_ENABLE_DDNS 1

The domain name to be registered is obtained using the gethostname() call.

To update the zone, TCPIP$ND6HOST sends dynamic updates to the primary master name server. To determine the master name server, a query for the zone's SOA record is sent to the name server specified in the DNS resolver configuration. To display this information, use the TCP/IP management command SHOW NAME. The name of the primary master server is stored in the SOA MNAME field.

To make use of this feature, you must enable dynamic updates. By default, dynamic updates are rejected by DNS servers. For information about allowing dynamic updates, see the BIND Chapter of the VSI TCP/IP Services for OpenVMS Management guide.

To configure your system as an IPv6 router, do the following:

At startup, the TCPIP$IP6RTRD process reads the TCPIP$IP6RTRD.CONF file to obtain data needed to send router advertisement and RIPng messages. The TCPIP$IP6RTRD.CONF file is created when TCPIP$IP6_SETUP is run, if the system is configured as a router. Initially, the link interface and advertised prefix are inserted, and other default values are used.

The TCPIP$IP6RTRD.CONF file consists of structured information for each interface in the following format:

       interface interface-name {
          # interface keyword-value pairs, one per line
          Prefix prefix/length {
              # prefix keyword-value pairs, one per line
          }
       }

Comments begin with the pound sign (#) and continue to the end of the line. Accepted and default values for the interface keywords and prefix keywords are listed in Section 2.6.2.1, “Interface Keyword Information for TCPIP$IP6RTRD.CONF” and Section 2.6.2.2, “Address-Prefix Keyword Information for TCPIP$IP6RTRD.CONF”. Section 2.6.2.3, “Editing the Router Configuration File” contains a sample configuration file.

x:x:x:x:x:x:x:x

#
# Sample ip6rtrd configuration file
#
interface WE0 {
        MaxRtrAdvInterval 600
        MinRtrAdvInterval 200
        AdvManagedFlag 0
        AdvOtherConfigFlag 0
        AdvLinkMTU 1500
        AdvReachableTime 0
        AdvRetransTimer 0
        AdvMaxHopLimit 64
        AdvDefaultLifetime 1800
        Prefix dec:1::/64 {
                AdvValidLifetime 1200
                AdvPreferredLifetime 600
                AdvOnLinkFlag 1
                AdvAutonomousFlag1 
        }
}

For name-to-address lookups, using AAAA records is recommended because A6 records have been moved to experimental status. Like most stub resolvers, the resolver in TCP/IP Services supports only AAAA lookups because of the difficulty in following A6 chains. The AAAA record for IPv6 is analogous to the A record for IPv4. It specifies an entire address in a single record. For example,

$ORIGIN ipv6.my.zone.

host1        IN        AAAA        5f00:0000:0102:0300:0203:0800:2b0a:0b0c

For address-to-name lookups, the nibble format is recommended because use of the bitstring format has been moved to experimental status. Use of the ip6.arpa IPv6 reverse mapping zone defined in RFC 3152 is recommended because the ip6.int IPv6 address space defined in RFC 1886 has been deprecated and will likely be phased out in the future.

As in IPv4, when looking up an address in nibble format, the address components are simply reversed and ip6.arpa. is appended to the resulting name. For example, the following would provide reverse lookup for a host with the address 5f00:0000:0102:0300:0203:0800:2b0d:0e0f:

$ORIGIN 3.0.2.0.0.0.3.0.2.0.1.0.0.0.0.0.0.0.f.5.ip6.arpa.

f.0.e.0.d.0.b.2.0.0.8.0        IN        PTR        host2.ipv6.my.zone.

The deprecation of the ip6.int IPv6 reverse mapping zone has resulted in an issue for existing clients that will continue to search the ip6.int name space for PTR resource records. Administrators will need to continue to provide PTR data under both of these zones to be compatible with both old and new clients. There is a convenient method using DNAME resource records that can ease administration of this data. The DNAME resource record is used to substitute one suffix of a domain name with another. In this case it will substitute your ip6.int zone suffix with the equivalent ip6.arpa zone suffix. For example, the following DNAME resource record accomplishes the substitution:

$ORIGIN 3.0.2.0.0.0.3.0.2.0.1.0.0.0.0.0.0.0.f.5.ip6.int.

        DNAME    3.0.2.0.0.0.3.0.2.0.1.0.0.0.0.0.0.0.f.5.ip6.arpa.

This approach will work for any point in the name space as long as all authoritative servers for the PTR zone fully implement DNAME resource record behavior as specified in RFC 2672. This includes BIND9 servers but excludes BIND8 servers.

For IPv6, the BIND server does not bind a separate socket to each interface address as it does for IPv4. Instead, it listens on the IPv6 wildcard address, which is not enabled by default. You must use the listen-on-v6 option to specify the ports on which the server will listen for incoming queries sent using IPv6. To enable the BIND server to answer IPv6 queries, you must specify the port in the options statement of the BIND server configuration file. The only values allowed for the option are { any; } and { none; }. For example, to listen on the default port 53 specify the following:

    listen-on-v6 { any; };

To listen on port 1234, specify the following:

    listen-on-v6 port 1234 { any; };

If you do not specify the listen-on-v6 option, the BIND server will not listen on any IPv6 interfaces.

For the AF_INET6 address family, use the following syntax:

ifconfig interface_id address_family [[ip6prefix]
  address[/bitmask] [dest_address]] [parameters]

For the AF_INET6 address family, the address argument is either a host name or the 128-bit IPv6 address, in the following format:

x:x:x:x:x:x:x:x

In this format, each x is the hexadecimal value of a 16-bit piece of the address.

The ip6prefix argument specifies that the interface identifier is to be appended to the address argument when configuring an address on the interface. The interface identifier uniquely identifies an interface on a subnet and is typically the interface's Link layer address. The following are the parameters for the ifconfig command.

Parameters [AF_INET6 only]:

Refer to the VSI TCP/IP Services for OpenVMS Tuning and Troubleshooting manual for more information on the ifconfig command.

The iptunnel command creates configured tunnels for sending and receiving IPv6 or IPv4 packets that are encapsulated as the payload of an IPv4 datagram.

The iptunnel command can perform the following operations:

For related information, see RFC 2003.

The 6bone network provides a test environment for IPv6 networks. To connect to the 6bone, choose a 6bone point that is reasonably close to your normal IPv4 paths into the Internet. The 6bone web site at http://www.6bone.net contains information on how to join the 6bone and how to find an attachment point. If you want to connect to the 6bone through the Palo Alto site either before or after you configure IPv6 on your host or router, complete the following steps:

In some cases, you might want to either add a new interface card to your system or change an interface card from one type to another. After the new card is installed, you must initialize it for IPv6 operation. To initialize an interface, use the ifconfig command with the following syntax:

$ ifconfig device ipv6 up

For LAN interfaces, the ifconfig command creates the link-local address (FE80::) and starts detection of duplicate addresses.

For example, to initialize Ethernet interface WE0 for use with IPv6, enter the following:

$ ifconfig "WE0" ipv6 up

To initialize the loopback interface for use with IPv6, enter the following:

$ ifconfig "LO0" ipv6 up

To initialize the automatic tunnel interface, enter the following:

$ ifconfig "TN0" ipv6 up

This command designates one of the system's IPv4 addresses for use as the tunnel endpoint.

If you want the designated IPv4 address to be the permanent tunnel endpoint, you must use TCPIP$IP6_SETUP.

$ ifconfig "WE0" ip6interfaceid ::0123:4567:89ab:cdef ipv6 up

$ ifconfig interface -ipv6

$ ifconfig "WE0" -ipv6

To create a configured tunnel, use the iptunnel command in the following format:

iptunnel create remote-tunnel-IPv4address

For example, to create a tunnel to remote system 16.20.136.47, enter the following command:

$ iptunnel create 16.20.136.47

To initialize the tunnel for IPv6 operation, enter the following command:

$ ifconfig "IT0" ipv6 up

To add or assign an IPv6 prefix to an interface and to direct the kernel to automatically append the interface identifier, use the ifconfig command with the following syntax:

ifconfig interface inet6 ip6prefix prefix

The following example assigns the address dec:2::0a00:2bff:fe12:3456 to interface WE0 (the interface ID is 0a00:2bff:fe12:3456):

$ ifconfig "WE0" inet6 ip6prefix dec:2::/64

The ip6prefix parameter directs the kernel to automatically append the interface identifier to the address prefix.

To add or assign a full IPv6 address to an interface manually, use the ifconfig command with the following syntax:

ifconfig interface inet6 ipv6address

The following example assigns the address dec:2::1 to interface WE0:

$ ifconfig "WE0" inet6 dec:2::1

To delete an IPv6 address from an interface manually, use the ifconfig command with the following syntax:

ifconfig interface inet6 delete ipv6address

For example:

$ ifconfig "WE0" inet6 delete dec:2::1

To add a default router, use the route command with the following syntax:

route add -inet6 default ipv6address -I interface

For example:

$ route add -inet6 default fe80::0a00:2bff:fe12:3456 -"I" "WE0"

To delete a default router, use the route command with the following syntax:

route delete -inet6 default ipv6address -I interface

For example:

$ route delete -inet6 default fe80::0a00:2bff:fe12:3456 -"I" "WE0"

After you manually add an address prefix to an interface, you also can add a static route so that traffic to other hosts with the same prefix is sent directly to the destination rather than through a router. For example, if the prefix DEC:5::/64 has been added to the Ethernet interface WE0, which has been initialized with the link-local address fe80::0a00:2bff:fe12:3456, the following command adds a route to neighboring hosts with the same prefix:

$ route add -inet6 dec:5::/64 fe80::0a00:2bff:fe12:3456 -interface

This command specifies that destinations with prefix dec:5::0/64 are reachable through the interface with address fe80::0a00:2bff:fe12:3456. That is, dec:5::0/64 is an on-link prefix.

You can test access to internet network hosts with the ping command. The ping command accepts an IPv4 address, an IPv6 address, or a node name on the command line. The following sample command specifies an IPv6 address:

$ ping -c 2 5F00:2100:108C:4000:8C40:800:2B2D:2B2
 
PING (5F00:2100:108C:4000:8C40:800:2B2D:2B2): 56 data bytes
64 bytes from 5F00:2100:108C:4000:8C40:800:2B2D:2B2: icmp6_seq=0
     hlim=58 time=17 ms
64 bytes from 5F00:2100:108C:4000:8C40:800:2B2D:2B2: icmp6_seq=1
     hlim=58 time=17 ms
----5F00:2100:108C:4000:8C40:800:2B2D:2B2 PING Statistics----
2 packets transmitted, 2 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 17/17/17 ms

The ping command accepts a -V4 or -V6 flag to send an IPv4 ECHO_REQUEST to a node with an IPv4 address, or to send an IPv6 ECHO_REQUEST to a node with an IPv6 address, respectively. If you do not specify either flag, the ping command sends an appropriate ECHO_REQUEST based on the address family being used.

You can also use the -I flag to force the use of a specific interface. For example:

$ ping -"I" "WE0" FE80::800:2B2D:2B2

The netstat command displays network-related data in various formats. You can display network statistics for sockets, interfaces, and routing tables.

The parameters -f address_family limit reports to the specified address family. For example,

To display IPv6 routing entries, enter this command:

$ netstat -rnf inet6

To display active IPv6 connections, enter this command:

$ netstat -af inet6

To display statistics for all protocols including IPv6 and ICMPv6, enter this command:

$ netstat -s

The traceroute command with the host argument prints the route that packets take to both IPv4 and IPv6 hosts.

The -G @addr1@addr2... parameters (IPv6 only) specify the source route for packets to travel. The route consists of one or more IPv6 node names or addresses. Use the at character (@) to separate multiple addresses. You can specify up to 10 addresses.

The -V version parameter specifies the Internet Protocol (IP) version number to enable the resolver to return the correct address. Use the -V 4 option if you want to issue a traceroute command to a host name (not an IP address) that has both IPv4 and IPv6 addresses, and you want to trace the route to the IPv4 address.

In the following examples, the backslash (\) and the continuation of output onto a second line is for display purposes only. In actual output, the information appears on a single line.

$ traceroute -n  -"V" 6 v6host1
 traceroute to v6host1.corp.com (3ffe:1200:4110:3:a00:2bff:feb4:89c5), \
30 hops max, 24 byte packets 
1  fe80::a00:2bff:fe2a:1ed3  130.86 ms 119.141 ms  119.14 ms 
2  3ffe:1200:4110:1:a00:2bff:fe2d:2b2  126.014 ms  117.308 ms  116.33 ms
3  3ffe:1200:4110:3:a00:2bff:feb4:89c5 122.195 ms  135.882 ms 119.263 ms
 
$ traceroute 3ffe:1200:4110:3:a00:2bff:feb4:89c5 
traceroute to 3ffe:1200:4110:3:a00:2bff:feb4:89c5 \
(3ffe:1200:4110:3:a00:2bff:feb4:89c5), 30 hops max, 24 byte packets 
1  fe80::a00:2bff:fe2a:1ed3 (fe80::a00:2bff:fe2a:1ed3) 123.046 ms \
114.258 ms  117.188 ms 
2  v6host2.corp.com (3ffe:1200:4110:1:a00:2bff:fe2d:2b2)  115.234 ms \
117.188 ms  116.287 ms 
3  v6host1.corp.com (3ffe:1200:4110:3:a00:2bff:feb4:89c5)  120.241 ms \
113.398 ms  120.24 ms

When the route has an IPv6-over-IPv4 tunnel, traceroute views this as a single hop. It prints only the IPv6 addresses of the nodes at each end of a tunnel, and none of the intermediate IPv4 routers between the tunnel source and destination. If a traceroute command over a tunnel interface fails, run the command again and specify the tunnel's IPv4 destination address.

The following command shows a trace across the 6bone network to destination tw4.es.net. Note that the intermediate routers appear to drop every other message. The probable reason for this is that the routers rate-limit IPv6 ICMP error messages to one per second. Rate-limiting ICMP error messages is valid behavior.

In the following examples, the backslash (\) and the continuation of output onto a second line is for display purposes only. In actual output, the information appears on a single line.

$ traceroute tw4.es.net
traceroute to tw4.es.net (3ffe:780:40:1:a00:2bff:febc:e96c), 30 hops max, 24 byte packets
1  gw1.ipv6.pa-x.dec.com (3ffe:1280:1000:1::f842:1428)  83.985 ms * 83.000 ms
2  3ffe:700:20:1::21 (3ffe:700:20:1::21)  108.399 ms *  112.305 ms
3  3ffe:780:40:1:a00:2bff:febc:e96c(3ffe:780:40:1:a00:2bff:febc:e96c) \
124.023 ms  134.766 ms  116.211 ms

The following example shows a trace to destination yogi-gbl using 2000-byte messages. It also shows the effect of path MTU discovery on traceroute results.

$ traceroute yogi-gbl 2000
traceroute to yogi-gbl (fec0:10:60:0:200:f8ff:fe40:d8e6), 30 hops max, 2024 byte packets
1  a30rtr-gbl (fec0:10:30:0:200:f8ff:fe45:cfb2)  5.859 ms  3.906 ms  3.907 ms
2  fec0:10:20:0:a00:2bff:feb0:972d (fec0:10:20:0:a00:2bff:feb0:972d) \
4.882 ms  3.906 ms  3.906 ms 
3  * fec0:10:40:1::a0a:283c (fec0:10:40:1::a0a:283c)  6.836 ms  6.836 ms
4  yogi-gbl (fec0:10:60:0:200:f8ff:fe40:d8e6)  8.789 ms  8.789 ms  7.812 ms

Hops 1 and 2 occur across Ethernet links that have a link MTU of 1500 bytes. Hop 3 occurs across a configured tunnel with an MTU of 1280 bytes.

The 1500-byte message fragments were transmitted without error until they hit the tunnel. The first fragment across hop 3 triggered a "message too big" error, which in turn caused the sender to record a reduced Path MTU for yogi-gbl. The sender sent all subsequent messages with smaller fragments. The traceroute display shows that the first probe to the tunnel was dropped but that all others succeeded.

The tcpdump command captures, parses, and prints IPv6 and ICMPv6 packets.

To see IPv6 packets, enter this command:

$ tcpdump interface -s 1500 [-x] [ipv6 | icmpv6]

The tunneling interface is not visible to the packet filter routines so you cannot trace the tunneled packets directly. To view these packets, use the actual IPv4 interface and filter for encapsulated IPv6 packets, which use the IP Protocol value 41, as follows:

$ tcpdump interface -s 1500 [-x] ip proto 41

After you verify that IPv6 mobile support is enabled, your system is ready to function as a correspondent node and to communicate with mobile nodes both through the home agent and, after the receiving a binding update from a mobile node, directly with the mobile node. No further configuration is necessary.

Please see the VSI TCP/IP Services for OpenVMS Release Notes for the latest information on configuring a mobile node as a home agent.

The tcpdump command captures, parses, and prints IPv6 packets. The binding update and acknowledgment options are contained in IPv6 Destination Option headers in IPv6 packets.

To see IPv6 packets, issue the tcpdump command as follows:

$ tcpdump -s 1500 -x ipv6

See the VSI TCP/IP Services for OpenVMS Tuning and Troubleshooting manual for more information about using tcpdump.

The netstat -b command allows you to monitor current mobility bindings and their attributes. The following example shows the command output:

$ netstat -b 
 
Mobile IPv6 Binding Cache 
 
Home Address     Care-of Address    Flags     Refs  Sequence#   Lifetime 
testhome         testcoa            A            1     1         43 
  [1]               [2]             [3]          [4]        [5]        [6] 
 

This example shows that:

The netstat -bs command enables you to monitor mobility binding statistics. The following example shows the command output:

$ netstat -bs
Mobile IPv6:
       1 entry in binding cache
       1 add
       0 deletes
       0 changes
       0 frees
       3 lookups

The TCPIP$IP6RTRD process logs informational and severity events in the SYS$MANAGER:TCPIP$IP6RTRD.LOG file.

Verify that the TCPIP$ND6HOST process is running by issuing the following command:

$ SHOW SYSTEM /PROCESS=TCPIP$ND6HOST

If the process is not running, enable IPv6 with the following command:

$ @SYS$STARTUP:TCPIP$STARTUP.COM

This creates the IPv6 interfaces, brings them up, and starts the TCPIP$ND6HOST process.

If a remote host is not known, the following message may appear in application log files:

unknown host

Perform the following steps:

If an on-link node is not reachable, one of the following messages may appear in an application log file:

no route to host
network is unreachable
connection timed out

Verify that an on-link node or router (if one exists) is reachable by using the ping command. If the command fails or if packets are frequently dropped, perform the following steps:

If an off-link node is not reachable, one of the following messages may appear in an application log files:

no route to host
network is unreachable
connection timed out

Verify that an off-link node is reachable by issuing the ping command.

If there is 100% packet loss, perform the following steps:

Frequently dropped packets might indicate either network congestion or an intermittent routing problem. To determine the cause, do the following:

If someone reports a problem reaching your node from another node, perform the following steps:

If a remote node is not configured to accept a connection from your application, the following message might appear in an application log file:

connection refused

Verify that TCP/IP Services has been correctly configured on the remote node to accept connections.

Contact the administrator for the remote node and ask whether the correct socket-based service definitions are defined in the TCPIP$SERVICES.DAT file. Check whether the service has IPv6 enabled.

If the connection terminates abnormally or a network application appears to hang, perform the following steps:

Verify that the TCPIP$IP6RTRD process is running by issuing the following command:

$ SHOW SYSTEM /PROCESS=TCPIP$IP6RTRD

If the process is not running, start IPv6 with the following command:

$ @SYS$STARTUP:TCPIP$STARTUP.COM

This creates the IPv6 interfaces, brings them up, and starts the TCPIP$IP6RTRD process.

If a remote host is not known, the following message may appear in an application log file:

unknown host

If you receive this message, perform these steps:

If an on-link node is not reachable, one of the following messages may appear in an application log file:

no route to host
network is unreachable
connection timed out

Verify that an on-link node or router is reachable by using the ping command. If the command fails or if packets are frequently dropped, complete the following steps:

If an off-link node is not reachable, the following messages may appear in an application log file:

no route to host
network is unreachable
connection timed out

Verify that an off-link node is reachable by issuing the ping command.

If there is 100% packet loss, perform the following steps:

Frequently dropped packets indicate either network congestion or an intermittent routing problem.

To determine the cause, do the following:

IPv6 hosts generate their global and site-local unicast addresses automatically by using address prefixes provided by a router on the link. If an on-link node cannot autoconfigure its addresses, perform the following steps:

If another network user reports that message transmission appears to be failing at your router, perform the following steps:

If someone reports a problem reaching your node from another node, perform the following steps:

If a remote node is not configured to accept a connection from your application, the following message might appear in an application log file:

connection refused

Verify that TCP/IP Services has been correctly configured on the remote node to accept connections.

Contact the administrator for the remote node and ask whether the correct socket-based service definitions are defined in the TCPIP$SERVICES.DAT file. Check whether the service has IPv6 enabled.

If the connection terminates abnormally or if a network application appears to hang, perform the following steps:

The in6_addr, defined in the IN6.H header file, supports IPv6.

The address is stored in network byte order as an array of sixteen 8-bit elements.

A wildcard address, defined in network byte order, has the following forms:

A loopback address, defined in network byte order, has the following forms:

The sockaddr_in6 structure, defined in IN6.H header file, is the protocol-specific address data structure for IPv6.

This data structure enables applications to send and receive ancillary data using the sendmsg and recvmsg functions. This data structure, which is defined in the SOCKET.H header file, also allows AF_INET sockets and raw AF_INET6 sockets to receive certain data.

For IPv4, see the VSI TCP/IP Services for OpenVMS Sockets API and System Services Programming manual for the descriptions of the IP_RECVDSTADDR and IP_RECVOPTS socket options.

For IPv6, Section 7.3, “Socket Options” describes the IPV6_RECVHOPOPTS , IPV6_RECVDSTOPTS , and IPV6_RECVRTHDR options.

The cmsghdr structure describes ancillary data objects transferred by the sendmsg and recvmsg functions.

The msg_control member of the msghdr data structure points to the ancillary data that are contained in a cmsghdr structure. Typically, only one data object is passed in a cmsghdr structure. However, the IPv6 advanced sockets API enables the sendmsg and recvmsg functions to pass multiple objects. See Section 7.5.1, “Using IPv6 Raw Sockets” for information about using raw IPv6 sockets.

The data structure is defined in the SOCKET.H header file.

To identify the interface on which a datagram is received, on which a datagram is to be sent, and on which a multicast group is joined, the API uses a small, positive integer called an interface index. The kernel assigns this integer to an interface when the interface is initialized.

The API defines the following new functions:

The following functions are available for node name to address translation:

The following functions are available for address to node name translation:

The following address conversion functions convert both IPv4 and IPv6 addresses.

Table 7.2, “Summary of Address-Testing Macros” lists the currently defined address-testing macros and the return value for a valid test. To use these macros, include the following file in your application:

#include <in.h>

Raw sockets are used in both IPv4 and IPv6 to bypass the TCP and UDP transport layers.

Table 7.3, “Differences Between IPv4 and IPv6 Raw Sockets” describes the principal differences between IPv4 and IPv6 raw sockets.

For output, applications can modify all fields, except for the flow label field, by using ancillary data or socket options, or both.

For input, applications can access all fields, except for the flow label, version number, and Next Header fields, and all extension headers by using ancillary data.

For IPv6 raw sockets other than ICMPv6 raw sockets, the application must set the IPV6_CHECKSUM socket option. For example:

int offset = 2;
setsockopt (fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset, sizeof(offset));

This enables the kernel to compute and store a checksum for output and to verify the checksum on input. This relieves the application from having to perform source address selection on all outgoing packets. This socket option is disabled by default. You can explicitly disable this option by setting the offset variable to -1.

Using IPv6 raw sockets, an application can access the following information:

The following sections describe how to access this information.

struct icmp6_filter myfilter;

setsockopt (fd, IPPROTO_ICMPV6, IPV6_FILTER, &(myfilter), (sizeof)(myfilter));

Applications that use the IPv4 in_addr structure must be changed to use the IPv6 in6_addr structure, as follows:

Make the following changes to your application, as needed:

Applications that use the generic socket address structure (sockaddr) to hold an AF_INET socket address (sockaddr_in) must be changed to use the AF_INET6 sockaddr_in6 structure, as follows:

Make the following change to your application, as needed:

Applications that use the BSD Version 4.4 IPv4 sockaddr_in structure must be changed to use the IPv6 sockaddr_in6 structure, as follows:

Make the following changes to your application, as needed:

Applications that use the hostent structure must be changed to use the addrinfo structure, as follows:

Make the following change to your application, as needed:

See also Section 8.4.2, “gethostbyname() Function” for related changes.

Applications that use the IPv4 gethostbyaddr() function must be changed to use the IPv6 getnameinfo() function, as follows:

Make the following change to your application, as needed:

Applications that use the gethostbynam()e function must be changed to use the getaddrinfo() function, as follows:

Make the following changes to your application, as needed:

Applications that use the inet_ntoa() function must be changed to use the getnameinfo() function, as follows:

Make the following change to your application, as needed:

Applications that use the inet_addr() function must be changed to use the getaddrinfo() function, as follows:

Make the following change to your application, as needed:

If your application compares IP addresses or tests IP addresses for equality, the in6_addr structure changes (see in Section 8.3.1, “in_addr Structure”) will change the comparison of int quantities to a comparison of structures. This will break the code and cause compiler errors.

Make either of the following changes to your application, as needed:

If your application compares an IP address to the wildcard address, the in6_addr structure changes (see Section 8.3.1, “in_addr Structure”) will change the comparison of int quantities to a comparison of structures. This will break the code and cause compiler errors.

Make either of the following changes to your application, as needed:

If your application uses int data types to hold IP addresses, the in6_addr structure changes (see Section 8.3.1, “in_addr Structure”) will change the assignment. This will break the code and cause compiler errors.

Make the following changes to your application, as needed:

If your application uses functions that return IP addresses as int data types, the in6_addr structure changes (see Section 8.3.1, “in_addr Structure” will change the destination of the return value from an int to an array of char. This will break the code and cause compiler errors.

Make the following changes to your application, as needed:

If your application uses IPv4 IP-level socket options, change them to the corresponding IPv6 options.

This section contains a client and a server program that use AF_INET sockets.

#include <in.h>          /* define internet related constants,   */
                                    /* functions, and structures     */
#include <inet.h>        /* define network address info     */

#include <netdb.h>       /* define network database library info */

#include <socket.h>      /* define BSD 4.x socket api     */
#include <stdio.h>       /* define standard i/o functions     */
#include <stdlib.h>      /* define standard library functions    */
#include <string.h>      /* define string handling functions     */

#include <unixio.h>      /* define unix i/o       */


#define BUFSZ           1024           /* user input buffer size     */
#define SERV_PORTNUM    12345          /* server port number      */


int  main( void );                     /* client main    */
void get_serv_addr( void * );     /* get server host address    */


int
main( void )
{
    int sockfd;                   /* connection socket descriptor    */

    char buf[512];                /* client data buffer    */

    struct sockaddr_in serv_addr;  /* server socket address structure */

    memset( &serv_addr, 0, sizeof(serv_addr) );
    serv_addr.sin_family = AF_INET;
    serv_addr.sin_port   = htons( SERV_PORTNUM );
    get_serv_addr( &serv_addr.sin_addr );

    if ( (sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0 )
 {
 perror( "Failed to create socket" );
 exit( EXIT_FAILURE );
 }

    printf( "Initiated connection to host: %s, port: %d\n",
     inet_ntoa(serv_addr.sin_addr), ntohs(serv_addr.sin_port)
   );

    if ( connect(sockfd,
   (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0 )
 {
 perror( "Failed to connect to server" );
 exit( EXIT_FAILURE );
 }

    if ( recv(sockfd, buf, sizeof(buf), 0) < 0 )
 {
 perror( "Failed to read data from server connection" );
 exit( EXIT_FAILURE );
 }

  printf( "Data received: %s\n", buf ); /* output client's data buffer */

    if ( shutdown(sockfd, 2) < 0 )
 {
 perror( "Failed to shutdown server connection" );
 exit( EXIT_FAILURE );
 }

    if ( close(sockfd) < 0 )
 {
 perror( "Failed to close socket" );
 exit( EXIT_FAILURE );
 }

    exit( EXIT_SUCCESS );
}

void
get_serv_addr( void *addrptr )
{
    char buf[BUFSZ];        /* input data buffer       */
    struct in_addr val;     /* remote host address structure  */
    struct hostent *host;   /* remote host hostent structure  */

    while ( TRUE )
 {
 printf( "Enter remote host: " );

 if ( fgets(buf, sizeof(buf), stdin) == NULL )
     {
     printf( "Failed to read User input\n" );
     exit( EXIT_FAILURE );
     }

 buf[strlen(buf)-1] = 0;

 val.s_addr = inet_addr( buf );

 if ( val.s_addr != INADDR_NONE )
     {
     memcpy( addrptr, &val, sizeof(struct in_addr) );
     break;
     }

 if ( (host = gethostbyname(buf)) )
     {
     memcpy( addrptr, host->h_addr, sizeof(struct in_addr) );
     break;
     }
 }
}

#include <in.h>          /* define internet related constants,   */
                                    /* functions, and structures     */
#include <inet.h>        /* define network address info     */

#include <netdb.h>       /* define network database library info */

#include <socket.h>      /* define BSD 4.x socket api     */
#include <stdio.h>       /* define standard i/o functions     */
#include <stdlib.h>      /* define standard library functions    */
#include <string.h>      /* define string handling functions     */

#include <unixio.h>      /* define unix i/o       */


#define SERV_BACKLOG 1               /* server backlog      */
#define SERV_PORTNUM 12345           /* server port number      */


int  main( void );                      /* server main       */


int
main( void )
{
    int optval = 1;                  /* SO_REUSEADDR'S option value (on) */

    int conn_sockfd;                 /* connection socket descriptor     */
    int listen_sockfd;               /* listen socket descriptor     */

    unsigned int client_addrlen; /* returned length of client socket */
                                 /* address structure */
  struct sockaddr_in client_addr; /* client socket address structure */
    struct sockaddr_in serv_addr;    /* server socket address structure */

    struct hostent *host;           /* host name structure */

    char buf[] = "Hello, world!";       /* server data buffer */

    memset( &client_addr, 0, sizeof(client_addr) );

    memset( &serv_addr, 0, sizeof(serv_addr) );
    serv_addr.sin_family  = AF_INET;
    serv_addr.sin_port    = htons( SERV_PORTNUM );
    serv_addr.sin_addr.s_addr = INADDR_ANY;

    if ( (listen_sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0 )
        {
        perror( "Failed to create socket" );
        exit( EXIT_FAILURE );
        }

    if ( setsockopt(listen_sockfd,
      SOL_SOCKET, SO_REUSEADDR, &optval, sizeof(optval)) < 0 )
        {
        perror( "Failed to set socket option" );
        exit( EXIT_FAILURE );
        }

    if ( bind(listen_sockfd,
       (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0 )
        {
        perror( "Failed to bind socket" );
        exit( EXIT_FAILURE );
        }

    if ( listen(listen_sockfd, SERV_BACKLOG) < 0 )
        {
        perror( "Failed to set socket passive" );
        exit( EXIT_FAILURE );
        }

    printf( "Waiting for a client connection on port: %d\n",
     ntohs(serv_addr.sin_port)
          );

    client_addrlen = sizeof(client_addr);

    conn_sockfd = accept( listen_sockfd,
                          (struct sockaddr *) &client_addr,
                          &client_addrlen
                        );
    if ( conn_sockfd < 0 )
        {
        perror( "Failed to accept client connection" );
        exit( EXIT_FAILURE );
        }

    host = gethostbyaddr( (char *)&client_addr.sin_addr.s_addr,
                         sizeof(client_addr.sin_addr.s_addr), AF_INET
                         );

    if ( host == NULL )
        {
        perror( "Failed to translate client address\n" );
        exit( EXIT_FAILURE );
        }

    printf( "Accepted connection from host: %s (%s), port: %d\n",
            host->h_name, inet_ntoa(client_addr.sin_addr),
            ntohs(client_addr.sin_port)
          );

    if ( send(conn_sockfd, buf, sizeof(buf), 0) < 0 )
        {
        perror( "Failed to write data to client connection" );
        exit( EXIT_FAILURE );
        }

    printf( "Data sent: %s\n", buf );    /* output server's data buffer  */

    if ( shutdown(conn_sockfd, 2) < 0 )
        {
        perror( "Failed to shutdown client connection" );
        exit( EXIT_FAILURE );
        }

    if ( close(conn_sockfd) < 0 )
        {
        perror( "Failed to close socket" );
        exit( EXIT_FAILURE );
        }

    if ( close(listen_sockfd) < 0 )
        {
        perror( "Failed to close socket" );
        exit( EXIT_FAILURE );
        }

    exit( EXIT_SUCCESS );
}

This section contains a client and a server program that use AF_INET6 sockets.

#include <in.h>            /* define internet related constants,   */
                                      /* functions, and structures     */
#include <inet.h>          /* define network address info     */

#include <netdb.h>         /* define network database library info */

#include <socket.h>        /* define BSD 4.x socket api     */
#include <stdio.h>         /* define standard i/o functions     */
#include <stdlib.h>        /* define standard library functions    */
#include <string.h>        /* define string handling functions     */

#include <unixio.h>        /* define unix i/o       */


#define BUFSZ           1024          /* user input buffer size     */
#define SERV_PORTNUM    "12345"       /* server port number string     */


int main( void );                     /* client main       */
void get_serv_addr( struct addrinfo *hints, struct addrinfo **res );
                                      /* get server host address */

int
main( void )
{
    int sockfd;                          /* connection socket descriptor */

    char buf[512];                       /* client data buffer */

    struct addrinfo hints;     /* input values to direct operation */
    struct addrinfo *res;     /* linked list of addrinfo structs */

    memset( &hints, 0, sizeof(hints) );
    hints.ai_family = AF_INET6;
    hints.ai_flags = AI_ADDRCONFIG | AI_V4MAPPED | AI_CANONNAME;
    hints.ai_protocol = IPPROTO_TCP;
    hints.ai_socktype = SOCK_STREAM;
    get_serv_addr( &hints, &res );

    if ( (sockfd = socket(AF_INET6, SOCK_STREAM, 0)) < 0 )
 {
 perror( "Failed to create socket" );
 exit( EXIT_FAILURE );
 }

    printf( "Initiated connection to host: %s, port: %d\n",
     res->ai_canonname,
     htons(((struct sockaddr_in6 *)res->ai_addr)->sin6_port)
   );

    if ( connect(sockfd, res->ai_addr, res->ai_addrlen) < 0 )
 {
 perror( "Failed to connect to server" );
 exit( EXIT_FAILURE );
 }

    if ( recv(sockfd, buf, sizeof(buf), 0) < 0 )
 {
 perror( "Failed to read data from server connection" );
 exit( EXIT_FAILURE );
 }

  printf( "Data received: %s\n", buf ); /* output client's data buffer */

    if ( shutdown(sockfd, 2) < 0 )
 {
 perror( "Failed to shutdown server connection" );
 exit( EXIT_FAILURE );
 }

    if ( close(sockfd) < 0 )
 {
 perror( "Failed to close socket" );
 exit( EXIT_FAILURE );
 }

    exit( EXIT_SUCCESS );
}

void
get_serv_addr( struct addrinfo *hints, struct addrinfo **res )
{
    int gai_error;   /* return value of getaddrinfo()  */
    char buf[BUFSZ];          /* input data buffer       */
    const char *port = SERV_PORTNUM;    /* server port number  */

    while ( TRUE )
        {
 printf( "Enter remote host: " );

 if ( fgets(buf, sizeof(buf), stdin) == NULL )
     {
     printf( "Failed to read User input\n" );
     exit( EXIT_FAILURE );
     }

 buf[strlen(buf)-1] = 0;

 gai_error = getaddrinfo( buf, port, hints, res );
 if ( gai_error )
            printf( "Failed to resolve name or address: %s\n",
                    gai_strerror(gai_error)
                  );
 else
     break;
 }
}

#include <in.h>             /* define internet related constants,
                            /* functions, and structures     */
#include <inet.h>           /* define network address info     */

#include <netdb.h>          /* define network database library info */

#include <socket.h>         /* define BSD 4.x socket api */
#include <stdio.h>          /* define standard i/o functions */
#include <stdlib.h>         /* define standard library functions */
#include <string.h>         /* define string handling functions */

#include <unixio.h>         /* define unix i/o */


#define SERV_BACKLOG    1              /* server backlog      */
#define SERV_PORTNUM    12345          /* server port number  */


int  main( void );                     /* server main         */

int
main( void )
{
    int optval = 1;       /* SO_REUSEADDR'S option value (on) */

    int conn_sockfd;              /* connection socket descriptor    */
    int listen_sockfd;            /* listen socket descriptor    */
    int gni_error;    /* return status for getnameinfo() */

    unsigned int client_addrlen;     /* returned length of client socket */
                                     /* address structure      */
    struct sockaddr_in6 client_addr; /* client socket address structure */
    struct sockaddr_in6 serv_addr;  /* server socket address structure */

    char buf[] = "Hello, world!";   /* server data buffer */
    char node[NI_MAXHOST];         /* buffer to receive node name */
    char port[NI_MAXHOST];          /* buffer to receive port number    */
    char addrbuf[INET6_ADDRSTRLEN]; /* buffer to receive host's address */

    memset( &client_addr, 0, sizeof(client_addr) );

    memset( &serv_addr, 0, sizeof(serv_addr) );
    serv_addr.sin6_family      = AF_INET6;
    serv_addr.sin6_port        = htons( SERV_PORTNUM );
    serv_addr.sin6_addr        = in6addr_any;

    if ( (listen_sockfd = socket(AF_INET6, SOCK_STREAM, 0)) < 0 )
 {
 perror( "Failed to create socket" );
 exit( EXIT_FAILURE );
 }

    if ( setsockopt(listen_sockfd,
      SOL_SOCKET, SO_REUSEADDR, &optval, sizeof(optval)) < 0 )
 {
 perror( "Failed to set socket option" );
 exit( EXIT_FAILURE );
 }

    if ( bind(listen_sockfd,
       (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0 )
 {
 perror( "Failed to bind socket" );
 exit( EXIT_FAILURE );
 }

    if ( listen(listen_sockfd, SERV_BACKLOG) < 0 )
 {
 perror( "Failed to set socket passive" );
 exit( EXIT_FAILURE );
 }

    printf( "Waiting for a client connection on port: %d\n",
     ntohs(serv_addr.sin6_port)
   );

    client_addrlen = sizeof(client_addr);

    conn_sockfd = accept( listen_sockfd,
     (struct sockaddr *) &client_addr,
     &client_addrlen
   );
    if ( conn_sockfd < 0 )
 {
 perror( "Failed to accept client connection" );
 exit( EXIT_FAILURE );
 }

    gni_error = getnameinfo( (struct sockaddr *)&client_addr, client_addrlen,

        node, sizeof(node), NULL, 0, NI_NAMEREQD
      );
    if ( gni_error )
 {
 printf( "Failed to translate client address: %s\n",
  gai_strerror(gni_error) 
       );
 exit( EXIT_FAILURE );
 }

    gni_error = getnameinfo( (struct sockaddr *)&client_addr, client_addrlen,
        addrbuf, sizeof(addrbuf), port, sizeof(port),
        NI_NUMERICHOST | NI_NUMERICSERV 
      );
    if ( gni_error )
 {
 printf( "Failed to translate client address and/or port: %s\n",
  gai_strerror(gni_error)
       );
 exit( EXIT_FAILURE );
 }

    printf( "Accepted connection from host: %s (%s), port: %s\n",
     node, addrbuf, port
   );

    if ( send(conn_sockfd, buf, sizeof(buf), 0) < 0 )
 {
 perror( "Failed to write data to client connection" );
 exit( EXIT_FAILURE );
 }

    printf( "Data sent: %s\n", buf ); /* output server's data buffer */

    if ( shutdown(conn_sockfd, 2) < 0 )
 {
 perror( "Failed to shutdown client connection" );
 exit( EXIT_FAILURE );
 }

    if ( close(conn_sockfd) < 0 )
 {
 perror( "Failed to close socket" );
 exit( EXIT_FAILURE );
 }

    if ( close(listen_sockfd) < 0 )
 {
 perror( "Failed to close socket" );
 exit( EXIT_FAILURE );
 }

    exit( EXIT_SUCCESS );
}

This section contains sample output from the preceding server and client programs. The server program makes and receives all requests on an AF_INET6 socket using sockaddr_in6. For requests received over IPv4, sockaddr_in6 contains an IPv4-mapped IPv6 address.

The following example shows a client program running on node hostb6 and sending a request to node hosta6. The program uses an AF_INET6 socket. The node hosta6 has the IPv6 address 3ffe:1200::a00:2bff:fe97:7be0 in the Domain Name System (DNS).

$ run client.exe
Enter remote host: hosta6
Initiated connection to host: hosta6.ipv6.corp.example, port: 12345
Data received: Hello, world!
$

On the server node, the following example shows the server program invocation and the request received from the client node hostb6:

$ run server.exe
Waiting for a client connection on port: 12345
Accepted connection from host: hostb6.ipv6.corp.example
(3ffe:1200::a00:2bff:fe97:7be0), port: 49174
Data sent: Hello, world!
$

The following example shows the client program running on node hostb and sending a request to node hosta. The program uses an AF_INET6 socket. The hosta node has only an IPv4 address in the DNS.

$ run client.exe
Enter remote host: hosta
Initiated connection to host: hosta.corp.example, port 12345
Data received: Hello, world!
$

On the server node, the following example shows the server program invocation and the request received from the client node hostb:

$ run server.exe
Waiting for a client connection on port: 12345
Accepted connection from host: hostb.corp.example (::ffff:10.10.10.251), port: 49175
Data sent: Hello, world!
$

The following example shows the client program running on node hostb6 and sending a request to node hosta6 using its link-local address fe80::a00:2bff:fe97:7be0. The program uses an AF_INET6 socket.

$ run client.exe
Enter remote host: fe80::a00:2bff:fe97:7be0
Initiated connection to host: fe80::a00:2bff:fe97:7be0, port: 12345
Data received: Hello, world!
$

On the server node, the following example shows the server program invocation and the request received from the client node hostb6.

$ run server.exe
Waiting for a client connection on port: 12345
Accepted connection from host: hosta6.ipv6.corp.example%WE0
(fe80::a00:2bff:fe97:7be0%WE0), port: 49177
Data sent: Hello, world!
$