DTTS: A Transparent and Scalable Solution for IPv4 to IPv6 Transition

Transcription

1 DTTS: A Transparent and Scalable Solution for to Transition Kai Wang, Ann-Kian Yeo, A. L. Ananda Center for Internet Research School of Computing National University of Singapore 3 Science Drive 2, Singapore {wangkai1, yeoak, ananda}@comp.nus.edu.sg Abstract - to transition is an inevitable process when deploying networks within the present Internet. The transition process is complex as it has to deal with issues related to - interoperability including routing, DNS, error handling, etc. In this paper, a new solution named DTTS (Dynamic Tunneling Transition Solution) for to transition based on dynamic tunneling technique and dual stack approach is presented. Dynamic tunneling technique is used to encapsulate an packet in an packet to achieve transparent and scalable transition. This technique, coupled with the dual stack approach, enables applications to run and interact with other applications in both and network environments without any modification and recompilation, and without NAT, nor any application proxy or gateway. Keywords: Interoperability,,, Transition, Dynamic Tunneling, Dual Stack. I. INTRODUCTION [1] and protocols do not interoperate, and hence applications do not work in environment and vice versa. However, the deployment of within the present Internet will be on an incremental basis and start from small networks that merge into the global network gradually. It is envisaged that a short-medium term coexistence of both and is inevitable. During the transition phase, due to lack of applications and services, any transition solution should incorporate mechanisms for existing applications to run in networks. The fundamental question that needs to be addressed is: How to enable transparent communication between the existing network and the new network?[17] To date, a set of to transition mechanisms and tools have been put forward to address the above issues. Of the known mechanisms, which are discussed in Section V, both NAT-based and proxy-based techniques have inherent weaknesses that deter their full-scale deployment. For example, some lack an end-to-end IP communication, or others require application gateways for address translation. In addition, none of these mechanisms scales well. In this proposal, our motivation is to design a viable solution: i) to enable transparent end-to-end IP communication between nodes and nodes; ii) to be capable of scalable deployment; iii) to enable based applications to run in networks seamlessly. In order to achieve theses goals and enable incremental deployment of networks within the based Internet, we have proposed a new solution named DTTS (Dynamic Tunneling Transition Solution). DTTS employs the dual stack approach coupled with dynamic tunneling technique to offer a transparent and scalable to transition. In DTTS, each host uses a private address[9] and a dynamically assigned global address to enable end-to-end IP communication. With this solution, users in new networks could obtain service from the existing Internet, and users in the Internet could communicate with the newly deployed networks. Moreover, more than one border routers equipped with DTTS, which serve as tunnel endpoints, could be deployed on the and network boundary. If one of the border routers fails, the - communication could still continue. Thus, this improves overall system reliability. The rest of this paper is organized as follows. Section II introduces DTTS, followed by a detailed description of various aspects of DTTS including address allocation, dynamic tunneling technique, DNS, ICMP, and routing issues. Section III describes the implementation and prototype system. Section IV discusses the limitations of DTTS and its deployment strategies. We present some related work in Section V and conclude with future work in Section VI. II. SYSTEM OVERVIEW InDTTS,eachhostinannetworkhasdualstacks ( & ). Only traffic is supported within the network, and routers understand only protocol. Border routers that also have dual stack connect to both and networks as showed in Fig. 1. For end-to-end IP communication between and hosts, the dynamic tunneling technique is used to encapsulate packets in to travel in the network based on routing without tunnel endpoint configuration. Border routers serve as tunnel endpoints and forward packets to networks and vice versa. When a border router receives tunnel packets, it decapsulates the tunnel and forward them to networks. On the other hand, when a border router receives packets, it encapsulates them with the tunneling and transmits to the host. The encapsulation effectively suppresses the direct movement of packets within an network, and instead allows their movement based only on routing tables, thereby simplifying the network management. Within the network, each dual stack host communicates only in or -encapsulated packets. An application running on an node uses either a private address to talk to another application within the network; or use dynamically assigned public /01/$10.00 (C) 2001 IEEE 248

