A design and implementation of a general-purpose translator for IPv6/IPv4 (GT64)

(1)

A Design and Implementation of a General-purpose Translator for IPv6/IPv4 (GT64) by

Peilei Fan

B.S., Computer Science, Nanjing University, 1993 Master of City and Regional Planning

Rutgers University, 1997

Submitted to the Department of Electrical Engineering and Computer Science in Partial Fulfillment of the Requirements for the Degree of

Master of Science in Electrical Engineering and Computer Science at the

Massachusetts Institute of Technology June 2001

Signature of Author... ...

Department of Electrical Engineering and Computer Science May 11, 2001

Certified by ...

Robert T. Morris Assistant Professor of Computer Science Thesis Supervisor

Accepted by ...

Arthur C. Smith Chairman, Committee on Graduate Students of Electrical Engineering and Computer Science

MASSAC HUSETe _t

(2)

A Design and Implementation of a General-purpose Translator for IPv6/IPv4 (GT64) by

Peilei Fan

Submitted to the Department of Electrical Engineering and Computer Science in June 2001 in partial fulfillment of the

requirements for the Degree of

Master of Science in Electrical Engineering and Computer Science Abstract:

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

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

GT64's design is more flexible than most existing network address translation implementations. It can be configured easily for a number of address translation

scenarios, including an IPv6 local net connected with the IPv4 Internet, an IPv6 local net connected with the IPv6 Internet, an IPv6 private net connected with the IPv6 Internet, and an IPv4 private net connected with the IPv4 Internet. Moreover, GT64 can also be configured for a variety of load balancing scenarios. Because of its modularity and ease of extension, GT64 is a powerful tool for helping the transition to the IPv6 network.

Thesis Supervisor: Robert Tappan Morris Title: Assistant Professor of Computer Science

(3)

Acknowledgements

This thesis would have been impossible without the support of a host of people. First, Robert Tappan Morris has been a great advisor who, with his time, knowledge, and talents enhanced the quality of this research. I thank him for giving me valuable advice and enormous help. Eddie Kohler helped me become familiar with the Click

environment and was always there for questions. Benjie provided help to set up the performance test. I am very grateful to the Click team: Robert Tappan Morris, Eddie Kohler, Benjie Chen, M. Frans Kaashoek, John Jannotti, and Massimiliano Poletto. Thanks also to others in the Parallel and Distributed Operating System Group (PDOS) at the MIT Laboratory for Computer Science: Jinyang Li, Charles Blake, Douglas S.J. De Couto, Kevin Fu, Thomas Gil, and Neena Lyall. I thank following people for their support: Hari Balakrishnan, Nancy Lynch, Karen R. Polenske, Xiaowei Yang, Zhao Chen, and Karen Wang.

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

(6)

Chapter 1. Introduction

Network Address Translation is a method by which IP addresses are mapped from one

address realm to another. Ideally, the method is transparent to end-users. The need for IP address translation arises when a network's internal addresses cannot be used to

communicate outside the network. As the Internet transitions from IPv4 to IPv6, Network

Address Translators (NATs) will be used as a mechanism for IPv6 hosts and routers to

communicate with IPv4 hosts through the existing IPv4 infrastructure. In this thesis, I describe the design and implementation of a General-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 next section briefly introduces translation between IPv6 and IPv4. The third section then shows how GT64 achieves the translation. The last section outlines the structure of the thesis.

1.1 IPv6 vs. IPv4 Addresses

Currently, the Internet Protocol (IP) is responsible for communication on the Internet. The Internet Protocol version 4 (IPv4) has expanded to support millions of nodes but is now running out of address space. The Internet Protocol-Next Generation (IPng), also known as IP version 6(IPv6), was designed in response to the Internet's high demand for IP addresses. The most distinguished feature of IPv6 is its address architecture.

1.1.1 IPv6 Address Architecture

IPv6 uses a 128-bit addressing scheme [RFC 2373] rather than the 32-bit addresses used by IPv4. IPv6 assigns addresses in a hierarchical manner, as needed by the requester, rather than in blocks of unused addresses, as IPv4 does. This hierarchical scheme allows an upper authority to subdivide its address space and allocate it to lower authorities, which can then subdivide and allocate them to authorities at the next lower level, and so on.

The 128-bit IPv6 addressing requires changes to the IPv4 address notation. IPv4 uses the format "D.D.D.D", a quad-octet dotted decimal notation, to represent numeric addresses; while IPv6 uses the format "X:X:X:X:X:X:X:X", an eight-16-bit hexadecimal notation, to represent numeric addresses. Colons separate this format into eight sections, and four hexadecimal digits represent each of the16-bit sections. However, the leading zeros in each section can be deleted to create a more simplified format. For example, an IPv6

address "3ffe: Ice1:0002:0000:0000:0000:0000:000 1" can be written as "3ffe: Ice 1:2:0:0:0:0:1,".

(7)

A compressed form of IPv6 address notation uses double colons (::) to indicate multiple groups of 16-bit zeros, which can appear only once in an address. Thus the above address can be simply represented as "3ffe:lce1:2::1".

1.1.2 IPv6 address with embedded IPv4 address

In the mixed environment of IPv4 and IPv6 nodes, it is convenient to use the mixed form, which has the representation of "X:X:X:X:X:X:D.D.D.D". The six higher-order sections

(separated by ":") _{have hexadecimal values and the four lower sections (separated by}_".")

have decimal numbers. The mixed address form is called a transition address, because it uses an IPv6 address format to represent an IPv4 address. Two types of transition addresses can contain an IPv4 address within an IPv6 address. The first type is called an

IPv4-compatible IPv6 address. Nodes with this type of transition address are always

identified as IPv4/IPv6 or IPv6 nodes and never as IPv4-only nodes. The IPv6 transition mechanisms [RFC 1993] include a technique for hosts and routers to dynamically tunnel IPv6 packets over IPv4 routing infrastructure. For instance, IPv4-compatible IPv6

address are assigned to IPv6 nodes that utilize this technique. The IPv4-compatible IPv6 address 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 bits

