IPv4 to IPv6 Network Address Translation

Introduction

What is the current internet addressing scheme and what limitations does it face.

A new addressing scheme that would resolve the limitations, and an interim path towards the new scheme.

What we will cover during this presentation :

IPv4 Address structure The IPv4 address resource problem Network Address translation of private address to global addresses for IPv4

address conservation. IPv6 Specifications (rfc1883) IPv6 addressing structure (rfc1884) IPv4 to IPv6 transition and NAT considerations IPv6 to IPv4 address translation at the edge router and higher layer

consideration. Need for port number translations in IPv4 to IPv6 NAT(rfc2766)

IPv4 Address Scheme :

– IP Packet Format

An IP packet contains several types of information, as illustrated.

Version---Indicates the version of IP currently used.

IP Header Length (IHL)---Indicates the datagram header length in 32-bit words.

Type-of-Service---Assigns datagrams various levels of importance.

Total Length---Specifies the length, in bytes, of the entire IP packet.

Identification---Contains an integer that identifies the current datagram.

Flags---The two low-order (least-significant) bits control fragmentation. The low-order bit specifies whether the packet can be fragmented. The middle bit specifies whether the packet is the last fragment in a series of fragmented packets. The third or high-order bit is not used.

Fragment Offset---Indicates the position of the fragment's data relative to the beginning of the data in the original datagram.

Time-to-Live---Maintains a counter that gradually decrements down to zero, at which point the datagram is discarded. This keeps packets from looping endlessly.

Protocol---Indicates which upper-layer protocol receives incoming packets after IP processing is complete.

Header Checksum---Helps ensure IP header integrity.

Source Address---Specifies the sending node.

Destination Address---Specifies the receiving node.

Options---Allows IP to support various options, such as security.

Data---Contains upper-layer information.

IPv4 Addressing

As with any other network-layer protocol, the IP addressing scheme is integral to the process of routing IP datagrams through an internetwork. Each IP address has specific components and follows a basic format. These IP addresses can be subdivided and used to create addresses for subnetworks, as discussed in more detail later.

Each host on a TCP/IP network is assigned a unique 32-bit logical address that is divided into two main parts: the network number and the host number. The network number identifies a network and must be assigned by the Internet Network Information Center (InterNIC) if the network is to be part of the Internet. An Internet Service Provider (ISP) can obtain blocks of network addresses from the InterNIC and can itself assign address space as necessary. The host number identifies a host on a network and is assigned by the local network administrator.

The 32-bit IP address is grouped eight bits at a time, separated by dots, and represented in decimal format (known as dotted decimal notation). Each bit in the octet has a binary weight (128, 64, 32, 16, 8, 4, 2, 1). The minimum value for an octet is 0, and the maximum value for an octet is 255.The figure below illustrates the basic format of an IP address.

Private addresses to assign within a network(Not globally routable)

172.16.0.0/255.255.0.0 192.168.0.0/255.255.255.0 10.0.0.0/255.0.0.0

So in order to resolve the shortage of IPv4 addresses so far the solution has been Network Address Translation as follows. With the following scheme a network can have almost infinite IP addresses yet never contribute to the finite globally routable IP addresses shortage.

In its simplest configuration, the Network Address Translator (NAT) operates on a router connecting two networks together; one of these networks (designated as inside) is addressed with either private or obsolete addresses that need to be converted into legal addresses before packets are forwarded onto the other network (designated as outside). The translation operates in conjunction with routing, so that NAT can simply be enabled on an Internet access router when translation is desired.

Use of a NAT device provides RFC 1631-style network address translation on the router platform. The goal of NAT is to provide functionality as if the private network had globally unique addresses and the NAT device was not present.

Schema diagram:

The above method is useful yet lacks a viable solution to globally routable IP address problem.

Since for every private IP address a globally routable IP address is needed for direct translation. Well in most cases it is not very profitable or at all possible to contain many IP addresses.

Dynamic Network address translation:

One way to resolve this issue would be through Port Address Translation (PAT) as follows:

– PAT (Port Address Translation)

PAT does not work with H.323 applications, multimedia applications, and caching nameservers.

PAT works with DNS, FTP and passive FTP, HTTP, mail, RPC, rshell, Telnet, URL filtering, and outbound traceroute.

Finally when we have completely exhausted all available IPv4 resources we need to explore the new version of Ipng

NAT Enroute to translate

Host-A NAT router Host-X

------ ----------- ------

<Outer IP header, with

src=Addr-A, Dest=Addr-X>,

embedding

<End-to-end packet, with

src=Addr-k, Dest=Addr-X>

----------------------------->

<Outer IP header, with

src=Addr-k, Dest=Addr-X>,

embedding

<End-to-end packet, with

src=Addr-k, Dest=Addr-X>

--------------------------->

<Outer IP header, with