2 addresstotalktoanotherapplicationintheinternet. Since only packets are allowed within the network, all private-address or public-address packets within the networkmustbeencapsulatedwithswith the help of dual stack approach and the dynamic tunneling technique. node A (Dual stack) -only Router R2 Address Allocation Server node B (Dual stack) Network -only Router R1 -only Router R3 Private DNS Server Global Address Pool Border Router BR (Dual stack) DNS Proxy - address mapping table DNS Server Network node C Fig. 1. A generic transition environment Fig. 1 shows DTTS with its components: Dualstackhost:ahostinannetworkwithboth and stacks. Both and based applications can run on this host. Address Allocation Server (AAS): a server which can dynamically allocate addresses to dual stack hosts from its global address pool. Private DNS server: a BIND server providing normal DNS functions that can resolve both private addresses and addresses for the network. Border router: a dual stack router sitting on the boundary between an and an network. The router maintains an - address mapping table for each outbound and inbound packet. A DNS proxy running on the border router relays DNS messages to/from the private DNS server. The following three typical communication scenarios are considered while describing components of DTTS: -to- scenario: the communication from a dual stack node in the network to an node in the Internet, e.g., node A to node C via border router BR. -to- scenario: the communication from an node in the Internet to a dual stack node in the network, e.g., node C to node A via border router BR. -to- scenario: the communication from a dual stack node to another dual stack node in the network, e.g., node A to node B via -only router R2. A. Dual Stack Hosts Address Allocation A dual stack node in DTTS has both and addresses assigned to its interfaces. Each node has a private address assigned either statically or through a DHCP server. Private addresses are used by applications in the -to- scenario. This includes DNS resolutions requested by applications to the private DNS server. A node may also be assigned dynamically a public address by the AAS (see Section III). Public addresses are used in -to- and -to- scenarios. As far as address is concerned, each interface of an node can have multiple addresses, for example, link local address, site local address, aggregatable global unicast address[10], etc. In DTTS, each host is assigned an -compatible address[10], which is constructed by prepending a null prefix, made of 96 zero bits, to a 32-bit private address. -compatiable addresses are used for -to- scenario. Also, each host is assigned a site local address through stateless autoconfiguration mechanism[11]. Site local addresses are used for -to- and -to- scenarios from hosts to border routers and vice versa. B. Dynamic Tunneling Technique With DTTS, the protocol layer is considered as a link layer for the protocol layer. The encapsulation of packets in packets coupled with dual stack helps in deploying applications in an network node and also to eliminate routing in the network. Fig. 2 depicts the general protocol layers of a dual stack node. TCPv4 Application (HTTP, FTP) Data Link Layer ( Ethernet ) TCPv6 Fig. 2. General protocol layer of a dual stack node We use the term dynamic tunneling to emphasize its characteristics distinguished from the traditional tunneling technique. Traditionally, a tunnel is a point-to-point link between two tunnel endpoints. Before setting up a tunnel, the tunnel entrypoint and endpoint addresses are obtained through manual configuration or other dynamic methods. But the tunnel lacks flexibility and the router which serves as tunnel endpoint is a single point of failure. On the other hand, dynamic tunneling technique employed by DTTS need not know the tunnel endpoint addresses before setting up the tunnel, thus enhances the system scalability and flexibility. The detailed tunneling processes are considered in the following subsections for host-to-host, host-to-router and route-to-host tunneling modes. 1) Host-to-host Tunneling Mode Host-to-host tunneling mode is used in the -to- communication scenario and is very straightforward. When an packet reaches the layer, its source and destination addresses are already known. No other process is 249