10000...0000 10000

32 bits IPv4 address

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

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

80 bits 16 bits 32 bits

0000...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-bit

prefix. IPv4 addresses are easily translated into IPv4-mapped IPv6 addresses by the addition of the 96-bit prefix "::ffff'. Therefore, if an IPv4-only node has IPv4 address as 18.26.4.2, its IPv6 address is ::ffff:18.26.4.2.

(8)

The movement of a packet from one address realm to another address realm primarily involves making the packet addresses and protocols meaningful for nodes in the other

address realm. Both address realms may use the same protocol as in the case of a private IPv6 local net connected with the IPv6 Internet. More often, they may have different protocols as in the case of an IPv6 local net connected with the IPv4 Internet.

1.2.1 Translating between IPv6 and IPv6

In the first case, the local net typically has several IPv6 addresses that nodes in the local net can use as their identities when they need to communicate with the outside world. When a node X in the private IPv6 local net sends a packet to a node Y in the IPv6 Internet, the packet must have its source address replaced with a global IPv6 address "AddressX6" so that the packet's addresses could be recognized in the IPv6 Internet. Moreover, if the node Y in the IPv6 Internet wants to send the node X a packet, it will use the global IPv6 address "AddressX6" as the destination address. But when the packet reaches the private IPv6 net, the destination address has to be replaced by the private

address of the node X.

The replacement of the source address or destination address is called address translation. To increase the number of nodes of a private net that can simultaneously communicate with the outside world, a global address can be shared by several nodes by allowing transport identifiers (e.g., TCP and UDP port numbers, ICMP query identifiers) of a number of private nodes to be multiplexed into transport identifiers of this single global IPv6 address. The translation mechanism uses different port numbers of the same global

address to represent a private host in the local network. Thus, port translation as well as address translation is involved. This is called address-and-port translation. It requires address and port translation and related checksum adjustments at the network and upper layers. At the transport layer, the values of the source port (or destination port) and the checksum field need to be changed.

1.2.2 Translating between IPv6 and IPv4

If the communicating address realms use two different protocols, such as an IPv6 local network connected with the IPv4 Internet, then the network layer header must be translated into the other protocol so that it can be recognized in the other realm. In this case, protocol translation as well as address-and-port translation is required. Protocol

translation refers to replacing one protocol header with the other protocol header. IPv6 and IPv4 have similar header formats, but with some different fields. More detail of protocol translation will be discussed in Chapter 6.

For instance, when a node X with an IPv6 address "AddressX6" in the private IPv6 local net sends a packet to an IPv4-only node Y with IPv4 address "AddressY4" in the IPv4 Internet, the original packet has "AddressX6" and "AddressY6"(IPv4-mapped IPv6

address) as source and destination addresses. Before it arrives Y, the packet's IPv6

(9)

direction, if Y sends a packet to node X, the original packet will have "AddressY4" and "AddressX4" as source and destination addresses. Before it arrives at the IPv6 local network where node x resides, the packet's IPv4 header will be replaced by a

corresponding IPv6 header. It will have "AddressY6" and "AddressX6" as its new source and destination addresses.

When one protocol is translated into another, such as from IPv6 to IPv4, the transport layer (TCP or UDP) will keep the same header format; but if port translation is involved, the values of the source port (or destination port) and the checksum field will be changed. Because of the TCP and UDP header formats remain the same in IPv6 as in IPv4,

translation for the transport layer is a simple matter.

Payload translation is also needed if the packet has address or port information in the application layer. When the address and port are replaced during the translation for the network layer and the transport layer, the payload at the application layer may need to be modified as well to reflect the updated address and port information.

1.3 GT64 for LPv6/IPv4

Translation

The design of the GT64 translation mechanism has three main goals. First, it should allow communication between IPv6-only nodes and IPv4-only nodes. The purpose of a network translator is that two different types of IP nodes be able to communicate with each other. Second, no change should be required at source or destination; all processing will be done at the edge router or other intermediary. This allows the local network to be

able to communicate with other networks with the minimum effort, since the number of edge routers is much less than the number of end nodes. Third, the implementation of

GT64 should be easily accomplished. GT64 is implemented in the context of the Click modular networking system [CLICK].

GT64 separates the task of address-and-port translation from protocol translation. The separation eases the implementation of GT64, since each can be implemented as a separate module in Click. GT64 uses an address-and-port translator for address and port translation of the packet and uses protocol translators for IPv4-to-IPv6 or IPv6-to-IPv4 protocol translation. The model used by address-and-port translation ensures that GT64 is capable of communicating between IPv6-only and IPv4-only hosts without changing end nodes. The protocol translation follows the RFC standards [RFC 2765]. Together they provide the most appropriate combination the our system solution.

The address-and-port translation is IPv6-based, i.e., it only maps between IPv6 addresses and ports. However, GT64 must be able to map between IPv6 and IPv4 addresses in order to work with IPv6/IPv4 translation scenarios. The address-and-port translation can translate between normal IPv6 addresses and IPv4-mapped IPv6 addresses for IPv6/IPv4 translation. The protocol translation can translate between IPv4-mapped IPv6 addresses and IPv4 addresses. Thus, an IPv6 address can go through the address-and-port

(10)

into IPv4 address through the IPv6 to IPv4 protocol translation. Conversely, an IPv4 address in a packet can be mapped back to an IPv6 node by going through the JPv4 to IPv6 protocol translation and then the address-and-port translation.

GT64 requires that communication between address realms must pass the edge router. GT64 on a local net should either reside in or be directly connected with the edge router. If GT64 does not reside at the edge router, then when packets that are destined to or sourced from a different address realm pass by, the edge router should pass the packets that need to be translated to the host in which GT64 resides. GT64 then emits the translated packets to appropriate routers that will direct the packets to the destination address realm. If GT64 is in the edge router, the above transportation of the packets will occur within the edge router.

Furthermore, GT64 can also be integrated into more complex Click IPv4 and IPv6 routers within the same node to build routers with translation functionality.

1.4 Thesis Structure