src=Addr-X, Dest=Addr-k>,

embedding

<End-to-end packet, with

src=Addr-X, Dest=Addr-k>

<---------------------------------

NAPT router enroute to translate:

Host-A NAPT router Host-X

------ ----------- ------

<Outer TCP/UDP packet, with

src=Addr-A, Src Port=T-Na,

Dest=Addr-X>,

embedding

<End-to-end packet, with

src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X>

----------------------------->

<Outer TCP/UDP packet, with

src=Addr-Nx, Src Port=T-Nxa,

Dest=Addr-X>,

embedding

<End-to-end packet, with

src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X>

--------------------------------------->

<Outer TCP/UDP packet with

src=Addr-X, Dest=Addr-Nx,

Dest Port=T-Nxa>,

embedding

<End-to-end packet, with

src=Addr-X, Dest=Addr-Nx,

Dest Port=T-Nx>

<----------------------------------

IPv6 Specification (rfc1883)

IP version 6 (IPv6) is a new version of the Internet Protocol, designed as a successor to IP version 4 (IPv4) [RFC-791]. The changes from IPv4 to IPv6 fall primarily into the following categories:

Expanded Addressing Capabilities IPv6 increases the IP address size from 32 bits to 128 bits, to support more levels of addressing hierarchy, a much greater number of addressable nodes, and simpler auto-configuration of addresses.

The scalability of multicast routing is improved by adding a "scope" field to multicast addresses.

And a new type of address called an "anycast address" is defined, used to send a packet to any one of a group of nodes.

Header Format Simplification Some IPv4 header fields have been dropped or made optional, to reduce the common-case processing cost of packet handling and to limit the bandwidth cost of the IPv6 header.

Improved Support for Extensions and Options Changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future.

Flow Labeling Capability A new capability is added to enable the labeling of packets belonging to particular traffic "flows" for which the sender requests special handling, such as non-default quality of service or "real-time" service.

Authentication and Privacy Capabilities Extensions to support authentication, data integrity, and (optional) data confidentiality are specified for IPv6.

IPv6 Header Format

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Prio. | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Source Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Destination Address + | | + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version 4-bit Internet Protocol version number = 6.

Prio. 4-bit priority value.

Flow Label 24-bit flow label.

Payload Length 16-bit unsigned integer. Length of payload, i.e., the rest of the packet following the IPv6 header, in octets. If zero, indicates that the payload length is carried in a Jumbo Payload hop-by-hop option.

Next Header 8-bit selector. Identifies the type of header immediately following the IPv6 header. Uses the same values as the IPv4 Protocol field

Hop Limit 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero.

Source Address 128-bit address of the originator of the packet.

Destination Address 128-bit address of the intended recipient of the packet (possibly not the ultimate recipient, if a Routing header is present).

Flow Labels

The 24-bit Flow Label field in the IPv6 header may be used by a source to label those packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or "real-time" service. This aspect of IPv6 is, at the time of writing, still experimental and subject to change as the requirements for flow support in the Internet become clearer. Hosts or routers that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, pass the field on unchanged when forwarding a packet, and ignore the field when receiving a packet.

A flow is a sequence of packets sent from a particular source to a particular (unicast or multicast) destination for which the source desires special handling by the intervening routers. The nature of that special handling might be conveyed to the routers by a control protocol, such as a resource reservation protocol, or by information within the flow's packets themselves, e.g., in a hop-by-hop option. The details of such control protocols or options are beyond the scope of this document.

Priority

The 4-bit Priority field in the IPv6 header enables a source to identify the desired delivery priority of its packets, relative to other packets from the same source. The Priority values are divided into two ranges: Values 0 through 7 are used to specify the priority of traffic for which the source is providing congestion control, i.e., traffic that "backs off" in response to congestion, such as TCP traffic. Values 8 through 15 are used to specify the priority of traffic that does not back off in response to congestion, e.g., "real-time" packets being sent at a constant rate.

For congestion-controlled traffic, the following Priority values are recommended for particular application categories:

0 - uncharacterized traffic 1 - "filler" traffic (e.g., netnews) 2 - unattended data transfer (e.g., email) 3 - (reserved) 4 - attended bulk transfer (e.g., FTP, NFS) 5 - (reserved) 6 - interactive traffic (e.g., telnet, X) 7 - internet control traffic (e.g., routing protocols, SNMP)

For non-congestion-controlled traffic, the lowest Priority value (8) should be used for those packets that the sender is most willing to have discarded under conditions of congestion (e.g., high-fidelity video traffic), and the highest value (15) should be used for those packets that the sender is least willing to have discarded (e.g., low-fidelity audio traffic). There is no relative ordering implied between the congestion-controlled priorities and the non-congestion- controlled priorities.

IPv6 Addressing scheme overview

IPv6 addresses are 128-bit identifiers for interfaces and sets of