3 needed but to insert 96-bit zeros before the source and the destination address to complete the encapsulation. Since each node within the network has been configured with an -compatible address, tunnel packets reach the destination host directly. Fig. 3 illustrates the encapsulation process. The source address is the site local address of the border router. Fig. 5 illustrates this encapsulation process. subnet bit of the Border Router SA: DA: EUI-64 interface ID Header Payload SA: /24 DA: /24 Header Payload SA: fec0::2:2d0:b7ff:fe6b:ca1b/64 DA: fec0::0:200:94ff:fea9:9f62/64 Tunnel Header Packet SA: :: /120 DA: :: /120 Tunnel Header Packet obtain the address from the address mapping table ( the address binding pair of ) Fig. 3. A host-to-host encapsulation process example 2) Host-to-router Tunneling Mode The host-to-router tunneling takes place in the -to- and -to- communication scenarios, as packets are tunneled from hosts to border routers. At the sending host, when packets reach the link layer, the destination address of the tunnel is constructed as an site local address. This site local address consists of site local address prefix(fec0), subnet bit and 64- bit interface ID. The subnet bit is selected differently from all existing local subnet bits for uniquely indicating the outbound communication. The administrators can designate it randomly provided that the packets with that 64-bit prefix could be routed to border routers. In DTTS, for indicating the destination, the last 64-bit is constructed with 32-bit zeros and the 32-bit destination address. The source site local address is just the site local address of the node s interface. It is selected automatically based on source address selection. Fig. 4 illustrates this encapsulation process. site local prefix subnet bit EUI-64 interface ID SA: fec0::0:200:94ff:fea9:9f62/64 DA: fec0::ff00:0:0:bca6:20a/64 subnet bit SA: DA: Tunnel Header Header Packet the construted interface ID from the DA. ( in this case: ) Fig. 4. A host-to-router encapsulation process example Payload The merit of this encapsulation process is that hosts need not be configured statically or through other dynamic methods with the tunnel endpoint address to proceed with tunneling. packets are routed to border routers based on routing. The routing issues are discussed in subsection E. 3) Router-to-host Tunneling Mode The router-to-host tunneling mode is used in the -to- and -to- communication scenarios, as packets are tunneled from border routers to the destination host. For the tunnel, the destination address is obtained from the address binding records in the - address mapping table maintained by the border router. Fig. 5. A router-to-host encapsulation process example C. DNS Issues DNS is the most important and integral part for to transition. name to address mappings are held in DNS as A records. name to address mappings are held in DNS as AAAA [12] or A6 [13] records. In DTTS, the private DNS server (e.g. BIND which is capable of resolving A, AAAA and A6 records) must run on a dual-stack node in the network. Its role is to resolve both private and public and DNS queries. Private and records are configured in the DNS server for the hosts in the network. Public records of hosts in the Internet are stored in the cache when the private DNS server obtains them through referral to an authoritative server in the Internet. Hence, this private DNS server acts as the authoritative server for the private and domains within the network. For the -to- and -to- scenarios, no special handling of DNS resolution is required. This is because applications uses resolver library to send packets to the private DNS server via host-to-host tunnel in the network. On the other hand, for the -to- scenario, a DNS request for an node originated from an node essentially needs to be resolved to its temporarily assigned public address for the node. A DNS proxy is running on the border router to act as the authoritative DNS server (in the public domain) for the pool of public addresses possessed by the AAS. When the DNS proxy receives an unresolved DNS request from the Internet in the -to- scenario, it triggers a series of translation processes. Basically, the DNS proxy is a faked DNS server serving as a translator between DNS messages of networks and DNS messages of networks. It establishes its own policy to filter and translate the payload of DNS packets. It helps translate name-to- mappings in DNS payloads into name-to-global address mappings using the address mapping states on border routers. The DNS proxy is merely a DNS relay server and it does not maintain a DNS databases. It has to cooperate with the AAS and the private DNS server to resolve all DNS requests. Fig. 6 depicts the DNS proxy filtering & translation process without dwelling into its detailed algorithm. One must note that the TTL values should be left unchanged for statically mapped addresses. The TTL values on all DNS resource records which are temporarily 250