The next chapter summarizes the background of the problem dealt with by this thesis by introducing different models for NATs with emphasis on models used by GT64. Chapter 3 introduces the IPv6 implementation for Click. Chapter 4 describes the design of GT64. Chapter 5 and Chapter 6 describe the design and implementation of the address-and-port translator, as well as the protocol translators. Chapter 7 illustrates how GT64 can be used in a variety of translation scenarios. Chapter 8 analyzes the performance of GT64 and describes a set of applications that have been tested, and Chapter 9 surveys related work on NAT. Chapter 10 summarizes the findings of the thesis.

(11)

Chapter 2. Existing NAT Models

This chapter reviews a number of existing models for IPv6/IPv4 inter-operations in order to find the most appropriate models for GT64. Each model has its advantages and disadvantages. The criteria for selection follow the three goals of GT64 mentioned in section 1.3. Section2.1 presents a general overview of six NAT models. Those models are interesting, but do not satisfy GT64's requirements. However, they provide certain insights about network translation. Section 2.2 identifies two models that have the features that GT64 needs.

2.1 General Overview of NAT Models

A number of IPv4/IPv6 inter-operation mechanisms have been proposed:

The Dual Stack Model [NAT-INTRO] requires allocation of an IPv4 address to each IPv6 host so that all IPv6 nodes are dual-stacked, i.e., they provide complete support for both IPv4 and IPv6 in hosts or routers. The dual stack nodes must have DNS resolver libraries that can deal with the IPv4 "A" record as well as the IPv6 "AAAA" or "A6" record. Thus, communication to IPv4 nodes takes place using the IPv4 stack;

communication with the IPv6 world takes place using the IPv6 stack. This model does not allow communication between IPv6-only nodes and IPv4-only nodes.

In the Limited Dual Stack Model [NAT-INTRO], only "server nodes" (nodes hosting Internet services, such as file sharing, DNS, web, etc.) are dual-stacked. "Client nodes" (nodes that do not offer those services) are IPv6-only. Though fewer IPv4 addresses are needed, this model does not allow communication between IPv6-only and IPv4-only nodes.

Dual Stack Transition Mechanism (DSTM) [DSTM] mainly targets the communication

between a newly deployed IPv6 network and the existing IPv4 networks. All IPv6 nodes in the DSTM network are dual-stacked. DSTM assigns temporary global IPv4 addresses to dual stack hosts during the communication between an IPv4/IPv6 host and an IPv4-only host. DSTM also requires that the host can perform dynamic tunneling of an IPv4 packet inside an IPv6 packet to suppress the exposure of IPv4 native packets within a DSTM domain of an IPv6 network. Each IPv6 DSTM host has an IPv4 interface called the Dynamic Tunneling Interface (DTI), which encapsulates IPv4 packets inside IPv6 packets.

The DSTM IPv6 host obtains the temporary global IPv4 addresses from DHCPv6 server in the IPv6 DSTM network. The DHCPv6 server provides the assignment of IPv4 global addresses to IPv6 hosts and maintains the mapping between the allocated IPv4 address and the permanent IPv6 address of the host. If an IPv4 host wants to initiate a

(12)

server in charge of the final resolution will ask the DHCPv6 server to allocate a temporary IPv4 address for the dual stack host and it will send back this address in an

"A" record to the IPv4 host. The DHCPv6 server will send a reconfigure command to the dual stack host to assign that temporary IPv4 address. Like the above two dual stack models, this model does not work for communication with IPv6-only hosts.

SOCKS-based IPv6/IPv4 Gateway (SOCKS64) [SOCKS-GATE] is a gateway system

that is based on the SOCKS protocol [SOCKSv5]. It relays two "terminated" IPv4 and IPv6 connections at the "application layer" (the SOCKS server). Especially for

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

The Transport Relay Translator (TRT) [TRT] enables TCP and UDP communications

between IPv6 hosts and IPv4 hosts. A TRT system, which is located between an IPv6-only host and an IPv4-IPv6-only host, translates TCP/IPv6 to TCP/IPv4, UDP/IPv6 to UDP/IPv4, or vice versa.

As shown in the following diagram, when the initiating host (whose IPv6 address is A6) wants to start communication with the destination host (whose IPv4 address is X4), it needs to make an TCP/IPv6 connection to C6::X4, an IPv6 address with a special form-TRT dummy prefix (C6::/64) plus the destination IPv4 address (X4). The routing information in A6 has been configured so that packets to C6::/64 are routed to the TRT gateway, whose IPv6 address is B6. The TRT gateway accepts the TCP/IPv6 connection between A6 and C6::X4 and communicates with the initiating host, using TCP/IPv6. It also obtains the real IPv4 destination address from the lowermost 32 bits of the

destination address (IPv6 address C6::X4). A protocol translator, which is installed at the TRT, does IPv6-to-IPv4 protocol translation for the packet. The TRT, whose IPv4 address is Y4, then connects to X4, using TCP/IPv4, and forwards the traffic across the two TCP connections. UDP traffic can be relayed in the same fashion as TCP. As seen in the example, the initiating host must use a special form of IPv6 address, such as C6::X4, to connect to an IPv4 destination host. The special form can be resolved from a

hostname by a special DNS server implementation, by the static address-mapping table on the initiating host, or by a modified DNS resolver implementation on the initiating host.

(13)

Destination host |X4

=====outer network

|Y4

TRT System ---dummy prefix (C6::/64) 1B6

+=+ inner network

JA6 Initiating host

The TRT has advantages, such as no extra modification on end hosts and no need to take care of path MTU or fragmentation issues that other IPv6-IPv4 header converters have. However, the TRT system can be a single point of failure between the communication peers because the TRT is a stateful system -it retains state of a packet and updates it when other packets belong to the same flow arrives. Furthermore, it is difficult to implement in Click, which builds its structure on the IP layer of the network.

The Bump-in-the-Stack [RFC 2767] model allows for the use of non-IPv6 capable applications on an IPv4 host to communicate with IPv6-only hosts. The Bump-in-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 the