interfaces. There are three types of addresses: Unicast: An identifier for a single interface. A packet sent

to a unicast address is delivered to the interface

identified by that address. Anycast: An identifier for a set of interfaces (typically

belonging to different nodes). A packet sent to an

anycast address is delivered to one of the interfaces

identified by that address (the "nearest" one,

according to the routing protocols' measure of

distance).

Multicast: An identifier for a set of interfaces (typically

belonging to different nodes). A packet sent to a

multicast address is delivered to all interfaces

identified by that address.

There are no broadcast addresses in IPv6, their function being

superseded by multicast addresses.

An example of a Unicast address format which will likely be common on

LANs and other environments where IEEE 802 MAC addresses are

available is:

| n bits | 80-n bits | 48 bits |

+--------------------------------+-----------+--------------------+

| subscriber prefix | subnet ID | interface ID |

+--------------------------------+-----------+--------------------+

Where the 48-bit Interface ID is an IEEE-802 MAC address. The use of

IEEE 802 MAC addresses as a interface ID is expected to be very

common in environments where nodes have an IEEE 802 MAC address. In

other environments, where IEEE 802 MAC addresses are not available,

other types of link layer addresses can be used, such as E.164

addresses, for the interface ID.

The Loopback Address

The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. It may be used by a node to send an IPv6 datagram to itself. It may never be assigned to any interface.

The loopback address must not be used as the source address in IPv6 datagrams that are sent outside of a single node. An IPv6 datagram with a destination address of loopback must never be sent outside of a single node.

2.4.4 IPv6 Addresses with Embedded IPv4 Addresses

The IPv6 transition mechanisms include a technique for hosts and routers to dynamically tunnel IPv6 packets over IPv4 routing infrastructure. IPv6 nodes that utilize this technique are assigned special IPv6 unicast addresses that carry an IPv4 address in the low-order 32-bits. This type of address is termed an "IPv4- compatible IPv6 address" and has the format:

| 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|0000| IPv4 address | +--------------------------------------+----+---------------------+

A second type of IPv6 address which holds an embedded IPv4 addressis also defined.

Multicast Addresses

An IPv6 multicast address is an identifier for a group of nodes. A node may belong to any number of multicast groups. Multicast addresses have the following format:

| 8 | 4 | 4 | 112 bits | +------ -+----+----+---------------------------------------------+ |11111111|flgs|scop| group ID | +--------+----+----+---------------------------------------------+

11111111 at the start of the address identifies the address as being a multicast address.

+-+-+-+-+ flgs is a set of 4 flags: |0|0|0|T| +-+-+-+-+

The high-order 3 flags are reserved, and must be initialized to 0.

T = 0 indicates a permanently-assigned ("well-known") multicast address, assigned by the global internet numbering authority.

T = 1 indicates a non-permanently-assigned ("transient") multicast address.

scop is a 4-bit multicast scope value used to limit the scope of the multicast group.

For example the following addresses:

1080:0:0:0:8:800:200C:417A a unicast address FF01:0:0:0:0:0:0:43 a multicast address 0:0:0:0:0:0:0:1 the loopback address 0:0:0:0:0:0:0:0 the unspecified addresses

Each being 16-bits wide for a total of 128 bits

Traditional-NAT-PT Operation (V6 to V4)

NAT-PT offers a straight forward solution based on transparent

routing [NAT-TERM] and address/protocol translation, allowing a large

number of applications in V6 and V4 realms to inter-operate without

requiring any changes to these applications.

In the following paragraphs we describe the operation of

traditional-NAT-PT and the way that connections can be initiated from

a host in IPv6 domain to a host in IPv4 domain through a

traditional-NAT-PT

Basic-NAT-PT Operation

[IPv6-B]-+

| +==============+ [IPv6-A]-+-[NAT-PT]---------| IPv4 network |--[IPv4-C]

| +==============+

(pool of v4 addresses)

Figure 1: IPv6 to IPv4 communication

Node IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210

Node IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211

Node IPv4-C has an IPv4 address -> 132.146.243.30

NAT-PT has a pool of addresses including the IPv4 subnet

120.130.26/24

The V4 addresses in the address pool could be allocated one-to-one to the V6 addresses of the V6 end nodes in which case one needs as many V4 addresses as V6 end points. In this document we assume that the V6 network has less V4 addresses than V6 end nodes and thus dynamic address allocation is required for at least some of them.

Say the IPv6 Node A wants to communicate with the IPv4 Node C. Node A creates a packet with:

Source Address, SA=FEDC:BA98::7654:3210 and Destination Address, DA = PREFIX::132.146.243.30

NOTE: The prefix PREFIX::/96 is advertised in the stub domain by the NAT-PT, and packets addressed to this PREFIX will be routed to the NAT-PT. The pre-configured PREFIX only needs to be routable within the IPv6 stub domain and as such it can be any routable prefix that the network administrator chooses.

