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 PlanningRutgers University, 1997

Submitted to the Department of Electrical Engineering and Computer Sciencein 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 TechnologyAll rights reserved

Signature of Author................ .......................................Department of Electrical Engineering and Computer Science

May 11, 2001

Certified by .......................................................Robert T. Morris

Assistant Professor of Computer ScienceThesis Supervisor

Accepted by ..........................Arthur C. Smith

Chairman, Committee on Graduate Studentsof Electrical Engineering and Computer ScienceMASSAC HUSETe t

JUL 11 2001

LIBRARIE

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 Sciencein June 2001 in partial fulfillment of the

requirements for the Degree ofMaster of Science in Electrical Engineering and Computer Science

Abstract:

This thesis describes the design and implementation of a general-purpose translator forIPv6/IPv4 (GT64). This translator permits address, port, and protocol translationbetween IPv4 and IPv6 address and protocol realms. Also included in this thesis is animplementation of the packet forwarding software required for IPv6.

GT64 has three principal components: an address-and-port translator and two protocoltranslators. Various combinations of these components are sufficient for translating mostreal world applications. Each is implemented as a separate Click element and can becombined in a variety of ways. A GT64 can be extended to connect with application-levelgateways (ALGs) or a DNS application-level gateway (DNSALG) when dealing withapplication-level translation or DNS lookups between different address realms. Inaddition, a GT64 can be extended to connect with other Click elements to build ClickIPv4 and IPv6 routers with translation functionality.

GT64's design is more flexible than most existing network address translationimplementations. It can be configured easily for a number of address translationscenarios, including an IPv6 local net connected with the IPv4 Internet, an IPv6 local netconnected 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 beconfigured for a variety of load balancing scenarios. Because of its modularity and easeof extension, GT64 is a powerful tool for helping the transition to the IPv6 network.

Thesis Supervisor: Robert Tappan MorrisTitle: Assistant Professor of Computer Science

2

Table of Contents

ACKNO W LEDG EM ENTS....................................................................................................................5

CHAPTER 1. INTRODUCTION ........................................................................................................... 6

1.1 IPv6 vs. IPv4 ADDRESSES.............................................................................................................61..1 IPv6 Address Architecture ................................................................................................. 6

1.1.2 IPv6 address with embedded IPv4 address............................................................................ 71.2 TRANSLATING BETWEEN DIFFERENT ADDRESS REALMS....................................................................7

1.2.1 Translating between IPv6 and IPv6........................................................................................ 81.2.2 Translating between IPv6 and IPv4........................................................................................ 8

1.3 GT64 FOR LPv6/IPv4 TRANSLATION ................................................................................................ 91.4 THESIS STRUCTURE........................................................................................................................ 10

CHAPTER 2. EXISTING NAT M ODELS .......................................................................................... 11

2.1 GENERAL OVERVIEW OF NAT M ODELS......................................................................................... 112.2 M ODELS FOR GT64........................................................................................................................ 13

CHAPTER 3. IPV6 FO R CLICK ......................................................................................................... 16

3.1 CLICK OVERVIEW .......................................................................................................................... 163.2 IMPLEMENTING IPv6 IN CLICK ....................................................................................................... 16

3.2.1 IPv6 Protocol ......................................................................................................................... 163.2.2 Address Resolution and Neighbor Discovery........................................................................ 173.2.3 ICM Pv6 Protocol ................................................................................................................... 19

3.3 A CLICK IPv6 ROUTER .................................................................................................................. 19

CHAPTER 4. DESIG N O F GT64........................................................................................................23

4.1 ARCHITECTURE.............................................................................................................................. 23

4.1. 1 Structure ................................................................................................................................ 23Figure 2b. Internal Structure of GT64 ......................................................................................... 244.1.2 Integrating GT64 into IPv4/IPv6 Click routers.................................................................... 25Figure 3a. GT64's Connection with an IPv4 Click Router............................................................ 254.1.3 Elements................................................................................................................................. 26

4.2 DISCUSSION................................................................................................................................... 274.2.1 Loss of Information during Translation............................................................................... 274.2.2 Alternatives forALGs ............................................................................................................. 274.2.3 Incorporating Hostname Lookup.......................................................................................... 274.2.4 TCP/UDP Checksum and Fragmentation Handling.............................................................. 28

CHAPTER 5. THE ADDRESS-AND-PORT TRANSLATOR ............................................................ 29

5.1 DESIGN OF THE ADDRESS-AND-PORT TRANSLATOR ....................................................................... 295.1.1 Function of the Address-and-port Translator....................................................................... 295.1.2 The IPv6 based Address-and-port Translator for IPv4/lIPv6 Translation.............................. 305.1.3 Static vs. Dynamic M apping................................................................................................. 305.1.4 Dynamic Address-only vs. Dynamic Address-and-Port Mapping .......................................... 30

5.2 CONFIGURATION............................................................................................................................ 315.3 IMPLEMENTATION.......................................................................................................................... 33

5.3.1 M apping Tables...................................................................................................................... 33Table 2a. The address-mapping table ............................................................................................ 34Table2b. out map ........................................................................................................................... 34Table2c. in map.............................................................................................................................. 345.3.2 Address Lookup and Translation.......................................................................................... 355.3.3 Address Allocation and Unbinding........................................................................................ 35

3

5.3.4 Checksum Adjustment............................................................................................................. 365.4 USING AN ADDRESS-AND-PORT TRANSLATOR FOR GT64 ............................................................. 36

CHAPTER 6. THE PROTOCOL TRANSLATORS ...................................................................... 37

6.1 DESIGN OF PROTOCOL TRANSLATORS........................................................................................... 376.2 IMPLEMENTATION.......................................................................................................................... 37

6.2.1 IP Translation ........................................................................................................................ 37Table 3. Translating IPv4 to IPv6 Headers ................................................................................... 406.2.2 ICM P Translation................................................................................................................... 416.2.3 Checksum Adjustment............................................................................................................. 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............................................................. 477.2 LOCAL IPv4 NET CONNECTED WITH THE IPv6 INTERNET ............................................................. 497.3 IPv6 PRIVATE NETWORK CONNECTED WITH THE IPv6 INTERNET ................................................. 507.4 IPv4 PRIVATE NETWORK CONNECTED WITH THE IPv4 INTERNET ................................................. 517.6 MIXED IPv6/IPv4 LOCAL NETWORK CONNECTED WITH THE IPv4 AND IPv6 INTERNET ................... 537.7 DISCUSSION...................................................................................................................................56

CHAPTER 8. PERFORM ANCE EVALUATION........................................................................... 57

CHAPTER 9. RELATED W ORK........................................................................................................59

CHAPTER 10. CONCLUSION............................................................................................................61

APPENDIX. A CLICK IPV4 ROUTER .............................................................................................. 62

BIBLIOGRAPHY.................................................................................................................................64

4

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, andtalents enhanced the quality of this research. I thank him for giving me valuable adviceand enormous help. Eddie Kohler helped me become familiar with the Clickenvironment and was always there for questions. Benjie provided help to set up theperformance test. I am very grateful to the Click team: Robert Tappan Morris, EddieKohler, Benjie Chen, M. Frans Kaashoek, John Jannotti, and Massimiliano Poletto.Thanks also to others in the Parallel and Distributed Operating System Group (PDOS) atthe MIT Laboratory for Computer Science: Jinyang Li, Charles Blake, Douglas S.J. DeCouto, Kevin Fu, Thomas Gil, and Neena Lyall. I thank following people for theirsupport: Hari Balakrishnan, Nancy Lynch, Karen R. Polenske, Xiaowei Yang, ZhaoChen, and Karen Wang.

Finally, thanks to my husband Raymond Louis Naseef and my parents Zhongli Fan andYing Huang, for their continuous encouragement, support, and love.

5

Chapter 1. Introduction

Network Address Translation is a method by which IP addresses are mapped from oneaddress realm to another. Ideally, the method is transparent to end-users. The need for IPaddress translation arises when a network's internal addresses cannot be used tocommunicate outside the network. As the Internet transitions from IPv4 to IPv6, NetworkAddress Translators (NATs) will be used as a mechanism for IPv6 hosts and routers tocommunicate with IPv4 hosts through the existing IPv4 infrastructure. In this thesis, Idescribe the design and implementation of a General-purpose Translatorfor IPv6/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 nextsection briefly introduces translation between IPv6 and IPv4. The third section thenshows how GT64 achieves the translation. The last section outlines the structure of thethesis.

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 isnow running out of address space. The Internet Protocol-Next Generation (IPng), alsoknown as IP version 6(IPv6), was designed in response to the Internet's high demand forIP 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 usedby 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 allowsan 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 soon.

The 128-bit IPv6 addressing requires changes to the IPv4 address notation. IPv4 uses theformat "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 fourhexadecimal digits represent each of the16-bit sections. However, the leading zeros ineach section can be deleted to create a more simplified format. For example, an IPv6address "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 multiplegroups of 16-bit zeros, which can appear only once in an address. Thus the aboveaddress 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 ituses an IPv6 address format to represent an IPv4 address. Two types of transitionaddresses can contain an IPv4 address within an IPv6 address. The first type is called anIPv4-compatible IPv6 address. Nodes with this type of transition address are alwaysidentified as IPv4/IPv6 or IPv6 nodes and never as IPv4-only nodes. The IPv6 transitionmechanisms [RFC 1993] include a technique for hosts and routers to dynamically tunnelIPv6 packets over IPv4 routing infrastructure. For instance, IPv4-compatible IPv6address are assigned to IPv6 nodes that utilize this technique. The IPv4-compatible IPv6address contains an IPv4 address in its lowest 32 bits and has a prefix of 96 bits of zeros,as the following shows:

80 bits 16 bits10000................................0000 10000

32 bitsIPv4 address

For instance, if an IPv6/IPv4 node has an IPv4 address as 18.26.4.1, then its IPv6 addressis ::18.26.4.1.

The second type of transition address is called an IPv4-mapped IPv6 address. It is usedto represent IPv4-only nodes, which do not support IPv6. An IPv4-mapped IPv6 addresshas the following format:

80 bits 16 bits 32 bits0000.....................................................0000 F FF IPv4 address