IPv4 stack are three modules that intervene between the application and the network: an extension to the name resolver, an address mapper, and a translator. The main idea is that when an IPv4 application needs to communicate with an IPv6-only host, the IPv6 address of the IPv6-only host is mapped into an IPv4 address out of a pool that is local to the dual stack host. The IPv4 packet generated for the communication is translated into an IPv6 packet before the dual-stack host sends it out to the network. This model requires that the IPv4 host is dual-stacked.

The Stateless IP/ICMP Translation Algorithm (SIIT) protocol [RFC 2765] describes a

method to translate between IPv6 and IPv4 protocols. Translation is limited to the IP packet header. The protocol does not describe a method for assigning a temporary IPv4 address to the IPv6 node. Therefore, SIIT needs to be combined with mechanisms that deal with IPv4 address allocation for IPv6 nodes. The translator operates in a stateless mode, which means that translation needs to be done separately for every packet.

Because of the "stateless" feature, SIIT avoids the single point of failure that can occur to stateful system such as TRT.

2.2 Models for GT64

Among the above seven models, most of them, i.e., Dual Stack Model, Limited Dual Stack Model, Dual Stack Transition Mechanism, and Bump-in-the-Stack Model, need end hosts to be dual-stacked. SOCKS64 requires "socksification" of end hosts. Though the TRT model doesn't require end hosts to be modified, it is difficult to implement in

(14)

Click. In comparison with the models listed above, the following model, which follows the protocol translation guideline of the SIIT, demonstrates the desired features for GT64.

Network Address Translation - Protocol Translation (NAT-PT) [RFC 2766] addresses

the communication between IPv6-only and IPv4-only hosts, which is realized by the use of a dedicated device that translates between IPv4 and IPv6 addresses. Since there is

limited IPv4 address space, the NAT-PT device keeps "state" during each session to track active flows so that it can dynamically allocate its address space to requested flows. The NAT-PT uses SIIT for protocol translation and includes an application layer gateway to make translation possible between IPv4 and IPv6 DNS requests and answers [RFC 2694]. The NAT-PT allows the transport identifiers (TCP or UDP port numbers) of a number of IPv6 hosts to be multiplexed into transport identifiers of a single assigned IPv4 address, thus allowing a set of IPv6 hosts to share a single IPv4 address.

The NAT-PT has certain disadvantages, most of which are general problems of NATs. First, the model requires all packets pertaining to a session to be routed via the same NAT-PT router. A border router unique to a stub domain can overcome this limitation.

Secondly, an NAT-PT can not avoid the loss of information in protocol translation; it simply can not translate everything in the packet since the fields in different protocols do not exactly match. For instances, fields such as Flow Label and Priority in the IPv6 header don't have corresponding fields in IPv4 protocols. Moreover, applications (e.g.

ftp) carrying IP addresses in higher layers will not work. Application Level Gateways (ALGs) are needed to overcome this disadvantage. Furthermore, end-to-end security of the network layer is not possible. Finally, the NAT-PT can not be deployed in

combination with secure DNS, because IPv6 DNS can not sign replies to queries originated from the IPv4 world.

