INTERNET-DRAFT Laurent Toutain NGTRANS Tools Working Group Hossam Afifi December 18,1998 ENST Bretagne expires in 6 month Dynamic Tunneling: A new method for the IPv4-IPv6 Transition Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress. To view the entire list of current Internet-Drafts, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract We propose to use an IPv6 tunneling mechanism and encapsulate IPv4 packets into IPv6 packets. This eases the transition and routers do not need to support IPv6 and IPv4 routing tables. The IN_ADDR.arpa domain is used to find IPv4 to IPv6 correspondence in a way that does not prevent the asymmetrical routing and multi-homing. The model also simplifies IPv4 address management since the address has no more a localization function but only an identification function. 1. Introduction The co-existence of IPv6 with IPv4 will be a temporary phase before a progressive transition to the IPv6 protocol even if no limit has been set for the transition period. The first phase in the transition was to install new IPv6 subnetworks connected by tunneling justified by the relatively small number of IPv6 networks compared to the global internet. The goal of this work is to propose a simple and flexible Toutain & Afifi [Page 1] Internet Draft IP Dynamic Tunneling Expire 6/99 interconnection mechanism where IPv6 and IPv4 networks can be separated, but where IPv6 and IPv4 applications can transparently exchange information. This gives the opportunity to use IPv6 in combination with other protocols for a more flexible routing. The next section introduces native IPv6 networks and hosts and places the study in its context. First we describe the model we choose to study. We analyze current transitions propositions. In a second part we describe the proposal. We cover the cases where connections are initiated from the IPv6 and from IPv4 sides respectively. 2. Transition Model In our view a general model describing the transition period is depicted in figure 1. We consider a domain running mostly IPv6 but where some IPv4 equipments or applications still remain used. This domain is connected to an IPv6-only provider. Somewhere on the network a third party provider is able to link the IPv4 and IPv6 domains. We solve the case where IPv6 equipment must talk with equipment in IPv4-only domains and vice versa. We suppose that no change can be made to the IPv4-only equipment and applications. The transition mechanism must be as transparent as possible to keep the advantages of the IPv6 autoconfigation. +------+ +-----+ +-----+ +-----+ +-----+ | DNS |....| DNS |....| DNS |....| DNS |....| DNS | | v6 | | | | | | | | v4 | +------+ +-----+ +-----+ +-----+ ------+ +---------------+ +-----------+ +------------+ | |....|dti-tunnel |....| | | | |provider y | | | | | +-----------+ | | | | | | | IPv6 | | ipv4-only | | network | +-----------+ | network | | |....|dti-tunnel |....| | | | |provider x | | | +---------------+ +-----------+ +------------+ A DNS is running on each domain. Queries to the DNS are done in the respective native protocol (we suppose that they are interconnected but the way of interconnection is beyond the scope of this draft). 2.1 The double stack Toutain & Afifi [Page 2] Internet Draft IP Dynamic Tunneling Expire 6/99 [RFC 1933] defines a transition mechanism based on a double stack. A host will either send packets in IPv4 or IPv6 depending on the protocol used by the destination. The IPv4 mapped addresses allow applications compiled with IPv6 system calls to talk with IPv4 only applications. This method is currently used in the early phase of the transition. The main drawbacks are the following. An IPv4 address must be allocated to each equipment. If we map this onto our transition model previously described, it means that the IPv6 domain is included in the IPv4 world. Routers must be configured for the two protocols and IPv4 applications must be slightly modified and recompiled to be adapted to the IPv6 API. 2.2 The SIIT proposal This proposal is similar to Network Address Translation (explained later), used in IPv4 networks to exchange a private IPv4 address to a public IPv4 address. It is difficult with the SIIT proposal to deal with applications sending addresses (such as FTP or RTP flows). In that case, some Application Level Gateways acting as proxy will be required. The proposal focuses on separate IPv6 and IPv4 domains. If in the IPv6 domain some equipment wants to talk with an IPv4 domain, it will use an automatic IPv4 address allocation of the double stack. In that case, routers will have to administrate IPv4 and IPv6 routing tables. Like NAT (described hereafter), this is a one way translation. It means that outside IPv6 domains, IPv4 applications cannot initiate communications with IPv6 hosts. The context for header translation in the SIIT box can be established only when an exiting IPv6 packet leaves the domain. 2.3 The NATPT Proposal Unlike SIIT [SIIT], NAT-PT is designed to provide transparently end- to-end solutions. A pool of IPv4 addresses is used to be assigned to IPv6 hosts dynamically in response to any request for packets leaving one of the boundaries. These assigned addresses in turn are used to transparently replace the original addresses used by IPv6 end nodes and vice versa. This proposal allows translation in both ways since the context inside the transition box is this time established by the DNS. NATPT does not solve the problem of applications sending IP addresses in the payload. DNS and NATPT must be combined to allow the establishment of the context. This is generally not the case if the translation is not directly made by the IPv6 domain. The DNS request Toutain & Afifi [Page 3] Internet Draft IP Dynamic Tunneling Expire 6/99 may follow another path that does not go through the third party provider assuring the transition. 2.4 The AIIH Proposal The AIIH proposal aims at using a combination of DHCPv6 and the DNS to establish a transition between IPv6 and v4 in both directions. This proposal is complementary to the NAT -PT and SIIT since it focuses on topology where IPv4 and IPv6 are in the same domains. For an IPv6 host to participate in the AIIH mechanism, it MUST have a dual IP layer, supporting both an IPv4 and IPv6 stack. When an IPv6 host wants to talk with an IPv4 one, the DNS will not answer with an IPv6 record but with an IPv4 one. The IPv6 will request a temporary IPv4 address. Mechanisms such as DHCP are currently available to do such assignment. The opposite case, where an IPv4 host wants to talk with a IPv6 host is more difficult to solve since no protocol is currently available to do a automatic assignation. In our view, there are two main drawbacks in this proposal. The router must be configured both for IPv4 and IPv6 protocol and the assignment of IPv4 addresses is difficult since the network topology must be taken into account. 3. The Dynamic Tunneling Interface In the IPv6 case networks are largely spread, we propose to reverse the tunneling and encapsulate IPv4 packet into IPv6 packets. This would ease the transition since routers need only to be configured with IPv6 routing tables. The case of dynamic attribution of IPv4 addresses will also be simplified since the address has no longer a localization function but only an identification function. The system has just to maintain uniqueness of the address allocation. We think this method can be used either in domains where IPv4 applications cannot be recompiled, but where the system stack can be changed to take benefit from an IPv6 network or with IPv4 only legacy equipment. We will explain later scenarios where an IPv4 only domain wants to join an IPv6 equipment. 3.1 IPv6 to IPv4 We start describing the general procedure for an IPv6 host to communicate with an IPv4 only application. From our assumptions we suppose that the IPv6 equipment MUST support a dual stack. When an equipment wants to join an IPv4 host, it may directly use an Toutain & Afifi [Page 4] Internet Draft IP Dynamic Tunneling Expire 6/99 IPv4 address or resolve a domain name from the DNS and obtain the correspondent IPv4 destination address. We propose to intercept the packet in a new interface that we call dti for dynamic tunneling interface. It may be intercepted by the host through the IPv4 routing table lookup or through dynamic network libraries hookups but this is implementation dependent. We try hence to offer transparently the dti functionalities with no changes in the applications. The main difference with AIIH is that IPv4 packets will not be directly sent over the network but first filtered by the dti. The dti interface systematically encapsulates the IPv4 packet into an IPv6 packet. It needs to find the destination IPv6 address and also needs to obtain for itself an IPv4 address. We propose to use the DNS to make this resolution. The procedure is explained later. Once a result is obtained, it should be cached after the first resolution. There are many possible results for this IPv6 resolution. - The destination has an IPv6 address. - It has only an IPv4 address. In the first case, the dti returns an IPv6 destination address. It is possible to establish an end-to-end tunnel and there is no need to obtain a global IPv4 address. If the dti has not yet a local address it will configure the IPv4 stack and use the address in the encapsulation. The local IPv4 address should be de-allocated after a certain idle time. In case of an IPv4-only destination equipment, we propose to implement tunneling boxes inside the network that we call dti- tunnels. These boxes should be as close as possible to IPv4 resources to reduce routing of native IPv4 packets. They can also be located on a third party provider network if no possible internetworking between IPv6 and IPv4 can be achieved in the local domain. The dti must obtain a dti-tunnel IPv6 address. This may be statically configured in each dual stack host. It could be obtained as mentioned in AIIH proposal by means of a RR record in the destination domain name (we propose to add in the DNS a new entry for NGTRANS-TUNNELING) or via more advanced methods like NHRP. The dti sends a DHCP(v4) query to the dti-tunnel encapsulated in IPv6. The dti-tunnel assigns an IPv4 address to the dti. In the general case, the assignment can be static through an IPv4 pool of addresses in the dti-tunnel. The dti-tunnel can act as forwarder and obtain dynamically an IPv4 address through a conventional DHCP(v4) procedure. Toutain & Afifi [Page 5] Internet Draft IP Dynamic Tunneling Expire 6/99 The dti is now able to send the packets to the dti-tunnel that decapsulates the IPv6 header and sends them to the destination through IPv4 network. The procedure is hence quite similar to NAT but does not need any address translation at boundaries. 3.2 DNS Resolution in the dti The dti queries the DNS when a packet is received from an IPv4 application to the dual stack. A query to the IN_ADDR.arpa domain is sent to obtain the original destination domain name. This is the main contribution in the dti tunneling model. Once this is achieved a second query is sent to the DNS for the resolution of an AAAA type address. If an answer is obtained a direct tunnel can be established. Otherwise, the dti may, as it is mentioned in the AIIH proposal look for a RR record with the AAAA type to be used as the dti-tunnel. The dti proceeds as explained before. During the name resolution the dti should check whether the destination is located on the local intranet or not. If it is in the same domain as the origin then the dti should use a local dti-tunnel. We illustrate the DNS procedure by an example: the dti receives a packet to be sent over IPv4 to the destination 192.44.77.131. It will make a query to the DNS asking for qtype=ptr. The query itself will look like: 131.77.44.192.in-addr.arpa. and the answer : 131.77.44.192.in-addr.arpa name = abc.xyz.com. This entry describing the host abc will give more information on its addresses and tell whether there is an IPv6 address for the host. The final answer if there is an IPv6 address will be: abc IN A 192.44.77.131 IN AAAA 3ffe:0305:1002:0001:0a00:2bff:fe1c:b0df 4. IPv4 to IPv6 We present the second part of the dti model where an IPv4 only equipment needs to reach an IPv6 only one. If the IPv4 host has already an IPv4 global address to the destination it will send the packet through the normal routing procedures. Once the packet arrives to any dti-tunnel equipment the same DNS resolution as in the dti case (section 3.2) should be done. Toutain & Afifi [Page 6] Internet Draft IP Dynamic Tunneling Expire 6/99 We try to find an IPv6 address for the IPv4 destination by consulting the IN_ADDR.arpa domain and once it is obtained we encapsulate the packet in IPv6 and send it to the destination. If the IPv4 only host sends a DNS query to resolve the destination domain name into an IPv4 address the query may succeed and nothing more is needed from the dti model. The packet will be sent using IPv4 and will arrive to the dti-tunnel as previously described. If however the resolver fails to locate an IPv4 address for the requested domain name we use the dti model to execute an additional procedure instead of returning the name-error to the IPv4 application. The dti will make a second query for the same domain name asking this time for an IPv6 address resolution. If there is no IPv6 available then the resolver will return a name error. If however an IPv6 address is found for the requested domain name the resolver library should trigger a special dti procedure for the tunneling. This is explained in the next paragraph. IPv4 to IPv6 tunneling The resolver must have a pre-configured dti-tunnel IPv4 address for its domain. It should send a query to this equipment asking to assign an IPv4 address to the IPv6 destination. The dti-tunnel obtains an IPv4 address from a local pool or using DHCPv4. It remotely configures the IPv4 destination stack and updates the in_addr.arpa domain name with a pointer entry to the IPv6 host. Since the destination may be multi-homed, it is also necessary to update the destination DNS database with the new IPv4 address. We present hereafter a solution to avoid the need to update the destination domain name. Note also that all these procedure will use time to live fields that will protect the system from any malicious attack trying to consume all IPv4 available addresses in a site. The following example traces the steps in the IPv4/IPv6 direction. The resolver intercepts a query to lmn.xyz.com asking for an IPv4 address (A type query). The query fails and the resolver asks again for an IPv6 address. This time the query succeeds and an IPv6 address is returned. The resolver sends a special query to its pre-configured dti-tunnel asking for the assignment of an IPv4 address to the lmn.xyz.com destination. The dti-tunnel makes a DHCPv4 query and obtains the required address (192.108.119.33 for example). It should use a special procedure to configure (lmn.xyz.com) with the new address and update its own DNS: 33.119.108.192.in-addr.arpa name = lmn.xyz.com. In case the dti-tunnel uses an additional DHCP(v4) feature that Toutain & Afifi [Page 7] Internet Draft IP Dynamic Tunneling Expire 6/99 enables to remotely configure the destination dual stack with the newly assigned IPv4 address, it returns the IPv4 address to the resolver and stops. If however a different procedure is used to configure the remote destination host with the IPv4 address another DNS update in the destination domain will also be needed: lmn IN A 192.119.108.33 AAAA 3ffe:0305:1002:0001:0a00:2bff:fe1c:b099 Any dti-tunnel that will receive the packet will be able to find the IPv6 address and establish the tunnel by consulting the destination domain name. Again if the use of a DHCPv4 server driven procedure is adopted then when a different dti-tunnel receives an IPv4 assignment request for the IPv6 host it will try to configure remotely the destination stack through DHCPv4. If an address is already assigned for that host then the DHCPv4 configuration will fail and the current IPv4 destination address will be returned in the error message (see section 5). The dti-tunnel will return the address to the resolver and the communication will start. The usage of a new server driven DHCPv4 request will improve the security environment since the dti-tunnel will not need to update the destination domain name. 4.1 Path MTU When packets are sent to the dti-tunnel the header length may change the link MTU. This can be either detected by the PMTU detection or if necessary by means of the IPv6 fragmentation extension. 5. Required Additional Features The dti model will require some additional protocol features. Note that most of them are also required in the AIIH proposal. In the reverse direction (from IPv4 to IPv6) two new procedures are required. The dti resolver needs to send a query to the dti-tunnel asking for the assignment of an IPv4 address. The dti-tunnel has to remotely configure the destination IPv4 stack with a new address. This whole procedure could be done by the DHCPv4 protocol if an additional feature enables the DHCPv4 server to initiate an IPv4 assignment procedure without a previous solicitation from the client. An additional entry in the DNS for ipv4/ipv6 capability tunnel would also be very useful (for all the proposals) in order to find for each domain the closest tunneling equipment. Toutain & Afifi [Page 8] Internet Draft IP Dynamic Tunneling Expire 6/99 6. Bibliography [AIIH] J. Bound. Assignment of IPv4 Global Addresses to IPv6 Hosts (AIIH). Expired. [SIIT] E. Nordmark,Stateless IP/ICMP Translator (SIIT), , Work in progress, November 1998. [NAT] G. Tsirtsis, P. Srishuresh. Network Address Translation - Protocol Translation (NAT-PT). . 7. Authors Addresses Laurent Toutain Hossam Afifi ENST Bretagne 2 rue de la chataigneraie BP 78 35512 Cesson Sevigne {toutain, afifi}@rennes.enst-bretagne.fr Tel: (+33) 2 99 12 70 20 - Fax: (+33) 2 99 12 70 30 Toutain & Afifi [Page 9]