Migrating from IPv4 to IPv6

IPv6 is the next generation Internet protocol and is designed to be a replacement for IPv4. However, it is expected that IPv6 adoption will be gradual and there will be a lengthy transition period during which IPv4 and IPv6 protocols will have to coexist. The IETF (ngtrans working group) has developed a number of transition mechanisms that facilitates IPv6 deployment.

The main goals of these transition mechanisms are to allow newly deployed IPv6 hosts and routers to inter-operate with existing IPv4 hosts and routers and allow isolated IPv6 hosts and routers to communicate with each other using the existing IPv4 infrastructure.

TOUR 2.0 supports the following three transition mechanisms:

Dual stack: This mechanism provides complete concurrent support for both IPv4 and IPv6 protocols in hosts and routers. It allows networks to support both IPv4 applications and IPv6 applications.
Tunneling: Tunneling encapsulates IPv6 packets within IPv4 packets. IPv6 transmission across the IPv4 network is transparent. On TOUR 2.0 configured (point-to-point) tunneling is supported. In addition to IP6-in-IP tunneling support, TOUR 2.0 also supports IP6-in-IP6 and IP-in-IP6 tunnels.
“6to4”: Isolated IPv6 nodes and networks can communicate over an IPv4 network, without explicitly configuring tunnels, by using the “6to4” mechanism (RFC 3056). “6to4” effectively treats the IPv4 wide area network as a unicast point-to-point link layer. “6to4” requires no end-node reconfiguration and minimal router configuration.

Tunneling

Tunneling enables IPv6 hosts and routers to connect with other IPv6 hosts and routers over an existing IPv4 network. Dual stack hosts and routers can tunnel IPv6 packets over regions of IPv4 routing topology by encapsulating them within IPv4 packets. The encapsulated packets travel across an IPv4 Internet until they reach their destination host or router. The IPv6-aware host or router decapsulates the IPv6 datagrams, forwarding them as needed. The IPv6 transmission across the IPv4 Internet is transparent. This type of tunneling is referred to as IP6-in-IP.

Tunneling can be used in a variety of ways:

Router-to-Router: IPv6/IPv4 dual stack routers interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans one segment of the end-to-end path that the IPv6 packet takes.
Host-to-Router: IPv6/IPv4 dual stack hosts can tunnel IPv6 packets to an intermediary IPv6/IPv4 router that is reachable over an IPv4 infrastructure. This type of tunnel spans the first segment of the packet’s end-to-end path.
Host-to-Host: IPv6/IPv4(dual stack hosts that are interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans the entire end-to-end path that the packet takes.
Router-to-Host: IPv6/IPv4 routers can tunnel IPv6 packets to their final destination IPv6/IPv4 host. This tunnel spans only the last segment of the end-to-end path.

Starting with TOUR2.0, the HP-UX 11i v1 IPv6/IPv4 dual stack node can perform the role of the router. It can also continue to perform the role of the host, as it has since IPv6NCF11i.

Configured and Automatic Tunneling

Two tunneling techniques are specified in RFC 2893: configured and automatic. The two techniques differ primarily in how the tunnel end-point is determined.

Configured Tunnels are point-to-point tunnels; tunnel configuration must be done on both ends of the tunnel. The tunnel endpoint is determined from the configuration information.

RFC 2893 specifies tunnels as IPv6 interfaces and requires them to be configured with at least (on primary interfaces) link-local addresses. To conform to RFC 2893, tunnels are implemented as IPv6 pseudo-interfaces.

In TOUR 2.0 tunnels can be configured (ephemerally) using ifconfig and permanently by editing /etc/rc.config.d/netconf-ipv6. In general, the following tunnel parameters are relevant in TOUR 2.0:

Tunnel interface name: This is a local identifier name for each tunnel configured. (It need not be the same on both ends of the configured tunnel.) For IP6-in-IP and “6to4” tunnels this would be iptu<#> (e.g. iptu0, iptu1). For IP6-in-IP6 and IP-in-IP6 tunnels it would be ip6tu<#> (e.g. ip6tu0, ipt6u1).
Tunnel Type: Type of tunnel. Supported tunnels are: “ip6inip”, “6to4” , “ip6inip6”, and “ipinip6”.
Tunnel entry-point node (local) address: This is the tunnel source address. For tunnel types "ip6inip" and "ip6inip6", it should be a link-local IPv6 address. Example: fe80::1. For tunnel type "ip6inip", if the link-local address is not specified, it will be automatically configured based on the source address in the encapsulating (outer) header. For tunnel type "ipinip6", it should be an IPv4 address. For tunnel type "6to4", it should be a “6to4” address derived from the source address in the encapsulating (outer) header. For example, if the source address in the encapsulating (outer) header is 15.13.136.204, the “6to4” prefix should be 2002:0f0d:88cc::, which can be combined to an interface identifier "1" to form the “6to4” address 2002:0f0d:88cc::1.
Tunnel exit-point node (remote) address: This is the tunnel destination address. For “ip6inip” it will be a link-local IPv6 address configured (automatically if not specified) from the destination address in the encapsulating (outer) header. For “6to4” this value must never be specified, since it will always be automatically determined based on routing information.
Source address in the encapsulating (outer) header: This must be an address configured on an interface on the tunnel entry-point (local) node. For “ip6inip” and “6to4” it must be an IPv4 address.
Destination address in the encapsulating (outer) header: This must be an address configured on an interface on the tunnel exit-point (remote) node. For “ip6inip” it must be an IPv4 address. For “6to4” this value must never be specified, since it will automatically be derived from the destination “6to4” address.
Interface State: Specifies the desired interface state, “up” or “down”. By default it is “up”.
Interface Flag: Specify interface flag. If set to “-private”, disable stateless address autoconfiguration using prefixes received in router advertisements. Default is “private”, the interface will autoconfigure addresses using prefixes received in router advertisements.

Automatic tunnels are point-to-multipoint tunnels. The IETF is in the process of deprecating automatic tunnels with IPv4-compatible address in favor of “6to4”. For more information on “6to4”, refer to ““6to4” - Connecting IPv6 Domains over IPv4 Clouds” of this guide.




	IMPORTANT: Starting with TOUR 2.0, automatic tunnels with IPv4-compatible addresses are not supported. (These were supported in HP-UX 11i v1 IPv6 releases prior to TOUR 2.0 (TOUR 1.0 and IPv6NCF11i).

Configured IP6-in-IP Tunnel (Host-Host) Example

This section provides an example of how to configure a simple IP6-in-IP configured tunnel between two dual stack hosts both running HP-UX 11i v1 TOUR 2.0.

Figure 7-1 Host-Host Configured Tunnel

Figure 7-1 “Host-Host Configured Tunnel” illustrates a scenario where you can set up a configured tunnel between Host A and Host B.

On Host A:

Using ifconfig (ephemeral), enter:

ifconfig iptu0 inet6 tunnel ip6inip fe80::1 fe80::2 tsrc 192.168.1.1 tdst 10.13.2.2 up

Editing /etc/rc.config.d/netconf-ipv6 (permanent), add:

TUN_INTERFACE_NAME[0]=”iptu0”
TUN_TYPE[0]=”ip6inip”
TUN_LOCAL_ADDRESS[0]=”fe80::1”
TUN_REMOTE_ADDRESS[0]=”fe80::2”
TUN_ENCAP_SRC_ADDRESS[0]=”192.168.1.1”
TUN_ENCAP_DST_ADDRESS[0]=”10.13.2.2”
TUN_INTERFACE_STATE[0]=”up”

On Host B:

Using ifconfig (ephemeral), enter:

ifconfig iptu0 inet6 tunnel ip6inip fe80::2 fe80::1 tsrc 10.13.2.2 tdst 192.168.1.1 up

Editing /etc/rc.config.d/netconf-ipv6 (permanent), add:

TUN_INTERFACE_NAME[0]=”iptu0”
TUN_TYPE[0]=”ip6inip”
TUN_LOCAL_ADDRESS[0]=”fe80::2”
TUN_REMOTE_ADDRESS[0]=”fe80::1”
TUN_ENCAP_SRC_ADDRESS[0]=”10.13.2.2”
TUN_ENCAP_DST_ADDRESS[0]=”192.168.1.1”
TUN_INTERFACE_STATE[0]=”up”

Configured IP6-in-IP6 Tunnel (Host-Host) Example

This section provides an example of how to configure a host-host IP6-in-IP6 configured tunnel . IP6-in-IP6 tunnel configuration allows transmission of IPv6 packets encapsulated in an IPv6 header.

On Local Host:

Using ifconfig (ephemeral), enter:

ifconfig ip6tu0 inet6 tunnel ip6inip6 fe80::1 fe80::2 tsrc 2ffe::1 tdst 3ffe::1 up

Editing /etc/rc.config.d/netconf-ipv6 (permanent), add:

TUN_INTERFACE_NAME[0]=”ip6tu0”
TUN_TYPE[0]=”ip6inip6”
TUN_LOCAL_ADDRESS[0]=”fe80::1”
TUN_REMOTE_ADDRESS[0]=”fe80::2”
TUN_ENCAP_SRC_ADDRESS[0]=”2ffe::1”
TUN_ENCAP_DST_ADDRESS[0]=”3ffe::1”
TUN_INTERFACE_STATE[0]=”up”

On Remote Host:

Using ifconfig (ephemeral), enter:

ifconfig ip6tu0 inet6 tunnel ip6inip6 fe80::2 fe80::1 tsrc 3ffe::1 tdst 2ffe::1 up

Editing /etc/rc.config.d/netconf-ipv6 (permanent), add:

TUN_INTERFACE_NAME[0]=”ipt6u0”
TUN_TYPE[0]=”ip6inip6”
TUN_LOCAL_ADDRESS[0]=”fe80::2”
TUN_REMOTE_ADDRESS[0]=”fe80::1”
TUN_ENCAP_SRC_ADDRESS[0]=”3ffe::1”
TUN_ENCAP_DST_ADDRESS[0]=”2ffe::1”
TUN_INTERFACE_STATE[0]=”up”

Configured IP-in-IP6 Tunnel (Host-Host) Example

This section provides an example of how to configure a host-host IP-in-IP6 configured tunnel . IP-in-IP6 tunnel configuration allows transmission of IPv4 packets encapsulated in an IPv6 header.

On Local Host:

Using ifconfig (ephemeral), enter:

ifconfig ip6tu0 inet tunnel ipinip6 	10.10.10.1 15.15.15.2 tsrc 2ffe::1 tdst 3ffe::1 up

Editing /etc/rc.config.d/netconf-ipv6 (permanent), add:

TUN_INTERFACE_NAME[0]=”iptu0”
TUN_TYPE[0]=”ipinip6”
TUN_LOCAL_ADDRESS[0]=”10.10.10.1”
TUN_REMOTE_ADDRESS[0]=”15.15.15.2”
TUN_ENCAP_SRC_ADDRESS[0]=”2ffe::1”
TUN_ENCAP_DST_ADDRESS[0]=”3ffe::1”
TUN_INTERFACE_STATE[0]=”up”

On Remote Host:

Using ifconfig (ephemeral), enter:

ifconfig ip6tu0 inet tunnel ipinip6 15.15.15.2 10.10.10.1 tsrc 3ffe::1 tdst 2ffe::1 up

Editing /etc/rc.config.d/netconf-ipv6 (permanent), add:

TUN_INTERFACE_NAME[0]=”ip6tu0”
TUN_TYPE[0]=”ipinip6”
TUN_LOCAL_ADDRESS[0]=”15.15.15.2”
TUN_REMOTE_ADDRESS[0]=”10.10.10.1”
TUN_ENCAP_SRC_ADDRESS[0]=”3ffe::1”
TUN_ENCAP_DST_ADDRESS[0]=”2ffe::1”
TUN_INTERFACE_STATE[0]=”up”




	NOTE: Refer to the ifconfig(1m) man page and the /etc/rc.config.d/netfconf-ipv6 file for more detailed information on tunneling parameters.

“6to4” - Connecting IPv6 Domains over IPv4 Clouds

“6to4” is an automatic tunneling mechanism that can be used to provide connectivity between isolated IPv6 domains or hosts across an IPv4 infrastructure and with native IPv6 domains via relay routers. “6to4” is based on the IP6-in-IP tunneling mechanism defined in RFC 2893 and it falls under the router-to-router tunneling scenario.

“6to4” uses the concept of automatic tunneling where the tunnel end-point is determined from the IPv6 destination address and avoids the complexity of manual tunnel configuration. It does not use the IPv4-compatible address, but instead determines the tunnel endpoint IPv4 address from the special “6to4” prefix of the IPv6 destination address.

“6to4” Well-Known Prefix

“6to4” defines an address assignment scheme that allows a site to obtain a unique externally routable prefix if the site has at least one globally unique IPv4 address. The Internet Assigned Number Authority (IANA) has assigned the unique IPv6 address prefix of 2002::/16 for “6to4”. Each site must have a border dual stack router that has at least one global IPv4 address.

A “6to4” prefix can be generated by concatenating the 2002:: prefix to the global IPv4 address. For example, if the dual stack router has an IPv4 address 15.1.1.1, then its “6to4” prefix will be 2002:0f01:0101::/48. The “6to4” prefix provides a network prefix for the local IPv6 host or network. The IPv4 address is the endpoint for all external IPv4 connections.

Figure 7-2 “6to4” Prefix

“6to4” Encapsulation

IPv6 packets from a “6to4” site are encapsulated in IPv4 packets when they leave the site over its external IPv4 connection. IPv6 packets are transmitted in IPv4 packets with an IPv4 protocol type of 41, the same protocol type set when IPv6 packets tunnel inside IPv4 frames.

“6to4” Topology Example

“6to4” topology consists of: one or more “6to4” hosts in a “6to4” domain; at least one “6to4” router in the domain that has at least one IPv4 connection to the Internet; and a “6to4” relay router that is used to connect to a native IPv6 domain.

Starting with TOUR 2.0, the HP-UX 11i v1 nodes can perform the role of the “6to4” router. Host configuration continues to be supported in TOUR 2.0 (as was the case in TOUR 1.0 and IPv6NCF11i).

Figure 7-3 “6to4” Topology Example

As shown in the “6to4” topology example of Figure 7-3 ““6to4” Topology Example”:

6to4 host: An IPv6 host that has at least one “6to4” address configured. The "6to4" address is autoconfigured using the "6to4" prefix advertised by the "6to4" router. It has a default route to the "6to4" router. All non-local "6to4" addressed packets and native IPv6 packets are sent to the "6to4" router.

"6to4" router: An IPv6/IPv4 border router that forwards "6to4" addressed traffic between "6to4" hosts within a site and other "6to4" routers or to "6to4" relay routers across IPv4 internet. "6to4" routers need to have at least one public IPv4 address and the "6to4" prefix is derived from the public IPv4 address. The "6to4" router advertises the "6to4" prefix on its attached link. It performs the encapsulation and decapsulation functions.

"6to4" relay router: An IPv6/IPv4 router that performs the functions of the "6to4" router and forwards "6to4" addressed traffic between "6to4" routers on the IPv4 internet and IPv6 hosts on the IPv6 internet.

An IPv6 interior routing protocol, such as routing information protocol next generation (RIPng), is used for routing IPv6 in a "6to4" domain. IPv4 exterior routing protocol handles the routing of tunneled IPv4 packets between "6to4" routers and relay routers. In addition, for forwarding native IPv6 addressed packets, a default route from the "6to4" router to the relay router can be setup or IPv6 exterior routing protocol can be used between "6to4" routers and relay routers.

“6to4” Security Considerations

By default, “6to4” routers and relay routers accept and decapsulate traffic from any source. This potentially allows malicious parties to get around access controls and spoof addresses, to perform denial of service attacks. Before setting up a tunnel from a “6to4” router to an external “6to4” relay router, review the internet draft Security Considerations for 6to4 at http://www.ietf.org.

Configuration Example:

For the topology example shown in Figure 7-3 ““6to4” Topology Example”, the following sample ifconfig commands will (ephemerally) configure the HP-UX 11i v1 dual stack routers to handle “6to4”:

On R1: ifconfig iptu0 inet6 tunnel 6to4 tsrc 15.1.1.1

On R2: ifconfig iptu1 inet6 tunnel 6to4 tsrc 16.2.2.2

On R3: ifconfig iptu2 inet6 tunnel 6to4 tsrc 17.3.3.3

In all three cases, you do not need to explicitly specify the address of the tunnel entry point, as this special "6to4" address will be automatically created based on the globally unique IPv4 address that will be the source address in the encapsulating (outer) header.

To configure R1 using the /etc/rc.config.d/netconf-ipv6 file, add the following lines:

TUN_INTERFACE_NAME[0]=”iptu0”
TUN_TYPE[0]=”6to4”
TUN_LOCAL_ADDRESS[0]=””
TUN_REMOTE_ADDRESS[0]=””
TUN_ENCAP_SRC_ADDRESS[0]=”15.1.1.1”
TUN_ENCAP_DST_ADDRESS[0]=””
TUN_INTERFACE_STATE[0]=”up”

“6to4” End-Node View Example

Figure 7-4 “"6to4" IPv6 End Node View Example” shows two IPv6 subnetworks. The end nodes have their routers’ globally unique IPv4 addresses embedded in their network prefixes. The routers have “6to4” addresses and corresponding globally unique IPv4 addresses. From the IPv6 end-node view, each host’s subnetwork is connected to the other’s through a "6to4" router. All IPv4 tunneling is transparent to the IPv6 end nodes.

Figure 7-4 "6to4" IPv6 End Node View Example

Using rtradvd to Advertise “6to4” Routing Prefix

This section provides a simple example to show how to advertise “6to4” routing. In this example, the globally unique IPv4 address of the host is 15.13.1.2.

#example beginsdefaults {
 
        AdvSendAdvertisement on ;
 };
 
  interface lan0 {
 
        prefixinfo 2002:f0d:0101::/64 {
        };

};
 
#example ends

For more examples, refer to the rtradvd.conf(4) man page.

Migrating from IPv4 to IPv6

Technical documentation

» Table of Contents

» Index

Tunneling

Configured IP6-in-IP Tunnel (Host-Host) Example

Configured IP6-in-IP6 Tunnel (Host-Host) Example

Configured IP-in-IP6 Tunnel (Host-Host) Example

“6to4” - Connecting IPv6 Domains over IPv4 Clouds

“6to4” Well-Known Prefix

“6to4” Encapsulation

“6to4” Topology Example

“6to4” Security Considerations

Configuration Example:

“6to4” End-Node View Example

Using rtradvd to Advertise “6to4” Routing Prefix