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 address

is 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.