4 assigned to hosts should be set to 0 so DNS servers/clients do not cache them. For compatibility with broken implementations, TTL of 1 might in practice work better[19]. Other types (CNAME, MX, etc. ) Othet type filtering & translation A A type filtering &translation get the DNS request request type? PTR PTR type filtering & translation NS NS type filtering & translation Fig. 6. DNS proxy s filtering & translation process D. ICMP Issues For achieving transparent communication, ICMP messages have to be handled differently depending on the origination of ICMP error messages. 1) ICMPv4 Messages Generated Outside the Tunnel The ICMPv4 messages generated outside the tunnel include the error messages generated in the network side, and the errors generated on the layer at dual stack nodes. In this case, ICMPv4 messages are treated as normal traffic from an node and are tunneled to the source host. 2) ICMPv6 Messages Generated within the Tunnel The most difficult problem to address is ICMPv6[14] messages generated within the network for the packets carrying payload. An ICMPv6 message sent to the tunnel entry-point node has an ICMPv6 payload which includes the tunnel packet as its payload. After it is transferred to the tunnel entry-point host, it is handled as follows. For the -to- scenario and -to- scenario, the tunnel entry-point is just the original source host, so the host decapsulates the tunnel, translates it to an ICMPv4 message, and sends it to the layer on the host. For the -to- scenario, an ICMPv6 message is first transferred to the border router, then the border router decapsulates its tunnel, translates it to an ICMPv4 message, and at the end forwards the ICMPv4 message to the original source host. Fig. 7 depicts the ICMPv4 message creation process[15]. As far as the ICMP message translation is concerned, the ICMPv6 error messages such as hop limit exceeded and unreachable node are translated into ICMPv4 messages with type 3(destination unreachable) and code 1(host unreachable) respectively. E. Routing Issues In DTTS, there is only routing infrastructure in networks, and routing infrastructure in networks. With the dynamic tunneling technique, tunneling packets are forwarded by routers as normal packets. New New ICMP + tunnel ICMP Tunnel paket in error + + Original Original packet payload Original pacet in error New ICMPv4 packet Fig. 7. An ICMPv4 message creation process 1) Routing Configurations on Hosts With respect to the encapsulation processes described in subsection B, the following two route entries are needed in the routing table of hosts: The route entry for reaching the nodes in other subnets connected with -only routers. This entry is for -to- scenario in which case the host-to-host tunneling is used for the entire path from the source node to the destination node. The default route entry. The default tunnel route is used to encapsulate all outbound packets destined to networks. This entry is for -to- and -to- scenarios in which the host-to-router tunneling is used for the path from the source host to the border router. 2) Routing Requirements on Border Routers Border routers in DTTS connect two different routing regions, that is, an and an routing region. A border router must: for routing, advertise reachability for the public addresses belonging to the address pool of the AAS into the routing region; for routing, advertise reachability for its dedicated 64-bit site local prefix into routing region. III. IMPLEMENTATION AND PROTOTYPE SYSTEM DTTS described in this paper has been implemented on Linux kernel version The dynamic tunneling function is realized as a software device in kernel module level. Both border routers and hosts in DTTS should load this module into the system to achieve encapsulation and decapsulation. On an host, a user-space Address Allocation Client daemon, acting as the interface between the dynamic tunneling module in kernel and the AAS, is serving to complete the address application and address initialization tasks. On a border router, an Address Mapping Table Operation daemon is running to update the address mapping table based on the multicast messages from the AAS. A DNS 251