The lowest 32 bits of the address represent the embedded IPv4 address; therefore, IPv4-mapped IPv6 addresses can be translated to IPv4 addresses by removing the 96-bitprefix. IPv4 addresses are easily translated into IPv4-mapped IPv6 addresses by theaddition of the 96-bit prefix "::ffff'. Therefore, if an IPv4-only node has IPv4 address as18.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 primarilyinvolves making the packet addresses and protocols meaningful for nodes in the otheraddress realm. Both address realms may use the same protocol as in the case of a privateIPv6 local net connected with the IPv6 Internet. More often, they may have differentprotocols 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 localnet 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 IPv6Internet, 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 willuse the global IPv6 address "AddressX6" as the destination address. But when the packetreaches the private IPv6 net, the destination address has to be replaced by the privateaddress 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 communicatewith the outside world, a global address can be shared by several nodes by allowingtransport identifiers (e.g., TCP and UDP port numbers, ICMP query identifiers) of anumber of private nodes to be multiplexed into transport identifiers of this single globalIPv6 address. The translation mechanism uses different port numbers of the same globaladdress to represent a private host in the local network. Thus, port translation as well asaddress translation is involved. This is called address-and-port translation. It requiresaddress and port translation and related checksum adjustments at the network and upperlayers. At the transport layer, the values of the source port (or destination port) and thechecksum 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 localnetwork connected with the IPv4 Internet, then the network layer header must betranslated into the other protocol so that it can be recognized in the other realm. In thiscase, protocol translation as well as address-and-port translation is required. Protocoltranslation refers to replacing one protocol header with the other protocol header. IPv6and IPv4 have similar header formats, but with some different fields. More detail ofprotocol translation will be discussed in Chapter 6.

For instance, when a node X with an IPv6 address "AddressX6" in the private IPv6 localnet sends a packet to an IPv4-only node Y with IPv4 address "AddressY4" in the IPv4Internet, the original packet has "AddressX6" and "AddressY6"(IPv4-mapped IPv6address) as source and destination addresses. Before it arrives Y, the packet's IPv6header is replaced by a corresponding IPv4 header. Its source address is replaced by aglobal 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 localnetwork where node x resides, the packet's IPv4 header will be replaced by acorresponding IPv6 header. It will have "AddressY6" and "AddressX6" as its newsource and destination addresses.

When one protocol is translated into another, such as from IPv6 to IPv4, the transportlayer (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 theapplication layer. When the address and port are replaced during the translation for thenetwork layer and the transport layer, the payload at the application layer may need to bemodified 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 shouldallow communication between IPv6-only nodes and IPv4-only nodes. The purpose of anetwork translator is that two different types of IP nodes be able to communicate witheach other. Second, no change should be required at source or destination; all processingwill be done at the edge router or other intermediary. This allows the local network to beable to communicate with other networks with the minimum effort, since the number ofedge routers is much less than the number of end nodes. Third, the implementation ofGT64 should be easily accomplished. GT64 is implemented in the context of the Clickmodular networking system [CLICK].

GT64 separates the task of address-and-port translation from protocol translation. Theseparation eases the implementation of GT64, since each can be implemented as aseparate module in Click. GT64 uses an address-and-port translator for address and porttranslation of the packet and uses protocol translators for IPv4-to-IPv6 or IPv6-to-IPv4protocol translation. The model used by address-and-port translation ensures that GT64 iscapable of communicating between IPv6-only and IPv4-only hosts without changing endnodes. The protocol translation follows the RFC standards [RFC 2765]. Together theyprovide the most appropriate combination the our system solution.

The address-and-port translation is IPv6-based, i.e., it only maps between IPv6 addressesand ports. However, GT64 must be able to map between IPv6 and IPv4 addresses inorder to work with IPv6/IPv4 translation scenarios. The address-and-port translation cantranslate between normal IPv6 addresses and IPv4-mapped IPv6 addresses for IPv6/IPv4translation. The protocol translation can translate between IPv4-mapped IPv6 addressesand IPv4 addresses. Thus, an IPv6 address can go through the address-and-porttranslation 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 IPv4address in a packet can be mapped back to an IPv6 node by going through the JPv4 toIPv6 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 orsourced from a different address realm pass by, the edge router should pass the packetsthat need to be translated to the host in which GT64 resides. GT64 then emits thetranslated packets to appropriate routers that will direct the packets to the destinationaddress realm. If GT64 is in the edge router, the above transportation of the packets willoccur within the edge router.

Furthermore, GT64 can also be integrated into more complex Click IPv4 and IPv6 routerswithin 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 byintroducing different models for NATs with emphasis on models used by GT64. Chapter3 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-porttranslator, as well as the protocol translators. Chapter 7 illustrates how GT64 can be usedin a variety of translation scenarios. Chapter 8 analyzes the performance of GT64 anddescribes a set of applications that have been tested, and Chapter 9 surveys related workon 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 orderto find the most appropriate models for GT64. Each model has its advantages anddisadvantages. The criteria for selection follow the three goals of GT64 mentioned insection 1.3. Section2.1 presents a general overview of six NAT models. Those modelsare interesting, but do not satisfy GT64's requirements. However, they provide certaininsights about network translation. Section 2.2 identifies two models that have thefeatures 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 IPv6host so that all IPv6 nodes are dual-stacked, i.e., they provide complete support for bothIPv4 and IPv6 in hosts or routers. The dual stack nodes must have DNS resolverlibraries 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 doesnot allow communication between IPv6-only nodes and IPv4-only nodes.

In the Limited Dual Stack Model [NAT-INTRO], only "server nodes" (nodes hostingInternet 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 areneeded, this model does not allow communication between IPv6-only and IPv4-onlynodes.

Dual Stack Transition Mechanism (DSTM) [DSTM] mainly targets the communicationbetween a newly deployed IPv6 network and the existing IPv4 networks. All IPv6 nodesin the DSTM network are dual-stacked. DSTM assigns temporary global IPv4 addressesto dual stack hosts during the communication between an IPv4/IPv6 host and an IPv4-only host. DSTM also requires that the host can perform dynamic tunneling of an IPv4packet inside an IPv6 packet to suppress the exposure of IPv4 native packets within aDSTM domain of an IPv6 network. Each IPv6 DSTM host has an IPv4 interface calledthe Dynamic Tunneling Interface (DTI), which encapsulates IPv4 packets inside IPv6packets.

The DSTM IPv6 host obtains the temporary global IPv4 addresses from DHCPv6 serverin the IPv6 DSTM network. The DHCPv6 server provides the assignment of IPv4 globaladdresses to IPv6 hosts and maintains the mapping between the allocated IPv4 addressand the permanent IPv6 address of the host. If an IPv4 host wants to initiate acommunication 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 atemporary 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 thedual stack host to assign that temporary IPv4 address. Like the above two dual stackmodels, this model does not work for communication with IPv6-only hosts.

SOCKS-based IPv6/IPv4 Gateway (SOCKS64) [SOCKS-GATE] is a gateway systemthat is based on the SOCKS protocol [SOCKSv5]. It relays two "terminated" IPv4 andIPv6 connections at the "application layer" (the SOCKS server). Especially for"socksified" sites, which already use SOCKS-aware clients and a SOCKS server, theSOCKS64 gateway provides an easy way to let IPv4 hosts connect to IPv6 hosts.SOCKS64 has advantages such as no DNS modifications, no address mapping. Inaddition, it provides security insurance on two "terminated" connections at the"application layer"[RFC 1928]. The end-to-end security is maintained at each of therelayed connections (i.e., between Client C and Gateway G, and between Gateway G andDestination D). However, SOCKS64 has the main problem that client nodes must be"socksified", which is not desirable for the end hosts. Furthermore, SOCKSv5 doesn'tprovide network-layer gateway services (e.g. ICMP messages).

The Transport Relay Translator (TRT) [TRT] enables TCP and UDP communicationsbetween IPv6 hosts and IPv4 hosts. A TRT system, which is located between an IPv6-only host and an IPv4-only host, translates TCP/IPv6 to TCP/IPv4, UDP/IPv6 toUDP/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), itneeds to make an TCP/IPv6 connection to C6::X4, an IPv6 address with a special form-TRT dummy prefix (C6::/64) plus the destination IPv4 address (X4). The routinginformation in A6 has been configured so that packets to C6::/64 are routed to the TRTgateway, whose IPv6 address is B6. The TRT gateway accepts the TCP/IPv6 connectionbetween A6 and C6::X4 and communicates with the initiating host, using TCP/IPv6. Italso obtains the real IPv4 destination address from the lowermost 32 bits of thedestination address (IPv6 address C6::X4). A protocol translator, which is installed at theTRT, does IPv6-to-IPv4 protocol translation for the packet. The TRT, whose IPv4address is Y4, then connects to X4, using TCP/IPv4, and forwards the traffic across thetwo TCP connections. UDP traffic can be relayed in the same fashion as TCP. As seen inthe 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 ahostname by a special DNS server implementation, by the static address-mapping tableon the initiating host, or by a modified DNS resolver implementation on the initiatinghost.

12

Destination host|X4=====outer network

|Y4TRT System ---dummy prefix (C6::/64)

1B6+=+ inner networkJA6

Initiating host

The TRT has advantages, such as no extra modification on end hosts and no need to takecare 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 communicationpeers because the TRT is a stateful system -it retains state of a packet and updates it whenother packets belong to the same flow arrives. Furthermore, it is difficult to implement inClick, 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 capableapplications on an IPv4 host to communicate with IPv6-only hosts. The Bump-in-the-Stack can be viewed as a particular implementation of the Network Address Translation -Protocol Translation (NAT-PT) model within the IP stack of an IPv4 host. Added to theIPv4 stack are three modules that intervene between the application and the network: anextension to the name resolver, an address mapper, and a translator. The main idea is thatwhen an IPv4 application needs to communicate with an IPv6-only host, the IPv6 addressof the IPv6-only host is mapped into an IPv4 address out of a pool that is local to the dualstack host. The IPv4 packet generated for the communication is translated into an IPv6packet before the dual-stack host sends it out to the network. This model requires that theIPv4 host is dual-stacked.

The Stateless IP/ICMP Translation Algorithm (SIIT) protocol [RFC 2765] describes amethod to translate between IPv6 and IPv4 protocols. Translation is limited to the IPpacket header. The protocol does not describe a method for assigning a temporary IPv4address to the IPv6 node. Therefore, SIIT needs to be combined with mechanisms thatdeal with IPv4 address allocation for IPv6 nodes. The translator operates in a statelessmode, 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 tostateful system such as TRT.

2.2 Models for GT64

Among the above seven models, most of them, i.e., Dual Stack Model, Limited DualStack Model, Dual Stack Transition Mechanism, and Bump-in-the-Stack Model, needend hosts to be dual-stacked. SOCKS64 requires "socksification" of end hosts. Thoughthe 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 followsthe protocol translation guideline of the SIIT, demonstrates the desired features for GT64.

Network Address Translation - Protocol Translation (NAT-PT) [RFC 2766] addressesthe communication between IPv6-only and IPv4-only hosts, which is realized by the useof a dedicated device that translates between IPv4 and IPv6 addresses. Since there islimited IPv4 address space, the NAT-PT device keeps "state" during each session to trackactive flows so that it can dynamically allocate its address space to requested flows. TheNAT-PT uses SIIT for protocol translation and includes an application layer gateway tomake 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 ofIPv6 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 sameNAT-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; itsimply can not translate everything in the packet since the fields in different protocols donot exactly match. For instances, fields such as Flow Label and Priority in the IPv6header 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 ofthe network layer is not possible. Finally, the NAT-PT can not be deployed incombination with secure DNS, because IPv6 DNS can not sign replies to queriesoriginated 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), andUniversity 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-and-port translation and protocol translation into two modules. One module is an IPv6-basedaddress-and-port translator that allows a set of IPv6 hosts to share a single IPv6 addressby multiplexing the transport identifiers of IPv6 hosts to the transport identifier of asingle assigned IPv6 address. This module uses IPv6-based NAT-PT and excludes theprotocol translation from the NAT-PT. The other module is for protocol translation andit has two elements: Protocol Translator for IPv6 to IPv4 (PT64) and ProtocolTranslatorfor IPv4 to IPv6 (PT46). Both protocol translators follow the SIIT fortranslation.

