INTERNET DRAFT Liu Min Wu Xianguo Expires November, 2004 Cai Yibing ICT Jin Mingye China Unicom Li Defeng HUAWEI May, 2004 Tunneling IPv6 with private IPv4 addresses through NAT devices Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The growth of IPv6 networks started mainly using the transport facilities offered by the current Internet. This led to the development of several techniques to manage IPv6 over IPv4 tunnels. However, classic tunneling methods do not work when the IPv6 candidate node is isolated behind a Network Address Translator (NAT) device. We propose here a service, called Silkroad, to enable nodes located behind one or several IPv4 NATs to obtain IPv6 connectivity. It can provide IPv6 connectivity through all existing NAT types and does not require any update of them. In addition, Silkroad does not need special IPv6 addressing prefix and can provide the users with permanent/temporary IPv6 addresses. Expires November,2004 [Page 1] Internet-Draft Silkroad May 2004 Table of Contents: 1 Introduction.....................................................3 2 Silkroad Terminology.............................................4 2.1 Silkroad Client (SC)...........................................4 2.2 Silkroad Access Router (SAR)...................................4 2.3 Silkroad Navigator (SN)........................................4 2.4 Silkroad UDP port..............................................4 3 Background.......................................................5 3.1 What is NAT?...................................................5 3.2 Types of NAT...................................................5 3.3 Traversal of User Datagram Protocol (UDP) Through NATs.........5 4 Silkroad Description.............................................6 4.1 Silkroad Model.................................................6 4.1.1 Silkroad Client (SC).........................................7 4.1.2 Silkroad Access Router (SAR).................................7 4.1.3 Silkroad Navigator (SN)......................................7 4.2 Silkroad Operation.............................................8 4.2.1 Determining the SAR..........................................8 4.2.2 Obtaining IPv6 Address.......................................9 4.2.3 Determining the Type of NAT.................................10 4.2.4 Packet Transmission from a SC to a Regular IPv6 Node........10 4.2.5 Packet Transmission from a Regular IPv6 Node to a SC........12 4.2.6 Exchanges Between Two Silkroad Clients......................14 4.3 Deployment Model..............................................15 4.3.1 Silkroad Access Router Deployment...........................16 4.3.2 Silkroad Navigator Deployment...............................16 5 Route Optimization..............................................18 5.1 Exchanges Between two Silkroad Clients........................18 5.2 Exchanges Between two Silkroad Clients on the Same Link.......19 6 Message Formats.................................................22 7 Other Issues of the Solution....................................23 7.1 Lifetime of NAT Mappings......................................23 7.2 Lifetime of Silkroad Tunnel...................................23 7.3 Silkroad in the Post Era of IPv6..............................23 7.4 Difference between Silkroad and Teredo........................23 8 Security Consideration..........................................25 9. IANA Considerations ...........................................25 10.Acknowledgments................................................25 References........................................................26 Authors' Addresses................................................27 Expires November,2004 [Page 2] Internet-Draft Silkroad May 2004 1. Introduction The growth of IPv6 networks started mainly using the transport facilities offered by the current Internet. Complete upgrades of current Internet from IPv4 to IPv6 will take a long time. Thus the key to a successful IPv6 transition is compatibility with the large installed base of IPv4 hosts and routers. Maintaining compatibility with IPv4 while deploying IPv6 will streamline the task of transition of the Internet to IPv6. This led to the development of several techniques to manage IPv6 over IPv4 tunnels. Classic tunneling methods designed for IPv6 transition operate by sending IPv6 packets as payload of IPv4 packets. However, these methods do not work when the IPv6 candidate node is isolated behind a Network Address Translator (NAT) device. The reason is that usually NATs will perform ingress filtering and refuse to allow the transmission of many payload types. In this memo, we propose a service, called Silkroad, to enable nodes located behind one or several IPv4 NATs to obtain IPv6 connectivity with the help of "Silkroad navigator" and "Silkroad access routers". It provides connectivity for clients located behind all existing NAT types, including symmetric NAT. Silkroad does not need special IPv6 addressing prefix and can provide the users with permanent IPv6 address. Silkroad approach is expect to be useful to stimulate the growth of IPv6 and to allow early IPv6 network providers to provide easy access to their IPv6 network. When IPv6 is quite widespread and IPv4 hosts are just small isolated sites on the IPv6 Internet, the process of Silkroad will be much simpler and the "Silkroad avigator" can be omitted. This document is intended to present a framework describing the guidelines for the provision of a Silkroad service within the Internet. It details the general architecture of the proposed approach and also outlines a set of viable implementation. The memo is organized as follows. Section 2 contains the definition of the terms used in the memo. Section 3 introduces the background information. Section 4 provides an overall description of the Silkroad model. Section 5 presents the route optimization of Silkroad in certain scenarios. Section 6 contains the format of the messages. Section 7 is a discussion of some other issues of this solution. Section 8 and Section 9 contain a security discussion and IANA consideration. Expires November,2004 [Page 3] Internet-Draft Silkroad May 2004 2. Silkroad Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This section defined other terminology used with Silkroad: 2.1 Silkroad Client (SC) A dual stack node that has some access to the IPv4 Internet and that wants to gain access to the IPv6 Internet. 2.2 Silkroad Access Router (SAR) A dual stack router that has access to the IPv4 Internet through a globally registered address. It will be used to help Silkroad clients to gain IPv6 connectivity. 2.3 Silkroad Navigator (SN) A node that has access to the IPv4 Internet, and that is used to help SCs to choose appropriate SAR and help SARs to route between each other. It may also be IPv6 addressable, but this is not mandatory. 2.4 Silkroad UDP port The UDP port number at which Silkroad Access Routers are waiting for packets. The value of this port is TBD. In this memo, we use port 5188 temporarily. Expires November,2004 [Page 4] Internet-Draft Silkroad May 2004 3. Background 3.1 What is NAT? The need for IP address translation arises when a network's internal IP addresses can not be used outside the network either because they are invalid for use outside, or because the internal addressing must be kept private from the external network. Network Address Translation(NAT)is a method by which IP addresses are mapped from one realm to another. It is often used to connect an isolated address realm with private unregistered addresses to an external realm with globally unique registered addresses. [2] describes the operation of NAT devices and the associated considerations in general. Typically, NATs are not programmed to allow the transmission of arbitrary payload types. As a result, many existing tunnel techniques for IPv6 transition operation, which send IPv6 packets as payload of IPv4 packets, can not work if the user is using private IPv4 address behind a NAT box. 3.2 Types of NAT It is assumed that the reader is familiar with NATs. It has been observed that NAT devices can adopt widely different strategies among implementations. Four treatments observed in implementations are described in [5], which are Full Cone NAT, Restricted Cone NAT, Port Restricted Cone NAT and Symmetric NAT. Silkroad can provide IPv6 connectivity for clients located behind all these four NAT types. However, determining the type of NAT will be important when we want to optimize the transmission performance of Silkroad. 3.3 Traversal of User Datagram Protocol (UDP) Through NATs Experience shows that TCP and UDP are the only protocols guaranteed to cross the majority of NAT devices. Although transporting IPv6 packets as the payload of TCP packets would be possible, it often result in a very poor QoS (Quality-of-Service). What's more, it is hard for applications to enforcing their own control on the transmission rate in TCP. As a result, current traversal techniques through NATs are generally based on UDP. Like Teredo, Silkroad also transports IPv6 packets as the payload of UDP packets. Expires November,2004 [Page 5] Internet-Draft Silkroad May 2004 4 Silkroad Description Silkroad communication procedures are based on assumptions on NAT treatment of UDP; such assumptions may prove invalid when new NAT devices are deployed. Silkroad is designed to robustly enable IPv6 traffic through NATs, and the price is a reasonable amount of overhead, due to UDP encapsulation. Thus Silkroad SHOULD NOT be used except when the direct IPv6 connectivity is not locally available and the node can not use a global IPv4 address. 4.1 Silkroad Model The typical model of Silkroad is shown in Figure 1. +------+ / | | / | SAR | / | | / +------+ +------+ +------+ / +------+ | | | | | | | SC |<--->| SN |<------>| SAR | | | | | | | +------+ +------+ \ +------+ \ +------+ +------+ tunnel end-point \ | | | | /\ \ | SAR |<------------->| SAR' | || \ | | | | || +------+ +------+ || /\ -------||------NAT tunnel end-point || || /\ || || || \/ || || +------+ || || | IPv6 | |+---------------------------+| | Node | +-----------------------------+ | | UDP tunnel +------+ Figure 1: The Silkroad model As can be seen from Figure 1, the Silkroad service requires the cooperation of three kinds of entities: Silkroad clients, who want to use IPv6 despite being located behind a NAT; Silkroad access routers, who provide for the interconnection between the Silkroad client and the existing IPv6 Internet; Silkroad navigators, who will facilitate the Silkroad client to find the appropriate SAR and help the SAR to forward packets. Expires November,2004 [Page 6] Internet-Draft Silkroad May 2004 4.1.1 Silkroad Client (SC) A SC is a node that has some access to the IPv4 Internet and that wants to gain access to the IPv6 Internet despite being located behind a NAT. It mainly has the following functions: - Connect to SN to search the list of available SARs, and choose the appropriate SAR to create UDP tunnel - Manage UDP tunnel with SAR Create, modify or delete tunnel; Determining the type of NAT; Optimize routes; - Security control with SN and SAR - Ingress filtering - Provide transparent Silkroad support for applications 4.1.2 Silkroad Access Router (SAR) A SAR is a dual-stack (IPv4 & IPv6) router that has access to the IPv4 Internet through a globally routable address. It mainly has the following functions: - Connect to the SN to register its information, such as: Its IPv4 addresses (a SAR may have several IPv4 addresses); A name to be used for the registration in the DNS; The location information of the SAR; - Manage UDP tunnel: Create, modify or delete tunnel; Determining the type of NAT; Maintain usage statistics for every active tunnel; - Connect to SN to search the IPv4 addresses of SARs that can forward IPv6 packets to a specific IPv6 network - IPv6 address assignment and management - Forward packets in IPv6/IPv4 networks - Access control and security control 4.1.3 Silkroad Navigator (SN) Expires November,2004 [Page 7] Internet-Draft Silkroad May 2004 In order to enable the service, the Silkroad navigator MUST be IPv4 addressable. It MAY also be IPv6 addressable, but this is not mandatory. A SN mainly has the following functions: - Provide the list of available SARs to allow SC to choose the appropriate one - Provide the list of SARs that can forward IPv6 packets to a specific IPv6 network and the IPv4 addresses of these SARs - Assist SAR administrators to configure static routes or tunnels between each other 4.2 Silkroad Operation 4.2.1 Determining the SAR The first phase of Silkroad operation is determining an appropriate SAR to provide Silkroad service to the SC. To do this, the SC should connect to SN to search the list of available SARs, and select an appropriate SAR. This assigned SAR's information will be automatically saved in the SC's configuration file. This SAR will become the SC's default SAR, unless the SC explicitly changes its configuration. The interaction between the SC and the SN could be based on http. In this way, the SN should maintain a web page to provide the list of the available SARs to allow SCs to choose. During this process, the SC MAY be asked to provide the relevant information by filling up some forms on the Web page. Then the SN could respond with an html page displaying all the relevant information of SARs. Of course, a SC can determine the address or domain name of a SAR through other means. For example, the SC could get the address of SAR by sending Router Solicitation message over UDP to the SN. The SN replies with a Router Advertisement over UDP containing the address of available SAR. The SC can also get the SAR's information from its administrator, or broadcast an Route Solicitation to wait for the SAR's reply. These packets may have the following format: +------+-----+---------------------+ | IPv4 | UDP | Router Solicitation | +------+-----+---------------------+ +------+-----+----------------------+ | IPv4 | UDP | Router Advertisement | +------+-----+----------------------+ Expires November,2004 [Page 8] Internet-Draft Silkroad May 2004 4.2.2 Obtaining IPv6 Address In order to obtain an IPv6 address, SC sends the assigned SAR a Router Request message over UDP. The SAR replies with a Router Response containing the assigned IPv6 address; the message also contains a "Control Option" domain that specifies the IPv4 address and port number from which the SAR received the Router Request. In fact, when a Router Request arrives at the SAR, it may have passed through one or more NATs between the SC and the SAR. As a result, the source address of the request received by the SAR will be the mapped address created by the NAT closest to the SAR. The SAR copies that source IP address and port into the "Control Option" domain and sends it back to the source IP address and port of the Router Request. For all of the NAT types mentioned above, this response will arrive at the SC. These packets will have the following format: +------+-----+----------------+ | IPv4 | UDP | Router Request | +------+-----+----------------+ +------+-----+----------------+-----------------+ | IPv4 | UDP | Control Option | Router Response | +------+-----+----------------+-----------------+ The IPv6 addresses assigned to SCs must be global IPv6 addresses belonging to the IPv6 addressing space managed by the SAR. These addresses could be assigned to the SC permanently. In this way, SC could preserve a permanent (static) IPv6 address even though its IPv4 address is dynamic. Similarly, SCs can also request for temporary addresses. These addresses will be assigned a lifetime and removed after its expiration unless an explicit lifetime extension request is submitted by the SC. The lifetime of these IPv6 addresses should be relatively longer than the lifetime of the IPv4 connection of the SC. This is to allow the SC to get semipermanent IPv6 addresses even though it is connected to the Internet with dynamically assigned IPv4 addresses through DHCP. Moreover, if the SC is an IPv6 router willing to provide IPv6 connectivity to several hosts, it should provide some information about how many IPv6 addresses are required. This allows the SAR to allocate the SC an IPv6 prefix that fits its address needs. Once a SAR has assigned an IPv6 address to a SC, this SAR will make an address binding in its mapping table, in which the assigned IPv6 address is associated with the mapped IPv4 address and mapped port of the SC. Address binding MAY be dynamic with dynamic IPv4 address of Expires November,2004 [Page 9] Internet-Draft Silkroad May 2004 SCs. Once the binding between two addresses is in place, all subsequent sessions originating from or to this host will use the same binding for packet disposal. In addition, the SAR will maintain the management information about this UDP tunnel. 4.2.3 Determining the Type of NAT The previous section presented a simple address assignment procedure. When the SC receives the Router Response, it compares the IP address and port in Control Option with the local IP address and port it bound to when the request was sent. If these do not match,the SC is behind one or more NATs; otherwise, the SC need not use the Silkroad service. For better transmission efficiency, the SC could choose to determine the type of NAT behind which it is located with the help of SAR. To determine that, the SC uses additional Router Requests. The procedure May generally work as in [5] (Of course, the exact implementation will be flexible). 4.2.4 Packet Transmission from a SC to a Regular IPv6 Node The exchange of packets between a SC and a regular IPv6 node is presented in the following figure, in which "A" is a SC located behind the NAT "N", "R1" is the SAR chosen by "A", "B" is a regular IPv6 node, and "R2" is a SAR close to "B" in the IPv6 Internet topology. UDP tunnel1 UDP tunnel2 +------+ | +------+ +------+ +------+ | | | | | | | | | | A |<-------->| R1 |<-------->| R2 |<-------->| B | | | | | | | | | | +------+ | +------+ +------+ +------+ | \ / N \ / \ / \/ +------+ | | | SN | | | +------+ Figure 2: Packet transmission from a SC to a regular IPv6 node We assume that A has already gotten its IPv6 address from R1. And in this example, we do not consider any route optimization based on different NAT types. We also assume that the address of each entity is the following: Expires November,2004 [Page 10] Internet-Draft Silkroad May 2004 - A's private IPv4 address and port are: 1.0.0.1:1234 - A's mapped IPv4 address and port are: 2.0.0.2:5678 - A's IPv6 address is: 3ffe:8330:1::1234 - R1's IPv4 address and port are: 3.0.0.3:5188 - R2's IPv4 address and port are: 4.0.0.4:5188 - B's IPv6 address is: 2001:250:f006:1::5678 A wants to transmit an IPv6 packet to B. A's first action is to encapsulate this IPv6 packet in a UDP Datagram within IPv4, and send it from source address and port 1.0.0.1:1234, to the address of R1: 3.0.0.3:5188. We call it Silkroad packet. This packet will have the following format: +------+-----+----------------+-------------+ | IPv4 | UDP | Control Option | IPv6 packet | +------+-----+----------------+-------------+ The packet is received by the NAT "N". N uses the existing mapping for 1.0.0.1:1234, and replaces the UDP source address and port by the mapped values 2.0.0.2:5678, before forwarding the packet. The packet is received over IPv4 UDP tunnel1 by R1. R1 takes out the IPv6 destination and checks the local route table to forward this packet. If R1 has direct tunnel to the destination IPv6 network or has direct access to the IPv6 Internet, R1 will find the route and forward this packet. If R1 has never forwarded an packet towards this IPv6 destination address and has no route information in its local route table, it will connect to SN to search the list of SARs that can forward IPv6 packets to the specific IPv6 network and get the IPv4 addresses of these SARs. The search process is like the disposal process of DNS (Domain Name System). The default route in SN will be a SAR connected to IPv6 Internet, that means if R1 can not find an appropriate SAR that can forward IPv6 packets to the specific IPv6 address directly, this packet will be forwarded to IPv6 Internet and then follows IPv6 routing rules. After determining the address of R2, which is the SAR close to B in the IPv6 Internet topology. R1 will tunnel the IPv6 packet together with the Control Option to the address of R2: 4.0.0.4:5188. The transmission between R1 and R2 may follow different ways. It can manage IPv6 packet over another UDP tunnel, like UDP tunnel2 in Figure 2. The advantage of this method is that the disposal of R1 before forwarding will be simple, just replacing the UDP source address and port by the values 3.0.0.3:5188 and replacing the UDP destination address and port by the values 4.0.0.4:5188. However, the price is a reasonable amount of overhead, due to UDP encapsulation. Silkroad can also send IPv6 packets between SARs as payload of IPv4 packets just like traditional tunnels. But this method does not support Control Option between SARs. In this way, the packet will Expires November,2004 [Page 11] Internet-Draft Silkroad May 2004 have the following format: +-------------+-------------+------------------------+------+ | IPv4 Header | IPv6 Header | Transport Layer Header | Data | +-------------+-------------+------------------------+------+ Using this method, R1 must unencapsulate the packet and reencapsulate it before forwarding. Anyway, the SC can specify the transmission method in Control Option domain. The default disposal is that when there is Control Option in the packet, SAR will take UDP tunnel to forward it; otherwise, traditional tunnel will be used. In fact, Control Option generally only appears in the foremost several packets in one session. As a result, SARs need to "listen" to both, UDP and IP encapsulation. But no matter what transmission method is token between SARs, SCs only need to support UDP encapsulation. The Control Option used to choose the transmission method between R1 and R2 will be discarded by R1 after the corresponding disposal, that means R1 will not carry such a Control Option in the UDP packet forwarded to R2. Contrarily, other types of Control Option should be tunneled together with the IPv6 packet to R2. For simplification, in the following description, we assume SARs always take UDP tunnel to forward packets between each other. When R2 receives the packet, if it finds that B is a SC serviced by itself, it will follow the forwarding process in section 4.2.6. Otherwise, it will discard the IPv4 and UDP header and Control Option domain, and forward other content of the packet over IPv6 to the address of B: 2001:250:f006:1::5678. This packet will be received by B, and which will appear to come from A's address, 3ffe:8330:1::1234. Note that R1 and R2 may be the same SAR if it can reach both A and B. In this way, UDP tunnel2 may be elided. 4.2.5 Packet Transmission from a Regular IPv6 Node to a SC The exchange of packets between a regular IPv6 node and a SC is presented in the following figure, in which "A" is a SC located behind the NAT "N", "R1" is the SAR chosen by "A", "B" is a regular IPv6 node, and "R2" is a SAR close to "B" in the IPv6 Internet topology. Expires November,2004 [Page 12] Internet-Draft Silkroad May 2004 UDP tunnel2 UDP tunnel1 +------+ +------+ +------+ | +------+ | | | | | | | | | | B |<-------->| R2 |<-------->| R1 |<-------->| A | | | | | | | | | | +------+ +------+ +------+ | +------+ \ / | \ / N \ / \/ +------+ | | | SN | | | +------+ Figure 3: Packet transmission from a regular IPv6 node to a SC We assume that A has already gotten its IPv6 address from R1. And in this example, we do not consider any route optimization based on different NAT types. We also assume that the address of each entity is the following: - A's private IPv4 address and port are: 1.0.0.1:1234 - A's mapped IPv4 address and port are: 2.0.0.2:5678 - A's IPv6 address is: 3ffe:8330:1::1234 - R1's IPv4 address and port are: 3.0.0.3:5188 - R2's IPv4 address and port are: 4.0.0.4:5188 - B's IPv6 address is: 2001:250:f006:1::5678 When B wants to transmit an IPv6 packet to A, B simply follows IPv6 rules. The packet will be forwarded to one SAR close to B in the IPv6 Internet topology, R2, over IPv6. R2 will takes out the IPv6 destination address and checks local route table to forward this packet. If R2 has no route information in its local route table, it will connect to SN to search the IPv4 address of the SAR that can forward IPv6 packets to the specific IPv6 address. Because the IPv6 address assigned to A is a global IPv6 addresses belonging to the IPv6 addressing space managed by R1. R2 will get the IPv4 address of R1 in the search process. Then R2 will encapsulate the packet and send it to the address of R1: 3.0.0.3:5188. The packet is received over IPv4 UDP tunnel2 by R1. R1 will find that the IPv6 destination address is belonging to its address space. Thus it will check the address binding in its mapping table, in which it will find that the IPv6 address 3ffe:8330:1::1234 is associated with A's mapped IPv4 address and port: 2.0.0.2:5678. Thus R1 will replace the UDP source address and port by the values 3.0.0.3:5188 and replace the UDP destination address and port by the values 2.0.0.2:5678, then forward the packet in UDP tunnel1. Expires November,2004 [Page 13] Internet-Draft Silkroad May 2004 The NAT "N" will receive this message. It will use the existing mapping to rewrite 2.0.0.2:5678 to 1.0.0.1:1234, and forward the packet to A. Then the packet will be received over IPv4 UDP tunnel1 by A. Note that R1 and R2 may be the same SAR if it can reach both A and B. In this way, UDP tunnel2 may be elided. 4.2.6 Exchanges Between Two Silkroad Clients The following figure shows two SCs,"A" and "B", connected through the NATs "N1" and "N2". "R1" is the SAR chosen by "A" and "R2" is the SAR chosen by "B". UDP tunnel1 UDP tunnel2 UDP tunnel3 +------+ | +------+ +------+ | +------+ | | | | | | | | | | | A |<-------->| R1 |<-------->| R2 |<-------->| B | | | | | | | | | | | +------+ | +------+ +------+ | +------+ | \ / | N1 \ / N2 \ / \/ +------+ | | | SN | | | +------+ Figure 4: Packet transmission between two SCs We assume that A and B have already gotten their IPv6 addresses from R1 and R2 respectively. And in this example, we do not consider any route optimization based on different NAT types. We also assume that the address of each entity is the following: - A's private IPv4 address and port are: 1.0.0.1:1234 - A's mapped IPv4 address and port are: 2.0.0.2:5678 - A's IPv6 address is: 3ffe:8330:1::1234 - R1's IPv4 address and port are: 3.0.0.3:5188 - R2's IPv4 address and port are: 4.0.0.4:5188 - B's private IPv4 address and port are: 5.0.0.5:1234 - B's mapped IPv4 address and port are: 6.0.0.6:5678 - B's IPv6 address is: 2001:250:f006:1::5678 A has learnt B's address, for example from the DNS, and starts communication with B. The data packets will be sent from A's IPv6 address (3ffe:8330:1::1234) to B's IPv6 address (2001:250:f006:1::5678). The transmission process from A to R2 is the Expires November,2004 [Page 14] Internet-Draft Silkroad May 2004 same as explained in section 4.2.4. When R2 receives the packet over IPv4 UDP tunnel2, it will find that B is a SC serviced by itself, and the address binding in its mapping table shows that the IPv6 destination address 2001:250:f006:1::5678 is associated with B's mapped IPv4 address and port: 6.0.0.6:5678. Thus R2 will replace the UDP source address and port by the values 4.0.0.4:5188 and replace the UDP destination address and port by the values 6.0.0.6:5678, then forward the packet in UDP tunnel3. The NAT "N2" will receive this message. It will use the existing mapping to rewrite 6.0.0.6:5678 to 5.0.0.5:1234, and forward the packet to B. Then the packet will be received over IPv4 UDP tunnel3 by B. Note that R1 and R2 may be the same SAR if it can reach both A and B. In this way, UDP tunnel2 may be elided. 4.3 Deployment Model As we all know, public IPv4 addresses is a scarce resource, especially for the mobile operators. As a result, NAT devices are widely deployed to connect a realm with private unregistered addresses to a realm with globally unique registered addresses. However, traditional tunneling methods do not work when the IPv6 candidate is located behind some NAT device. Silkroad is designed to enable IPv6 traffic through NATs. There are many scenarios that need Silkroad deployment. For example, although the user equipments can be dual stack, current existing GPRS operators already have IPv4 backbone networks deployed. What have been currently deployed in commercial networks are Mobile IPv4 and Simple IPv4 modes. A majority of current existing commercial networks only support IPv4 in the Serving GPRS Support Node (SGSN), the Gateway GPRS Support Node (GGSN) and the Home Location Register(HLR). In addition, the GGSN usually allocates private IPv4 addresses to user equipments. In this way, the GGSN acts as a NAT. Then how can the dual stack user equipment with a private IPv4 address access the IPv6 Internet through IPv4 GPRS backbone? Before the ISPs deploy basic IPv6 support by making upgrades in their network elements, they can take Silkroad service to provide early easy access to IPv6 networks. The deployment model of Silkroad makes two assumptions: - That all Silkroad clients and Silkroad access routers will be cognizant of the Silkroad port; - That all Silkroad clients and Silkroad access routers will know the IPv4 address of the Silkroad navigator. Expires November,2004 [Page 15] Internet-Draft Silkroad May 2004 4.3.1 Silkroad Access Router Deployment In the simplest case, when the Silkroad clients are very few, one SAR may be enough, only if the SAR has connected to IPv6 Internet. Every time the SAR receives the IPv6 packet encapsulated in a UDP Datagram from a SC and the IPv6 destination address is also belonging to its address space, it will check the address binding in its mapping table and forward the packet in UDP tunnel. Otherwise, it will discard the IPv4 and UDP header, and forward the content of the packet over IPv6. In this case, the destination address must be connected to IPv6 Internet. Otherwise, the SAR must have direct tunnel to the specific IPv6 network. Contrarily, every time the SAR receives an IPv6 packet to its client, it will encapsulate it in a UDP Datagram and forward it to the corresponding SC. In the simplest instance, even the SN can be omitted. However, in the emerging IPv6 Internet, it is expected that many users will need to access IPv6 by the current Internet with the large installed base of IPv4 hosts and routers. Thus it is impossible to provide Silkroad service to all these hosts only by one SAR. What's more, many destination nodes may not connect to IPv6 Internet and the only SAR can not have direct tunnels to all destination IPv6 networks. Consequently, it is expected that many Silkroad access routers will be available so that the user will just have to pick the appropriate one. There will be at least one SAR connected to IPv6 Internet. All SARs could configure static routes between each other with the help of SN. Silkroad access routers may be deployed either as part of an ISP, or as an enabler for an application that requires direct IPv6 communication between client hosts. SARs are expected to perform some amount of access control. 4.3.2 Silkroad Navigator Deployment In the simplest case, when the Silkroad clients and Silkroad access routers are very few, there is no need to configure Silkroad navigator. However, when the scale of Silkroad service is relatively large, it may be necessary to configure Silkroad navigator to help Silkroad clients to choose appropriate SAR and to help SARs to route between each other. The only deployment requirement for Silkroad navigator is IPv4 connectivity. It may also be IPv6 addressable, but this is not mandatory. In the initial deployment of the Silkroad service, we expect to find a globally accessible Silkroad navigator. However, along with the Expires November,2004 [Page 16] Internet-Draft Silkroad May 2004 increase in the size of the route database in SN and frequency of updates, it may demand a distributed manner with local caching to improve performance. But at this time, it is recommended to offer native IPv6 instead of deploying many SNs. In fact, when all SARs have easy access to IPv6 Internet, SN could be omitted. Expires November,2004 [Page 17] Internet-Draft Silkroad May 2004 5 Route Optimization For better transmission efficiency, we can do some route optimization in certain scenarios. Route optimization is optional. 5.1 Exchanges Between Two Silkroad Clients As described in 4.2.6, Figure 5 shows two SCs,"A" and "B", connected through the NATs "N1" and "N2". "R1" is the SAR chosen by "A" and "R2" is the SAR chosen by "B". As we have mentioned above, R1 and R2 may be the same SAR if it can reach both A and B. In this way, UDP tunnel2 may be elided. direct communication +------------------------------------------------------+ |+----------------------------------------------------+| || || || || \/ UDP tunnel1 UDP tunnel2 UDP tunnel3 \/ +------+ | +------+ +------+ | +------+ | | | | | | | | | | | A |<-------->| R1 |<-------->| R2 |<-------->| B | | | | | | | | | | | +------+ | +------+ +------+ | +------+ | \ / | N1 \ / N2 \ / \/ +------+ | | | SN | | | +------+ Figure 5: Exchanges between two SCs In fact, A and B can communicate with each other directly, unless N1 and N2 are both Symmetric NAT. Of course, they need the help of R1 and R2 to exchange some parameters at first. Assume that A wants to communicate with B. Firstly, A should obtain an IPv6 address from R1 as described in section 4.2.2. When A receives the Router Response from R1, it compares the IP address and port in Control Option with the local IP address and port it bound to when the request was sent. If these do not match, A knows that it is behind one or more NATs; otherwise, A need not use the Silkroad service and can choose other tunnel technologies. For better transmission efficiency, A could choose to determine the Expires November,2004 [Page 18] Internet-Draft Silkroad May 2004 type of NAT behind which it is located with the help of R1. To determine that, A uses additional Router Requests as described in 4.2.3. Then A will include its mapped address and mapped port together with its type of NAT in the Control Option in the first encapsulated packet to B. If both N1 and N2 are Full Cone NAT, B will reply IPv6 packets encapsulated in UDP directly to A, with Control Option indicating its mapped address and mapped port. Then A and B will communicate with each other directly through UDP tunnel. If both N1 and N2 are Symmetric NAT, A and B can not transmit packets to each other without the help of SAR. In other case, A and B must generate some control packets to establish corresponding mapping at the Restricted Cone NAT/Port Restricted Cone NAT/Symmetric NAT before they can transmit packets directly to each other. In this case, it is recommended that A and B choose to do route optimization only if they want to transmit large bulk traffic. If they only want to transmit a few of messages, there is no need to send control packets to make route optimization. If B is a regular IPv6 node, the Control Option domain in the first encapsulated packet to B will be discarded by R2. Thus no route optimization will be made. 5.2 Exchanges Between Two Silkroad Clients on the Same Link The following figure shows two Silkroad Clients, A and B, connected to the same link, which is connected to the Internet through the NAT N1. The exchanges between A and B will use the SAR,R1. We are not making any assumption about the type of N1. This scenario explains how the exchanges between clients on the same link can be optimized to avoid routing all packets through R1 and N1. Expires November,2004 [Page 19] Internet-Draft Silkroad May 2004 +------+ | | +----------->| R1 |<-----------+ | | | | | +------+ | | | | | | | | | | UDP tunnel1 | | | UDP tunnel2 | +------+ | | | | | | | N1 | | | | | | | +------+ | | / \ | | / \ | | / \ | | / \ | | +------+ +------+ | | | | | | | +-->| A |<-------->| B |<--+ | | | | +------+ +------+ direct communication Figure 6: Packet transmission between two SCs on the same link We assume that A and B have already gotten their IPv6 addresses from R1 respectively. We also assume that the address of each entity is the following: - A's private IPv4 address and port are: 1.0.0.1:1234 - A's mapped IPv4 address and port are: 2.0.0.1:5678 - A's IPv6 address is: 3ffe:8330:1::1234 - R1's IPv4 address and port are: 3.0.0.3:5188 - B's private IPv4 address and port are: 1.0.0.2:3456 - B's mapped IPv4 address and port are: 2.0.0.2:5678 - B's IPv6 address is: 3ffe:8330:1::5678 Of course, A and B are possibly located behind the same NAT, if they are both using the same mapped IPv4 address. However, even if the mapped IPv4 addresses are different, they are also possibly located behind the same NAT. On the other hand, even if they are behind the same NAT, it is possible that they can not communicate with each other directly. Thus they have to take some actions to confirm that they are directly reachable. There are several ways to gain this end. Here we only give a viable alternative to implement it. Expires November,2004 [Page 20] Internet-Draft Silkroad May 2004 If A wants to discover whether it and B are on the same link, it can include its private address in the Control Option in the packet sent to B through N1 and R1. When B receives this packet, it will reply encapsulated packets including its private address to R1's address (3.0.0.3:5188) and A's private address (1.0.0.1:1234) simultaneously. If A receives both packets, it will confirm that it and B are on the same link and they are directly reachable. Then the packets will be sent directly on the local link, avoiding the loop through R1 and N1. Expires November,2004 [Page 21] Internet-Draft Silkroad May 2004 6 Message Formats As mentioned in 4.2, the message type can be Router Solicitation, Router Advertisement, Router Request, Router Response, or Silkroad packet. In this section, we will introduce Silkroad packet in details. The main intention is to explain how the Control Option can be used to optimize routes and make individual choices. Silkroad packets are transmitted as the payload of UDP packets [3] within IPv4 [4]. In order to control and optimize the transmission, Control Option may be inserted in the first bytes of the UDP payload: +------+-----+----------------+-------------+ | IPv4 | UDP | Control Option | IPv6 packet | +------+-----+----------------+-------------+ The Control Option encapsulation is a variable length-element, with the following format: 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | Option Type | Option Length |flag | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | | Option Content | | | +-----+-----+-----+-----+-----+-----+-----+-----+ Option Type is 3 bits, which indicates the content type of this option. We have already defined 5 types as follows: 111 - Mapped address and port 110 - private address and port 101 - Type of NAT 100 - Transmission method 011 - The control option is empty 010 - unused 001 - unused 000 - unused Option Length is 4 bits, which indicates the length of this option content in unit of byte. The 1 bit flag is used to indicate whether there are other options following this option in this packet. It means the Control Option domain in one packet could carry more than one type of option. Expires November,2004 [Page 22] Internet-Draft Silkroad May 2004 7 Other Issues of the Solution 7.1 Lifetime of NAT Mappings Regardless of their types, NAT mappings are not kept forever. Generally, if no traffic is observed on the specified port for a "lifetime" period, the corresponding mapping will be removed. The Silkroad client that wants to maintain a mapping open in the NAT will have to send some "keep alive" traffic before the lifetime expires. 7.2 Lifetime of Silkroad Tunnel As mentioned in 4.2.2, IPv6 addresses can be assigned to the SC permanently. In this way, SC could preserve a permanent (static) IPv6 address even though its IPv4 address is dynamic. Similarly, SC can also request for temporary addresses. The lifetime of these temporary IPv6 addresses should be relatively longer than the lifetime of the IPv4 connection of the SC. In addition, there should be keep-alive mechanism on SARs.In this case, if no "refresh" traffic is observed on the assigned address for a duration that exceeds a refresh interval, the Silkroad tunnel will be canceled and the address binding will be removed. 7.3 Silkroad in the Post Era of IPv6 In the post era of IPv6, when IPv4 hosts are just small isolated sites on the IPv6 Internet. The disposal of SARs will be simpler. Every time one SAR receives the IPv6 packet encapsulated in a UDP Datagram from a SC, it will discard the IPv4 and UDP header, and forward the content of the packet over IPv6. Then the packet transmission will follow IPv6 rules. Contrarily, every time the SAR receives an IPv6 packet to its client, it will encapsulate it in a UDP Datagram and forward it to the corresponding SC. In this instance, SN can be omitted. 7.4 Difference between Silkroad and Teredo A service, called Teredo[6], has been presented to enable nodes located behind IPv4 NATs to obtain IPv6 connectivity with the help of "Teredo servers" and "Teredo relays". Teredo addresses need special IPv6 addressing prefix. What's more, in order to minimize the fraction of traffic that has to be routed through the servers, the Teredo addresses will incorporate the IPv4 address and UDP port through which a Teredo client can be reached. This creates an implicit limit on the stability of the Teredo addresses, which can only remain valid as long as the underlying IPv4 address and UDP port remains valid. In fact, although Teredo can minimize the fraction of Expires November,2004 [Page 23] Internet-Draft Silkroad May 2004 traffic routing through the servers, it need Teredo relays in every IPv6 network to receive traffic destined to Teredo clients and forward it using the Teredo service, which needs to update the existing infrastructure. In addition, Teredo does not provide connectivity for clients located behind a symmetric NAT, which is common in large enterprises. Silkroad is also a tunnel service to enable nodes located behind IPv4 NAT devices to obtain IPv6 connectivity over IPv4 UDP. However,it can provide connectivity for clients located behind all existing NAT types, including symmetric NAT. Moreover, Silkroad does not need special IPv6 addressing prefix and can provide the users with permanent IPv6 address. Silkroad has no special requirement for infrastructure and easy to deploy in existing network. Of course, the route optimization May be more complicated in Silkroad than in Teredo, because there is no information about the IPv4 address and UDP port through which a Silkroad client can be reached in its IPv6 address. Expires November,2004 [Page 24] Internet-Draft Silkroad May 2004 8 Security Consideration All the interactions between the functional elements of the Silkroad model need to be secured. The security techniques adopted for each of these interactions are dependent on the concrete implementation. For the interaction between SN and SAR, secure SNMP could be adopted [7,8,9]. In addition, if a simpler approach based on RSH commands is used, standard IPsec mechanisms can be applied [10]. For the interaction between SC and SAR, a loss of confidentiality may occur whenever a SC disconnects from the Internet without tearing down the tunnel previously established through the SAR. As a result, the SAR will keep tunneling the IPv6 traffic addressed to that user to its old IPv4 address. However, the fact may be that this IPv4 address has already been dynamically assigned to another user. This problem could be solved by implementing on every tunnel the keep-alive mechanism as mentioned in section 7.2. In this way, the SAR will immediately stop IPv6 traffic forwarding towards disconnected users. On the other hand, the SC must ensure that the Silkroad tunnels that it uses remain valid. It does so by checking that packets are regularly received from the SAR. What's more, the SAR must implement protections against denial of service attacks which may occur whenever a malicious user exhausts all the resources available on the SAR and spoofs a SAR and sends improper information to the client. 9 IANA Considerations This memo requests an allocation of a "privileged" UDP port (TBD). 10 Acknowledgments The authors would like to thank Li Zhongcheng, Shi Jinglin and Ma Jian for their comments, and Zhang Tianle for initial implementations. Expires November,2004 [Page 25] Internet-Draft Silkroad May 2004 Normative References [1] P. Srisuresh and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC3022, Jan 2001. [2] P. Srisuresh and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC2663, Aug 1999. [3] J. Postel, "User Datagram Protocol", RFC 768, August 1980. [4] J. Postel, "Internet Protocol", RFC 791, September 1981. Informative References [5] J. Rosenberg, J. Weinberger, C. Huitema and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [6] C. Huitema, "Teredo: Tunneling IPv6 over UDP through NATs", draft-huitema-v6ops-teredo-01.txt (Work in Progress), February 2004. [7] B. Wijnen, D. Harrington and R. Presuhn, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [8] U. Blumenthal and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [9] B. Wijnen, R. Presuhn and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [10] S. Kent and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [11] A. Durand, P. Fasano, I. Guardini and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. Expires November,2004 [Page 26] Internet-Draft Silkroad May 2004 Authors' Addresses Liu Min Institute of Computing Technology Chinese Academy of Sciences Box 2704, Beijing, 100080 PRC Email: liumin@ict.ac.cn Wu Xianguo Institute of Computing Technology Chinese Academy of Sciences Box 2704, Beijing, 100080 PRC Email: xgwu@ict.ac.cn Cai Yibing Institute of Computing Technology Chinese Academy of Sciences Box 2704, Beijing, 100080 PRC Email: cyb@ict.ac.cn Jin Mingye China Unicom No.133A, Xidan North Street, Xicheng Beijing,100032 PRC Emailú¦jinmy@chinaunicom.com.cn Li Defeng HUAWEI Technologies Co., LTD. Hua Wei Bld., No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing, 100085 PRC Email: 77cronux.leed0621@huawei.com Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires November,2004 [Page 27]