z/OS Communications Server: IPv6 Network and Application Design Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Assigning IPv6 addresses

z/OS Communications Server: IPv6 Network and Application Design Guide
SC27-3663-00

When you are assigning IPv6 addresses, use the following guidelines.

Defining the interface ID for physical interfaces

If you do not manually configure the interface ID, the system selects an interface ID by using one of the following values:

  • A random value on an MPCPTP6 interface
  • A value that is derived from the MAC address on an IPAQENET6 interface
  • A value that is derived from the IQD CHPID on an IPAQIDIO6 interface

The interface ID is used to form the link-local address for the interface. The interface ID is also appended to any manually configured prefixes for the interface, to form complete IPv6 addresses on the interface. If you do not configure manual IP addresses on the interface, the interface ID is appended to any prefixes that are learned over this interface by way of router advertisements, to form public IPv6 addresses on the interface.

To simplify the configuration effort, let the system select the interface ID. However, controlling all IPv6 addresses that are assigned to a physical adapter might be useful if other IPv6 nodes need to define static routes to this host, or if you use IPv6 addresses in multilevel security policies.

Use stateless address autoconfiguration for physical interfaces

IPv6 addresses for physical interfaces can be manually defined or can be automatically assigned by stateless address autoconfiguration. Use the stateless address autoconfiguration for this assignment. Using stateless address autoconfiguration reduces the amount of definition required to enable IPv6 support, while making future site renumbering easier.

Use VIPAs

Using static VIPAs removes hardware as a single point of failure for connections being routed over the failed hardware. If you are not using dynamic routing, configure at least one static VIPA for each LAN to which z/OS® Communications Server TCP/IP is connected. Each VIPA configured this way should be associated with all physical adapters connected to that same LAN.

Requirement: Static VIPAs must be manually configured; z/OS Communications Server TCP/IP does not support stateless address autoconfiguration for VIPAs.

Dynamic VIPAs (DVIPAs) can also be used in an IPV6 network. The decision to use DVIPAs in an IPv6 network is similar to the decision to use DVIPAs in an IPv4 network. For detailed information, see z/OS Communications Server: IP Configuration Guide.

Selecting the network prefix

z/OS Communications Server TCP/IP does not perform duplicate address detection for VIPAs, because they are not assigned to a physical interface attached to the LAN.

Guideline: To avoid possible address collisions, the network prefix used for static VIPAs should be different from the network prefix used for physical interfaces (either manually configured or autoconfigured using stateless address autoconfiguration).

If either the IPv6 OSPF or IPv6 RIP dynamic routing protocol of OMPROUTE is being used, the network prefix for a static VIPA should not be the same as any prefix defined as on-link on a physical link. The VIPA can then be associated with interfaces attached to any physical link, thus enabling maximum redundancy. This association between VIPAs and interfaces attached to physical links is accomplished using the SOURCEVIPAINTERFACE parameter of the INTERFACE statement for the interface attached to the physical link.

If IPv6 OSPF or IPv6 RIP dynamic routing protocol of OMPROUTE is not being used, the network prefix for a static VIPA should be selected from the set of prefixes which are advertised by way of router discovery by one or more routers attached to the LAN. The prefix should be advertised as on-link and not to be used for address autoconfiguration. By using an on-link prefix, hosts and routers attached to the LAN use neighbor discovery address resolution to obtain a link-layer address for the VIPA. z/OS Communications Server TCP/IP selects a link-layer address of an attached physical interface when responding to the query, and the attached host or router forwards the packet to z/OS Communications Server TCP/IP. This eliminates the need to define static routes for VIPAs at hosts and routers attached to the same LAN as z/OS Communications Server TCP/IP. By using a prefix that is not being used for address autoconfiguration, the network prefix is not used by hosts for autoconfiguring addresses for physical interfaces.

Selecting the interface identifier

The VIPA interface identifier must be unique among all IP addresses that are created using the combination of network prefix and interface identifier. Any scheme can be used in generating the interface identifiers, as long as they are unique. By using a network prefix that is not used by stateless address autoconfiguration, it is necessary only to ensure the interface identifier is unique among all VIPAs that are sharing the same network prefix.

Effects of site renumbering on static VIPAs

When renumbering a site, new network prefixes are assigned to subnetworks. The existing network prefixes are marked as deprecated, during which time either the new prefixes or the old, deprecated prefixes can be used. After some time period, the deprecated network prefixes are deleted, along with all IPv6 addresses which use the network prefix.

For autoconfigured addresses, this process is automatically managed by stateless address autoconfiguration algorithms. For manually defined addresses, including all VIPAs, the process must be managed manually. When a prefix is to be deprecated, addresses that use the prefix should be deprecated using the INTERFACE DEPRADDR statement. After the prefix has expired, addresses that use the prefix should be deleted using the INTERFACE DELADDR statement.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014