A Design and Implementation of a General-purpose Translator for IPv6/IPv4 (GT64)
by
Peilei Fan
B.S., Computer Science,
Nanjing University, 1993
Master of City and Regional Planning
Rutgers University, 1997
Submitted to the Department of Electrical Engineering and Computer Science
in Partial Fulfillment of the Requirements for the Degree of
Master of Science in Electrical Engineering and Computer Science
at the
Massachusetts Institute of Technology
June 2001
© 2001 Massachusetts Institute of Technology
All rights reserved
.......................................
Signature of Author................
Department of Electrical Engineering and Computer Science
May 11, 2001
Certified by .......................................................
Robert T. Morris
Assistant Professor of Computer Science
Thesis Supervisor
Accepted by ..........................
MASSAC HUSETe
JUL 11 2001
LIBRARIE
t
Arthur C. Smith
Chairman, Committee on Graduate Students
of Electrical Engineering and Computer Science
A Design and Implementation of a General-purpose Translator for IPv6/IPv4 (GT64)
by
Peilei Fan
Submitted to the Department of Electrical Engineering and Computer Science
in June 2001 in partial fulfillment of the
requirements for the Degree of
Master of Science in Electrical Engineering and Computer Science
Abstract:
This thesis describes the design and implementation of a general-purpose translator for
IPv6/IPv4 (GT64). This translator permits address, port, and protocol translation
between IPv4 and IPv6 address and protocol realms. Also included in this thesis is an
implementation of the packet forwarding software required for IPv6.
GT64 has three principal components: an address-and-port translator and two protocol
translators. Various combinations of these components are sufficient for translating most
real world applications. Each is implemented as a separate Click element and can be
combined in a variety of ways. A GT64 can be extended to connect with application-level
gateways (ALGs) or a DNS application-level gateway (DNSALG) when dealing with
application-level translation or DNS lookups between different address realms. In
addition, a GT64 can be extended to connect with other Click elements to build Click
IPv4 and IPv6 routers with translation functionality.
GT64's design is more flexible than most existing network address translation
implementations. It can be configured easily for a number of address translation
scenarios, including an IPv6 local net connected with the IPv4 Internet, an IPv6 local net
connected with the IPv6 Internet, an IPv6 private net connected with the IPv6 Internet,
and an IPv4 private net connected with the IPv4 Internet. Moreover, GT64 can also be
configured for a variety of load balancing scenarios. Because of its modularity and ease
of extension, GT64 is a powerful tool for helping the transition to the IPv6 network.
Thesis Supervisor: Robert Tappan Morris
Title: Assistant Professor of Computer Science
2
Table of Contents
ACKNO W LEDG EMENTS....................................................................................................................5
CHAPTER 1. INTRODUCTION ...........................................................................................................
1.1 IPv6 vs. IPv4 ADDRESSES.............................................................................................................6
1..1 IPv6 Address Architecture.................................................................................................
1.1.2 IPv6 address with embedded IPv4 address............................................................................
6
6
7
1.2 TRANSLATING BETWEEN DIFFERENT ADDRESS REALMS....................................................................7
1.2.1 Translatingbetween IPv6 and IPv6........................................................................................
8
1.2.2 Translatingbetween IPv6 and IPv4........................................................................................
1.3 GT64 FOR LPv6/IPv4 TRANSLATION ................................................................................................
8
9
1.4
THESIS STRUCTURE........................................................................................................................
10
CHAPTER 2. EXISTING NAT MODELS ..........................................................................................
11
2.1 GENERAL OVERVIEW OF NAT M ODELS.........................................................................................
11
2.2 M ODELS FOR GT64........................................................................................................................
13
CHAPTER 3. IPV6 FOR CLICK.........................................................................................................
16
3.1 CLICK OVERVIEW ..........................................................................................................................
3.2 IMPLEMENTING IPv6 IN CLICK .......................................................................................................
16
16
3.2.1 IPv6 Protocol.........................................................................................................................
3.2.2 Address Resolution and Neighbor Discovery........................................................................
16
3.2.3 ICMPv6 Protocol ...................................................................................................................
19
3.3 A CLICK IPv6 ROUTER ..................................................................................................................
19
17
CHAPTER 4. DESIG N O F GT64........................................................................................................23
4.1 ARCHITECTURE..............................................................................................................................
4.1. 1 Structure ................................................................................................................................
Figure 2b. Internal Structure of GT64 .........................................................................................
4.1.2 Integrating GT64 into IPv4/IPv6 Click routers....................................................................
Figure 3a. GT64's Connection with an IPv4 Click Router............................................................
4.1.3 Elements.................................................................................................................................
4.2 DISCUSSION...................................................................................................................................
23
23
24
25
25
26
27
4.2.1 Loss of Information during Translation...............................................................................
4.2.2 AlternativesforALGs .............................................................................................................
4.2.3 IncorporatingHostname Lookup..........................................................................................
4.2.4 TCP/UDP Checksum and FragmentationHandling..............................................................
27
27
27
28
CHAPTER 5. THE ADDRESS-AND-PORT TRANSLATOR ............................................................
29
5.1 DESIGN OF THE ADDRESS-AND-PORT TRANSLATOR .......................................................................
5.1.1
5.1.2
5.1.3
5.1.4
Function of the Address-and-port Translator.......................................................................
The IPv6 based Address-and-port Translatorfor IPv4/lIPv6 Translation..............................
Static vs. Dynamic M apping.................................................................................................
DynamicAddress-only vs. Dynamic Address-and-PortMapping ..........................................
29
29
30
30
30
5.2 CONFIGURATION............................................................................................................................
5.3 IMPLEMENTATION..........................................................................................................................
31
33
5.3.1 Mapping Tables......................................................................................................................
33
Table 2a. The address-mappingtable ............................................................................................
Table2b. out map ...........................................................................................................................
Table2c. in map..............................................................................................................................
5.3.2 Address Lookup and Translation..........................................................................................
5.3.3 Address Allocation and Unbinding........................................................................................
34
34
34
35
35
3
5.3.4 Checksum Adjustment.............................................................................................................
36
5.4 USING AN ADDRESS-AND-PORT TRANSLATOR FOR GT64 .............................................................
36
CHAPTER 6. THE PROTOCOL TRANSLATORS ......................................................................
37
6.1 DESIGN OF PROTOCOL TRANSLATORS...........................................................................................
6.2 IMPLEMENTATION..........................................................................................................................
37
37
6.2.1 IP Translation ........................................................................................................................
Table 3. Translating IPv4 to IPv6 Headers...................................................................................
6.2.2 ICMP Translation...................................................................................................................
6.2.3 Checksum Adjustment.............................................................................................................
37
40
41
43
6.3 USING PROTOCOL TRANSLATORS FOR GT64...............................................................................
44
CHAPTER 7. GT64 FOR DIFFERENT TRANSLATION SCENARIOS.......................................
45
7.1 LOCAL LPv6 NET CONNECTED WITH THE IPv4 INTERNET.............................................................
47
7.2 LOCAL IPv4 NET CONNECTED WITH THE IPv6 INTERNET .............................................................
49
7.3 IPv6 PRIVATE NETWORK CONNECTED WITH THE IPv6 INTERNET .................................................
50
7.4 IPv4 PRIVATE NETWORK CONNECTED WITH THE IPv4 INTERNET .................................................
51
7.6 MIXED IPv6/IPv4 LOCAL NETWORK CONNECTED WITH THE IPv4 AND IPv6 INTERNET ................... 53
7.7 DISCUSSION...................................................................................................................................56
CHAPTER 8. PERFORM ANCE EVALUATION...........................................................................
57
CHAPTER 9. RELATED WORK........................................................................................................59
CHAPTER 10. CONCLUSION............................................................................................................61
APPENDIX. A CLICK IPV4 ROUTER ..............................................................................................
BIBLIOGRAPHY.................................................................................................................................64
4
62
Acknowledgements
This thesis would have been impossible without the support of a host of people. First,
Robert Tappan Morris has been a great advisor who, with his time, knowledge, and
talents enhanced the quality of this research. I thank him for giving me valuable advice
and enormous help. Eddie Kohler helped me become familiar with the Click
environment and was always there for questions. Benjie provided help to set up the
performance test. I am very grateful to the Click team: Robert Tappan Morris, Eddie
Kohler, Benjie Chen, M. Frans Kaashoek, John Jannotti, and Massimiliano Poletto.
Thanks also to others in the Parallel and Distributed Operating System Group (PDOS) at
the MIT Laboratory for Computer Science: Jinyang Li, Charles Blake, Douglas S.J. De
Couto, Kevin Fu, Thomas Gil, and Neena Lyall. I thank following people for their
support: Hari Balakrishnan, Nancy Lynch, Karen R. Polenske, Xiaowei Yang, Zhao
Chen, and Karen Wang.
Finally, thanks to my husband Raymond Louis Naseef and my parents Zhongli Fan and
Ying Huang, for their continuous encouragement, support, and love.
5
Chapter 1. Introduction
Network Address Translationis a method by which IP addresses are mapped from one
address realm to another. Ideally, the method is transparent to end-users. The need for IP
address translation arises when a network's internal addresses cannot be used to
communicate outside the network. As the Internet transitions from IPv4 to IPv6, Network
Address Translators(NATs) will be used as a mechanism for IPv6 hosts and routers to
communicate with IPv4 hosts through the existing IPv4 infrastructure. In this thesis, I
describe the design and implementation of a General-purposeTranslatorforIPv6/IPv4
(GT64), which can be configured easily for different address translation scenarios.
In this chapter, the first section compares IPv6 and IPv4 address architecture. The next
section briefly introduces translation between IPv6 and IPv4. The third section then
shows how GT64 achieves the translation. The last section outlines the structure of the
thesis.
1.1 IPv6 vs. IPv4 Addresses
Currently, the Internet Protocol (IP) is responsible for communication on the Internet.
The Internet Protocol version 4 (IPv4) has expanded to support millions of nodes but is
now running out of address space. The Internet Protocol-Next Generation (IPng), also
known as IP version 6(IPv6), was designed in response to the Internet's high demand for
IP addresses. The most distinguished feature of IPv6 is its address architecture.
1.1.1 IPv6 Address Architecture
IPv6 uses a 128-bit addressing scheme [RFC 2373] rather than the 32-bit addresses used
by IPv4. IPv6 assigns addresses in a hierarchical manner, as needed by the requester,
rather than in blocks of unused addresses, as IPv4 does. This hierarchical scheme allows
an upper authority to subdivide its address space and allocate it to lower authorities,
which can then subdivide and allocate them to authorities at the next lower level, and so
on.
The 128-bit IPv6 addressing requires changes to the IPv4 address notation. IPv4 uses the
format "D.D.D.D", a quad-octet dotted decimal notation, to represent numeric addresses;
while IPv6 uses the format "X:X:X:X:X:X:X:X", an eight-16-bit hexadecimal notation,
to represent numeric addresses. Colons separate this format into eight sections, and four
hexadecimal digits represent each of the16-bit sections. However, the leading zeros in
each section can be deleted to create a more simplified format. For example, an IPv6
address "3ffe: Ice1:0002:0000:0000:0000:0000:000 1" can be written as
"3ffe: Ice 1:2:0:0:0:0:1,".
6
A compressed form of IPv6 address notation uses double colons (::) to indicate multiple
groups of 16-bit zeros, which can appear only once in an address. Thus the above
address can be simply represented as "3ffe:lce1:2::1".
1.1.2 IPv6 address with embedded IPv4 address
In the mixed environment of IPv4 and IPv6 nodes, it is convenient to use the mixed form,
which has the representation of "X:X:X:X:X:X:D.D.D.D". The six higher-order sections
(separated by ":") have hexadecimal values and the four lower sections (separated by ".")
have decimal numbers. The mixed address form is called a transition address, because it
uses an IPv6 address format to represent an IPv4 address. Two types of transition
addresses can contain an IPv4 address within an IPv6 address. The first type is called an
IPv4-compatible IPv6 address. Nodes with this type of transition address are always
identified as IPv4/IPv6 or IPv6 nodes and never as IPv4-only nodes. The IPv6 transition
mechanisms [RFC 1993] include a technique for hosts and routers to dynamically tunnel
IPv6 packets over IPv4 routing infrastructure. For instance, IPv4-compatibleIPv6
address are assigned to IPv6 nodes that utilize this technique. The IPv4-compatibleIPv6
addresscontains an IPv4 address in its lowest 32 bits and has a prefix of 96 bits of zeros,
as the following shows:
80 bits
10000................................0000
16 bits
32 bits
10000 IPv4 address
For instance, if an IPv6/IPv4 node has an IPv4 address as 18.26.4.1, then its IPv6 address
is ::18.26.4.1.
The second type of transition address is called an IPv4-mapped IPv6 address. It is used
to represent IPv4-only nodes, which do not support IPv6. An IPv4-mapped IPv6 address
has the following format:
80 bits
0000.....................................................0000
16 bits
F FF
32 bits
IPv4 address
The lowest 32 bits of the address represent the embedded IPv4 address; therefore, IPv4mapped IPv6 addressescan be translated to IPv4 addresses by removing the 96-bit
prefix. IPv4 addresses are easily translated into IPv4-mapped IPv6 addressesby the
addition of the 96-bit prefix "::ffff'. Therefore, if an IPv4-only node has IPv4 address as
18.26.4.2, its IPv6 address is ::ffff:18.26.4.2.
1.2 Translating between different address realms
7
The movement of a packet from one address realm to another address realm primarily
involves making the packet addresses and protocols meaningful for nodes in the other
address realm. Both address realms may use the same protocol as in the case of a private
IPv6 local net connected with the IPv6 Internet. More often, they may have different
protocols as in the case of an IPv6 local net connected with the IPv4 Internet.
1.2.1 Translating between IPv6 and IPv6
In the first case, the local net typically has several IPv6 addresses that nodes in the local
net can use as their identities when they need to communicate with the outside world.
When a node X in the private IPv6 local net sends a packet to a node Y in the IPv6
Internet, the packet must have its source address replaced with a global IPv6 address
"AddressX6" so that the packet's addresses could be recognized in the IPv6 Internet.
Moreover, if the node Y in the IPv6 Internet wants to send the node X a packet, it will
use the global IPv6 address "AddressX6" as the destination address. But when the packet
reaches the private IPv6 net, the destination address has to be replaced by the private
address of the node X.
The replacement of the source address or destination address is called address translation.
To increase the number of nodes of a private net that can simultaneously communicate
with the outside world, a global address can be shared by several nodes by allowing
transport identifiers (e.g., TCP and UDP port numbers, ICMP query identifiers) of a
number of private nodes to be multiplexed into transport identifiers of this single global
IPv6 address. The translation mechanism uses different port numbers of the same global
address to represent a private host in the local network. Thus, port translation as well as
address translation is involved. This is called address-and-port translation. It requires
address and port translation and related checksum adjustments at the network and upper
layers. At the transport layer, the values of the source port (or destination port) and the
checksum field need to be changed.
1.2.2 Translating between IPv6 and IPv4
If the communicating address realms use two different protocols, such as an IPv6 local
network connected with the IPv4 Internet, then the network layer header must be
translated into the other protocol so that it can be recognized in the other realm. In this
case, protocol translation as well as address-and-port translation is required. Protocol
translation refers to replacing one protocol header with the other protocol header. IPv6
and IPv4 have similar header formats, but with some different fields. More detail of
protocol translation will be discussed in Chapter 6.
For instance, when a node X with an IPv6 address "AddressX6" in the private IPv6 local
net sends a packet to an IPv4-only node Y with IPv4 address "AddressY4" in the IPv4
Internet, the original packet has "AddressX6" and "AddressY6"(IPv4-mapped IPv6
address) as source and destination addresses. Before it arrives Y, the packet's IPv6
header is replaced by a corresponding IPv4 header. Its source address is replaced by a
global IPv4 address "AddressX4" and "AddressY4" is the destination address. In reverse
8
direction, if Y sends a packet to node X, the original packet will have "AddressY4" and
"AddressX4" as source and destination addresses. Before it arrives at the IPv6 local
network where node x resides, the packet's IPv4 header will be replaced by a
corresponding IPv6 header. It will have "AddressY6" and "AddressX6" as its new
source and destination addresses.
When one protocol is translated into another, such as from IPv6 to IPv4, the transport
layer (TCP or UDP) will keep the same header format; but if port translation is involved,
the values of the source port (or destination port) and the checksum field will be changed.
Because of the TCP and UDP header formats remain the same in IPv6 as in IPv4,
translation for the transport layer is a simple matter.
Payload translation is also needed if the packet has address or port information in the
application layer. When the address and port are replaced during the translation for the
network layer and the transport layer, the payload at the application layer may need to be
modified as well to reflect the updated address and port information.
1.3 GT64 for LPv6/IPv4 Translation
The design of the GT64 translation mechanism has three main goals. First, it should
allow communication between IPv6-only nodes and IPv4-only nodes. The purpose of a
network translator is that two different types of IP nodes be able to communicate with
each other. Second, no change should be required at source or destination; all processing
will be done at the edge router or other intermediary. This allows the local network to be
able to communicate with other networks with the minimum effort, since the number of
edge routers is much less than the number of end nodes. Third, the implementation of
GT64 should be easily accomplished. GT64 is implemented in the context of the Click
modular networking system [CLICK].
GT64 separates the task of address-and-port translation from protocol translation. The
separation eases the implementation of GT64, since each can be implemented as a
separate module in Click. GT64 uses an address-and-port translator for address and port
translation of the packet and uses protocol translators for IPv4-to-IPv6 or IPv6-to-IPv4
protocol translation. The model used by address-and-port translation ensures that GT64 is
capable of communicating between IPv6-only and IPv4-only hosts without changing end
nodes. The protocol translation follows the RFC standards [RFC 2765]. Together they
provide the most appropriate combination the our system solution.
The address-and-port translation is IPv6-based, i.e., it only maps between IPv6 addresses
and ports. However, GT64 must be able to map between IPv6 and IPv4 addresses in
order to work with IPv6/IPv4 translation scenarios. The address-and-port translation can
translate between normal IPv6 addresses and IPv4-mapped IPv6 addressesfor IPv6/IPv4
translation. The protocol translation can translate between IPv4-mappedIPv6 addresses
and IPv4 addresses. Thus, an IPv6 address can go through the address-and-port
translation to be mapped with IPv4-mapped IPv6 address, which can then be translated
9
into IPv4 address through the IPv6 to IPv4 protocol translation. Conversely, an IPv4
address in a packet can be mapped back to an IPv6 node by going through the JPv4 to
IPv6 protocol translation and then the address-and-port translation.
GT64 requires that communication between address realms must pass the edge router.
GT64 on a local net should either reside in or be directly connected with the edge router.
If GT64 does not reside at the edge router, then when packets that are destined to or
sourced from a different address realm pass by, the edge router should pass the packets
that need to be translated to the host in which GT64 resides. GT64 then emits the
translated packets to appropriate routers that will direct the packets to the destination
address realm. If GT64 is in the edge router, the above transportation of the packets will
occur within the edge router.
Furthermore, GT64 can also be integrated into more complex Click IPv4 and IPv6 routers
within the same node to build routers with translation functionality.
1.4 Thesis Structure
The next chapter summarizes the background of the problem dealt with by this thesis by
introducing different models for NATs with emphasis on models used by GT64. Chapter
3 introduces the IPv6 implementation for Click. Chapter 4 describes the design of GT64.
Chapter 5 and Chapter 6 describe the design and implementation of the address-and-port
translator, as well as the protocol translators. Chapter 7 illustrates how GT64 can be used
in a variety of translation scenarios. Chapter 8 analyzes the performance of GT64 and
describes a set of applications that have been tested, and Chapter 9 surveys related work
on NAT. Chapter 10 summarizes the findings of the thesis.
10
Chapter 2. Existing NAT Models
This chapter reviews a number of existing models for IPv6/IPv4 inter-operations in order
to find the most appropriate models for GT64. Each model has its advantages and
disadvantages. The criteria for selection follow the three goals of GT64 mentioned in
section 1.3. Section2.1 presents a general overview of six NAT models. Those models
are interesting, but do not satisfy GT64's requirements. However, they provide certain
insights about network translation. Section 2.2 identifies two models that have the
features that GT64 needs.
2.1 General Overview of NAT Models
A number of IPv4/IPv6 inter-operation mechanisms have been proposed:
The Dual Stack Model [NAT-INTRO] requires allocation of an IPv4 address to each IPv6
host so that all IPv6 nodes are dual-stacked, i.e., they provide complete support for both
IPv4 and IPv6 in hosts or routers. The dual stack nodes must have DNS resolver
libraries that can deal with the IPv4 "A" record as well as the IPv6 "AAAA" or "A6"
record. Thus, communication to IPv4 nodes takes place using the IPv4 stack;
communication with the IPv6 world takes place using the IPv6 stack. This model does
not allow communication between IPv6-only nodes and IPv4-only nodes.
In the Limited Dual Stack Model [NAT-INTRO], only "server nodes" (nodes hosting
Internet services, such as file sharing, DNS, web, etc.) are dual-stacked. "Client nodes"
(nodes that do not offer those services) are IPv6-only. Though fewer IPv4 addresses are
needed, this model does not allow communication between IPv6-only and IPv4-only
nodes.
Dual Stack TransitionMechanism (DSTM) [DSTM] mainly targets the communication
between a newly deployed IPv6 network and the existing IPv4 networks. All IPv6 nodes
in the DSTM network are dual-stacked. DSTM assigns temporary global IPv4 addresses
to dual stack hosts during the communication between an IPv4/IPv6 host and an IPv4only host. DSTM also requires that the host can perform dynamic tunneling of an IPv4
packet inside an IPv6 packet to suppress the exposure of IPv4 native packets within a
DSTM domain of an IPv6 network. Each IPv6 DSTM host has an IPv4 interface called
the Dynamic Tunneling Interface (DTI), which encapsulates IPv4 packets inside IPv6
packets.
The DSTM IPv6 host obtains the temporary global IPv4 addresses from DHCPv6 server
in the IPv6 DSTM network. The DHCPv6 server provides the assignment of IPv4 global
addresses to IPv6 hosts and maintains the mapping between the allocated IPv4 address
and the permanent IPv6 address of the host. If an IPv4 host wants to initiate a
communication with an IPv4/IPv6 host, it first asks the DNS for an "A" record. The DNS
11
server in charge of the final resolution will ask the DHCPv6 server to allocate a
temporary IPv4 address for the dual stack host and it will send back this address in an
"A" record to the IPv4 host. The DHCPv6 server will send a reconfigure command to the
dual stack host to assign that temporary IPv4 address. Like the above two dual stack
models, this model does not work for communication with IPv6-only hosts.
SOCKS-based IPv6/IPv4 Gateway (SOCKS64) [SOCKS-GATE] is a gateway system
that is based on the SOCKS protocol [SOCKSv5]. It relays two "terminated" IPv4 and
IPv6 connections at the "application layer" (the SOCKS server). Especially for
"socksified" sites, which already use SOCKS-aware clients and a SOCKS server, the
SOCKS64 gateway provides an easy way to let IPv4 hosts connect to IPv6 hosts.
SOCKS64 has advantages such as no DNS modifications, no address mapping. In
addition, it provides security insurance on two "terminated" connections at the
"application layer"[RFC 1928]. The end-to-end security is maintained at each of the
relayed connections (i.e., between Client C and Gateway G, and between Gateway G and
Destination D). However, SOCKS64 has the main problem that client nodes must be
"socksified", which is not desirable for the end hosts. Furthermore, SOCKSv5 doesn't
provide network-layer gateway services (e.g. ICMP messages).
The TransportRelay Translator(TRT) [TRT] enables TCP and UDP communications
between IPv6 hosts and IPv4 hosts. A TRT system, which is located between an IPv6only host and an IPv4-only host, translates TCP/IPv6 to TCP/IPv4, UDP/IPv6 to
UDP/IPv4, or vice versa.
As shown in the following diagram, when the initiating host (whose IPv6 address is A6)
wants to start communication with the destination host (whose IPv4 address is X4), it
needs to make an TCP/IPv6 connection to C6::X4, an IPv6 address with a special formTRT dummy prefix (C6::/64) plus the destination IPv4 address (X4). The routing
information in A6 has been configured so that packets to C6::/64 are routed to the TRT
gateway, whose IPv6 address is B6. The TRT gateway accepts the TCP/IPv6 connection
between A6 and C6::X4 and communicates with the initiating host, using TCP/IPv6. It
also obtains the real IPv4 destination address from the lowermost 32 bits of the
destination address (IPv6 address C6::X4). A protocol translator, which is installed at the
TRT, does IPv6-to-IPv4 protocol translation for the packet. The TRT, whose IPv4
address is Y4, then connects to X4, using TCP/IPv4, and forwards the traffic across the
two TCP connections. UDP traffic can be relayed in the same fashion as TCP. As seen in
the example, the initiating host must use a special form of IPv6 address, such as C6::X4,
to connect to an IPv4 destination host. The special form can be resolved from a
hostname by a special DNS server implementation, by the static address-mapping table
on the initiating host, or by a modified DNS resolver implementation on the initiating
host.
12
Destination host
|X4
=====outer
network
|Y4
+=+
TRT System ---dummy prefix (C6::/64)
1B6
inner network
JA6
Initiating host
The TRT has advantages, such as no extra modification on end hosts and no need to take
care of path MTU or fragmentation issues that other IPv6-IPv4 header converters have.
However, the TRT system can be a single point of failure between the communication
peers because the TRT is a stateful system -it retains state of a packet and updates it when
other packets belong to the same flow arrives. Furthermore, it is difficult to implement in
Click, which builds its structure on the IP layer of the network.
The Bump-in-the-Stack [RFC 2767] model allows for the use of non-IPv6 capable
applications on an IPv4 host to communicate with IPv6-only hosts. The Bump-in-theStack can be viewed as a particular implementation of the Network Address TranslationProtocol Translation(NAT-PT) model within the IP stack of an IPv4 host. Added to the
IPv4 stack are three modules that intervene between the application and the network: an
extension to the name resolver, an address mapper, and a translator. The main idea is that
when an IPv4 application needs to communicate with an IPv6-only host, the IPv6 address
of the IPv6-only host is mapped into an IPv4 address out of a pool that is local to the dual
stack host. The IPv4 packet generated for the communication is translated into an IPv6
packet before the dual-stack host sends it out to the network. This model requires that the
IPv4 host is dual-stacked.
The Stateless IP/ICMP TranslationAlgorithm (SIIT) protocol [RFC 2765] describes a
method to translate between IPv6 and IPv4 protocols. Translation is limited to the IP
packet header. The protocol does not describe a method for assigning a temporary IPv4
address to the IPv6 node. Therefore, SIIT needs to be combined with mechanisms that
deal with IPv4 address allocation for IPv6 nodes. The translator operates in a stateless
mode, which means that translation needs to be done separately for every packet.
Because of the "stateless" feature, SIIT avoids the single point of failure that can occur to
stateful system such as TRT.
2.2 Models for GT64
Among the above seven models, most of them, i.e., Dual Stack Model, Limited Dual
Stack Model, Dual Stack Transition Mechanism, and Bump-in-the-Stack Model, need
end hosts to be dual-stacked. SOCKS64 requires "socksification" of end hosts. Though
the TRT model doesn't require end hosts to be modified, it is difficult to implement in
13
Click. In comparison with the models listed above, the following model, which follows
the protocol translation guideline of the SIIT, demonstrates the desired features for GT64.
Network Address Translation- ProtocolTranslation (NAT-PT) [RFC 2766] addresses
the communication between IPv6-only and IPv4-only hosts, which is realized by the use
of a dedicated device that translates between IPv4 and IPv6 addresses. Since there is
limited IPv4 address space, the NAT-PT device keeps "state" during each session to track
active flows so that it can dynamically allocate its address space to requested flows. The
NAT-PT uses SIIT for protocol translation and includes an application layer gateway to
make translation possible between IPv4 and IPv6 DNS requests and answers [RFC 2694].
The NAT-PT allows the transport identifiers (TCP or UDP port numbers) of a number of
IPv6 hosts to be multiplexed into transport identifiers of a single assigned IPv4 address,
thus allowing a set of IPv6 hosts to share a single IPv4 address.
The NAT-PT has certain disadvantages, most of which are general problems of NATs.
First, the model requires all packets pertaining to a session to be routed via the same
NAT-PT router. A border router unique to a stub domain can overcome this limitation.
Secondly, an NAT-PT can not avoid the loss of information in protocol translation; it
simply can not translate everything in the packet since the fields in different protocols do
not exactly match. For instances, fields such as Flow Label and Priorityin the IPv6
header don't have corresponding fields in IPv4 protocols. Moreover, applications (e.g.
ftp) carrying IP addresses in higher layers will not work. Application Level Gateways
(ALGs) are needed to overcome this disadvantage. Furthermore, end-to-end security of
the network layer is not possible. Finally, the NAT-PT can not be deployed in
combination with secure DNS, because IPv6 DNS can not sign replies to queries
originated from the IPv4 world.
Several commercial/research NAT-PTs already exist. The research teams include:
British Telecommunications Lab (http://www.labs.bt.com/technical/natpt/),
Vermicelli Project (http://www.vermicelli.pasta.cs.uit.no/IPv6/DNS.html), and
University of Washington (http://www.cs.washington.edu/research/networking/napt/)
(base for Microsoft Research IPv6 Stack)
GT64 uses a modified NAT-PT model for IPv4/IPv6 translation. It divides address-andport translation and protocol translation into two modules. One module is an IPv6-based
address-and-port translator that allows a set of IPv6 hosts to share a single IPv6 address
by multiplexing the transport identifiers of IPv6 hosts to the transport identifier of a
single assigned IPv6 address. This module uses IPv6-based NAT-PT and excludes the
protocol translation from the NAT-PT. The other module is for protocol translation and
it has two elements: Protocol Translatorfor IPv6 to IPv4 (PT64) and Protocol
TranslatorforIPv4 to IPv6 (PT46). Both protocol translators follow the SIIT for
translation.
GT64 can be combined with ALGs (for application level translation) and a DNSALG
(for DNS packets' address mapping) to provide the most appropriate solution for
communication between IPv6-only nodes and IPv4-only nodes. For instance, GT64
14
combined with an ALG for FTP protocol would be able to completely translate an
IP/TCP/FTP packet, because the FTP_ALG will deal with the modification of the
addresses in the payload. Since GT64 is implemented in Click, the next chapter describes
the related implementation - IPv6 for Click. Following that, Chapter 4 presents a detailed
design of GT64 and its implementation in Click.
15
Chapter 3. IPv6 for Click
3.1 Click Overview
GT64 is implemented in the context of the Click modular networking system [CLICK], a
software architecture for building flexible and configurable routers. Modules, called
elements, which implement simple router functions, process packets. A router
configuration is a directed graph with elements at the vertices; packets follow along the
edges of the graph.
The components of GT64 are constructed as individual Click elements. GT64 is
assembled from components that are configured differently for different translation
scenarios. Not only can it be used alone, but GT64 can be incorporated with other Click
elements to build configurable routers with translation functions.
In order to translate between IPv4 and IPv6, the router should be able to handle IPv6
packets as well as IPv4 packets. Therefore, part of this thesis was the implementation of
IPv6 elements for Click. The next section briefly introduces the implementation of IPv6,
ICMPv6, and Neighbor Discovery Protocol in Click. Section 3 presents a basic Click
IPv6 router.
3.2 Implementing IPv6 in Click
3.2.1 IPv6 Protocol
Beside the increase of the address space, IPv6 was designed to enhance and maintain
current IPv4 functionality while eliminating its limitations. IPv6 features include
security, quality of service, efficiency, growth, flexibility and reliability, most of which
are closely related with the use of the IPv6 option mechanism.
The option mechanism of IPv6 improved over that of IPv4. IPv6 options are placed in
separate extension headers located between IPv6 header and transport-layer header in a
packet. Not all IPv6 extension headers need to be examined or processed by routers
along a packet's delivery path. However, in IPv4, the presence of any options requires the
router to examine all options. Thus IPv6 dramatically improves router performance for
packets containing options. Another advantage is that the IPv6 extension header can be of
arbitrary length as long as it can be kept as an integer multiple of 8 octets to retain the
alignment for subsequent headers. In contrast, IPv4 limits the total number of options
carried in a packet to 40 bytes. Currently, IPv6 extension headers include routing,
fragmentation, authentication, security encapsulation, hop-by-hop option, and destination
options. Below is shown the format of an IPv6 header and an IPv6 fragment header.
16
IPv6 Header
0
Version I Class
Payload Length
31
Flow Label
Next Header
Hop Limit
Source Address
Destination Address
IPv6 Fragment Header
0
Reserved
Next header
Fragment Identifier
31
Fragment Offset
Flags
Since the router is not required to process options, the implementation of an IPv6 Click
router is simplified. This project has implemented several elements that can forward and
check IPv6 packets. These elements check the validity of the packets' header, decrease
the hop limit and discard the packets if the hop limit is zero, and fragment packets if they
are too long. Most importantly, they can route the packets to the next hop by looking up
the destination address at the routing table.
3.2.2 Address Resolution and Neighbor Discovery
In IPv4, the Address Resolution Protocol (ARP) is used to map IP addresses to hardware
MAC addresses. The Neighbor Discovery protocol (ND) performs the same functionality
for IPv6.
3.2.2.1 Neighbor Discovery Protocol
IPv6 nodes on the same link use ND to discover each other's presence and to determine
each other's link-layer address, to find routers, and to maintain reachability information
about active neighbors. The Neighbor Discovery protocol is a synthesis of several IPv4
protocols in IPv6: the Address Resolution Protocol (ARP) [RFC 826], ICMP Router
Discovery (RDISC) [RFC 1256], and ICMP Redirect messages [RFC 792].
The Neighbor Discovery protocol defines mechanisms for solving a set of problems
related to the interaction between nodes attached to the same link. This thesis includes an
implementation of the mechanism that deals with only address resolution, i.e., how a
node determines the link-layer address of a neighbor given only the destination IP
address.
17
ND uses ICMPv6 messages to communicate. A Click IPv6 router sends out a neighbor
solicitation message if it wants to determine a link-layer address of an IPv6 address. It
can also send out a neighbor advertisement message when it wants to advertise the linklayer address of some IPv6 address or to reply to a solicitation message. The following
further explains the format of the neighbor solicitation messages and neighbor
advertisement messages.
3.2.2.2 Neighbor Solicitation Messages
Nodes send neighbor solicitation messages to request the link-layer address of a target
node while also providing their own link-layer address to the target. Neighbor
solicitation messages are multicast messages when the node needs to resolve an address
and unicast messages when the node seeks to verify the reachability of a neighbor.
Neighbor solicitation messages have the following format:
0
Type
Reserved
31
Code
Checksum
Target Address
Options...
3.2.2.3 Neighbor Advertisement Messages
Nodes send neighbor advertisement messages to advertise the link-layer address of some
IPv6 addresses. A neighbor advertisement message is a response to a neighbor
solicitation message. Nodes may also send unsolicited neighbor advertisements to
announce a link-layer address change. Neighbor advertisement messages have the
following format:
0
Type
R S 0 Reserved
31
Code
Checksum
Target Address
Options...
18
3.2.3 ICMPv6 Protocol
IPv6 uses the Internet Control Message Protocol (ICMP) [RFC 792] as defined for IPv4,
with many changes. The modified protocol is called ICMPv6 [RFC 1885]. It also
absorbed the revised Internet Group Membership Protocol (IGMP) [RFC 1112]. IPv6
nodes use ICMPv6 to report errors encountered in processing packets, and to perform
other Internet-layer functions, such as diagnostic and multicast membership reporting.
ICMPv6 is an integral part of IPv6 and is implemented by every IPv6 node.
ICMPv6 messages have the same general format as ICMPv4 messages, with Type, Code,
and Checksum fields. The Type field indicates the type of the message. The code field is
used to create an additional level of message granularity. The checksum is used to detect
data corruption in the ICMPv6 message and parts of the IPv6 header. Every ICMPv6
message is preceded by an IPv6 header and zero or more IPv6 extension headers. The
ICMPv6 header is identified by a Next Headervalue of 58 in the immediately preceding
header. The following shows the general format of an ICMPv6 message:
31
1
Type
Checksum
Code
Message Body ...
ICMPv6 messages have two groups: error messages and informational messages. This
thesis project has implemented an ICMP6Errorelement to create all types of ICMPv6
error messages. In addition, the Click IPv6 elements are able to deal with four types of
ICMPv6 informational messages: Echo Request, Echo Reply, Neighbor Solicitation, and
Neighbor Advertisement messages (Type 128, 129, 135, 136).
3.3 A Click IPv6 Router
A set of IPv6 Click elements is required for a basic IPv6 router. Some IPv6 elements are
quite similar to their counterparts in IPv4, such as: GetIP6Address, LookupIP6Route,
DecIP6Hlim, and IP6Frgamenter.Others are quite different, such as CheckIP6Header,
IP6NDSolicitor,IP6NDAdvertiser,and ICMP6Error,which follow the standard IPv6,
ND, and ICMPv6 protocols. The IPv6 Click router also uses several general-purpose
Click elements, such as, Classifier,Discard,Queue, DropBroadCast,FromDevice,
ToDevice, and ToLinux.
The IPv6 router is able to handle normal IPv6 packets, Neighbor Solicitation messages,
Neighbor Advertisement messages, and ICM[Pv6 error messages. Since IPv6 does not
require the router to process options, the IPv6 Click router can forward unicast packets in
19
full compliance with RFC standards [RFC 2373]. Figure 1 illustrates a basic Click IPv6
router, whose configuration is similar to that of an IPv4 router. Please refer to [CLICK]
for a detailed description of Click. A glossary (Table 1) describes the functions of the
IPv6 elements used in Figure 1. In Click, the elements take actions based only on the
content of a packet. For instance, if a packet's Hop Limit has expired, a DecIP6Hlim
element will direct the packet to the output that deals with the error (which is usually
connected to an ICMP6Errorelement); otherwise, it will decrement the Hop Limit and
direct the packet to the normal output.
A LookupIP6Route element uses a list of the router's addresses and the broadcast
addresses of all interfaces to decide which packets are addressed to the router itself and
what interface the packet should be sent to if the packet is to be forwarded. A
CheckIP6Headerelement checks the validity of the IPv6 source address. An
IP6Fragmenterelement fragments packets larger than the configured MTU, but sends
too-large packets that are marked unfragmentable to an error output instead. An
ICMP6Errorelement accepts invalid input packets, encapsulates them within an ICMP6
error message and emits the result.
20
FromDevice(eth)
FromDevice(ethln)
s
Classifter(...)
Classifter(...)
IP6NDSolicitation IP6NDAdvertisement
IP6
IP6NDAdvertisement
IP6NDIP6ND
Advertiser
to
IP6NDSolicitor
to IP6NDSolicitor
Advertiser
Strip(14)
CheckIP6Header(...)
to Queue
I
GetIP6Address(24)
II
to Queue
I
I
'Route(...
)
I
DropBroadCasts
DropBroadCasts
L
L
DeclP6Hlim
HopLimitxpired
IPurragment(...
to Linux
ICMP6Error
Must fragment
Iruvragment(...
from Classifier
lCMP6Error
HopLimitE xpired
ICMP6Error
Must fragment
from Classifier
V
IP6NDSolicitor(...)
IP6NDSolicitor(...)
FToDevice(eth0)
ToDevice(ethl)
Figure 1. A Two-Interface IP6 router Configuration
21
Table 1. IPv6 router element glossary
New IPv6 Elements
IP6NDSolicitor
(IP6Address,
ethernetAddress)
Description
First input takes IPv6 packets, second input takes neighbor
advertisement messages with Ethernet headers. Output emits
neighbor solicitation messages and IPv6-in-Ethernet packets.
Uses ND to find the Ethernet address corresponding to each input
IPv6 packet's destination IPv6 address annotation; encapsulates
the packet in an Ethernet with that destination Ethernet address.
IP6NDAdvertiser
(IP6addresslmask]
Input takes neighbor solicitation messages, output emits Neighbor
Advertisement messages. Responds to neighbor solicitation
ethi, ... )
messages for IPv6 address with the static Ethernet address.
CheckIP6Header
Input takes IPv6 packet. Discards packets with invalid source
addresses, forwards valid packets unchanged.
DecIP6Hlim
Input takes IPv6 packets. Decrements input packets'hop limit
field. Sends to output 1 if hop limit has expired, otherwise to
output 0.
GetIP6Address
ICMP6Error
(type, code)
LookuplP6Route(...)
Existing Click
Elements
Classifier(...)
DropBroadcasts
Discard
FromDevice(device)
Queue(n)
ToDevice(device)
ToLinux
Input takes IPv6 packets. Copies the IPv6 header's destination
address field (offset 24 in the IPv6 header) into the destination
IPv6 address annotation; forwards packets unchanged.
Input takes IPv6 packets, output emits ICMPv6 error packets.
Encapsulates first part of input packet in ICMPv6 error header
with source address ip6, error type type, and error code code.
Input takes IPv6 packets with valid destination IPv6 address
annotation. Arbitrary number of outputs. Looks up input packets'
destination annotation in a static routing table specified in the
configuration string. Forwards each packet to the output port
specified in the resulting routing table entry; sets its destination
annotation to the resulting gateway IPv6 address, if any.
Description
Input takes any packet, examines packet data according to a set of
classifiers, one classifier per output port. Forwards packet to
output port corresponding to the first classifier that matched.
Input takes any packet. Discards packets that arrived as link-level
broadcasts; forwards others unchanged.
Discards all input packets.
No inputs. Sends packets to the single output as they arrive from
a Linux device driver.
Input takes any packet. Stores packets in a FIFO queue;
maximum queue capacity is n.
Input takes Ethernet packets; no outputs. Hands packets to a
Linux driver for transmission.
Input takes Ethernet packets; Linux will ignore Ethernet header
except for the protocol field. No outputs. Hands packets to
Linux's default network input software
22
Chapter 4. Design of GT64
This chapter presents the design of GT64. The first section describes the architecture and
introduces the elements of GT64; next, it shows how those elements form a complete
GT64 for different translations and how GT64 can be incorporated with Click routers.
The second section discusses limitations, such as loss of information during protocol
translation. It also addresses some other issues when designing translators for IPv6/IPv4
translation, such as alternatives for ALGs, incorporating hostname lookup ability, and
TCP/UDP checksum update and fragmentation.
4.1 Architecture
4.1.1 Structure
GT64 can be used as a part of a Click router to connect a local net with the Internet
(Figure 2a). The local net may have mixed environment, i.e., it has IPv4-only nodes,
IPv6-only nodes, and IPv4/IPv6 nodes. The Internet may also support both IPv4 and
IPv6. Click IPv6 or IPv4 router elements can recognize IPv6 or IPv4 packets that need
translation and direct them to GT64. After translation, GT64 outputs updated packets to
Click IPv6 or IPv4 router elements for further processing.
GT64 has three basic elements (Figure 2b): an address-and-port translator (APT) and two
protocol translators. One protocol translator translates from IPv6 to IPv4 (PT64) and the
other translator translates from IPv4 to IPv6 (PT46). GT64 achieves flexibility and
modularity by splitting translation functionality into individual elements so that addressand-port translation is separated from protocol translation.
Assume that an IPv6-only node in the local net wants to communicate with an IPv4-only
node in the Internet. Once the IPv6 Click elements recognize that the packet is destined to
an IPv4-only node, they send the packet to GT64. The packet will be translated into an
IPv4 packet, output to the IPv4 Click elements, and then routed to the IPv4-only
destination node. Inside of GT64, the IPv6 packet is translated into an IPv4 packet via
several steps. First, APT translates the source address into an IPv4-mappedIPv6 address.
Then, PT64 transforms the updated IPv6 packet into an IPv4 packet. In short, the packet
in this example goes through the following path: Source IPv6 node => IPv6 routers ... =>
IPv6 Click Router => GT64 (APT => PT64) => IPv4 Click router => IPv4 routers ... =>
Destination IPv4 node.
In the above case, a packet's translation path in GT64 is (APT=> PT64). GT64 can work
with any IPv6-IPv4 related translation scenario by providing different paths for flows that
connect different types of nodes and require different translations.
23
IPv4/IPv6
Internet
INv6/v4
local net
IPv4 and
IPv4 and
Host A
1Pv6
GT64
IPv6
aC lik
Click
other
Host B
othe
routine
outine
Application
Level Gateway
Figure 2a. GT64 in use for translation scenarios between a IPv4/IPv6 local net and
the IPv4/IPv6 Internet
Packets
destined to
the Internet
and sourced
from the
local net
A
PT64-
PT46
APT
Packets
destined to
the
local net
and sourced
4
PT64
Packets destined to
the Internet and
sourced from the
local net
dstn
'Pake
_Packets destined to
the local net and
sourced from the
Internet
4__PT46
Pacet
from t
Figure 2b. Internal Structure of GT64
24
Splitting address and port translation from protocol translation lends modularity and
flexibility to GT64. Some translation scenarios (IPv6/IPv4 network translations) involve
both address-and-port and protocol translations. Other translation scenarios involve only
address-and-port translation (e.g., GT64 for an IPv6 private network connected with the
IPv6 Internet) and related checksum adjustments. In these cases, only APT is on the
translation path of GT64. If address-and-port and protocol translations were not
separated, it would be difficult to configure GT64 to suit these scenarios.
4.1.2 Integrating GT64 into IPv4/IPv6 Click routers
As Figure 3a and Figure 3b illustrate, GT64 can be connected with Click router elements
to build modular and flexible routers with NAT functionality. The Click IPv6 router
outputs an IPv6 packet that needs to be translated to GT64 via an output of the
LookupIP6Route element. GT64 then directs the translated IPv4 packet to the IPv4 Click
router, which processes the packet as a normal IPv4 one. Similarly, the IPv4 router
outputs an IPv4 packet that needs to be translated to GT64 via one of the outputs of the
LookupIPRoute element. GT64 then sends the translated IPv6 packet to the IPv6 Click
router.
IPv4 packets from Classifiers
Translated IPv4
Packets from the
GT64
Strip(14)
To
IPv6 Router 4 .
CheckIPHeader(...)
fm
Translated
IPv6 Packets:
GT64
GetIPAddress(16)
4..........
I
I
LookupIP~ot(.
IPv4 packets to
be translated to IPv6
Figure 3a. GT64's Connection with an IPv4 Click Router
25
IPv6 packets from Classifiers
Strip(14)
To
IPv4 Route
.
Translated IPv6
Packets from the
GT64
................... . . . .................
.....
_................_
; .........
.
CheckIP6Hleader(...
)
Translated
IPv4 Packets!
GetIP6Address(24)
-01
G T64
..........
_ML
LookpIP6Route(...
M
IPv6 packets to
be translated to IPv4
Figure 3b. GT64's Connection with an IPv6 Click Router
4.1.3 Elements
The address-and-port translator (APT) is the most important element of GT64 because it
performs network address and port translation. APT maintains records for active flows.
As packets arrive, APT uses their flow identification to find the corresponding mappings
and translates the addresses and ports accordingly. When no mappings are found, APT
creates new mappings by following certain rules. APT always translates between IPv6
address and ports of two different IPv6 address realms.
GT64's two protocol translators - PT64 and PT46 - perform packet translation between
IPv4 and IPv6 protocols as well as between ICMPv4 and ICMPv6 protocols. The IPv6
and IPv4 headers are similar, but do not exactly match. Adjustments need to be made
when translating from one version of IP or ICMP to the other. PT64 only accepts IPv6
packets with IPv4-mapped IPv6 addresses;PT46 only accepts IPv4 packets. Since there
is a one-to-one relationship between IPv4-mapped IPv6 addresses and IPv4 addresses,
the protocol translator only needs to map other fields of the headers between the two
protocols. Therefore, when an IPv6 or ICMPv6 packet arrives, PT64 will translate it to
an IPv4 or ICMPv4 packet by simply taking the lowest 32 bits of the IPv6 address as
translated IPv4 address for source or destination. When an IPv4 or ICMPv4 packet
arrives, PT46 will translate it to an IPv6 or ICMPv6 packet. It will simply translate IPv4
source or destination address to an IPv4-mappedIPv6 address by adding the 96-bit
prefix.
26
4.2 Discussion
4.2.1 Loss of Information during Translation
The loss of information during translation is one intrinsic shortcoming of a network
translator that translates between two different protocols. There are fields of IPv6 and
IPv4 protocols that can not be translated simply because there are no corresponding fields
in the other protocol that can carry the information. Those fields, for instance, the Type
of Service (TOS) field of the IPv4 header, have to be ignored when an IPv4 packet is
translated to an IPv6 one. The Class, Flow Label, and Reserved fields of IPv6 Header
and IPv6 Fragment Header have to be ignored as well when an IPv6 packet is translated
to an IPv4 one. Any network translator will have to face this structural shortcoming when
translating between different protocol realms.
4.2.2 Alternatives for ALGs
GT64 can translate for packets of most protocols. However, when there are protocols
that carry the IP address and port information in their payload, ALGs need to be
developed and used with GT64 to achieve complete translation. For instance, an ALG
for the FTP protocol would be able to do a complete translation for an IP/TCP/FIP
packet by updating values of the addresses and ports in the payload so they are consistent
with those in the IP and TCP headers. The design and implementation for ALGs is,
however, beyond the scope of this research. In addition, new IPv6 applications that are
IPv4-aware, e.g., FTP, can detect whether the connection is with an IPv6 or IPv4 version
of the ftp daemon. When communicating with an IPv4 ftp daemon, it needs to use an
IPv4 address instead of the host's original IPv6 address. Conversely, if an IPv4 ftp client
contacts an IPv6 ftp daemon, the daemon must treat the IPv4 address in the payload as an
IPv4-mapped IPv6 address. Therefore, the network address-and-port translator often
does not need to update IP addresses in the application payload. If all applications that
embed IP addresses did their own address translation in this way, then there would be no
need for GT64 to include ALGs to deal with application level translation.
4.2.3 Incorporating Hostname Lookup
Completely transparent IPv6/IPv4 translation requires GT64 to be used with some
mechanism that has DNS lookup ability, since some applications require that a host first
look up another host's address before initiating a session with the other host. The IPv6
site's DNS server should be an IPv6/IPv4 node so it can forward DNS request from
internal IPv6 hosts to external IPv4 DNS servers. Since each IPv4 node has a unique IPv6
address (either IPv4-mappedIPv6 address or IPv4-compatible IPv6 address), each "A"
record has a corresponding "AAAA" record listed in the DNS. If an IPv6 host tries to
initiate communication with a node in the IPv4 world, it first looks up the "AAAA"
record of the IPv4 node at the local DNS server. If the IPv6 site's local DNS server has
an "A" record of the IPv4 host, it will also have an "AAAA" record with IPv4-mapped
27
IPv6 address, and thus it will return an IPv6 address of the IPv4 host. Otherwise, the
local DNS server will communicate with the IPv4 world to get an "A" record, translate it
to an "AAAA" record, and send the "AAAA" record to the internal client.
However, the converse direction (an IPv4 host looks up an IPv6 host) is much more
difficult. Because an IPv6-only node doesn't have an IPv4 address, each "AAAA"
record does not have a corresponding "A" record. To solve the problem, there are several
approaches that translate an IPv6 DNS record to an IPv4 DNS record. First, the resolver
library in IPv4 nodes can be modified to request the alias (a temporary IPv4 address for
the IPv6 node) from GT64. Second, the IPv6 site's DNS server can be modified to
request a temporary address from GT64 on behalf of its IPv4 clients. The third approach
requires GT64 to recognize DNS request and response packets and to translate them
transparently. For a detailed description of DNS extension for network address
translators, please refer to [RFC 2694].
While the first two approaches involve modifying end nodes, which is not completely
transparent translation, the last approach fits in the design of GT64. It can be done in a
DNSALG. GT64 does not currently do this translation, but could be modified to do it.
4.2.4 TCP/UDP Checksum and Fragmentation Handling
After address and port translation, GT64 needs to update the TCP/UDP checksum fields.
TCP and UDP compute their checksum values on a pseudo-header that consists of fields
(including addresses) from the IPv4/IPv6 header as well as the TCP/UDP header and
payload. The change of the address and port value affects the value of the checksum.
PT64 and PT46 calculate both IP/IPv4 and TCP/UPD checksums after their protocol
translation.
Currently, GT64 drops all packets with IPv6 extension headers, including the IPv6
fragment header. GT64 doesn't deal with translation for IPv6 or IPv4 fragment packets
because it calculates checksums directly from the packet content. GT64 can evaluate the
checksum only when all the fragment packets are assembled into a single one. Currently
GT64 ignores both IPv4 and IPv6 fragment packets.
This project does not deploy the incremental checksum adjustment algorithm for
checksum calculation, which can correctly reflect the change of address and port, even
for fragmented packets. As soon as the incremental checksum adjustment algorithm is
implemented, the translation for fragmented packets should be easily accomplished.
28
Chapter 5. The Address-and-port Translator
This chapter describes details of the address-and-port translator (APT). Section 5.1
introduces the design of the APT, and Section 5.2 shows how to configure the APT.
Section 5.3 then illustrates implementation details by demonstrating the structure of the
APT mapping tables and the processes of address lookup, address binding, address
unbinding, and checksum-updating. Section 5.4 describes how the APT can be used by
GT64.
5.1 Design of the Address-and-port Translator
5.1.1 Function of the Address-and-port Translator
When a host inside a GT64 needs to communicate with the outside world, GT64 has to
temporarily allocate a global address to make the node recognizable to the outside world.
If several internal nodes need to communicate with the outside world but there is only
one global address, each individual connection can be temporarily allocated with a
distinct address-and-port pair so that these internal nodes can share the same global
address. For instance, an IPv6 local network usually only has a few IPv4-mapped IPv6
addresses available when communicating with the global IPv4 Internet, while there are
far more internal nodes. APT resolve the resource limit by letting a set of local IPv6 hosts
to share a single IPv4-mapped IPv6 address,i.e. the transport identifiers of these internal
IPv6 hosts are multiplexed into the transport identifiers of the IPv4-mapped IPv6 address.
APT uses the address-and-port pair to replace the original source address and port for
packets that are destined to outside world. This function of APT is called address-andport translation.
APT decides how to allocate such temporary address-and-port pairs for outgoing
connections. Moreover, it remembers the allocations and always replaces the internal
source address-and-port with the same mapped address-and-port pair for packets of the
same flow. Here, if two packets have the same identifiers, i.e., source address, source
port, destination address, and destination port, they belong to the same flow. Moreover,
on the reverse direction, the APT uses a reverse mapping to replace packets' destination
address-and-port with the internal node's address-and-port pair.
When APT receives an IPv6 packet, it replaces the original flow ID of the packet with the
mapped flow ID. The mapped flow ID uses some other address-and-port pair to replace
the source address-and-port pair or the destination address-and-port pair of the packet.
The configuration string of the address-and-port translator determines how the
replacement is conducted. In addition to the dynamic address-and-port allocation
described above, the APT can deal with other simplified forms of address-and-port
29
translation, such as static address translation and dynamic address-only translation.
Those forms will be described later.
APT accepts outward packets and inward packets, but treats them differently. APT is
usually configured to only allocate dynamic mappings for packets of certain direction.
Thus, flows initiated from the other direction will not be able to be allocated with
mappings. Outward packets are those packets that originate from the local network and
destined to some host on the Internet (IPv4 or IPv6), while inward packets are those
packets that originate from the outside world and destined to some host in the local
network. APT has two inputs and two outputs. It accepts outward and inward packets
from different inputs and directs them to different outputs after translation.
5.1.2 The IPv6 based Address-and-port Translator for IPv4/IPv6 Translation
APT only accepts and outputs IPv6 packets with IPv6 addresses. In order for GT64 to
work for IPv4/IPv6 translation scenarios, GT64 temporarily allocate IPv4 addresses to
internal IPv6 hosts when they communicate the IPv4-only hosts. The IPv6-based APT
achieves this by assigning IPv4-mappedIPv6 addresses for the internal IPv6 hosts.
When GT64 translates an IPv6 packet to an IPv4 packet, APT first maps the source or
destination IPv6 address and port to an IPv4-mapped IPv6 address and a port. PT64 then
translates the IPv6 packet to an IPv4 packet and translates the IPv4-mapped IPv6
addresses to IPv4 addresses.
When GT64 translates an IPv4 packet to IPv6, PT46 maps IPv4 addresses into IPv4mapped IPv6 addresses for the packet. APT then maps the source or destination IPv4mapped IPv6 address and port to the real source or destination IPv6 address and port.
5.1.3 Static vs. Dynamic Mapping
APT can map addresses and ports of hosts to some global addresses and related ports
statically as well as dynamically, called static mapping or dynamic mapping functions
respectively. Static mapping refers to the static relationship between internal address-andport pairs and the mapped address-and-port pairs. In most case, static mapping is used
for address-only mapping, i.e., certain external addresses will be reserved for particular
internal addresses. Contrary to the static mapping, dynamic mapping only keeps
mappings for active flows.
5.1.4 Dynamic Address-only vs. Dynamic Address-and-Port Mapping
Dynamic address-only translation allocates only the global addresses instead of the
address-port pairs dynamically. APT will then use the mapped address to represent the
internal node to communicate with the outside world. As we described above, dynamic
address-and-port mapping replaces the original flow ID with the mapped flow ID that has
a different address-and-port pair for either source or destination. However, dynamic
address-only mapping replaces only one address of the packet and keeps the other three
30
items of the flow ID the same. For an outward packet, it replaces the source address with
the mapped global address; for an inward packet, it replaces the destination address with
the internal node's address.
5.2 Configuration
5.2.1 Configuration String
A user controls the APT using a configuration string, which specifies the mapping rules
for both static mapping and dynamic mapping. The arguments of a configuration string
are separated by commas, as illustrated by Figure 4a. Figure 4b shows an example of an
APT configured for a local IPv6 net connected with the IPv4 Internet. The APT is
configured for static address mapping and dynamic address-and-port mapping.
First, the configuration string specifies the number and rules of static mapping. The first
argument is the number of staticMappings.The second argument staticPortMappingis
a boolean which indicates whether or not APT does static port mapping. In Figure 4b, the
first argument number_ofstaticMappingshas the value "1", which means one static
mapping exists. The second argument staticPortMappinghas "0" value which states that
APT will do address-only mapping for static translation.
APT (number-ofstaticMappings,
staticPortMapping
StaticMappingl,...
StaticMappingm,
dynamicMapping
dynamicPortMapping,
addressAllocationDirection,
Mapped_IP6Addressl,
Mapped_IP6Address2,
MappedIP6Addressn)
APT (numberofstaticMappings,
staticPortMapping
StaticMapping],...
StaticMappingm,
dynamicMapping
dynamicPortMapping,
addressAllocationDirection,
MappedIP6Address Portstart Portend)
Figure 4a. Format of a Configuration String for an APT
Note: The top figure is the format for an APT configured for static address mapping and dynamic
address-only mapping ; the bottom figure is the format for an APT configured for static address mapping
and dynamic address-and-port mapping.
31
APT(1,
0,
3ffe:lcel:2::1 ::18.26.4.115,
1,
1,
0,
::18.26.4.116 6000 6010)
Figure 4b. An Example: Configuration of an Address-and-port Translator
Following staticPortMappingare the detailed static mappings, as expressed by
staticMappingl, ... , staticMappingm. Those m arguments correspond to m static
mappings where m is specified by number ofrstatic.Mappings. Depending on the
staticPortMappingvalue, each static mapping can have either two strings or four strings.
If the value of the staticPortMapping is "0", i.e., static address-only mapping, the
argument should have two strings, an internal and an external IPv6 address. If the value
of the staticPortMappingis 1, i.e., static address-and-port mapping, the argument has
four strings: the internal IPv6 address and port of the node, and the mapped IPv6 address
and port for that node.
In Figure 4b, APT statically maps the internal address 3ffe: Icel:2::1 to the externally
visible address ::18.26.4.115. APT replaces the source address 3ffe:1ce1:2::1 with
18.26.4.115 in outgoing packets. In the reverse direction, if there is a packet destined to
::18.26.4.115 coming from the outside world, APT replaces the destination address with
the address 3ffe:lcel:2::1.
Second, the configuration string indicates whether there are any dynamic mappings and
the rules for dynamic mapping. The argument dynamicMapping uses a boolean value to
indicate whether or not APT does dynamic address mapping. If the value is "1", APT
takes more arguments which specify dynamic mapping rules. The following argument
dynamicPortMappingdecides if APT doe dynamic address-and-port mapping or dynamic
address-only mapping. Most APT configurations will have the latter, as in Figure 4b,
because dynamic address-and-port mapping allows one global address to be multiplexed
among several active flows.
Furthermore, the argument addressAllocationDirectiondecides when APT can allocate a
new mapping, i.e., whether or not to allocate a new mapping when a packet without a
mapped entry passes by. The addressAllocationDirectionhas two values: 1(inward) and
0 (outward). If the configuration is not specified, the outward direction is the default
direction. Address translation scenarios for local networks to the outside world will
designate the addressAllocationDirectionas outward, as shown in Figure 4b. However,
the direction should be inward if GT64 is used for scenarios like webserver load
32
balancing, i.e., APT will allocate new mappings for the new active flows initiated from
the outside. Load balancing tries to distribute the load on one web address to several
internal nodes. GT64 for load balancing serves flows initiated from outside. The inward
addressAllocationDirectionallows APT to allocate mappings for those flows.
Finally, the configuration string indicates the range of dynamically allocatable global
IPv6 addresses and ports. If dynamic mapping does not have a dynamic port mapping
function, the remaining arguments are IPv6 addresses. With dynamic address-and-port
translation, the remaining argument is a triplet (Mapped IP6Address Portstart
Port-end). It indicates an IPv6 address and the range of ports (Port-startto Portend)
that can be allocated when an active flow passes the APT. A set of private or local IPv6
hosts can share a single global IPv6 address by multiplexing the port of a single assigned
IPv6 address to the transport identifier of a number of IPV6 hosts.
In Figure 4b, the last argument shows that ports 6000 to 6010 of IPv4-mapped IPv6
address ::18.26.4.116 are available to be allocated to internal nodes for communication
with the outside world. Since there are 10 combinations of address-and-port pairs, the
APT can simultaneously serve 10 active flows.
5.3 Implementation
5.3.1 Mapping Tables
Depending on its configuration, APT has different tables to track the address-and-port
mapping of flows. The address-mappingtable serves for static address and dynamic
address-only mapping. APT uses tables called inmap and out-map for dynamic
address-and-port mapping. This table-driven APT is the core of GT64. The
configuration string determines primarily how to set up the mapping tables.
The example below shows an APT configured for static-address mapping and dynamic
address-only mapping. It only needs an address-mappingtable. Not all of the table
fields (See Table 2a) need to be filled with values in order to be a valid entry. A static
entry (value of staticMapping field is 1) follows the static mapping rules. A dynamic
entry (value of staticMapping field is 0) follows the dynamic mapping rules. For
instance, entry 2 shows a dynamic binding of an active flow that has source address
3ffe:lcel:2::3 (from local IPv6 net) has been mapped to ::18.26.4.116.
APT(1,
0,
3ffe:lce1:2::1 ::18.26.4.115,
1,
0,
0,
::18.26.4.116,
::18.26.4.117,
::18.26.4.118,
::18.26.4.119)
33
Table 2a. The address-mapping table
Field
Binding
State
Entryl
Entry2
Entry3
1
1
0
Entry5
0
lastAccessTime
staticMapping
internal
Address
global
Address
2:23:45.156732
1
0
0
3ffe:1ce1:2::1
3ffe:lcel:2::3
::18.26.4.115
::18.26.4.116
::18.26.4.117
" bindingState:
only for dynamic address-only mapping: whether or not the
global address has been allocated to (bound with) an
internal node (1: bound, 0: unbound)
only for dynamic address-only mapping, record last time
that packets come from (or destined to) the internal address
pass the APT
indicates whether the entry is a static address-mapping or
dynamic address-only mapping
internal host IPv6 address
mapped global IPv6 address
" lastAccessTime:
"
::18.26.4.119
0
staticMapping:
" internalAddress:
" globalAddress:
For dynamic address-and-port mapping, APT uses two other tables - out-map and
in-map - to track all active flows. The tables start out empty after configuration. They
grow when there are dynamic address-and-port allocations. They shrink when idle entries
are deleted from the tables. Each entry of the dynamic mapping table contains an
originalFlowIDand a mappedFlowID, and the lastAccessTime. The following shows an
APT configured only for dynamic address-and-port mapping. Table 2b and Table 2c
show the tables' content after one active flow (3ffe:lcel:2::4, 2600, ::18.97.2.126, 25)
passes the APT configured for the example.
APT(0,
1,
1,
0,
::18.26.4.116 6000 6010)
Table2b. out map
Field
LastAccessTime
originalFlowID
mappedFlowID
Entryl
...
(3ffe:lce1:2::4, 2600 ,
(::18.26.4.116, 6001,
1
25)
_1_1_::18.97.2.126,
::18.97.2.126, 25)
Table2c. in map
Field
LastAccessTime
originalFlowID
mappedFlowID
EntryI
...
(::18.97.2.126, 25,
(::18.97.2.126, 25,
::18.26.4.116, 6001)
3ffe:IceI:2::,
34
2600)
5.3.2 Address Lookup and Translation
If the APT is configured for dynamic address-only mapping, then when an outward
packet arrives, APT looks for the entry that has the internal address the same as the
packet's source address. When an inward packet arrives, the APT looks for an entry that
has the internal address the same as the packet's destination address. Both searches occur
in the address-mappingtable.
If the APT is configured for dynamic address-and-port mapping, then when an outward
packet arrives, APT looks for the entry whose originalFlowIDis the same as the packet's
flow ID in the out-map. For an inward packet, APT looks for the entry whose
originaiFlowIDis the same as the packet's flow ID in the inmap. In the previous
example, if an inward packet with destination address ::18.26.4.116, port 6001 and source
address ::18.97.2.126, port 25 arrives, i.e, with the Flow ID (::18.97.2.126, 25 ,
::18.26.4.116, 6001), APT will successfully find a matching entry (Entry 1) in in-map
and return a mapped flow ID (::18.97.2.126, 25, 3ffe:Ice1:2::4, 2600). APT then
translates the destination address to 3ffe:icel:2::4, destination port to 2600.
5.3.3 Address Allocation and Unbinding
The addressAllocationDirectionspecifies when the APT can allocate a mapping if a
packet without a mapped entry passes by. The addressAllocationDirectionin the
previous example is outward. Thus, if there is no matching entry, APT will try to
allocate a new mapping for an outward packet, but will simply discard an inward packet.
If APT is configured for dynamic address-only mapping, APT will look for an unbound
entry in address-mappingtable and bind that entry with the packet's source address if the
packet is outward. The binding involves setting the value of the field internalAddressto
the packet's source address, setting the bindingStateto bound, and recording current time
in the lastAccessTime field in the address-mappingtable.
If APT is configured as dynamic address-and-port mapping, mapping allocation involves
the following steps for an outward packet, assuming addressAllocationDirectionis
specified as outward. APT always first looks up in the outmap table. If no matching
entry is found, APT will to find a free port, a port that no active flows in the inmap or
out-map has used as a mapped port. It then use the free port to create a mapped flow ID
(ma, mp, da, dp), where ma is the mapped address that is configured for APT, mp is the
free port, and da and dp refer to the destination address and port of the packet. APT
adds the entry with the new mapped flow ID to the outmap, where the search key is the
packet's original flow ID. At the same time, the APT adds the reverse of the packets'
original flow ID to the in-map, where the search key is the reverse of the mapped flow
ID.
35
Still using the previous example shown in Table 2b and Table 2c, assuming a packet with
source address 3ffe: Icel:2::4, port 2600 (from local IPv6 net), destination address
::18.97.2.126, port 25 (to the IPv4 Internet) arrives, APT cannot find an entry in the
out-map by using the flow ID (3ffe:lcel:2::4, 2600, ::18.97.2.126, 25). Since this is an
outward packet, the APT therefore allocates a free port "6001" for this new active flow.
Therefore it creates the mapped flow ID (::18.26.4.116, 6001, ::18.97.2.126, 25) for this
new flow. It then adds the mapped flow ID to the out__map, which corresponds to the
search key (3ffe:1cel:2::4, 2600, ::18.97.2.126, 25). Meanwhile, it adds (::18.97.2.126,
25, 3ffe:Ice1:2::4, 2600) to the in-map with the search key (::18.97.2.126,
25,::18.26.4.116, 6001).
Assume an inward packet with source address ::18.97.2.126, port 5001 (from the IPv4
Internet), destination address ::18.97.2.128, port 79 arrives, APT will find no matching
entry in the in-map table, thus discard the packet.
In order to make dynamic address translation efficient, the APT unbinds entries of
inactive flows. In address-mappingtable, an entry's binding state (bindingState) will be
reset to "0" (unbound) if the flow has been idle over a long period of time
(lastAccessTime is greater than a certain period of time). In in-map and outmap,
lastAccessTime indicates the last time that the flow has passed APT: APT uses it to
determine which entry could be deleted when all the mapped ports are used up for the
active flows. In future, TCP packets, FIN flag may be used as recognition for
deactivating a finished connection. The process of unbinding allows entries with idle
flows to be reused for new flows.
5.3.4 Checksum Adjustment
After the proper replacement of the address and port in the IPv6 packet, the checksum
value of the upper layer needs to be adjusted according to the difference between the
original address and port and the translated address and port. TCP, UDP, ICMPv6
compute checksum over the transport layer data and a pseudo-header that consists of
fields from the IPv6 header. APT ensures that every packet emitted from its output ports
has updated checksums.
5.4 Using an Address-and-Port Translator for GT64
The APT can be used alone in GT64 for translation between different address realms with
the same IPv6 protocol, such as IPv6 local network connected with the IPv6 Internet.
More often, the APT is connected with the protocol translator to construct a GT64 to deal
with packet translation between different protocol realms.
36
Chapter 6. The Protocol Translators
PT64 and PT46 are GT64's components for protocol translation. PT64 translates IPv6
packets to IPv4 ones and ICMPv6 packets to ICMPv4 ones. PT46 accepts IPv4 and
ICMPv4 packets and translates them to IPv6 and ICMPv6 packets.
This chapter provides a high-level overview of the protocol translation process. The first
section presents the design of protocol translators. The next section describes the
implementation details of IPv4/IPv6 and ICM[Pv4/ICMPv6 translations. It also addresses
the checksum updating issue at different layers when performing protocol translation.
The last section discusses the usage of protocol translators in GT64.
6.1 Design of Protocol Translators
One of the most important applications for GT64 is to enable communications between
IPv6-only and IPv4-only nodes. Translating a packet from IPv6 to IPv4 or vice versa
involves protocol translation as well as address-and-port translation. PT64 and PT46 are
used in conjunction with the IPv6-based APT to complete the translation for needed
packets. As shown in Chapter 4, GT64 needs APT and PT64 for a complete translation
for an IPv6 packet sent by a local IPv6-only host to a IPv4-only host on the Internet.
APT maps the source address-and-port pair to an "IPv4-mappedIPv6 address"-and-port
pair. PT64 translates the IPv6 header of the packet into an IPv4 one and takes the lowest
32 bits of the IPv6 addresses for the source and destination IPv4 addresses.
Similarly, an IPv4 packet sent by an IPv4-only host to an IPv6-only host needs to pass
PT46 and APT for a complete translation. PT46 translates the IPv4 header of the packet
into an IPv6 one, with source and destination addresses being simply translated into IPv4mapped IPv6 addressesby adding a 96-bit prefix. APT then maps the destination IPv4mapped IPv6 address into the real destination IPv6 address.
Since the APT deals with address mapping and allocation, PT64 and PT46 are
responsible only for protocol translation. The implementation of PT64 and PT46 are
eased because of the modular design. The following sections show the implementation
details.
6.2 Implementation
6.2.1 IP Translation
37
Protocol translators need to make adjustments when translating from one version of IP to
the other because the IPv6 and IPv4 headers do not exactly match. (See Figure 5a).
During the translation, some fields can be directly copied. For instance, the TTL and
Protocol fields of an IPv4 header directly correspond to Hop Limit and Next Header
fields of an IPv6 header (Figure 5b). Some fields need to be translated with adjustment.
For example, IPv4's Total Length field is the packet total length, which includes the IPv4
header. It can be translated to the PayloadLength field of IPv6, which refers to only the
packet length. The way to get the PayloadLength value is to subtract the length of the
IPv4 Internet header from the original value of the Total Length field.
IPv4 Header
0
Version I IHL
TOS
Frag. identifier
TTL
protocol
Source Address
Destination Address
[Pv6 Header
)
Version Class
Payload Length
31
Total Length
Flags
I Fragment Offset
Header Checksum
31
Flow Label
Next Header
Hop Limit
Source Address
Destination Address
[Pv6 Fragment Header
Nst31
Next header
Reserved
Fragment Identifier
Fragment. Offset
Figure 5a. IPv4, IPv6 and IPv6 Fragment Header Format
38
Flags
Directly Copied Fields
IPv4 Header
IPv6 Header
Field
TTL
Frag. Offset
Protocol2
Field
Hop Limit
Frag. Offset'
Next Header2
Value
8-bit
13-bit
8-bit
IPv6 Header
Field
Ver
Value
6
Value
8-bit
13-bit
8-bit
Translatable Fields
IPv4 Header
Value
Field
4
Ver
IP header length
Ihl
Total Length
Packet length
(including header)
Frag. Identifier
Flags
Source Address
Dest. Address
16-bit
3-bit
32-bit
32-bit
Payload Length
Frag Identifier
Flags'
Source Address
Dest. Address
Packet length IPv6 header
length
32-bit
3-bit
128-bit
128-bit
Note:
1. The field goes in the IPv6 Fragmentation Header.
2. The value can be directly copied except when the protocol is ICMP or ICMPv6.
3. Ignored Fields in Translation:
IPv4 Header: TOS
IPv6/IPv6 Fragment Header: Class, Flow Label, Reserved
4. Special Care: IPv4's Header Checksum
Figure 5b. Translation between IPv4 and IPv6 Protocols
Some fields have to be ignored simply because there are no corresponding fields that can
carry the information in the other protocol. Traffic Class, Flow Label, and Reserved
fields in IPv6 and IPv6 fragmented headers are examples. The TOS (Type-of-Service)
field of the IPv4 header has to be dropped for the same reason. Finally, if a packet is
translated from IPv6 to IPv4, the Header Checksum field (IPv4 protocol) should be
computed after the IPv4 header is constructed; IPv6 has no header checksum. PT64
follows Table 3 when translating an IPv6 header into an IPv4 one. PT46 follows Table 4
for translating an IPv4 header to an IPv6 one.
39
Table 3. Translating IPv4 to IPv6 Headers
No IPv6fragmentationrequired
IPv6 Field
Value
6
Version
Traffic-Class
0 (all zero bits)
Flow ID
0 (all zero bits)
Payloadlength value of total Length from IPv4 header, minus value of Internet
HeaderLength (multiply by 4) from the IPv4 header
Next Header
value of Protocolfield from IPv4 header
If it is 1 (ICM~v4), then substitute it with 58 (ICMPv6)
Hop Limit
Source and
Destination
Address
Time to Live field value from IPv4 header
directly adding :: (96 bits of 0) to the Source and destination IPv4
address to make them IPv4-mappedIIPv6 address.
IPv6 Fragmentationis required
IPv6 Field
Value
Payload
Total Length minus the Internet Header Length (multiply by 4) from
Length
the IPv4 header, plus 8 for Fragment header
Next Header
44 (Fragment Header)
Fragment
Value
Header Field
Next Header
value of Protocolfield from IPv4 header
If it is 1 (ICMPv4), then substitute it with 58 (ICMPv6)
Reserved
0 (all zero bits)
Fragment
value of FragmentOffset from IPv4 Header
Offset
Mflag
value of More Fragmentsflag from the IPv4 header
Identification
The low-order 16 bits are copied from the value of Identificationfield
in the IPv4 Header. The higher order bits set to zero.
Note:
1. Fragmentation is needed when the IPv4 More Fragment flag is true or the Fragment
Offset is non-zero. Except for the PayloadLength and Next HeaderFields, the IPv6 fields
are the same as for the no fragmentation case.
40
Table 4. Translating IPv6 to IPv4 Headers
No IPv6 Fragmentheader
Value
IPv4 Field
4
Version
5 (no IPv4 options)
Internet Header
Length
0 (all zero bits)
Type of Service
value of PayloadLength field from IPv6 header, plus the size of
Total Length'
the IPv4 header (20).
0 (all zero bits)
Identification
Don't Fragment flag is set to true(1), and all other flags set to
Flags
false (0)
0 (all zero bits)
FragmentOffset
value of Hop Limit from IPv6 header
Time To Live
Protocol
value of Next Header from IPv6 header or last extension
header; if the value is 58 (ICMPv6), replace it with 1 (ICMPv4).
Source and
copy the lower 32 bits of the Source/DestinationAddress fields
DestinationAddress
from IPv6 header.
Header Checksum
Compute it once the IPv4 Header has been created
Containsa IPv6 FragmentHeader2
Value
IPv4 Field
Total Length
value of PayloadLength from IPv6 header, minus 8 for the
Fragment header, plus the size of the IPv4 header
Identification
copy from the low-order 16 bits in the Identificationfield in the
Fragment header
Flags
the More Fragmentsflag is copied from the Fragment header
and the Don't Fragmentflag is set to false.
Fragment Offset
copy value of Fragment Offset field in the Fragment Header
Note:
1. All IPv6 extension headers are ignored, except for IPv6 fragment header. For each
IPv6 extension header that is ignored, the PayloadLength needs to be adjusted by the
size of these headers before the IPv4 Total Length field is calculated.
2. If the IPv6 packet contains a Fragment header, the header fields are set as there is no
fragment header except Total Length, Identification, Flags,and FragmentOffset Fields.
6.2.2 ICMP Translation
The protocol translator will drop ICMP messages with unknown Type fields. It will
translate the remaining ICMP messages. Header formats for ICMPv4 and ICMPv6
messages are nearly identical, with minor changes. Both ICMPv4 and ICMPv6 have
41
messages such as Echo Request, Echo Reply, Time Exceeded, Destination Unreachable,
Packet Too Big, and ParameterProblem. Consequently, the ICMP translation involves
simple type-code translation for the above ICMP messages (except ParameterProblem)
that have counterparts in the other protocol.
The formats of ICMPv4 and ICMPv6's ParameterProblem message are quite different
because ICMPv4 has a 8-bit point value whereas ICMPv6 has a 32-bit point value.
Furthermore, the Pointerfield needs to be adjusted to point to the corresponding field in
the IP header where error occurs.
Finally, a recursive translation is needed for the IP packet contained in the ICMP error
message. Currently, PT64 and PT46 can translate any ICMPv4 or ICMPv6 messages that
do not involve recursive translation (IP packet contained in the ICMP error message).
Table 5 illustrates details of ICMPv6 to ICMPv4 header translation that PT64 follows.
Table 6 illustrates details of ICMPv6 to ICMPv4 header translation that PT46 follows.
Table 5. Translating ICMPv6 to ICMPv4
ICMPv6 Header
Message
Type
Code/Pointer*
Echo Request
128
-
Echo Reply
129
-
Translated ICMPv4 Header
Type Code/Pointer* Other Change
0
8
-
Dest. Unreachable
Dest. Unreachable
1
1
0
1
3
3
1
10
Dest. Unreachable
Dest. Unreachable
Dest. Unreachable
1
1
1
2
3
4
3
3
3
5
1
3
Pkt. Too Big
2
3
4
Time Exceed
Parameter Prob.
Parameter Prob.
Parameter Prob.
Parameter Prob.
Parameter Prob.
Parameter Prob.
3
4
4
4
4
4
4
-
2
1
0; Pointer:O
0; Pointer:4
0; Pointer:7
0; Pointer:6
11
12
3
12
12
12
12
0;
2
0;
0;
0;
0;
0; Pointer:8
0; Pointer:24
0; Pointer: others
12
12
12
0; Pointer = 12
0; Pointer = 16
0; Pointer = -1
Parameter Prob.
4
Parameter Prob.
4
Parameter Prob.
4
- : code field unchanged.
* : unless specified, refer to code value
source: [1].
42
Port unreachable
Adjust MTU
Code Unchanged
Pointer = -1
Pointer
Pointer
Pointer
Pointer
=
=
=
=
0
2
8
9
Table 6. Translating ICMPv4 to ICMPv6
Translated ICMPv6 Header
ICMPv4 Header
Code/pointer*
0,1,6,7,8,11
2
3
4
5
9,10
Type
128
129
1
4
1
2
1
1
11
12
12
Pointer:O
Pointer:2
3
4
4
Pointer:O
Pointer:4
Parameter Prob.
12
Pointer:8
4
Pointer:7
Parameter
Parameter
Parameter
Parameter
12
12
12
12
Pointer:9
Pointer:12
Pointer:16
Pointer:all other
4
4
4
4
Pointer:6
Pointer:8
Pointer:24
Pointer: -1
Message
Echo
Echo Reply
Dest. Unreachable
Dest. Unreachable
Dest. Unreachable
Dest. Unreachable
Dest. Unreachable
Dest. Unreachable
Type
0
8
3
3
3
3
3
3
Time Exceeded
Parameter Prob.
Parameter Prob.
Prob.
Prob.
Prob.
Prob.
Code /Pointer *
-
Other Change
-
0
1
3
0
2
1
Pointer = 6
Adjust MTU
: code field unchanged.
: unless specified, refer to code value
source: [1].
-
*
6.2.3 Checksum Adjustment
Both PT64 and PT46 need to recalculate the checksum of the higher-layer protocol (e.g.,
TCP, UDP) after the protocol translation of the packet. TCP and UDP compute their
checksum value based on a pseudo header that includes values of source and destination
addresses, upper-layer packet length and protocol (next header) fields from the IP/IPv6
header. When translating from IPv6 to IPv4, PT64 needs to calculate the IP checksum
that is required by the IPv4 header. However, PT46 need not calculate IPv6 checksum
since IPv6 header does not have that field.
PT46 and PT64 also differ in ICMPv6 and ICMPv4 checksum calculation. PT46 needs
to compute the ICMPv6 checksum in the same fashion as TCP and UDP because
ICMPv6 includes the pseudo header in its computation. However, PT64 can directly
calculate the ICMPv4's checksum directly from the ICMPv4 packet. When translating
between ICMPv4 and ICMPv6, the difference in the checksum value needs to be taken
into account.
43
6.3 Using Protocol Translators for GT64
Protocol translators are used in GT64 so that GT64 is able to deal with translation
between different protocol realms. They are always used together with an APT. Protocol
translators can be omitted from a GT64 if the two networks use IPv6, such as the
translation scenario of an IPv6 private net connected with the IPv6 Internet.
44
Chapter 7. GT64 for Different Translation
Scenarios
This chapter illustrates how modular structure allows GT64 to easily handle different
translation requirements. With different configurations, GT64 can be used in different
translation scenarios such as:
*
"
"
"
"
Local IPv6 network connected with the IPv4 Internet
Local IPv4 network connected with the IPv6 Internet
IPv6 private network connected with the IPv6 Internet
IPv4 private network connected with the IPv4 Internet
Load balancing
A local IPv6 network connected with the IPv4 Internet will be the most common
translation scenario at the early stage of transitioning to the IPv6 Internet. As the
transition goes to a later stage, the second translation scenario, a local IPv4 network
connected with the IPv6 Internet, will be common for the local sites that are slow in IPv6
implementation, but are willing to explore the IPv6 infrastructure. The third scenario,
IPv6 private network connected with the IPv6 Internet, will be less common, since the
primary reason for private networks is due to the insufficiency of global IP addresses,
which is not the case for IPv6 global addresses. An IPv4 private network connected with
the IPv4 Internet is very common for today's network. In fact, most existing network
translators were designed for IPv4/IPv4. GT64 can also be utilized in that situation.
GT64 can balance load across replicated servers, all of which appear to share a single
globally visible address. The major difference between the above four scenarios and load
balancing is that the address mapping occurs only when the flow is initiated from the
outside world.
Table 7 summarizes configurations of GT64 of the five translation scenarios. Following
that, Section 7.1 to Section 7.6 illustrate in detail how to set up configurations for each of
the five scenarios and a mixed environment scenario.
45
Table 7. Configurations of GT64 for Different Translation Scenarios
Translation Scenario
Local IPv6 net with the
GT64 path
Outward Packet
IPv6 packet =>
GT64 path
Inward Packet
IPv4 packet =>
IPv4 Internet
APT =>
PT46=>
Local IPv4 net with the
PT64=>
IPv4 packet
IPv4 packet =>
APT=>
IPv6 packet
IPv6 packet =>
PT46 =>
APT =>
APT =>
PT64 =>
Local IPv6 net with the
IPv6 packet
IPv6 packet =>
IPv4 packet
IPv6 packet =>
IPv6 Internet
APT =>
APT=>
Local IPv4 net with the
IPv6 packet
IPv4 packet =>
IPv6 packet
IPv4 packet =>
PT46 =>
APT =>
PT46 =>
APT =>
PT64 =>
PT64 =>
Load balancer
(IPv6 local net
IPv4 packet
IPv6 packet =>
APT =>
IPv4 packet
IPv6 packet =>
APT =>
supported web server
IPv6 packet
IPv6 packet
IPv6 Internet
IPv4 Internet
with the IPv6 Internet)
46
Address Allocation
Direction
Outward
Outward
Outward
Outward
Inward
7.1 Local IPv6 Net Connected with the IPv4 Internet
Take the first scenario as an example: Figure 6 shows how GT64 can be connected with
IPv6 routing elements and IPv4 routing elements to achieve translation and routing
functions for a local IPv6 net connected with the IPv4 Internet. APT is configured to have
static mapping and dynamic address-and-port mapping. Local IPv6 host 3ffe: lcel:2::1 is
statically mapped with a global IPv4-mapped IPv6 address :: 18.26.4.115. APT has 1000
ports (port number range from 6000 to 7000) that can be multiplexed to the flows
connecting local IPv6 and IPv4 hosts in the Internet. Moreover, this APT allows
dynamic address allocation for outward packets because the dynamic address allocation
direction is configured as 0.
When a packet that is originated from host A2 of the local net and destined to host B in
the IPv4 Internet passes the IPv6 routing elements, they will output the packet to GT64,
since the destination address is an IPv4-mapped IPv6 address ::64.58.76.177. This
packet has an original flow ID as (3ffe:Icel:2::2, 5001, ::64.58.76.177, 125). APT will
replace its source IPv6 address and port with a mapped IPv4-mapped IPv6 address
::18.26.4.116 and a mapped port 6000, i.e, the flow ID becomes (::18.26.4.116, 6000,
::64.58.76.177, 25). Then the packet will be directed to PT64 to be translated into an IPv4
packet whose flow ID will be (18.26.4.116, 6000, 64.58.76.177, 25). PT64 outputs the
IPv4 packet to the IPv4 routing elements, which will route the packet to the outside world
- the IPv4 Internet.
In the reverse direction, when an inward packet, for instance, a packet that is originated
from host B in the IPv4 Internet and destined to Host A2 in the local IPv6 net, arrives at
the edge router, the IPv4 routing elements routes the packet to GT64. After address-andport translation at APT and the protocol translation at PT46, the packet changes from an
IPv4 packet to an IPv6 packet with IPv4 mapped IPv6 addresses for both source and
destination address, and then to an IPv6 packet with local IPv6 address 3ffe:1ce1:2::2 for
destination address. The IPv6 routing elements then routes the packet to the final
destination in the local IPv6 net. In the above process, the flow ID changed from
(64.58.76.177, 25,18.26.4.116, 6000) to (::64.58.76.177, 25,::18.26.4.116, 6000) to
(::64.58.76.177, 25, 3ffe:icel:2::2, 5001).
47
Configuration Example: APT(1,
0,
3ffe:1ce1:2::1 ::18.26.4.115,
1,
1,
0,
::18.26.4.116 6000 7000)
IPv6 packets
destined for IPv4
node
IPv6 packets with IPv4
mapped IPv6 (translated)
addresses
Completely
translated IPv4
packets
IPv4
Internet
IPv6
local net
Host
PA_
Al:
3ffe:lcel
:2::1
rout-
Host B:
e e-
64.58.76.
ments
177
Host A2:
3ffe:lcel
:2::2
Completely
translated IPv6
packets
Translated IPv6 packets
with IPv4 mapped IPv6
addresses
IPv4 packets
destined for
TPv6 no&e
Figure 6 Configuration of GT64 for connecting Local IPv6 net with IPv4 Internet
48
7.2 Local IPv4 Net Connected with the IPv6 Internet
Figure 7 shows how GT64 can be used to translate and route for a local IPv4 net
connected with the IPv6 Internet. This figure is exactly the same as Figure 6 except that
PT64 and PT46's positions have been exchanged, as well as those of IPv4 and IPv6
routing elements. APT is configured to have static address mapping as well as dynamic
address-and-port mapping. Notice that in the global addresses that APT uses are normal
IPv6 addresses rather than IPv4-mapped IPv6 addresses. Internal host 1.0.0.1 is statically
mapped with IPv6 address 3ffe:1ce1:2::1. Flows of other internal hosts that
communicate with the outside world need to be dynamically mapped with a global IPv6
address 3ffe:lce1:2::2 and a port (in the range from 6000 to 7000) as source address and
port.
Configuration Example: APT(1,
0,
::1.0.0.1 3ffe:1ce1:2::1,
1,
1,
0,
3ffe:1ce1:2::2 6000 7000)
DNSA]LG
IPv4
local net
IPv4
routing
PT46
APT
PT64
Host Al:
1.0.0.1me
IMv
routing
ele-HotB
Internet
(6 bone)
es5f29
b:
s
Host A2:
1.0.0.2
...
....
..
Figure 7. Configuration of GT64 for connecting Local IPv4 net with IPv6
Internet
49
7.3 IPv6 Private Network Connected with the IPv6 Internet
When GT64 is used to translate for an IPv6 private net connected with the IPv6 Internet,
protocol translators will not be included in the configuration of GT64, since protocol
translation is unnecessary. Figure 8 shows such a translation scenario. When a packet
destined to the host of the IPv6 Internet passes the IPv6 routing elements, the packet is
directed to GT64, where the address and port translation is conducted - i.e. the source
private IPv6 address is translated to a global IPv6 address, along with the port. The IPv6
routing elements then routes the translated IPv6 packet to the IPv6 Internet.
Configuration Example: APT(1,
0,
1ffe::1 3ffe:1ce1:2::1,
1,
1,
0,
3ffe:1ce1:2::2 6000 7000)
IPv6 packets with
private source IPv6
address
IPv6 packets with
(translated) global source
TPv6 addresses
Private
IPv6 net
IPv6
Internet
(6 bone)
Host A1:
Iffe::1
Host A2:
1ffe::2
Host B:
5f02:971b:
:1
IPv6 packets
destined for global
destination Address
IPv6 packets with private
IPv6 dest. (translated)
addresses
Figure 8. Configuration of GT64 for connecting
private IPv6 net with IPv6 Internet
50
7.4 IPv4 Private Network Connected with the IPv4 Internet
When an IPv4 private net is connected with the IPv4 Internet, both PT64 and PT46 are
needed for any packet's translation. Figure 9 illustrates how GT64 is configured for this
scenario. In the example, APT is configured the same as Figure 6. Obviously, this is not
the best approach to deal with translation for an IPv4 private net connected with the IPv4
Internet: the double protocol translation is very inefficient. However, it does
demonstrate the generality of GT64: GT64 can be configured for any IPv4/IPv6 related
translation scenarios. Furthermore, in the future, an IPv4-based APT, i.e., an APT that
can also do IPv4-to-IPv4 address-and-port translation, can be easily developed.
(Currently, the APT is IPv6-based.)
Configuration Example: APT(1,
0,
::1.0.0.1 ::18.26.4.125,
1,
1,
0,
::18.26.4.116 6000 7000)
IPv4 packets with
private IPv4 src
add.
Translated IPv6 packets
with IPv4 mapped IPv6
addresses (private src add)
Translated IPv6 packets
with IPv4 mapped IPv6
addresses (global src add)
IPv4 packet with
global (translated) IP
src address.
JIPv4
lIP4
Internet
local net
Host
Al:
1.0.0.1
Host B:
18.26.4.125
Host
A2:
IPv4
packets with
private IPv4 dst
address
Translated IPv6 packets
with IPv4 mapped IPv6
addresses (global dst add)
Translated IPv6 packets
with IPv4 mapped IPv6
addresses (private dst add)
IPv4 packet
with global IP
dst address.
Figure 9. Configuration of GT64 for connecting private IPv4
net with IPv4 Internet
51
7.5 Load Balancing
GT64 can be used as a load balancer. Assume that the web address 3ffe:ice l:2::1 has ten
IPv6-only machines (Iffe::1,..., Iffe::10) to back up its functions and they are connected
to the IPv6 Internet through an edge router where GT64 resides, as illustrated in Figure
10. GT64 consists of APT only. An IPv6 packet coming from the IPv6 Internet will be
sent to the APT directly; the destination address and port (web server) will be mapped to
one of the local machines' IPv6 addresses and certain port. The IPv6 routing elements
then forward the packet to that local machine.
GT64 can be easily configured to handle other load balancing situations, such as an IPv4
web address that has several IPv4-only machines to back up its functions, an IPv4 web
address that has several IPv6-only machines to back up its functions.
Configuration Example: APT(O,
1,
0,
1,
1 ffe::1,
1ffe::2,
1ffe:: 10)
(
IPv6 packets with (translated)
global source IPv6 addresses
(from webserver)
IPv6 packets with
private source IPv6
address
J
Private
IPv6 net
for
webserver
3ffe:1cel:
2::1
IPv6
Internet
(6 bone)
Host A:
Iffe::1
Host A2:
lffe::2
IPv6 packets destined
IPv6 packets with
private IPv6 dest.
(translated) addresses
to
global destination Address
(to web server)
Figure 10. Configuration of GT64 for Load Balancing
52
7.6 Mixed IPv6/IPv4 Local Network Connected with the IPv4 and
IPv6 Internet
A local network will not transit from IPv4 to IPv6 in a single step. Most likely, some
nodes of a local network will be IPv6-only, some nodes will be IPv4-only, and others will
be IPv4/IPv6. GT64 can be easily configured for this kind of situation, as seen in Figure
11. When a packet comes to an edge router, it is sent to the IPv4/IPv6 Click routing
elements that can route both IPv4 and IPv6 packets. There, the first classifier decides
which path, IPv4 or IPv6, should handle the packet. On the left side, Figure 12 shows an
IPv4 path in Click that an IPv4 packet will follow; on the right side, an IPv6 path that an
IPv6 packet will follow. If the packet needs to be translated, the LookupIPRoute or
LookupIP6Route element will output the packet to GT64. After the translation, the
translated packet is sent back to the corresponding path of the router to be processed as
other normal packets.
53
-*
LPv4/IPv6
mixed
Local
network
IPv4/IPv6
Internet
IPv4/
IMv
IPv4
mi xed
/AM6
Local
network
Click
Router
/EPv6
IA 4
Click
Router
IPv6
Inter
net
Figure 11. IPv4/lPv6 mixed local net connected with the IPv4/lPv6 Internet
54
h1)
FromDevice(ethO) IFromDevice(et
Classifier(.)
IPv4, ARP queries/response
EMv, NDady, NDSoli
Classifier(...)
Classifier(...
)
ARP Queries
ARPResponder
to
A RP Response
IN4
IP6
IP6NDAdvertisement IP6NDSolicitation
to IP6NDSolicitor
to XRQuerier
Strip(14)
I
IP6NDAdvertiser
Strip(14)
to
Oueue
Queue
I CheckIP6Header(...)
CheckIPHeader(...)
Trans-
lated
GetIPAddress(16)
Translated
IPv6
packets
IPv4
packets
GetIP6Adress(24)
Lo§kuvIP6oute .d
IPv6 packets to
be translated
IPv4 packets to
be translated
GT64
-IN
Figure 12. Segment of Click Configuration for the scenario IPv4/IPv6
mixed local net connected with the IPv4/IPv6 Internet
55
7.7 Discussion
The set of translation scenarios demonstrated in this section indicates that GT64 is truly
general-purpose, i.e., it suits a diversity of the translation scenarios with easy
configurations. The modularity of Click software contributes to the ease of the translator
configuration.
The previous examples use combinations of Click routing elements and GT64.
Nevertheless, GT64 can also be connected with any existing routers to achieve the above
translations.
This thesis focuses on IPv6 related translations. Therefore, most IPv6 related translations
(IPv6/IPv4 and IPv6/IPv6) are dealt with by GT64 very easily. However, further
development, such as APT that can also make IPv4-to-IPv4 address translation will
further ease the configuration for translation scenarios such as IPv4 local net connected
with the IPv4 Internet and load balancing (e.g. IPv4 hosts back up an IPv4 internet
address).
56
Chapter 8. Performance Evaluation
This chapter presents basic performance measurements for GT64. It analyzes the
performance by measuring numbers of packets per second.
The experiment consists of three machines that are connected as shown in Figure 13. The
router running GT64 has a separate full-duplex point-to-point gigabit Ethernet link to
each of the two "host" PCs (Host A and Host B). The router is a Dell PowerEdge 6300,
with four 500 mHz Intel Pentium III Xeon CPUs, an Intel 450NX chipset motherboard,
and 1GB of RAM. The router machine uses only one CPU. The two hosts have dual 800
mHZ Pentium III CPUs, SeverWorks LE chipsets, and 256MB of RAM. All the network
devices are Intel Pro/1000F gigabit Ethernet cards, connected to the motherboards with
64 bit 66 mHz PCI.
Host
A
IMv
Node
1PT64
Click
Routing
Elements
APT
P4
IN
Click
Routing
Elements
7
Host
B
IPv4
node
T4other
other
routing
routing
outputs-
upt
Figure 13. Experiment: GT64 for an INv4 host and an INv6 host
57
Each host generates an even flow of UDP packets addressed to the other host; the router
is expected to perform the network translation and then route the packet to the other host.
Each UDP packet includes Ethernet, IP (IPv6), and UDP headers as well as some bytes of
data and the 4-byte Ethernet CRC. Host A sends IPv6 UDP packets into the router to be
forwarded to Host B which is IPv4-only. In the reverse direction, Host B sends IPv4
UDP packets into the router to be forwarded to Host A, which is an IPv6-only host.
Host A generates eight streams of 64-byte IPv6 UDP packets where each stream has a
different destination IPv6 address. Each stream consists of a sequence of flows; the
packets of each flow all have the same port numbers, but successive flows in the same
stream have different port numbers. Each flow consists of 50 packets. The router
forwards these packets to Host B after performing network translation with GT64, i.e.,
address-and-port translation at APT and IPv6-to-IPv4 protocol translation at PT64. The
router runs in kernel Click. It uses polling drivers to get packets from the network
interfaces. The APT is configured to have more than 61000 ports available (from port
number 4096 to port number 65535) for dynamic address-and-port allocation. The APT
adds a new translation table entry for each new flow. Mappings for inactive flows will be
deallocated after 20 minutes. Host B (IPv4-only host) echoes every packet it receives
back to the router after reversing source and destination address and port fields. The
router forwards the packets after the reverse network translation at GT64, i.e., IPv4-toIPv6 protocol translation at PT46 and address-and-port translation at APT. Both end
hosts count the number of packets the router forwards to them.
The experiment shows that the maximum loss-free forwarding rate for the router and the
translator is 64k packets per second, implying that it takes 15us to process a packet. The
router can only sustain this rate while there are unused ports available. Performance will
go down once all the ports are used up since each new flow has to wait for the
deallocation of a previous flow's port. The CPU time required to execute GT64 is 4.5us
per packet, or 3,577 cycles, as measured by PentiumPro performance counters.
58
Chapter 9. Related Work
[RFC 1631] is the first specification that documented IP network address translator. The
operation of NAT devices and the terminology for various NAT are defined and
described in [RFC 2663]. Kohler et. al. implemented a set of Click NAT elements using
its terminology [Click] [Click-Thesis]. Using a flexible, usable set of components in
Click, Kohler's NAT can perform basic NAT, Network Address Port Translation, Load
Sharing, and full Two-Way NAT, Twice-NAT, and Multihomed NAT in IPv4.
[RFC 2766] specifies a stateful IPv4/IPv6 translation mechanism. It is based on a
combination of address translation theme as described in [RFC 2663] and V6/V4 protocol
translation theme as described in [RFC2765]. Following the specification, Click's GT64
implements a flexible, usable set of Click components for network address translation
between IPv6 and IPv4 networks.
Ultima [7]is an experimental interworking device developed within British Telecom. The
Ultima interworking device has the ability to translate from IPv6 to IPv4 (and vice versa)
and also tunnel IPv6 over IPv4. The translation is via the NAT-PT mechanism (including
NAPT-PT and DNS/FTP ALGs). Address translation is performed by aliasing an IPv6
address with an IPv4 address in much the same way as a conventional NAT device.vThe
Ultima NAT-PT contains ALG's for both DNS and FTP. The DNS-ALG is a
comprehensive implementation supporting both UDP and most TCP type DNS requests
and responses. The DNS-ALG currently handles translation of A records originating from
the IPv4 to AAAA records for forwarding to the IPv6 network and AAAA records from
IPv6 translated to A records for forwarding to IPv4. An implementation of the Ultima
device is resident on the BT portion of the 6Bone to allow native IPv4 access to an IPv6
WWW mirror server.
The Microsoft IPv6 stack [6] is a modification of a NAT-PT developed by Fiuczynski [1]
et al. from the University of Washington. The system requires Windows 2000 PC
running the Microsoft IPv6 stack. The implementation uses a device driver which can be
manually started and stopped. The device uses static mapping for its stateful translation,
i.e., it uses a list of explicit IPv4 to IPv6 mappings to assign IPv4 addresses to the IPv6
hosts. This deviates from the NAT-PT idea where mappings are dynamically allocated
by the NAT-PT device as new sessions are supported by the device.
NAT-PT is a part of Cisco's future IOS IPv6 implementation [5] (currently Beta version).
The translator allows access from both IPv6 networks to IPv4 servers and from IPv4
networks to IPv6 servers. It works in conjunction with IPv4 NAT, and by using the IPv4
overload parameter it is possible to use one IPv4 address for a subset of IPv6 addresses
(NAPT-PT). It is also possible to configure static mappings between IPv4 and IPv6
addresses.
Those implementations only incorporate the address translation part of NAT-PT and
exclude the port-number translation. Furthermore, unlike Click's GT64, those
59
implementations are embedded inside a fixed router configuration, which doesn't allow
change of interaction with other forwarding functions.
60
Chapter 10. Conclusion
It is clear that the transition from the IPv4 Internet to the LPv6 Internet will take years.
Every site has to decide its own transitional plan. Only a very few sites will be able to
achieve a single-step transition. NAT will be used as a mechanism to support the
communication between IPv4- and IPv6-only nodes for most sites.
This thesis describes the design and implementation of a General-purposeTranslatorfor
IPv6/IPv4 (GT64) based on Click software. GT64 has three basic elements: APT, PT64,
and PT46. They can be used for IPv4/IPv6 translation for most network applications.
GT64 satisfies three crucial criteria of a good network translator: being able to
communicate between IPv6-only nodes and IPv4-only nodes, requiring no change at
either the source or destination machine, and ease of implementation. GT64 can be easily
configured for different translation scenarios between different IPv4 and IPv6 address
and protocol realms.
Its modularity and ease of configuration and extension indicates that the GT64 is a
powerful tool for network communication. Further development and deployment of
GT64 will facilitate our transition to the IPv6 world.
61
Appendix. A Click IPv4 router
Figure 14 shows a two interface basic Click IPv4 router [Click-Thesis]. Every element
represents a simple router function. A number of elements can be added to increase the
routing efficiency or enable the router for other complex routing tasks.
62
Figure 14. Click Configuration for an IPv4 router
FromDe
FromDeviQ(ethl)
ce(etho)
Classifier(...)
A RP Queries
Classifier(...)
A RP Responses
IP4
IN4
ARPResponder
ARPQuerier
Paint(2)
Paint(l)
to Queue
I
CheckIPHeader(...)
GetIPAddress(16)
A RP Queries
ARP Responses
to
TPResponder
ARPQuerier
to Queue
I
I
LokuplPoute(...)
I
DropBrodass
DropBroadCas
L
k
CheckPaint(2)
ICMPError
l1CMPError
reirect
TCTPError
L
k
er
IP6Fragment(...)
Must fragment
from
Classifie
I
ARPQuerier(...)
I~r(.oa
IP6Fragment(...)
from Clas sifi
ARPQuerier(...)
I
ToDevice(ethO]
ToDevice(ethl)
63
Ms
fragment
Bibliography
RFCs:
[RFC 1631]
Egevang, K. and P. Francis, "The IP Network Address Translator
(NAT)", May 1994.
[RFC1886]
S. Thomson and C. Huitema, "DNS Extensions to support IP version 6",
December 1995.
[RFC1918]
Y. Rekhter, B. Moskowitz, D. Karrenberg, G.J. de Groot and E. Lear,
"Address Allocation for Private Internets", February 1996.
[RFC1928]
M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas and L. Jones, "SOCKS
Protocol Version 5", March 1996.
R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts
[RFC1933]
and Routers", April 1996.
[RFC2373]
1998.
R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", July
[RFC 2391] P. Srisuresh and D. Gan. "Load sharing using IP Network Address
Translation", August 1998.
[RFC 2428] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for IPv6 and
NATs", September 1998.
[RFC2529]
B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4 Domains without
Explicit Tunnels", March 1999.
[RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT)
Terminology and Considerations", August 1999.
[RFC 2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions
to Network Address Translators (DNSALG)", September 1999.
[RFC2765]
E. Nordmark, "Stateless IP/ICMP Translator",
[RFC2766]
G. Tsirtsis, P. Srisuresh, "Network Address Translation - Protocol
Translation (NAT-PT)", February 2000.
K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts using the Bump[RFC2767]
in-the-Stack technique", February 2000.
64
[RFC2772]
2000.
R. Rockell, R. Fink, "6Bone Backbone Routing Guidelines", February
[RFC 2993]
T. Hain. "Architectural implications of NAT", November 2000.
Internet Drafts:
[NAT-INTRO] W. Biemolt et al, "On overview of the introduction of IPv6 in the
Internet. Draft-ietf-ngtrans-introduction-to-IPv6-transition-04.txt (work in progress)
Jim Bound, "Assignment of IPv4 Global Addresses to IPv6 Hosts (AIIH)",
[AIIH]
draft-ietf-ngtrans-assgn-ipv4-addrs-01.txt (work in progress).
[DHCPIPv6]
J. Bound, C. Perkins, "Dynamic Host Configuration Protocol for IPv6",
draft-ietf-dhc-dhcpIPv6-14.txt (work in progress).
J. Bound, L. Toutain, H. Affifi, "Dual Stack Transition Mechanism
[DSTM]
(DSTM)", draft-ietf-ngtrans-dstm-01.txt (work in progress).
[NAT] P. Srisuresh, Campio Communications, K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", draft-ietf-nat-traditional-04.txt (work in
progress).
[SOCKS-EXT] H. Kitamura, "SOCKSv5 Protocol Extensions for IPv6/IPv4
Communication Environment", draft-kitamura-socks-IPv6-01.txt (work in progress).
[SOCKS-GATE] H. Kitamura, A. Jinzaki, S. Kobayashi, "A SOCKS-based IPv6/IPv4
Gateway Mechanism", draft-ietf-ngtrans-socks-gateway-02.txt (work in progress).
J. Hagino, K. Yamamoto, "An IPv6-to-IPv4 transport relay translator", draft[TRT]
ietf-ngtrans-tcpudp-relay-00.txt, (work in progress).
Articles and websites:
E. Kohler, R. Morris, Benjie Chen, J. Jannotti, and M.F. Kaashoek, "The
[CLICK]
Click modular router", ACM Transactions on Computer Systems, 18(4), November 2000.
[CLICK- Thesis]
November, 2000.
E. Kohler, The Click modular router. MIT Ph.D. Thesis,
[1] M.E. Fiuczynski et al, 1998, "The Design and Implementation of an IPv6/IPv4
Network Address and Protocol Translator," Proceedings of the USENIX Annual
Technical Conference (N098), New Orleans, Louisiana.
http://www.cs.washington.edu/research/networking/napt/reports/usenix98/index.html, as
of April, 2001.
65
[2] Stardust.com "Migration from IPv4 to IPv6 for a network manager: Implementation
of the IPv4/IPv6 network address and protocol translator" Project Report, 2000
http://www.winsock2.com/ipv6/documents/v6migrate/v6migrate_30.htm, as of April,
2001.
[3] K. Yamamoto et al, 2000, "Deployment and Experiences of WIDE 6bone", WIDE
6bone Project, http://www.v6.wide.ad.jp/Papers/yamamoto/#trans, as of April, 2001.
[4] H.Y. Yeom et al, 1996, "IP Multiplexing by Transparent Port-Address Translator",
Proceedings of the Tenth USENIX System Administration Conference Chicago, IL,
USA, Sept. 29 - Oct. 4,1996.
[5] Cisco NAT-PT (IPv6/IPv4) implementation:
http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/ip6vds.htm, as of April 2001.
[6] Microsoft Research IPv6, http://www.research.microsoft.com/msripv6/msripv6.htm,
as of April, 2001.
[7] Ultima IPv6 Access, British Telecom http://ultima.ipv6.bt.com/, as of April 2001.
66