5 proxy daemon, sitting on the border router, intercepts DNS messages directed to or from networks and performs transparent payload translation so that hosts in networks have the right address mappings within address realm. AAS possesses a pool of public addresses for dynamic assignment to clients and keeps track of addresses assigned to hosts. Basic renewing, reclaiming and timing function are also included. Besides the address assignment, the AAS is designed to be a central control point for the address mapping tables on all deployed border routers. When the AAS assigns an address to an host, it informs new address binding record to Address Mapping Table Operation daemons on border routers via multicast mechanism simultaneously. With the table synchronization mechanism, all address mapping tables could be assured to keep consistent address binding records. This guarantees that packets are tunneled to hosts correctly via any border router. WehavesetupantestbedasdescribedinFig.1 within the departmental intranet and deployed DTTS prototype system in the network. On our dual stack Linux nodes in the network, we used available applications to communicate with the Internet. We could visit dual stack hosts within our testbed from the Internet seamlessly. None of programs required any modification and/or recompilation to enable them running in the network. We have tested some basic network applications such as telnet, ftp, , WWW, and we also ran version X-windows program from our testbed to access the Unix servers on the network. The performance was acceptable except for the initial delay in assigning a public address to an host. The implementation has successfully demonstrated that the DTTS can provide a transparent communication between and nodes, as well as guarantee end-to-end IP connection. IV. DISCUSSION In this section, we discuss the limitations of DTTS and issues related to its deployment strategies. A. DTTS Limitations Firstly, DTTS requires a pool of global addresses for dynamic assignment to inbound and outbound communications with networks. Because of the limited addresses in the pool, the maximum number of communication sessions is fixed. When the number of sessions outstrip a specified level, denial-of-service will occur because of lack of addresses, in a way similar to NAT-based solutions. However, we argue that this limitation is not worse than the current NAT solutions; moreover DTTS does provide end-to-end IP communication. Secondly, in DTTS, each host in network has to be installed with DTTS components which are platformdependent. In addition, with an upgrade of OS, some DTTS components also need to be upgraded as well. However, if DTTS can be accepted as a standard and supported by major vendors, this will not be a problem. B. DTTS Deployment The transition is a gradual process, and it needs a staged transition plan, especially for large organizations. The solution offered by DTTS enables applications to run in networks without any modification and/or recompilation. This allows one to take advantage of abundant applications when deploying, thus helps speeding up its deployment. In addition, legacy applications can still run after some network infrastructure is upgraded to, thus users present investment can be protected without hampering the deployment. In general, deploying DTTS within the present networks includes the following steps: 1) Upgrade all nodes within a chosen subnet to dual stacks; 2) Upgrade all the routers within the subnet to -only routers; 3) Configure all hosts with DTTS client modules and AAS client programs; 4) Upgrade border routers with DTTS server modules, DNS proxy applications and Address Table Mapping daemons; 5) Deploy AAS servers with a public address pool within the subnet. After applying the above steps, an existing subnet will become an subnet like an island. With the maturity of, these islands can eventually merge into a pure network. V. RELATED WORK In this section, we review some related works proposed under IETF Next Generation Transition Working Group(Ngtrans)[17]. Dual stack[2] mechanism is one of two basic transition mechanisms, which mandates the complete support for both and in hosts and routers. But it does not reduce the demand for globally routable addresses and increases the network complexity due to the need for a mixture of androutinginfrastructure. Application Level Gateway(ALG), SOCKS64[3] and TCP- Relay[4] are proxy-based mechanisms which can provide communication between nodes and nodes. They all split one IP connection into two closed connections on application or TCP layer, one is in the network and the other is in the network. Their common demerit is that they break the end-to-end principle of the Internet, which is important aspect for e-commerce and business communications. ALG is an application-dependent mechanism, which means for the different applications it should provide different application gateway components. SOCKS64 can only be for sockcified sites consisting of SOCKS aware clients and a SOCKS server. NATPT[6] is derived from the traditional NAT[16] mechanism, plus protocol translation between and protocol. BIS[7] adds an address translator module into the node ssystem,cooperatedwithanaddressmapperandan 252