GT64 can be combined with ALGs (for application level translation) and a DNSALG(for DNS packets' address mapping) to provide the most appropriate solution forcommunication 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 anIP/TCP/FTP packet, because the FTP_ALG will deal with the modification of theaddresses in the payload. Since GT64 is implemented in Click, the next chapter describesthe related implementation - IPv6 for Click. Following that, Chapter 4 presents a detaileddesign 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], asoftware architecture for building flexible and configurable routers. Modules, calledelements, which implement simple router functions, process packets. A routerconfiguration is a directed graph with elements at the vertices; packets follow along theedges of the graph.

The components of GT64 are constructed as individual Click elements. GT64 isassembled from components that are configured differently for different translationscenarios. Not only can it be used alone, but GT64 can be incorporated with other Clickelements to build configurable routers with translation functions.

In order to translate between IPv4 and IPv6, the router should be able to handle IPv6packets as well as IPv4 packets. Therefore, part of this thesis was the implementation ofIPv6 elements for Click. The next section briefly introduces the implementation of IPv6,ICMPv6, and Neighbor Discovery Protocol in Click. Section 3 presents a basic ClickIPv6 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 maintaincurrent IPv4 functionality while eliminating its limitations. IPv6 features includesecurity, quality of service, efficiency, growth, flexibility and reliability, most of whichare closely related with the use of the IPv6 option mechanism.

The option mechanism of IPv6 improved over that of IPv4. IPv6 options are placed inseparate extension headers located between IPv6 header and transport-layer header in apacket. Not all IPv6 extension headers need to be examined or processed by routersalong a packet's delivery path. However, in IPv4, the presence of any options requires therouter to examine all options. Thus IPv6 dramatically improves router performance forpackets containing options. Another advantage is that the IPv6 extension header can be ofarbitrary length as long as it can be kept as an integer multiple of 8 octets to retain thealignment for subsequent headers. In contrast, IPv4 limits the total number of optionscarried in a packet to 40 bytes. Currently, IPv6 extension headers include routing,fragmentation, authentication, security encapsulation, hop-by-hop option, and destinationoptions. Below is shown the format of an IPv6 header and an IPv6 fragment header.

16

IPv6 Header0 31

Version I Class Flow LabelPayload Length Next Header Hop Limit

Source Address

Destination Address

IPv6 Fragment Header0 31

Next header Reserved Fragment Offset FlagsFragment Identifier

Since the router is not required to process options, the implementation of an IPv6 Clickrouter is simplified. This project has implemented several elements that can forward andcheck IPv6 packets. These elements check the validity of the packets' header, decreasethe hop limit and discard the packets if the hop limit is zero, and fragment packets if theyare too long. Most importantly, they can route the packets to the next hop by looking upthe 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 hardwareMAC addresses. The Neighbor Discovery protocol (ND) performs the same functionalityfor IPv6.

3.2.2.1 Neighbor Discovery Protocol

IPv6 nodes on the same link use ND to discover each other's presence and to determineeach other's link-layer address, to find routers, and to maintain reachability informationabout active neighbors. The Neighbor Discovery protocol is a synthesis of several IPv4protocols in IPv6: the Address Resolution Protocol (ARP) [RFC 826], ICMP RouterDiscovery (RDISC) [RFC 1256], and ICMP Redirect messages [RFC 792].

The Neighbor Discovery protocol defines mechanisms for solving a set of problemsrelated to the interaction between nodes attached to the same link. This thesis includes animplementation of the mechanism that deals with only address resolution, i.e., how anode determines the link-layer address of a neighbor given only the destination IPaddress.

17

ND uses ICMPv6 messages to communicate. A Click IPv6 router sends out a neighborsolicitation message if it wants to determine a link-layer address of an IPv6 address. Itcan also send out a neighbor advertisement message when it wants to advertise the link-layer address of some IPv6 address or to reply to a solicitation message. The followingfurther explains the format of the neighbor solicitation messages and neighboradvertisement messages.

3.2.2.2 Neighbor Solicitation Messages

Nodes send neighbor solicitation messages to request the link-layer address of a targetnode while also providing their own link-layer address to the target. Neighborsolicitation messages are multicast messages when the node needs to resolve an addressand unicast messages when the node seeks to verify the reachability of a neighbor.Neighbor solicitation messages have the following format:

0 31Type Code ChecksumReserved

Target Address

Options...

3.2.2.3 Neighbor Advertisement Messages

Nodes send neighbor advertisement messages to advertise the link-layer address of someIPv6 addresses. A neighbor advertisement message is a response to a neighborsolicitation message. Nodes may also send unsolicited neighbor advertisements toannounce a link-layer address change. Neighbor advertisement messages have thefollowing format:

0 31Type Code ChecksumR S 0 Reserved

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 alsoabsorbed the revised Internet Group Membership Protocol (IGMP) [RFC 1112]. IPv6nodes use ICMPv6 to report errors encountered in processing packets, and to performother 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 isused to create an additional level of message granularity. The checksum is used to detectdata corruption in the ICMPv6 message and parts of the IPv6 header. Every ICMPv6message is preceded by an IPv6 header and zero or more IPv6 extension headers. TheICMPv6 header is identified by a Next Header value of 58 in the immediately precedingheader. The following shows the general format of an ICMPv6 message:

1 31Type Code Checksum

Message Body ...

ICMPv6 messages have two groups: error messages and informational messages. Thisthesis project has implemented an ICMP6Error element to create all types of ICMPv6error messages. In addition, the Click IPv6 elements are able to deal with four types ofICMPv6 informational messages: Echo Request, Echo Reply, Neighbor Solicitation, andNeighbor 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 arequite 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-purposeClick 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 notrequire 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 IPv6router, 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 theIPv6 elements used in Figure 1. In Click, the elements take actions based only on thecontent of a packet. For instance, if a packet's Hop Limit has expired, a DecIP6Hlimelement will direct the packet to the output that deals with the error (which is usuallyconnected to an ICMP6Error element); otherwise, it will decrement the Hop Limit anddirect the packet to the normal output.

A LookupIP6Route element uses a list of the router's addresses and the broadcastaddresses of all interfaces to decide which packets are addressed to the router itself andwhat interface the packet should be sent to if the packet is to be forwarded. ACheckIP6Header element checks the validity of the IPv6 source address. AnIP6Fragmenter element fragments packets larger than the configured MTU, but sendstoo-large packets that are marked unfragmentable to an error output instead. AnICMP6Error element accepts invalid input packets, encapsulates them within an ICMP6error message and emits the result.

20

FromDevice(eth) s

Classifter(...)

IP6NDSolicitation IP6NDAdvertisement

IP6NDAdvertiser

to Queue

toIP6NDSolicitor

to IP6NDSolicitor

Strip(14)

CheckIP6Header(...)

GetIP6Address(24)

I I

DropBroadCasts

HopLimitxpired

ICMP6ErrorIPurragment(... Must fragment

L

from Classifier

IP6NDSolicitor(...)

FToDevice(eth 0)

V

'Route( ... )

to Linux

DropBroadCasts

DeclP6Hlim lCMP6ErrorHopLimitE xpired

ICMP6ErrorIruvragment(... Must fra gment

L

from Classifier

IP6NDSolicitor(...)

ToDevice(ethl)

Figure 1. A Two-Interface IP6 router Configuration

21

FromDevice(ethln)

Classifter(...)

IP6 IP6NDAdvertisement

IP6ND-

Advertiser

to Queue

I

I

I I

Table 1. IPv6 router element glossary

New IPv6 Elements DescriptionIP6NDSolicitor First input takes IPv6 packets, second input takes neighbor(IP6Address, advertisement messages with Ethernet headers. Output emitsethernetAddress) neighbor solicitation messages and IPv6-in-Ethernet packets.

Uses ND to find the Ethernet address corresponding to each inputIPv6 packet's destination IPv6 address annotation; encapsulatesthe packet in an Ethernet with that destination Ethernet address.

IP6NDAdvertiser Input takes neighbor solicitation messages, output emits Neighbor(IP6addressl mask] Advertisement messages. Responds to neighbor solicitationethi, ... ) 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 tooutput 0.

GetIP6Address Input takes IPv6 packets. Copies the IPv6 header's destinationaddress field (offset 24 in the IPv6 header) into the destinationIPv6 address annotation; forwards packets unchanged.

ICMP6Error Input takes IPv6 packets, output emits ICMPv6 error packets.(type, code) Encapsulates first part of input packet in ICMPv6 error header

with source address ip6, error type type, and error code code.LookuplP6Route(...) 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 theconfiguration string. Forwards each packet to the output portspecified in the resulting routing table entry; sets its destinationannotation to the resulting gateway IPv6 address, if any.

Existing Click DescriptionElementsClassifier(...) Input takes any packet, examines packet data according to a set of

classifiers, one classifier per output port. Forwards packet tooutput port corresponding to the first classifier that matched.

DropBroadcasts Input takes any packet. Discards packets that arrived as link-levelbroadcasts; forwards others unchanged.

Discard Discards all input packets.FromDevice(device) No inputs. Sends packets to the single output as they arrive from

a Linux device driver.Queue(n) Input takes any packet. Stores packets in a FIFO queue;

maximum queue capacity is n.ToDevice(device) Input takes Ethernet packets; no outputs. Hands packets to a

Linux driver for transmission.ToLinux Input takes Ethernet packets; Linux will ignore Ethernet header

except for the protocol field. No outputs. Hands packets toLinux's default network input software

22

Chapter 4. Design of GT64

This chapter presents the design of GT64. The first section describes the architecture andintroduces the elements of GT64; next, it shows how those elements form a completeGT64 for different translations and how GT64 can be incorporated with Click routers.The second section discusses limitations, such as loss of information during protocoltranslation. It also addresses some other issues when designing translators for IPv6/IPv4translation, such as alternatives for ALGs, incorporating hostname lookup ability, andTCP/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 andIPv6. Click IPv6 or IPv4 router elements can recognize IPv6 or IPv4 packets that needtranslation and direct them to GT64. After translation, GT64 outputs updated packets toClick IPv6 or IPv4 router elements for further processing.

GT64 has three basic elements (Figure 2b): an address-and-port translator (APT) and twoprotocol translators. One protocol translator translates from IPv6 to IPv4 (PT64) and theother translator translates from IPv4 to IPv6 (PT46). GT64 achieves flexibility andmodularity by splitting translation functionality into individual elements so that address-and-port translation is separated from protocol translation.

Assume that an IPv6-only node in the local net wants to communicate with an IPv4-onlynode in the Internet. Once the IPv6 Click elements recognize that the packet is destined toan IPv4-only node, they send the packet to GT64. The packet will be translated into anIPv4 packet, output to the IPv4 Click elements, and then routed to the IPv4-onlydestination node. Inside of GT64, the IPv6 packet is translated into an IPv4 packet viaseveral steps. First, APT translates the source address into an IPv4-mapped IPv6 address.Then, PT64 transforms the updated IPv6 packet into an IPv4 packet. In short, the packetin 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 workwith any IPv6-IPv4 related translation scenario by providing different paths for flows thatconnect different types of nodes and require different translations.

23

IPv4/IPv6Internet

INv6/v4local net IPv4 and IPv4 and

IPv6 GT64 1Pv6Host A aC lik Click Host B

other otheroutine outine

ApplicationLevel Gateway

Figure 2a. GT64 in use for translation scenarios between a IPv4/IPv6 local net andthe IPv4/IPv6 Internet

24

Packetsdestined tothe Internetand sourcedfrom thelocal net

Packetsdestined tothe local netand sourced

from t

Packets destined tothe Internet andsourced from thelocal net

_Packets destined tothe local net andsourced from theInternet

PT46 PT64- A

APTPT64 4__PT46

Pacet 'Paket dstne6tFigure 2b. Internal Structure of GT64

4

Splitting address and port translation from protocol translation lends modularity andflexibility to GT64. Some translation scenarios (IPv6/IPv4 network translations) involveboth address-and-port and protocol translations. Other translation scenarios involve onlyaddress-and-port translation (e.g., GT64 for an IPv6 private network connected with theIPv6 Internet) and related checksum adjustments. In these cases, only APT is on thetranslation path of GT64. If address-and-port and protocol translations were notseparated, 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 elementsto build modular and flexible routers with NAT functionality. The Click IPv6 routeroutputs an IPv6 packet that needs to be translated to GT64 via an output of theLookupIP6Route element. GT64 then directs the translated IPv4 packet to the IPv4 Clickrouter, which processes the packet as a normal IPv4 one. Similarly, the IPv4 routeroutputs an IPv4 packet that needs to be translated to GT64 via one of the outputs of theLookupIPRoute element. GT64 then sends the translated IPv6 packet to the IPv6 Clickrouter.

ToIPv6 Router 4 .

TranslatedIPv6 Packets:

GT64 4..........

IPv4 packets tobe translated to IPv6

IPv4 packets from Classifiers

Strip(14)

Translated IPv4Packets from theGT64

CheckIPHeader(...)

fmGetIPAddress(16)

LookupIP~ot(.

Figure 3a. GT64's Connection with an IPv4 Click Router

25

I

I

IPv6 packets from Classifiers

Strip(14)

; ........._................_ .....

CheckIP6Hleader( ...)

GetIP6Address(24)-01

ToIPv4 Route . .

TranslatedIPv4 Packets!

G T64 ..........

Translated IPv6Packets from theGT64

................... ..... .................

LookpIP6Route(..._ML M

IPv6 packets tobe 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 itperforms network address and port translation. APT maintains records for active flows.As packets arrive, APT uses their flow identification to find the corresponding mappingsand translates the addresses and ports accordingly. When no mappings are found, APTcreates new mappings by following certain rules. APT always translates between IPv6address and ports of two different IPv6 address realms.

GT64's two protocol translators - PT64 and PT46 - perform packet translation betweenIPv4 and IPv6 protocols as well as between ICMPv4 and ICMPv6 protocols. The IPv6and IPv4 headers are similar, but do not exactly match. Adjustments need to be madewhen translating from one version of IP or ICMP to the other. PT64 only accepts IPv6packets with IPv4-mapped IPv6 addresses; PT46 only accepts IPv4 packets. Since thereis 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 twoprotocols. Therefore, when an IPv6 or ICMPv6 packet arrives, PT64 will translate it toan IPv4 or ICMPv4 packet by simply taking the lowest 32 bits of the IPv6 address astranslated IPv4 address for source or destination. When an IPv4 or ICMPv4 packetarrives, PT46 will translate it to an IPv6 or ICMPv6 packet. It will simply translate IPv4source or destination address to an IPv4-mapped IPv6 address by adding the 96-bitprefix.

26

4.2 Discussion

4.2.1 Loss of Information during Translation

The loss of information during translation is one intrinsic shortcoming of a networktranslator that translates between two different protocols. There are fields of IPv6 andIPv4 protocols that can not be translated simply because there are no corresponding fieldsin the other protocol that can carry the information. Those fields, for instance, the Typeof Service (TOS) field of the IPv4 header, have to be ignored when an IPv4 packet istranslated to an IPv6 one. The Class, Flow Label, and Reserved fields of IPv6 Headerand IPv6 Fragment Header have to be ignored as well when an IPv6 packet is translatedto an IPv4 one. Any network translator will have to face this structural shortcoming whentranslating between different protocol realms.

4.2.2 Alternatives for ALGs

GT64 can translate for packets of most protocols. However, when there are protocolsthat carry the IP address and port information in their payload, ALGs need to bedeveloped and used with GT64 to achieve complete translation. For instance, an ALGfor the FTP protocol would be able to do a complete translation for an IP/TCP/FIPpacket by updating values of the addresses and ports in the payload so they are consistentwith 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 areIPv4-aware, e.g., FTP, can detect whether the connection is with an IPv6 or IPv4 versionof the ftp daemon. When communicating with an IPv4 ftp daemon, it needs to use anIPv4 address instead of the host's original IPv6 address. Conversely, if an IPv4 ftp clientcontacts an IPv6 ftp daemon, the daemon must treat the IPv4 address in the payload as anIPv4-mapped IPv6 address. Therefore, the network address-and-port translator oftendoes not need to update IP addresses in the application payload. If all applications thatembed IP addresses did their own address translation in this way, then there would be noneed 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 somemechanism that has DNS lookup ability, since some applications require that a host firstlook up another host's address before initiating a session with the other host. The IPv6site's DNS server should be an IPv6/IPv4 node so it can forward DNS request frominternal IPv6 hosts to external IPv4 DNS servers. Since each IPv4 node has a unique IPv6address (either IPv4-mapped IPv6 address or IPv4-compatible IPv6 address), each "A"record has a corresponding "AAAA" record listed in the DNS. If an IPv6 host tries toinitiate 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 hasan "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, thelocal DNS server will communicate with the IPv4 world to get an "A" record, translate itto 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 moredifficult. 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 severalapproaches that translate an IPv6 DNS record to an IPv4 DNS record. First, the resolverlibrary in IPv4 nodes can be modified to request the alias (a temporary IPv4 address forthe IPv6 node) from GT64. Second, the IPv6 site's DNS server can be modified torequest a temporary address from GT64 on behalf of its IPv4 clients. The third approachrequires GT64 to recognize DNS request and response packets and to translate themtransparently. For a detailed description of DNS extension for network addresstranslators, please refer to [RFC 2694].

While the first two approaches involve modifying end nodes, which is not completelytransparent translation, the last approach fits in the design of GT64. It can be done in aDNSALG. 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 andpayload. 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 protocoltranslation.

Currently, GT64 drops all packets with IPv6 extension headers, including the IPv6fragment header. GT64 doesn't deal with translation for IPv6 or IPv4 fragment packetsbecause it calculates checksums directly from the packet content. GT64 can evaluate thechecksum only when all the fragment packets are assembled into a single one. CurrentlyGT64 ignores both IPv4 and IPv6 fragment packets.

This project does not deploy the incremental checksum adjustment algorithm forchecksum calculation, which can correctly reflect the change of address and port, evenfor fragmented packets. As soon as the incremental checksum adjustment algorithm isimplemented, 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.1introduces 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 theAPT mapping tables and the processes of address lookup, address binding, addressunbinding, and checksum-updating. Section 5.4 describes how the APT can be used byGT64.

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 totemporarily 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 onlyone global address, each individual connection can be temporarily allocated with adistinct address-and-port pair so that these internal nodes can share the same globaladdress. For instance, an IPv6 local network usually only has a few IPv4-mapped IPv6addresses available when communicating with the global IPv4 Internet, while there arefar more internal nodes. APT resolve the resource limit by letting a set of local IPv6 hoststo share a single IPv4-mapped IPv6 address, i.e. the transport identifiers of these internalIPv6 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 forpackets that are destined to outside world. This function of APT is called address-and-port translation.

APT decides how to allocate such temporary address-and-port pairs for outgoingconnections. Moreover, it remembers the allocations and always replaces the internalsource address-and-port with the same mapped address-and-port pair for packets of thesame flow. Here, if two packets have the same identifiers, i.e., source address, sourceport, 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' destinationaddress-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 themapped flow ID. The mapped flow ID uses some other address-and-port pair to replacethe 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 thereplacement is conducted. In addition to the dynamic address-and-port allocationdescribed 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 isusually 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 withmappings. Outward packets are those packets that originate from the local network anddestined to some host on the Internet (IPv4 or IPv6), while inward packets are thosepackets that originate from the outside world and destined to some host in the localnetwork. APT has two inputs and two outputs. It accepts outward and inward packetsfrom 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 towork for IPv4/IPv6 translation scenarios, GT64 temporarily allocate IPv4 addresses tointernal IPv6 hosts when they communicate the IPv4-only hosts. The IPv6-based APTachieves this by assigning IPv4-mapped IPv6 addresses for the internal IPv6 hosts.

When GT64 translates an IPv6 packet to an IPv4 packet, APT first maps the source ordestination IPv6 address and port to an IPv4-mapped IPv6 address and a port. PT64 thentranslates the IPv6 packet to an IPv4 packet and translates the IPv4-mapped IPv6addresses to IPv4 addresses.

When GT64 translates an IPv4 packet to IPv6, PT46 maps IPv4 addresses into IPv4-mapped IPv6 addresses for the packet. APT then maps the source or destination IPv4-mapped 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 portsstatically as well as dynamically, called static mapping or dynamic mapping functionsrespectively. Static mapping refers to the static relationship between internal address-and-port pairs and the mapped address-and-port pairs. In most case, static mapping is usedfor address-only mapping, i.e., certain external addresses will be reserved for particularinternal addresses. Contrary to the static mapping, dynamic mapping only keepsmappings 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 theaddress-port pairs dynamically. APT will then use the mapped address to represent theinternal node to communicate with the outside world. As we described above, dynamicaddress-and-port mapping replaces the original flow ID with the mapped flow ID that hasa different address-and-port pair for either source or destination. However, dynamicaddress-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 withthe mapped global address; for an inward packet, it replaces the destination address withthe 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 rulesfor both static mapping and dynamic mapping. The arguments of a configuration stringare separated by commas, as illustrated by Figure 4a. Figure 4b shows an example of anAPT configured for a local IPv6 net connected with the IPv4 Internet. The APT isconfigured for static address mapping and dynamic address-and-port mapping.

First, the configuration string specifies the number and rules of static mapping. The firstargument is the number of staticMappings. The second argument staticPortMapping isa boolean which indicates whether or not APT does static port mapping. In Figure 4b, thefirst argument number_ofstaticMappings has the value "1", which means one staticmapping exists. The second argument staticPortMapping has "0" value which states thatAPT will do address-only mapping for static translation.

APT (number-ofstaticMappings,staticPortMappingStaticMappingl,...StaticMappingm,dynamicMappingdynamicPortMapping,addressAllocationDirection,Mapped_IP6Addressl,Mapped_IP6Address2,

MappedIP6Addressn)

APT (numberofstaticMappings,staticPortMappingStaticMapping],...StaticMappingm,dynamicMappingdynamicPortMapping,addressAllocationDirection,MappedIP6Address Portstart Portend)

Figure 4a. Format of a Configuration String for an APTNote: 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 mappingand 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 staticPortMapping are the detailed static mappings, as expressed bystaticMappingl, ... , staticMappingm. Those m arguments correspond to m staticmappings where m is specified by number ofrstatic.Mappings. Depending on thestaticPortMapping value, each static mapping can have either two strings or four strings.If the value of the staticPort Mapping is "0", i.e., static address-only mapping, theargument should have two strings, an internal and an external IPv6 address. If the valueof the staticPortMapping is 1, i.e., static address-and-port mapping, the argument hasfour strings: the internal IPv6 address and port of the node, and the mapped IPv6 addressand port for that node.

In Figure 4b, APT statically maps the internal address 3ffe: Icel:2::1 to the externallyvisible 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 withthe address 3ffe:lcel:2::1.

Second, the configuration string indicates whether there are any dynamic mappings andthe rules for dynamic mapping. The argument dynamicMapping uses a boolean value toindicate whether or not APT does dynamic address mapping. If the value is "1", APTtakes more arguments which specify dynamic mapping rules. The following argumentdynamicPortMapping decides if APT doe dynamic address-and-port mapping or dynamicaddress-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 multiplexedamong several active flows.

Furthermore, the argument addressAllocationDirection decides when APT can allocate anew mapping, i.e., whether or not to allocate a new mapping when a packet without amapped entry passes by. The addressAllocationDirection has two values: 1(inward) and0 (outward). If the configuration is not specified, the outward direction is the defaultdirection. Address translation scenarios for local networks to the outside world willdesignate the addressAllocationDirection as 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 fromthe outside. Load balancing tries to distribute the load on one web address to severalinternal nodes. GT64 for load balancing serves flows initiated from outside. The inwardaddressAllocationDirection allows APT to allocate mappings for those flows.

Finally, the configuration string indicates the range of dynamically allocatable globalIPv6 addresses and ports. If dynamic mapping does not have a dynamic port mappingfunction, the remaining arguments are IPv6 addresses. With dynamic address-and-porttranslation, the remaining argument is a triplet (Mapped IP6Address PortstartPort -end). It indicates an IPv6 address and the range of ports (Port-start to Portend)that can be allocated when an active flow passes the APT. A set of private or local IPv6hosts can share a single global IPv6 address by multiplexing the port of a single assignedIPv6 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 IPv6address ::18.26.4.116 are available to be allocated to internal nodes for communicationwith the outside world. Since there are 10 combinations of address-and-port pairs, theAPT 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-portmapping of flows. The address-mapping table serves for static address and dynamicaddress-only mapping. APT uses tables called inmap and out-map for dynamicaddress-and-port mapping. This table-driven APT is the core of GT64. Theconfiguration string determines primarily how to set up the mapping tables.

The example below shows an APT configured for static-address mapping and dynamicaddress-only mapping. It only needs an address-mapping table. Not all of the tablefields (See Table 2a) need to be filled with values in order to be a valid entry. A staticentry (value of staticMapping field is 1) follows the static mapping rules. A dynamicentry (value of staticMapping field is 0) follows the dynamic mapping rules. Forinstance, entry 2 shows a dynamic binding of an active flow that has source address3ffe: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 lastAccessTime staticMapping internal globalState Address Address

Entryl 1 1 3ffe:1ce1:2::1 ::18.26.4.115Entry2 1 2:23:45.156732 0 3ffe:lcel:2::3 ::18.26.4.116Entry3 0 0 ::18.26.4.117

Entry5 0 0 ::18.26.4.119

" bindingState:

" lastAccessTime:

" staticMapping:

" internalAddress:" globalAddress:

only for dynamic address-only mapping: whether or not theglobal address has been allocated to (bound with) aninternal node (1: bound, 0: unbound)only for dynamic address-only mapping, record last timethat packets come from (or destined to) the internal addresspass the APTindicates whether the entry is a static address-mapping ordynamic address-only mappinginternal host IPv6 addressmapped global IPv6 address

For dynamic address-and-port mapping, APT uses two other tables - out-map andin-map - to track all active flows. The tables start out empty after configuration. Theygrow when there are dynamic address-and-port allocations. They shrink when idle entriesare deleted from the tables. Each entry of the dynamic mapping table contains anoriginalFlowID and a mappedFlowID, and the lastAccessTime. The following shows anAPT configured only for dynamic address-and-port mapping. Table 2b and Table 2cshow 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 mapField LastAccessTime originalFlowID mappedFlowIDEntryl ... (3ffe:lce1:2::4, 2600 , (::18.26.4.116, 6001,1 _1_1_::18.97.2.126, 25) ::18.97.2.126, 25)

Table2c. in mapField LastAccessTime originalFlowID mappedFlowID

EntryI ... (::18.97.2.126, 25, (::18.97.2.126, 25,::18.26.4.116, 6001) 3ffe:IceI:2::, 2600)

34

5.3.2 Address Lookup and Translation

If the APT is configured for dynamic address-only mapping, then when an outwardpacket arrives, APT looks for the entry that has the internal address the same as thepacket's source address. When an inward packet arrives, the APT looks for an entry thathas the internal address the same as the packet's destination address. Both searches occurin the address-mapping table.

If the APT is configured for dynamic address-and-port mapping, then when an outwardpacket arrives, APT looks for the entry whose originalFlowID is the same as the packet'sflow ID in the out-map. For an inward packet, APT looks for the entry whoseoriginaiFlowID is the same as the packet's flow ID in the inmap. In the previousexample, if an inward packet with destination address ::18.26.4.116, port 6001 and sourceaddress ::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-mapand return a mapped flow ID (::18.97.2.126, 25, 3ffe:Ice1:2::4, 2600). APT thentranslates the destination address to 3ffe:icel:2::4, destination port to 2600.

5.3.3 Address Allocation and Unbinding

The addressAllocationDirection specifies when the APT can allocate a mapping if apacket without a mapped entry passes by. The addressAllocationDirection in theprevious example is outward. Thus, if there is no matching entry, APT will try toallocate 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 unboundentry in address-mapping table and bind that entry with the packet's source address if thepacket is outward. The binding involves setting the value of the field internalAddress tothe packet's source address, setting the bindingState to bound, and recording current timein the lastAccessTime field in the address-mapping table.

If APT is configured as dynamic address-and-port mapping, mapping allocation involvesthe following steps for an outward packet, assuming addressAllocationDirection isspecified as outward. APT always first looks up in the outmap table. If no matchingentry is found, APT will to find a free port, a port that no active flows in the inmap orout-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 thefree port, and da and dp refer to the destination address and port of the packet. APTadds the entry with the new mapped flow ID to the outmap, where the search key is thepacket'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 flowID.

35

Still using the previous example shown in Table 2b and Table 2c, assuming a packet withsource 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 theout-map by using the flow ID (3ffe:lcel:2::4, 2600, ::18.97.2.126, 25). Since this is anoutward 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 thisnew flow. It then adds the mapped flow ID to the out__map, which corresponds to thesearch 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 IPv4Internet), destination address ::18.97.2.128, port 79 arrives, APT will find no matchingentry in the in-map table, thus discard the packet.

In order to make dynamic address translation efficient, the APT unbinds entries ofinactive flows. In address-mapping table, an entry's binding state (bindingState) will bereset 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 todetermine which entry could be deleted when all the mapped ports are used up for theactive flows. In future, TCP packets, FIN flag may be used as recognition fordeactivating a finished connection. The process of unbinding allows entries with idleflows 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 checksumvalue of the upper layer needs to be adjusted according to the difference between theoriginal address and port and the translated address and port. TCP, UDP, ICMPv6compute checksum over the transport layer data and a pseudo-header that consists offields from the IPv6 header. APT ensures that every packet emitted from its output portshas 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 withthe 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 dealwith packet translation between different protocol realms.

36

Chapter 6. The Protocol Translators

PT64 and PT46 are GT64's components for protocol translation. PT64 translates IPv6packets to IPv4 ones and ICMPv6 packets to ICMPv4 ones. PT46 accepts IPv4 andICMPv4 packets and translates them to IPv6 and ICMPv6 packets.

This chapter provides a high-level overview of the protocol translation process. The firstsection presents the design of protocol translators. The next section describes theimplementation details of IPv4/IPv6 and ICM[Pv4/ICMPv6 translations. It also addressesthe 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 betweenIPv6-only and IPv4-only nodes. Translating a packet from IPv6 to IPv4 or vice versainvolves protocol translation as well as address-and-port translation. PT64 and PT46 areused in conjunction with the IPv6-based APT to complete the translation for neededpackets. As shown in Chapter 4, GT64 needs APT and PT64 for a complete translationfor 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-mapped IPv6 address"-and-portpair. PT64 translates the IPv6 header of the packet into an IPv4 one and takes the lowest32 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 passPT46 and APT for a complete translation. PT46 translates the IPv4 header of the packetinto an IPv6 one, with source and destination addresses being simply translated into IPv4-mapped IPv6 addresses by adding a 96-bit prefix. APT then maps the destination IPv4-mapped IPv6 address into the real destination IPv6 address.

Since the APT deals with address mapping and allocation, PT64 and PT46 areresponsible only for protocol translation. The implementation of PT64 and PT46 areeased because of the modular design. The following sections show the implementationdetails.

6.2 Implementation

6.2.1 IP Translation

37

Protocol translators need to make adjustments when translating from one version of IP tothe 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 andProtocol fields of an IPv4 header directly correspond to Hop Limit and Next Headerfields 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 IPv4header. It can be translated to the Payload Length field of IPv6, which refers to only thepacket length. The way to get the Payload Length value is to subtract the length of theIPv4 Internet header from the original value of the Total Length field.

IPv4 Header31

Version I IHL TOS Total LengthFrag. identifier Flags I Fragment OffsetTTL protocol Header ChecksumSource AddressDestination Address

[Pv6 Header) 31

Version Class Flow LabelPayload Length Next Header Hop Limit

Source Address

Destination Address

[Pv6 Fragment HeaderNst31Next header Reserved Fragment. Offset FlagsFragment Identifier

Figure 5a. IPv4, IPv6 and IPv6 Fragment Header Format

38

0

Directly Copied FieldsIPv4 Header IPv6 HeaderField Value Field ValueTTL 8-bit Hop Limit 8-bitFrag. Offset 13-bit Frag. Offset' 13-bitProtocol2 8-bit Next Header2 8-bit

Translatable FieldsIPv4 Header IPv6 HeaderField Value Field ValueVer 4 Ver 6Ihl IP header lengthTotal Length Packet length Payload Length Packet length -

(including header) IPv6 headerlength

Frag. Identifier 16-bit Frag Identifier 32-bitFlags 3-bit Flags' 3-bitSource Address 32-bit Source Address 128-bitDest. Address 32-bit Dest. Address 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: TOSIPv6/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 cancarry the information in the other protocol. Traffic Class, Flow Label, and Reservedfields 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 istranslated from IPv6 to IPv4, the Header Checksum field (IPv4 protocol) should becomputed after the IPv4 header is constructed; IPv6 has no header checksum. PT64follows Table 3 when translating an IPv6 header into an IPv4 one. PT46 follows Table 4for translating an IPv4 header to an IPv6 one.

39

Table 3. Translating IPv4 to IPv6 Headers

Note:1. Fragmentation is needed when the IPv4 More Fragment flag is true or the FragmentOffset is non-zero. Except for the Payload Length and Next Header Fields, the IPv6 fieldsare the same as for the no fragmentation case.

40

No IPv6fragmentation requiredIPv6 Field ValueVersion 6Traffic-Class 0 (all zero bits)Flow ID 0 (all zero bits)Payload length value of total Length from IPv4 header, minus value of Internet

Header Length (multiply by 4) from the IPv4 headerNext Header value of Protocol field from IPv4 header

If it is 1 (ICM~v4), then substitute it with 58 (ICMPv6)Hop Limit Time to Live field value from IPv4 headerSource and directly adding :: (96 bits of 0) to the Source and destination IPv4Destination address to make them IPv4-mapped IIPv6 address.Address

IPv6 Fragmentation is requiredIPv6 Field ValuePayload Total Length minus the Internet Header Length (multiply by 4) fromLength the IPv4 header, plus 8 for Fragment headerNext Header 44 (Fragment Header)Fragment ValueHeader FieldNext Header value of Protocol field from IPv4 header

If it is 1 (ICMPv4), then substitute it with 58 (ICMPv6)Reserved 0 (all zero bits)Fragment value of Fragment Offset from IPv4 HeaderOffsetMflag value of More Fragments flag from the IPv4 headerIdentification The low-order 16 bits are copied from the value of Identification field

in the IPv4 Header. The higher order bits set to zero.

Table 4. Translating IPv6 to IPv4 Headers

No IPv6 Fragment headerIPv4 Field ValueVersion 4Internet Header 5 (no IPv4 options)LengthType of Service 0 (all zero bits)Total Length' value of Payload Length field from IPv6 header, plus the size of

the IPv4 header (20).Identification 0 (all zero bits)Flags Don't Fragment flag is set to true(1), and all other flags set to

false (0)Fragment Offset 0 (all zero bits)Time To Live value of Hop Limit from IPv6 headerProtocol 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/Destination Address fieldsDestination Address from IPv6 header.Header Checksum Compute it once the IPv4 Header has been created

Contains a IPv6 Fragment Header2IPv4 Field ValueTotal Length value of Payload Length from IPv6 header, minus 8 for the

Fragment header, plus the size of the IPv4 headerIdentification copy from the low-order 16 bits in the Identification field in the

Fragment headerFlags the More Fragments flag is copied from the Fragment header

and the Don't Fragment flag 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 eachIPv6 extension header that is ignored, the Payload Length needs to be adjusted by thesize 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 nofragment header except Total Length, Identification, Flags, and Fragment Offset Fields.

6.2.2 ICMP Translation

The protocol translator will drop ICMP messages with unknown Type fields. It willtranslate the remaining ICMP messages. Header formats for ICMPv4 and ICMPv6messages 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 Parameter Problem. Consequently, the ICMP translation involvessimple type-code translation for the above ICMP messages (except Parameter Problem)that have counterparts in the other protocol.

The formats of ICMPv4 and ICMPv6's Parameter Problem message are quite differentbecause ICMPv4 has a 8-bit point value whereas ICMPv6 has a 32-bit point value.Furthermore, the Pointer field needs to be adjusted to point to the corresponding field inthe IP header where error occurs.

Finally, a recursive translation is needed for the IP packet contained in the ICMP errormessage. Currently, PT64 and PT46 can translate any ICMPv4 or ICMPv6 messages thatdo 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 Translated ICMPv4 HeaderMessage Type Code/Pointer* Type Code/Pointer* Other ChangeEcho Request 128 - 0 -

Echo Reply 129 - 8 -Dest. Unreachable 1 0 3 1Dest. Unreachable 1 1 3 10Dest. Unreachable 1 2 3 5Dest. Unreachable 1 3 3 1Dest. Unreachable 1 4 3 3 Port unreachablePkt. Too Big 2 - 3 4 Adjust MTUTime Exceed 3 - 11 Code UnchangedParameter Prob. 4 2 12 0; Pointer = -1Parameter Prob. 4 1 3 2Parameter Prob. 4 0; Pointer:O 12 0; Pointer = 0Parameter Prob. 4 0; Pointer:4 12 0; Pointer = 2Parameter Prob. 4 0; Pointer:7 12 0; Pointer = 8Parameter Prob. 4 0; Pointer:6 12 0; Pointer = 9Parameter Prob. 4 0; Pointer:8 12 0; Pointer = 12Parameter Prob. 4 0; Pointer:24 12 0; Pointer = 16Parameter Prob. 4 0; Pointer: others 12 0; Pointer = -1- : code field unchanged.* : unless specified, refer to code valuesource: [1].

42

Table 6. Translating ICMPv4 to ICMPv6

ICMPv4 Header Translated ICMPv6 HeaderMessage Type Code /Pointer * Type Code/pointer* Other ChangeEcho 0 - 128 -

Echo Reply 8 - 129 -Dest. Unreachable 3 0,1,6,7,8,11 1 0Dest. Unreachable 3 2 4 1 Pointer = 6Dest. Unreachable 3 3 1 3Dest. Unreachable 3 4 2 0 Adjust MTUDest. Unreachable 3 5 1 2Dest. Unreachable 3 9,10 1 1Time Exceeded 11 - 3 -Parameter Prob. 12 Pointer:O 4 Pointer:OParameter Prob. 12 Pointer:2 4 Pointer:4Parameter Prob. 12 Pointer:8 4 Pointer:7Parameter Prob. 12 Pointer:9 4 Pointer:6Parameter Prob. 12 Pointer:12 4 Pointer:8Parameter Prob. 12 Pointer:16 4 Pointer:24Parameter Prob. 12 Pointer:all other 4 Pointer: -1

- : code field unchanged.* : unless specified, refer to code valuesource: [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 theirchecksum value based on a pseudo header that includes values of source and destinationaddresses, upper-layer packet length and protocol (next header) fields from the IP/IPv6header. When translating from IPv6 to IPv4, PT64 needs to calculate the IP checksumthat is required by the IPv4 header. However, PT46 need not calculate IPv6 checksumsince IPv6 header does not have that field.

PT46 and PT64 also differ in ICMPv6 and ICMPv4 checksum calculation. PT46 needsto compute the ICMPv6 checksum in the same fashion as TCP and UDP becauseICMPv6 includes the pseudo header in its computation. However, PT64 can directlycalculate the ICMPv4's checksum directly from the ICMPv4 packet. When translatingbetween ICMPv4 and ICMPv6, the difference in the checksum value needs to be takeninto account.

43

6.3 Using Protocol Translators for GT64

Protocol translators are used in GT64 so that GT64 is able to deal with translationbetween different protocol realms. They are always used together with an APT. Protocoltranslators can be omitted from a GT64 if the two networks use IPv6, such as thetranslation scenario of an IPv6 private net connected with the IPv6 Internet.

44

Chapter 7. GT64 for Different TranslationScenarios

This chapter illustrates how modular structure allows GT64 to easily handle differenttranslation requirements. With different configurations, GT64 can be used in differenttranslation 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 commontranslation scenario at the early stage of transitioning to the IPv6 Internet. As thetransition goes to a later stage, the second translation scenario, a local IPv4 networkconnected with the IPv6 Internet, will be common for the local sites that are slow in IPv6implementation, but are willing to explore the IPv6 infrastructure. The third scenario,IPv6 private network connected with the IPv6 Internet, will be less common, since theprimary 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 withthe IPv4 Internet is very common for today's network. In fact, most existing networktranslators 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 singleglobally visible address. The major difference between the above four scenarios and loadbalancing is that the address mapping occurs only when the flow is initiated from theoutside world.

Table 7 summarizes configurations of GT64 of the five translation scenarios. Followingthat, Section 7.1 to Section 7.6 illustrate in detail how to set up configurations for each ofthe five scenarios and a mixed environment scenario.

45

Table 7. Configurations of GT64 for Different Translation Scenarios

46

Translation Scenario GT64 path GT64 path Address AllocationOutward Packet Inward Packet Direction

Local IPv6 net with the IPv6 packet => IPv4 packet => OutwardIPv4 Internet APT => PT46=>

PT64=> APT=>IPv4 packet IPv6 packet

Local IPv4 net with the IPv4 packet => IPv6 packet => OutwardIPv6 Internet PT46 => APT =>

APT => PT64 =>IPv6 packet IPv4 packet

Local IPv6 net with the IPv6 packet => IPv6 packet => OutwardIPv6 Internet APT => APT=>

IPv6 packet IPv6 packetLocal IPv4 net with the IPv4 packet => IPv4 packet => OutwardIPv4 Internet PT46 => PT46 =>

APT => APT =>PT64 => PT64 =>IPv4 packet IPv4 packet

Load balancer IPv6 packet => IPv6 packet => Inward(IPv6 local net APT => APT =>supported web server IPv6 packet IPv6 packetwith the IPv6 Internet)

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 withIPv6 routing elements and IPv4 routing elements to achieve translation and routingfunctions for a local IPv6 net connected with the IPv4 Internet. APT is configured to havestatic mapping and dynamic address-and-port mapping. Local IPv6 host 3ffe: lcel:2::1 isstatically mapped with a global IPv4-mapped IPv6 address :: 18.26.4.115. APT has 1000ports (port number range from 6000 to 7000) that can be multiplexed to the flowsconnecting local IPv6 and IPv4 hosts in the Internet. Moreover, this APT allowsdynamic address allocation for outward packets because the dynamic address allocationdirection is configured as 0.

When a packet that is originated from host A2 of the local net and destined to host B inthe 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. Thispacket has an original flow ID as (3ffe:Icel:2::2, 5001, ::64.58.76.177, 125). APT willreplace 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 IPv4packet whose flow ID will be (18.26.4.116, 6000, 64.58.76.177, 25). PT64 outputs theIPv4 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 originatedfrom host B in the IPv4 Internet and destined to Host A2 in the local IPv6 net, arrives atthe edge router, the IPv4 routing elements routes the packet to GT64. After address-and-port translation at APT and the protocol translation at PT46, the packet changes from anIPv4 packet to an IPv6 packet with IPv4 mapped IPv6 addresses for both source anddestination address, and then to an IPv6 packet with local IPv6 address 3ffe:1ce1:2::2 fordestination address. The IPv6 routing elements then routes the packet to the finaldestination 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 with IPv4mapped IPv6 (translated)addresses

IPv6local net

HostPA_Al:

3ffe:lcel:2::1

Host A2:3ffe:lcel:2::2

Completely Translated IPv6 packetstranslated IPv6 with IPv4 mapped IPv6packets addresses

Completelytranslated IPv4packets

IPv4Internet

rout- Host B:e e- 64.58.76.

ments 177

IPv4 packetsdestined forTPv6 no&e

Figure 6 Configuration of GT64 for connecting Local IPv6 net with IPv4 Internet

48

IPv6 packetsdestined for IPv4node

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 netconnected with the IPv6 Internet. This figure is exactly the same as Figure 6 except thatPT64 and PT46's positions have been exchanged, as well as those of IPv4 and IPv6routing elements. APT is configured to have static address mapping as well as dynamicaddress-and-port mapping. Notice that in the global addresses that APT uses are normalIPv6 addresses rather than IPv4-mapped IPv6 addresses. Internal host 1.0.0.1 is staticallymapped with IPv6 address 3ffe:1ce1:2::1. Flows of other internal hosts thatcommunicate with the outside world need to be dynamically mapped with a global IPv6address 3ffe:lce1:2::2 and a port (in the range from 6000 to 7000) as source address andport.

Configuration Example: APT(1,0,::1.0.0.1 3ffe:1ce1:2::1,1,1,0,3ffe:1ce1:2::2 6000 7000)

49

DNSA]LG

Internet(6 bone)

IPv4 IMvlocal net IPv4 PT46 routing

routing APT ele-HotB

Host Al: PT64 es5f291.0.0.1me s b:

Host A2:1.0.0.2

.... .. ...

Figure 7. Configuration of GT64 for connecting Local IPv4 net with IPv6Internet

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 protocoltranslation is unnecessary. Figure 8 shows such a translation scenario. When a packetdestined to the host of the IPv6 Internet passes the IPv6 routing elements, the packet isdirected to GT64, where the address and port translation is conducted - i.e. the sourceprivate IPv6 address is translated to a global IPv6 address, along with the port. The IPv6routing 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 withprivate source IPv6address

IPv6 packets with privateIPv6 dest. (translated)addresses

IPv6 packets with(translated) global sourceTPv6 addresses

IPv6 packetsdestined for globaldestination Address

Figure 8. Configuration of GT64 for connectingprivate IPv6 net with IPv6 Internet

50

PrivateIPv6 net

Host A1:Iffe::1Host A2:1ffe::2

IPv6Internet(6 bone)

Host B:5f02:971b::1

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 areneeded for any packet's translation. Figure 9 illustrates how GT64 is configured for thisscenario. In the example, APT is configured the same as Figure 6. Obviously, this is notthe best approach to deal with translation for an IPv4 private net connected with the IPv4Internet: the double protocol translation is very inefficient. However, it doesdemonstrate the generality of GT64: GT64 can be configured for any IPv4/IPv6 relatedtranslation scenarios. Furthermore, in the future, an IPv4-based APT, i.e., an APT thatcan 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 withprivate IPv4 srcadd.

Translated IPv6 packets Translated IPv6 packetswith IPv4 mapped IPv6 with IPv4 mapped IPv6addresses (private src add) addresses (global src add)

IPv4 packet withglobal (translated) IPsrc address.

JIPv4local net

HostAl:1.0.0.1HostA2:

IPv4 packets withprivate IPv4 dstaddress

Translated IPv6 packetswith IPv4 mapped IPv6addresses (private dst add)

Translated IPv6 packetswith IPv4 mapped IPv6addresses (global dst add)

Figure 9. Configuration of GT64 for connecting private IPv4net with IPv4 Internet

51

lIP4Internet

Host B:18.26.4.125

IPv4 packetwith global IPdst address.

7.5 Load Balancing

GT64 can be used as a load balancer. Assume that the web address 3ffe:ice l:2::1 has tenIPv6-only machines (Iffe::1,..., Iffe::10) to back up its functions and they are connectedto the IPv6 Internet through an edge router where GT64 resides, as illustrated in Figure10. GT64 consists of APT only. An IPv6 packet coming from the IPv6 Internet will besent to the APT directly; the destination address and port (web server) will be mapped toone of the local machines' IPv6 addresses and certain port. The IPv6 routing elementsthen forward the packet to that local machine.

GT64 can be easily configured to handle other load balancing situations, such as an IPv4web address that has several IPv4-only machines to back up its functions, an IPv4 webaddress 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 withprivate source IPv6address (IPv6 packets with (translated)

global source IPv6 addresses(from webserver)

PrivateIPv6 netforwebserver3ffe:1cel:2::1

Host A: Iffe::1Host A2:lffe::2

IPv6 packets with IPv6 packets destined toprivate IPv6 dest. global destination Address(translated) addresses (to web server)

Figure 10. Configuration of GT64 for Load Balancing

52

IPv6Internet(6 bone)

J

7.6 Mixed IPv6/IPv4 Local Network Connected with the IPv4 andIPv6 Internet

A local network will not transit from IPv4 to IPv6 in a single step. Most likely, somenodes of a local network will be IPv6-only, some nodes will be IPv4-only, and others willbe IPv4/IPv6. GT64 can be easily configured for this kind of situation, as seen in Figure11. When a packet comes to an edge router, it is sent to the IPv4/IPv6 Click routingelements that can route both IPv4 and IPv6 packets. There, the first classifier decideswhich path, IPv4 or IPv6, should handle the packet. On the left side, Figure 12 shows anIPv4 path in Click that an IPv4 packet will follow; on the right side, an IPv6 path that anIPv6 packet will follow. If the packet needs to be translated, the LookupIPRoute orLookupIP6Route element will output the packet to GT64. After the translation, thetranslated packet is sent back to the corresponding path of the router to be processed asother normal packets.

53

LPv4/IPv6mixedLocalnetwork

IPv4/IMv IPv4mi xed /AM6Local Clicknet- Routerwork

IPv4/IPv6-* Internet

/EPv6 IA 4

Click IPv6Router Inter

net

Figure 11. IPv4/lPv6 mixed local net connected with the IPv4/lPv6 Internet

54

Classifier(...)

IP6 IP6NDAdvertisement IP6NDSolicitation

Classifier( ... )

ARP Queries A RP Response IN4

ARPResponder to XRQuerier

to Strip(14)Queue

CheckIPHeader(...)

Trans-lated

GetIPAddress(16) IPv4packets

IPv4 packets tobe translated

-IN

to IP6NDSolicitor IIP6NDAdvertiser

Strip(14) toOueue

GT64

CheckIP6Header(...)

Trans-latedIPv6packets

GetIP6Adress(24)

Lo§kuvIP6oute .d

IPv6 packets tobe translated

Figure 12. Segment of Click Configuration for the scenario IPv4/IPv6mixed local net connected with the IPv4/IPv6 Internet

55

FromDevice(ethO) IFromDevice(et h1)

Classifier(.)IPv4, ARP queries/response EMv, NDady, NDSoli

I

7.7 Discussion

The set of translation scenarios demonstrated in this section indicates that GT64 is trulygeneral-purpose, i.e., it suits a diversity of the translation scenarios with easyconfigurations. The modularity of Click software contributes to the ease of the translatorconfiguration.

The previous examples use combinations of Click routing elements and GT64.Nevertheless, GT64 can also be connected with any existing routers to achieve the abovetranslations.

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, furtherdevelopment, such as APT that can also make IPv4-to-IPv4 address translation willfurther ease the configuration for translation scenarios such as IPv4 local net connectedwith the IPv4 Internet and load balancing (e.g. IPv4 hosts back up an IPv4 internetaddress).

56

Chapter 8. Performance Evaluation

This chapter presents basic performance measurements for GT64. It analyzes theperformance by measuring numbers of packets per second.

The experiment consists of three machines that are connected as shown in Figure 13. Therouter running GT64 has a separate full-duplex point-to-point gigabit Ethernet link toeach 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 800mHZ Pentium III CPUs, SeverWorks LE chipsets, and 256MB of RAM. All the networkdevices are Intel Pro/1000F gigabit Ethernet cards, connected to the motherboards with64 bit 66 mHz PCI.

57

Click 1 PT64 INHost Routing APT Click Host

A Elements Routing 7 BIMv P4 Elements IPv4Node node

other T4otherrouting routingoutputs- upt

Figure 13. Experiment: GT64 for an INv4 host and an INv6 host

Each host generates an even flow of UDP packets addressed to the other host; the routeris 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 ofdata and the 4-byte Ethernet CRC. Host A sends IPv6 UDP packets into the router to beforwarded to Host B which is IPv4-only. In the reverse direction, Host B sends IPv4UDP 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 adifferent destination IPv6 address. Each stream consists of a sequence of flows; thepackets of each flow all have the same port numbers, but successive flows in the samestream have different port numbers. Each flow consists of 50 packets. The routerforwards 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. Therouter runs in kernel Click. It uses polling drivers to get packets from the networkinterfaces. The APT is configured to have more than 61000 ports available (from portnumber 4096 to port number 65535) for dynamic address-and-port allocation. The APTadds a new translation table entry for each new flow. Mappings for inactive flows will bedeallocated after 20 minutes. Host B (IPv4-only host) echoes every packet it receivesback to the router after reversing source and destination address and port fields. Therouter forwards the packets after the reverse network translation at GT64, i.e., IPv4-to-IPv6 protocol translation at PT46 and address-and-port translation at APT. Both endhosts count the number of packets the router forwards to them.

The experiment shows that the maximum loss-free forwarding rate for the router and thetranslator is 64k packets per second, implying that it takes 15us to process a packet. Therouter can only sustain this rate while there are unused ports available. Performance willgo down once all the ports are used up since each new flow has to wait for thedeallocation of a previous flow's port. The CPU time required to execute GT64 is 4.5usper 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. Theoperation of NAT devices and the terminology for various NAT are defined anddescribed in [RFC 2663]. Kohler et. al. implemented a set of Click NAT elements usingits terminology [Click] [Click-Thesis]. Using a flexible, usable set of components inClick, Kohler's NAT can perform basic NAT, Network Address Port Translation, LoadSharing, 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 acombination of address translation theme as described in [RFC 2663] and V6/V4 protocoltranslation theme as described in [RFC2765]. Following the specification, Click's GT64implements a flexible, usable set of Click components for network address translationbetween IPv6 and IPv4 networks.

Ultima [7]is an experimental interworking device developed within British Telecom. TheUltima 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 (includingNAPT-PT and DNS/FTP ALGs). Address translation is performed by aliasing an IPv6address with an IPv4 address in much the same way as a conventional NAT device.vTheUltima NAT-PT contains ALG's for both DNS and FTP. The DNS-ALG is acomprehensive implementation supporting both UDP and most TCP type DNS requestsand responses. The DNS-ALG currently handles translation of A records originating fromthe IPv4 to AAAA records for forwarding to the IPv6 network and AAAA records fromIPv6 translated to A records for forwarding to IPv4. An implementation of the Ultimadevice is resident on the BT portion of the 6Bone to allow native IPv4 access to an IPv6WWW 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 PCrunning the Microsoft IPv6 stack. The implementation uses a device driver which can bemanually 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 IPv6hosts. This deviates from the NAT-PT idea where mappings are dynamically allocatedby 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 IPv4networks to IPv6 servers. It works in conjunction with IPv4 NAT, and by using the IPv4overload 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 IPv6addresses.

Those implementations only incorporate the address translation part of NAT-PT andexclude the port-number translation. Furthermore, unlike Click's GT64, those

59

implementations are embedded inside a fixed router configuration, which doesn't allowchange 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 toachieve a single-step transition. NAT will be used as a mechanism to support thecommunication between IPv4- and IPv6-only nodes for most sites.

This thesis describes the design and implementation of a General-purpose TranslatorforIPv6/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 tocommunicate between IPv6-only nodes and IPv4-only nodes, requiring no change ateither the source or destination machine, and ease of implementation. GT64 can be easilyconfigured for different translation scenarios between different IPv4 and IPv6 addressand protocol realms.

Its modularity and ease of configuration and extension indicates that the GT64 is apowerful tool for network communication. Further development and deployment ofGT64 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 elementrepresents a simple router function. A number of elements can be added to increase therouting efficiency or enable the router for other complex routing tasks.

62

Figure 14. Click Configuration for an IPv4 router

FromDe ce(etho)

Classifier(...)

A RP Queries A RP Responses IN4

FromDeviQ(ethl)

Classifier(...)

IP4 ARP Responses A RP Queries

ARPResponder

to Queue

ARPQuerier Paint(l) Paint(2)

CheckIPHeader(...)

toARPQuerier TPResponder

to Queue

GetIPAddress(16)

LokuplPoute(...)

DropBrodass

ICMPError

IP6Fragment(...) Must fragment

fromClassifie from Clas

ARPQuerier(...)

DropBroadCas

CheckPaint(2) l1CMPErrorreirect

TCTPError

IP6Fragment(...) Ms fragment

er I~r(.oa

sifi

ARPQuerier(...)

ToDevice(ethl)

63

k

k

ToDevice(ethO]

I

I I

I

L

L

I I

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, "SOCKSProtocol Version 5", March 1996.

[RFC1933] R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hostsand Routers", April 1996.

[RFC2373]1998.

[RFC 2391]

R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", July

P. Srisuresh and D. Gan. "Load sharing using IP Network AddressTranslation", August 1998.

[RFC 2428] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for IPv6 andNATs", September 1998.

[RFC2529] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4 Domains withoutExplicit 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 extensionsto Network Address Translators (DNSALG)", September 1999.

[RFC2765]

[RFC2766]

E. Nordmark, "Stateless IP/ICMP Translator",

G. Tsirtsis, P. Srisuresh, "Network Address Translation - ProtocolTranslation (NAT-PT)", February 2000.

[RFC2767] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts using the Bump-in-the-Stack technique", February 2000.

64

[RFC2772] R. Rockell, R. Fink, "6Bone Backbone Routing Guidelines", February2000.

[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 theInternet. Draft-ietf-ngtrans-introduction-to-IPv6-transition-04.txt (work in progress)

[AIIH] Jim Bound, "Assignment of IPv4 Global Addresses to IPv6 Hosts (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).

[DSTM] J. Bound, L. Toutain, H. Affifi, "Dual Stack Transition Mechanism(DSTM)", draft-ietf-ngtrans-dstm-01.txt (work in progress).

[NAT] P. Srisuresh, Campio Communications, K. Egevang, "Traditional IP NetworkAddress Translator (Traditional NAT)", draft-ietf-nat-traditional-04.txt (work inprogress).

[SOCKS-EXT] H. Kitamura, "SOCKSv5 Protocol Extensions for IPv6/IPv4Communication Environment", draft-kitamura-socks-IPv6-01.txt (work in progress).

[SOCKS-GATE] H. Kitamura, A. Jinzaki, S. Kobayashi, "A SOCKS-based IPv6/IPv4Gateway Mechanism", draft-ietf-ngtrans-socks-gateway-02.txt (work in progress).

[TRT] J. Hagino, K. Yamamoto, "An IPv6-to-IPv4 transport relay translator", draft-ietf-ngtrans-tcpudp-relay-00.txt, (work in progress).

Articles and websites:

[CLICK] E. Kohler, R. Morris, Benjie Chen, J. Jannotti, and M.F. Kaashoek, "TheClick modular router", ACM Transactions on Computer Systems, 18(4), November 2000.

[CLICK- Thesis] E. Kohler, The Click modular router. MIT Ph.D. Thesis,November, 2000.

[1] M.E. Fiuczynski et al, 1998, " The Design and Implementation of an IPv6/IPv4Network Address and Protocol Translator," Proceedings of the USENIX AnnualTechnical Conference (N098), New Orleans, Louisiana.http://www.cs.washington.edu/research/networking/napt/reports/usenix98/index.html, asof April, 2001.

65

[2] Stardust.com "Migration from IPv4 to IPv6 for a network manager: Implementationof the IPv4/IPv6 network address and protocol translator" Project Report, 2000http://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", WIDE6bone 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