Several commercial/research NAT-PTs already exist. The research teams include: British Telecommunications Lab (http://www.labs.bt.com/technical/natpt/),

Vermicelli Project (http://www.vermicelli.pasta.cs.uit.no/IPv6/DNS.html), and University of Washington (http://www.cs.washington.edu/research/networking/napt/) (base for Microsoft Research IPv6 Stack)

GT64 uses a modified NAT-PT model for IPv4/IPv6 translation. It divides address-and-port translation and protocol translation into two modules. One module is an IPv6-based address-and-port translator that allows a set of IPv6 hosts to share a single IPv6 address by multiplexing the transport identifiers of IPv6 hosts to the transport identifier of a single assigned IPv6 address. This module uses IPv6-based NAT-PT and excludes the protocol translation from the NAT-PT. The other module is for protocol translation and it has two elements: Protocol Translator for IPv6 to IPv4 (PT64) and Protocol

Translatorfor IPv4 to IPv6 (PT46). Both protocol translators follow the SIIT for

translation.

GT64 can be combined with ALGs (for application level translation) and a DNSALG (for DNS packets' address mapping) to provide the most appropriate solution for

(15)

combined with an ALG for FTP protocol would be able to completely translate an IP/TCP/FTP packet, because the FTP_ALG will deal with the modification of the

addresses in the payload. Since GT64 is implemented in Click, the next chapter describes the related implementation -IPv6 for Click. Following that, Chapter 4 presents a detailed design of GT64 and its implementation in Click.

(16)

Chapter 3. IPv6 for Click

3.1 Click Overview

GT64 is implemented in the context of the Click modular networking system [CLICK], a software architecture for building flexible and configurable routers. Modules, called elements, which implement simple router functions, process packets. A router

configuration is a directed graph with elements at the vertices; packets follow along the edges of the graph.

The components of GT64 are constructed as individual Click elements. GT64 is assembled from components that are configured differently for different translation

scenarios. Not only can it be used alone, but GT64 can be incorporated with other Click elements to build configurable routers with translation functions.

In order to translate between IPv4 and IPv6, the router should be able to handle IPv6 packets as well as IPv4 packets. Therefore, part of this thesis was the implementation of IPv6 elements for Click. The next section briefly introduces the implementation of IPv6, ICMPv6, and Neighbor Discovery Protocol in Click. Section 3 presents a basic Click IPv6 router.

3.2 Implementing IPv6 in Click

3.2.1 IPv6 Protocol

Beside the increase of the address space, IPv6 was designed to enhance and maintain current IPv4 functionality while eliminating its limitations. IPv6 features include

security, quality of service, efficiency, growth, flexibility and reliability, most of which are closely related with the use of the IPv6 option mechanism.

The option mechanism of IPv6 improved over that of IPv4. IPv6 options are placed in separate extension headers located between IPv6 header and transport-layer header in a packet. Not all IPv6 extension headers need to be examined or processed by routers

along a packet's delivery path. However, in IPv4, the presence of any options requires the router to examine all options. Thus IPv6 dramatically improves router performance for packets containing options. Another advantage is that the IPv6 extension header can be of

arbitrary length as long as it can be kept as an integer multiple of 8 octets to retain the alignment for subsequent headers. In contrast, IPv4 limits the total number of options carried in a packet to 40 bytes. Currently, IPv6 extension headers include routing,

fragmentation, authentication, security encapsulation, hop-by-hop option, and destination options. Below is shown the format of an IPv6 header and an IPv6 fragment header.

(17)

IPv6 Header

0 31

Version

I

Class Flow Label

Payload Length Next Header Hop Limit

Source Address

Destination Address

IPv6 Fragment Header

0 31

Next header Reserved Fragment Offset Flags

Fragment Identifier

Since the router is not required to process options, the implementation of an IPv6 Click router is simplified. This project has implemented several elements that can forward and

check IPv6 packets. These elements check the validity of the packets' header, decrease the hop limit and discard the packets if the hop limit is zero, and fragment packets if they are too long. Most importantly, they can route the packets to the next hop by looking up the destination address at the routing table.

3.2.2 Address Resolution and Neighbor Discovery

In IPv4, the Address Resolution Protocol (ARP) is used to map IP addresses to hardware MAC addresses. The Neighbor Discovery protocol (ND) performs the same functionality for IPv6.

3.2.2.1 Neighbor Discovery Protocol

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

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

(18)

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

advertisement messages.

3.2.2.2 Neighbor Solicitation Messages

Nodes send neighbor solicitation messages to request the link-layer address of a target node while also providing their own link-layer address to the target. Neighbor

solicitation messages are multicast messages when the node needs to resolve an address and unicast messages when the node seeks to verify the reachability of a neighbor. Neighbor solicitation messages have the following format:

0 31

Type Code Checksum

Reserved

Target Address Options...

3.2.2.3 Neighbor Advertisement Messages

Nodes send neighbor advertisement messages to advertise the link-layer address of some IPv6 addresses. A neighbor advertisement message is a response to a neighbor

solicitation message. Nodes may also send unsolicited neighbor advertisements to announce a link-layer address change. Neighbor advertisement messages have the following format:

0 31

Type Code Checksum

R S 0 Reserved

Target Address Options...

(19)

3.2.3 ICMPv6 Protocol

IPv6 uses the Internet Control Message Protocol (ICMP) [RFC 792] as defined for IPv4, with many changes. The modified protocol is called ICMPv6 [RFC 1885]. It also absorbed the revised Internet Group Membership Protocol (IGMP) [RFC 1112]. IPv6 nodes use ICMPv6 to report errors encountered in processing packets, and to perform other Internet-layer functions, such as diagnostic and multicast membership reporting. ICMPv6 is an integral part of IPv6 and is implemented by every IPv6 node.

ICMPv6 messages have the same general format as ICMPv4 messages, with Type, Code,

and Checksum fields. The Type field indicates the type of the message. The code field is

used to create an additional level of message granularity. The checksum is used to detect data corruption in the ICMPv6 message and parts of the IPv6 header. Every ICMPv6 message is preceded by an IPv6 header and zero or more IPv6 extension headers. The ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header. The following shows the general format of an ICMPv6 message:

1 31

Type Code Checksum

Message Body ...

ICMPv6 messages have two groups: error messages and informational messages. This thesis project has implemented an ICMP6Error element to create all types of ICMPv6 error messages. In addition, the Click IPv6 elements are able to deal with four types of ICMPv6 informational messages: Echo Request, Echo Reply, Neighbor Solicitation, and Neighbor Advertisement messages (Type 128, 129, 135, 136).

3.3 A Click IPv6 Router

A set of IPv6 Click elements is required for a basic IPv6 router. Some IPv6 elements are quite similar to their counterparts in IPv4, such as: GetIP6Address, LookupIP6Route,

DecIP6Hlim, and IP6Frgamenter. Others are quite different, such as CheckIP6Header, IP6NDSolicitor, IP6NDAdvertiser, and ICMP6Error, which follow the standard IPv6,

ND, and ICMPv6 protocols. The IPv6 Click router also uses several general-purpose Click elements, such as, Classifier, Discard, Queue, DropBroadCast, FromDevice,

ToDevice, and ToLinux.

The IPv6 router is able to handle normal IPv6 packets, Neighbor Solicitation messages, Neighbor Advertisement messages, and ICM[Pv6 error messages. Since IPv6 does not require the router to process options, the IPv6 Click router can forward unicast packets in

(20)

full compliance with RFC standards [RFC 2373]. Figure 1 illustrates a basic Click IPv6 router, whose configuration is similar to that of an IPv4 router. Please refer to [CLICK] for a detailed description of Click. A glossary (Table 1) describes the functions of the IPv6 elements used in Figure 1. In Click, the elements take actions based only on the content of a packet. For instance, if a packet's Hop Limit has expired, a DecIP6Hlim element will direct the packet to the output that deals with the error (which is usually connected to an ICMP6Error element); otherwise, it will decrement the Hop Limit and direct the packet to the normal output.

A LookupIP6Route element uses a list of the router's addresses and the broadcast addresses of all interfaces to decide which packets are addressed to the router itself and what interface the packet should be sent to if the packet is to be forwarded. A

CheckIP6Header element checks the validity of the IPv6 source address. An

IP6Fragmenter element fragments packets larger than the configured MTU, but sends

too-large packets that are marked unfragmentable to an error output instead. An

ICMP6Error element accepts invalid input packets, encapsulates them within an ICMP6

(21)

FromDevice(eth) s Classifter(...) IP6NDSolicitation IP6NDAdvertisement IP6ND Advertiser to Queue to IP6NDSolicitor to IP6NDSolicitor Strip(14) CheckIP6Header(...) GetIP6Address(24)

I

I DropBroadCasts HopLimitxpired ICMP6Error

IPurragment(... Must fragment

L from Classifier IP6NDSolicitor(...)

FToDevice(eth

0)

V

'Route( ... ₎ to Linux DropBroadCasts DeclP6Hlim lCMP6Error HopLimitE xpired ICMP6Error

Iruvragment(... Must fra gment

L

from Classifier

IP6NDSolicitor(...)

ToDevice(ethl)

Figure 1. A Two-Interface IP6 router Configuration

FromDevice(ethln) Classifter(...) IP6 IP6NDAdvertisement IP6ND-Advertiser to Queue I I I I

(22)

Table 1. IPv6 router element glossary New IPv6 Elements Description

IP6NDSolicitor First input takes IPv6 packets, second input takes neighbor

(IP6Address, advertisement messages with Ethernet headers. Output emits

ethernetAddress) neighbor solicitation messages and IPv6-in-Ethernet packets.

Uses ND to find the Ethernet address corresponding to each input IPv6 packet's destination IPv6 address annotation; encapsulates

the packet in an Ethernet with that destination Ethernet address.

IP6NDAdvertiser Input takes neighbor solicitation messages, output emits Neighbor

(IP6addressl mask] Advertisement messages. Responds to neighbor solicitation

ethi, ... ) messages for IPv6 address with the static Ethernet address.

CheckIP6Header Input takes IPv6 packet. Discards packets with invalid source

addresses, forwards valid packets unchanged.

DecIP6Hlim Input takes IPv6 packets. Decrements input packets'hop limit

field. Sends to output 1 if hop limit has expired, otherwise to output 0.

GetIP6Address Input takes IPv6 packets. Copies the IPv6 header's destination

address field (offset 24 in the IPv6 header) into the destination IPv6 address annotation; forwards packets unchanged.

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 the configuration string. Forwards each packet to the output port specified in the resulting routing table entry; sets its destination annotation to the resulting gateway IPv6 address, if any.

Existing Click Description Elements

Classifier(...) Input takes any packet, examines packet data according to a set of

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

DropBroadcasts Input takes any packet. Discards packets that arrived as link-level

broadcasts; 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.

(23)

Chapter 4. Design of GT64

This chapter presents the design of GT64. The first section describes the architecture and introduces the elements of GT64; next, it shows how those elements form a complete GT64 for different translations and how GT64 can be incorporated with Click routers. The second section discusses limitations, such as loss of information during protocol translation. It also addresses some other issues when designing translators for IPv6/IPv4 translation, such as alternatives for ALGs, incorporating hostname lookup ability, and TCP/UDP checksum update and fragmentation.

4.1 Architecture

4.1.1 Structure

GT64 can be used as a part of a Click router to connect a local net with the Internet (Figure 2a). The local net may have mixed environment, i.e., it has IPv4-only nodes, IPv6-only nodes, and IPv4/IPv6 nodes. The Internet may also support both IPv4 and IPv6. Click IPv6 or IPv4 router elements can recognize IPv6 or IPv4 packets that need translation and direct them to GT64. After translation, GT64 outputs updated packets to Click IPv6 or IPv4 router elements for further processing.

GT64 has three basic elements (Figure 2b): an address-and-port translator (APT) and two protocol translators. One protocol translator translates from IPv6 to IPv4 (PT64) and the other translator translates from IPv4 to IPv6 (PT46). GT64 achieves flexibility and modularity by splitting translation functionality into individual elements so that 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-only node in the Internet. Once the IPv6 Click elements recognize that the packet is destined to

an IPv4-only node, they send the packet to GT64. The packet will be translated into an IPv4 packet, output to the IPv4 Click elements, and then routed to the IPv4-only destination node. Inside of GT64, the IPv6 packet is translated into an IPv4 packet via

several steps. First, APT translates the source address into an IPv4-mapped IPv6 address. Then, PT64 transforms the updated IPv6 packet into an IPv4 packet. In short, the packet in this example goes through the following path: Source IPv6 node => IPv6 routers ... =>

IPv6 Click Router => GT64 (APT => PT64) => IPv4 Click router => IPv4 routers ... => Destination IPv4 node.

In the above case, a packet's translation path in GT64 is (APT=> PT64). GT64 can work with any IPv6-IPv4 related translation scenario by providing different paths for flows that connect different types of nodes and require different translations.

(24)

IPv4/IPv6

Internet

INv6/v4

local net IPv4 and IPv4 and

IPv6 GT64 1Pv6

Host A aC lik Click Host B

other

othe

routine _outine

Application Level Gateway

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

Packets destined to the Internet and sourced from the local net Packets destined to

the local net

and sourced from t

Packets destined to the Internet and sourced from the local net

_Packets destined to the local net and sourced from the Internet

PT46 PT64- A

APT

PT64 4__PT46

Pacet

'Paket

dstne6t

Figure 2b. Internal Structure of GT64

(25)

Splitting address and port translation from protocol translation lends modularity and flexibility to GT64. Some translation scenarios (IPv6/IPv4 network translations) involve both address-and-port and protocol translations. Other translation scenarios involve only address-and-port translation (e.g., GT64 for an IPv6 private network connected with the IPv6 Internet) and related checksum adjustments. In these cases, only APT is on the translation path of GT64. If address-and-port and protocol translations were not separated, it would be difficult to configure GT64 to suit these scenarios.

4.1.2 Integrating GT64 into IPv4/IPv6 Click routers

As Figure 3a and Figure 3b illustrate, GT64 can be connected with Click router elements to build modular and flexible routers with NAT functionality. The Click IPv6 router outputs an IPv6 packet that needs to be translated to GT64 via an output of the

LookupIP6Route element. GT64 then directs the translated IPv4 packet to the IPv4 Click

router, which processes the packet as a normal IPv4 one. Similarly, the IPv4 router outputs an IPv4 packet that needs to be translated to GT64 via one of the outputs of the

LookupIPRoute element. GT64 then sends the translated IPv6 packet to the IPv6 Click

router. To IPv6 Router 4 . Translated IPv6 Packets: GT64 4... IPv4 packets to be translated to IPv6

IPv4 packets from Classifiers

Strip(14)

Translated IPv4 Packets from the

GT64

CheckIPHeader(...)

fm

GetIPAddress(16)

LookupIP~ot(.

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

(26)

IPv6 packets from Classifiers Strip(14) ; ..._..._ ... CheckIP6Hleader( ...) GetIP6Address(24) -01 To IPv4 Route . . Translated IPv4 Packets! G T64 ... Translated IPv6 Packets from the GT64 ... ... ... LookpIP6Route(... _ML M IPv6 packets to be translated to IPv4

Figure 3b. GT64's Connection with an IPv6 Click Router

4.1.3 Elements

The address-and-port translator (APT) is the most important element of GT64 because it performs network address and port translation. APT maintains records for active flows.

As packets arrive, APT uses their flow identification to find the corresponding mappings and translates the addresses and ports accordingly. When no mappings are found, APT creates new mappings by following certain rules. APT always translates between IPv6 address and ports of two different IPv6 address realms.

GT64's two protocol translators -PT64 and PT46 -perform packet translation between IPv4 and IPv6 protocols as well as between ICMPv4 and ICMPv6 protocols. The IPv6 and IPv4 headers are similar, but do not exactly match. Adjustments need to be made when translating from one version of IP or ICMP to the other. PT64 only accepts IPv6 packets with IPv4-mapped IPv6 addresses; PT46 only accepts IPv4 packets. Since there is a one-to-one relationship between IPv4-mapped IPv6 addresses and IPv4 addresses, the protocol translator only needs to map other fields of the headers between the two protocols. Therefore, when an IPv6 or ICMPv6 packet arrives, PT64 will translate it to an IPv4 or ICMPv4 packet by simply taking the lowest 32 bits of the IPv6 address as translated IPv4 address for source or destination. When an IPv4 or ICMPv4 packet arrives, PT46 will translate it to an IPv6 or ICMPv6 packet. It will simply translate IPv4 source or destination address to an IPv4-mapped IPv6 address by adding the 96-bit

(27)

4.2 Discussion

4.2.1 Loss of Information during Translation

The loss of information during translation is one intrinsic shortcoming of a network translator that translates between two different protocols. There are fields of IPv6 and IPv4 protocols that can not be translated simply because there are no corresponding fields in the other protocol that can carry the information. Those fields, for instance, the Type

of Service (TOS) field of the IPv4 header, have to be ignored when an IPv4 packet is

translated to an IPv6 one. The Class, Flow Label, and Reserved fields of IPv6 Header and IPv6 Fragment Header have to be ignored as well when an IPv6 packet is translated to an IPv4 one. Any network translator will have to face this structural shortcoming when translating between different protocol realms.

4.2.2 Alternatives for ALGs

GT64 can translate for packets of most protocols. However, when there are protocols that carry the IP address and port information in their payload, ALGs need to be

developed and used with GT64 to achieve complete translation. For instance, an ALG for the FTP protocol would be able to do a complete translation for an IP/TCP/FIP packet by updating values of the addresses and ports in the payload so they are consistent with those in the IP and TCP headers. The design and implementation for ALGs is, however, beyond the scope of this research. In addition, new IPv6 applications that are IPv4-aware, e.g., FTP, can detect whether the connection is with an IPv6 or IPv4 version of the ftp daemon. When communicating with an IPv4 ftp daemon, it needs to use an IPv4 address instead of the host's original IPv6 address. Conversely, if an IPv4 ftp client contacts an IPv6 ftp daemon, the daemon must treat the IPv4 address in the payload as an

IPv4-mapped IPv6 address. Therefore, the network address-and-port translator often

does not need to update IP addresses in the application payload. If all applications that embed IP addresses did their own address translation in this way, then there would be no need for GT64 to include ALGs to deal with application level translation.

4.2.3 Incorporating Hostname Lookup

Completely transparent IPv6/IPv4 translation requires GT64 to be used with some mechanism that has DNS lookup ability, since some applications require that a host first look up another host's address before initiating a session with the other host. The IPv6 site's DNS server should be an IPv6/IPv4 node so it can forward DNS request from internal IPv6 hosts to external IPv4 DNS servers. Since each IPv4 node has a unique IPv6 address (either IPv4-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 to initiate communication with a node in the IPv4 world, it first looks up the "AAAA" record of the IPv4 node at the local DNS server. If the IPv6 site's local DNS server has an "A" record of the IPv4 host, it will also have an "AAAA" record with IPv4-mapped

(28)

IPv6 address, and thus it will return an IPv6 address of the IPv4 host. Otherwise, the

local DNS server will communicate with the IPv4 world to get an "A" record, translate it to an "AAAA" record, and send the "AAAA" record to the internal client.

However, the converse direction (an IPv4 host looks up an IPv6 host) is much more difficult. Because an IPv6-only node doesn't have an IPv4 address, each "AAAA" record does not have a corresponding "A" record. To solve the problem, there are several approaches that translate an IPv6 DNS record to an IPv4 DNS record. First, the resolver library in IPv4 nodes can be modified to request the alias (a temporary IPv4 address for the IPv6 node) from GT64. Second, the IPv6 site's DNS server can be modified to request a temporary address from GT64 on behalf of its IPv4 clients. The third approach requires GT64 to recognize DNS request and response packets and to translate them transparently. For a detailed description of DNS extension for network address translators, please refer to [RFC 2694].

While the first two approaches involve modifying end nodes, which is not completely transparent translation, the last approach fits in the design of GT64. It can be done in a DNSALG. GT64 does not currently do this translation, but could be modified to do it. 4.2.4 TCP/UDP Checksum and Fragmentation Handling

After address and port translation, GT64 needs to update the TCP/UDP checksum fields. TCP and UDP compute their checksum values on a pseudo-header that consists of fields

(including addresses) from the IPv4/IPv6 header as well as the TCP/UDP header and payload. The change of the address and port value affects the value of the checksum. PT64 and PT46 calculate both IP/IPv4 and TCP/UPD checksums after their protocol translation.

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

This project does not deploy the incremental checksum adjustment algorithm for checksum calculation, which can correctly reflect the change of address and port, even for fragmented packets. As soon as the incremental checksum adjustment algorithm is implemented, the translation for fragmented packets should be easily accomplished.

(29)

Chapter

5. The Address-and-port Translator

This chapter describes details of the address-and-port translator (APT). Section 5.1 introduces the design of the APT, and Section 5.2 shows how to configure the APT. Section 5.3 then illustrates implementation details by demonstrating the structure of the APT mapping tables and the processes of address lookup, address binding, address unbinding, and checksum-updating. Section 5.4 describes how the APT can be used by GT64.

5.1 Design of the Address-and-port Translator

5.1.1 Function of the Address-and-port Translator

When a host inside a GT64 needs to communicate with the outside world, GT64 has to temporarily allocate a global address to make the node recognizable to the outside world. If several internal nodes need to communicate with the outside world but there is only one global address, each individual connection can be temporarily allocated with a distinct address-and-port pair so that these internal nodes can share the same global address. For instance, an IPv6 local network usually only has a few IPv4-mapped IPv6

addresses available when communicating with the global IPv4 Internet, while there are

far more internal nodes. APT resolve the resource limit by letting a set of local IPv6 hosts to share a single IPv4-mapped IPv6 address, i.e. the transport identifiers of these internal IPv6 hosts are multiplexed into the transport identifiers of the IPv4-mapped IPv6 address. APT uses the address-and-port pair to replace the original source address and port for packets that are destined to outside world. This function of APT is called address-and-port translation.

APT decides how to allocate such temporary address-and-port pairs for outgoing connections. Moreover, it remembers the allocations and always replaces the internal

source address-and-port with the same mapped address-and-port pair for packets of the same flow. Here, if two packets have the same identifiers, i.e., source address, source port, destination address, and destination port, they belong to the same flow. Moreover,

on the reverse direction, the APT uses a reverse mapping to replace packets' destination address-and-port with the internal node's address-and-port pair.

When APT receives an IPv6 packet, it replaces the original flow ID of the packet with the mapped flow ID. The mapped flow ID uses some other address-and-port pair to replace the source address-and-port pair or the destination address-and-port pair of the packet. The configuration string of the address-and-port translator determines how the

replacement is conducted. In addition to the dynamic address-and-port allocation described above, the APT can deal with other simplified forms of address-and-port

(30)

translation, such as static address translation and dynamic address-only translation. Those forms will be described later.

APT accepts outward packets and inward packets, but treats them differently. APT is usually configured to only allocate dynamic mappings for packets of certain direction. Thus, flows initiated from the other direction will not be able to be allocated with mappings. Outward packets are those packets that originate from the local network and destined to some host on the Internet (IPv4 or IPv6), while inward packets are those packets that originate from the outside world and destined to some host in the local network. APT has two inputs and two outputs. It accepts outward and inward packets from different inputs and directs them to different outputs after translation.

5.1.2 The IPv6 based Address-and-port Translator for IPv4/IPv6 Translation APT only accepts and outputs IPv6 packets with IPv6 addresses. In order for GT64 to work for IPv4/IPv6 translation scenarios, GT64 temporarily allocate IPv4 addresses to internal IPv6 hosts when they communicate the IPv4-only hosts. The IPv6-based APT achieves this by assigning IPv4-mapped IPv6 addresses for the internal IPv6 hosts. When GT64 translates an IPv6 packet to an IPv4 packet, APT first maps the source or destination IPv6 address and port to an IPv4-mapped IPv6 address and a port. PT64 then translates the IPv6 packet to an IPv4 packet and translates the IPv4-mapped IPv6

addresses to IPv4 addresses.

When GT64 translates an IPv4 packet to IPv6, PT46 maps IPv4 addresses into

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 ports statically as well as dynamically, called static mapping or dynamic mapping functions respectively. Static mapping refers to the static relationship between internal address-and-port pairs and the mapped address-and-address-and-port pairs. In most case, static mapping is used for address-only mapping, i.e., certain external addresses will be reserved for particular internal addresses. Contrary to the static mapping, dynamic mapping only keeps

mappings for active flows.

5.1.4 Dynamic Address-only vs. Dynamic Address-and-Port Mapping

Dynamic address-only translation allocates only the global addresses instead of the address-port pairs dynamically. APT will then use the mapped address to represent the internal node to communicate with the outside world. As we described above, dynamic

address-and-port mapping replaces the original flow ID with the mapped flow ID that has a different address-and-port pair for either source or destination. However, dynamic

(31)

items of the flow ID the same. For an outward packet, it replaces the source address with the mapped global address; for an inward packet, it replaces the destination address with the internal node's address.

5.2 Configuration

5.2.1 Configuration String

A user controls the APT using a configuration string, which specifies the mapping rules for both static mapping and dynamic mapping. The arguments of a configuration string are separated by commas, as illustrated by Figure 4a. Figure 4b shows an example of an APT configured for a local IPv6 net connected with the IPv4 Internet. The APT is configured for static address mapping and dynamic address-and-port mapping.

First, the configuration string specifies the number and rules of static mapping. The first argument is the number of staticMappings. The second argument staticPortMapping is

a boolean which indicates whether or not APT does static port mapping. In Figure 4b, the first argument number_ofstaticMappings has the value "1", which means one static mapping exists. The second argument staticPortMapping has "0" value which states that

APT will do address-only mapping for static translation. APT (number-ofstaticMappings, staticPortMapping StaticMappingl,... StaticMappingm, dynamicMapping dynamicPortMapping, addressAllocationDirection, Mapped_IP6Addressl, Mapped_IP6Address2, MappedIP6Addressn) APT (numberofstaticMappings, staticPortMapping StaticMapping],... StaticMappingm, dynamicMapping dynamicPortMapping, addressAllocationDirection,

MappedIP6Address Portstart Portend)

Figure 4a. Format of a Configuration String for an APT

Note: The top figure is the format for an APT configured for static address mapping and dynamic address-only mapping ; the bottom figure is the format for an APT configured for static address mapping and dynamic address-and-port mapping.