6 extension to the name resolver, to facilitate the transition. SIIT[5] provides a flexible and stateless translation between and, but it is incomplete since it does not specify how the packets with -translated address to be routed in the network. These three mechanisms can be thought as NAT-based mechanisms, so they have the inherent NAT deficiencies. NAT-unfriendly applications can not pass through the translator box without involvement of application level gateways. At the same time, NAT-based mechanisms also have the same demerit as proxy-based mechanisms as far as the end-to-end communication is concerned. Further, any solution based on NAT boxes is inefficient and not scalable. DSTM[8] suggests a dual stack approach with dynamically assigned addresses and the use -over- tunneling to help transition, but it only provides the limited communication scenario and lacks flexibility since hosts have to obtain a tunnel endpoint address somehow before setting up an -over- tunnel. In summary, DTTS is not a proxy-based nor NAT-based mechanism, so it does not have such inherent weaknesses mentioned before. DTTS is very similar to DSTM, but we have not found a DSTM implementation. In addition, DTTS hires dynamic tunneling technique, this makes it more flexible and stable than DSTM. VI. CONCLUSION AND FUTURE WORK In this paper, we have presented a new to transition solution called DTTS for achieving dual stack nodes to communicate with nodes in network using dynamic tunneling technique. Compared with other related works, DTTS has several obvious advantages: transparent end-to-end IP communication, scalable deployment, and most importantly, running of applications in an environment seamlessly. We have implemented a prototype system and tested its functions in our testbed. We believe DTTS as an to transition solution has great potential to speed up deployment. We plan to port DTTS to other OSs like Windows and Solaris and to add system security mechanism into public address application and allocation process. ACKNOWLEDGMENT The authors would like to acknowledge the School of Computing, National University of Singapore, and the management committee of SingAREN ( net.sg) project for supporting this work. We would also like to thank Zit-Seng Lai and Budiman Tsjin for suggestions and discussions. REFERENCES [1] S. Deering, R. Hinden, Internet protocol, version 6 () specification, RFC2460, December [2] R. Gilligan, E. Nordmark, Transition mechanisms for hosts and routers, RFC2893, August [3] H. Kitamura, A. Jinzaki, S. Kobayashi, A SOCKS-based / gateway mechanism, Internet Draft(draft-ietf-ngtranssocks-gateway-06.txt). [4] J. Hagino, K. Yamamoto, An -to- transport relay translator, Internet Draft (draft-ietf-ngtrans-tcpudp-relay-01.txt). [5] E. Nordmark, Stateless IP/ICMP translation algorithm (SIIT), RFC2675, February 2000 [6] G. Tsirtsis, P. Srisuresh, Network address translation - protocol translation (NAT-PT), RFC2766, February [7] K. Tsuchiya, H. Higuhi, Y. Atarashi, Dual stack hosts using the Bump-In-the-Stack: technique (BIS), RFC2767, February [8] Jim Bound, Laurent Toutain, Hossam Afifi, Francis Dupont, Alain Durand, Dual stack transition mechanism (DSTM), Internet Draft (draft-ietf-ngtrans-dstm-04.txt). [9] Y. Rekhter, B.Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear, Address allocation for private internets, RFC1918, February [10] R. Hinden, S. Deering, IP version 6 addressing architecture, RFC2373, July 1998 [11] S. Thomson, T. Narten, statelesss address autoconfiguration, RFC2462, December [12] S. Thomson, C. Huitema, DNS extensions to support IP version 6, RFC1886, December [13] M. Crawford, C. Huitema, DNS extensions to support address aggregation and renumbering, RFC2874, July [14] A. Conta, S.Deering, Internet control message protocol (ICMPv6) for the internet protocol version 6 () specification, RFC2463, December, [15] Conta, S. Deering, Generic packet tunneling in specification, RFC2473, December [16] P. Srisuresh, M, Holdrege, IP network address translator(nat) terminology and condiderations, RFC2663, August [17] I. Guardini, Migrating from to : planning an effective transition, May 2000, /globalipsummit-v6trans/ipv6-transition-summary.html. [18] IETF Next Generation Transition working group, [19] P. Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan, DNS extensions to network address translators (DNS_ALG), RFC2694, September