The packet is routed via the NAT-PT gateway, where it is translated to IPv4.

NAPT-PT Operation

NAPT-PT, which stands for "Network Address Port Translation + Protocol Translation", would allow V6 nodes to communicate with the V4 nodes transparently using a single V4 address. The TCP/UDP ports of the V6 nodes are translated into TCP/UDP ports of the registered V4 address.

While NAT-PT support is limited to TCP, UDP and other port multiplexing type of applications, NAPT-PT solves a problem that is inherent with NAT-PT. That is, NAT-PT would fall flat when the pool of V4 addresses assigned for translation purposes is exhausted. Once the address pool is exhausted, newer V6 nodes cannot establish sessions with the outside world anymore. NAPT-PT, on the other hand, will allow for a maximum of 63K TCP and 63K UDP sessions per IPv4 address before having no TCP and UDP ports left to assign.

To modify the example sited in figure 1, we could have NAPT-PT on the border router (instead of NAT-PT) and all V6 addresses could be mapped to a single v4 address 120.130.26.10.

IPv6 Node A would establish a TCP session with the IPv4 Node C as follows:

Node A creates a packet with:

Source Address, SA=FEDC:BA98::7654:3210 , source TCP port = 3017 and Destination Address, DA = PREFIX::132.146.243.30, destination TCP port = 23.

When the packet reaches the NAPT-PT box, NAPT-PT would assign one of the TCP ports from the assigned V4 address to translate the tuple of (Source Address, Source TCP port) as follows:

SA=120.130.26.10, source TCP port = 1025 and DA=132.146.243.30, destination TCP port = 23.

The returning traffic from 132.146.243.30, TCP port 23 will be recognised as belonging to the same session and will be translated back to V6 as follows:

SA = PREFIX::132.146.243.30, source TCP port = 23; DA = FEDC:BA98::7654:3210 , destination TCP port = 3017

Inbound NAPT-PT sessions are restricted to one server per service, assigned via static TCP/UDP port mapping. For example, the Node [IPv6-A] in figure 1 may be the only HTTP server (port 80) in the V6 domain. Node [IPv4-C] sends a packet:

SA=132.146.243.30, source TCP port = 1025 and DA=120.130.26.10, destination TCP port = 80

NAPT-PT will translate this packet to:

SA=PREFIX::132.146.243.30, source TCP port = 1025 DA=FEDC:BA98::7654:3210, destination TCP port = 80

In the above example, note that all sessions which reach NAPT-PT with a destination port of 80 will be redirected to the same node [IPv6- A].

TCP/UDP/ICMP Checksum Update from IPv4 to IPv6

UDP checksums, when set to a non-zero value, and TCP checksum SHOULD be recalculated to reflect the address change from v4 to v6. The incremental checksum adjustment algorithm may be borrowed from [NAT]. In the case of NAPT-PT, TCP/UDP checksum should be adjusted to account for the address and TCP/UDP port changes, going from V4 to V6 address.

When the checksum of a V4 UDP packet is set to zero, NAT-PT MUST evaluate the checksum in its entirety for the V6-translated UDP packet. If a V4 UDP packet with a checksum of zero arrives in fragments, NAT-PT MUST await all the fragments until they can be assembled into a single non-fragmented packet and evaluate the checksum prior to forwarding the translated V6 UDP packet.

ICMPv6, unlike ICMPv4, uses a pseudo-header, just like UDP and TCP during checksum computation. As a result, when the ICMPv6 header checksum is computed [SIIT], the checksum needs to be adjusted to account for the additional pseudo-header. Note, there may also be adjustments required to the checksum due to changes in the source and destination addresses (and changes in TCP/UDP/ICMP identifiers in the case of NAPT-PT) of the payload carried within ICMP.

TCP/UDP/ICMP Checksum Update from IPv6 to IPv4

TCP and UDP checksums SHOULD be recalculated to reflect the address change from v6 to v4. The incremental checksum adjustment algorithm may be borrowed from [NAT]. In the case of NAPT-PT, TCP/UDP checksums should be adjusted to account for the address and TCP/UDP port changes, going from V6 to V4 addresses. For UDP packets, optionally, the checksum may simply be changed to zero.

The checksum calculation for a V4 ICMP header needs to be derived from the V6 ICMP header by running the checksum adjustment algorithm [NAT] to remove the V6 pseudo header from the computation. Note, the adjustment must additionally take into account changes to the checksum as a result of updates to the source and destination addresses (and transport ports in the case of NAPT-PT) made to the payload carried within ICMP.

Close

Even with 20 years of TCP networks UUCP still exists

IPv6 to IPv4 NAT is just an iterim solution, will not work with all protocols.

Yet as a knowledgeable network professional we need to know about IPv6 issues.