Network Working Group F. Parent Internet-Draft M. Blanchet Expires: December 23, 2002 Viagenie inc. June 24, 2002 TSP-TEREDO: Stateful IPv6 over IPv4 Tunnels with NAT using TSP and TEREDO draft-parent-blanchet-ngtrans-tsp-teredo-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. This Internet-Draft will expire on December 23, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Teredo [3] is a stateless mechanism to encapsulate IPv6 traffic in IPv4 when there is an IPv4 NAT between the tunnel endpoints. This document enhances Teredo by providing a stateful IPv6 in IPv4 connexion which enables additional features to be used, like permanent IPv6 address or prefixes. It uses the Tunnel Setup Protocol (TSP) [2] to negociate the parameters of the tunnel and identify the NAT translation map. TSP also enables negociation and establishment of prefixes, routing, DNS delegation and other parameters related to the tunnel. Parent & Blanchet Expires December 23, 2002 [Page 1] Internet-Draft teredo-tsp June 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. TSP-Teredo Operation . . . . . . . . . . . . . . . . . . . . 3 3. TSP Profile for Teredo . . . . . . . . . . . . . . . . . . . 4 3.1 Element 'tunnel' . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1 Attribute 'action' . . . . . . . . . . . . . . . . . . . . . 5 3.1.2 Attribute 'type' . . . . . . . . . . . . . . . . . . . . . . 5 3.1.3 Attribute 'lifetime' . . . . . . . . . . . . . . . . . . . . 5 3.2 Element 'server' . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Element 'client' . . . . . . . . . . . . . . . . . . . . . . 5 3.4 Element 'router' . . . . . . . . . . . . . . . . . . . . . . 6 3.5 Element 'dns_server' . . . . . . . . . . . . . . . . . . . . 6 3.6 Element 'prefix' . . . . . . . . . . . . . . . . . . . . . . 6 3.7 Element 'address' . . . . . . . . . . . . . . . . . . . . . 6 4. Tunnel encapsulation negociation . . . . . . . . . . . . . . 7 5. Teredo/TSP client and server negociation examples . . . . . 8 6. Differences between TSP-Teredo and Teredo . . . . . . . . . 11 7. Security considerations . . . . . . . . . . . . . . . . . . 12 References . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 A. IPv6 over UDPv4 tunnel DTD . . . . . . . . . . . . . . . . . 13 Full Copyright Statement . . . . . . . . . . . . . . . . . . 15 Parent & Blanchet Expires December 23, 2002 [Page 2] Internet-Draft teredo-tsp June 2002 1. Introduction Teredo [3] describes a service that enables nodes located behind one or several IPv4 NATs to obtain IPv6 connectivity by tunneling packets over UDP. This document describes how Teredo and TSP can be used together to provide new services to nodes behind an IPv4 NAT such as permanent IPv6 address or prefixes allocation, routing services, DNS delegation and other parameters related to the tunnel. 2. TSP-Teredo Operation In order to offer services such as permanent IPv6 address or prefix to clients, the Teredo server must work in stateful mode, where authentication phase is required prior to allocating a prefix to the client. This allows to tie an IPv6 prefix to an identity chosen by the client. This is the scheme proposed in TSP [2] and this document describes how TSP can be used in the Teredo context. In stateless Teredo [3], the initial traffic sent by the client is an IPv6 router solicitation to the Teredo server. By its stateless nature, the Teredo server offers IPv6 connectivity to any client. In the first phase of Teredo operation, the server obtains the IPv4 mapped (by NAT) address and UDP port of the client from the IPv6 router solicitation received from that client. Using this information, the client prefix is created from the Teredo global prefix space. This document proposes using TSP to allocate the IPv6 address to the client. The address allocated is taken from the global IPv6 address space available to the TSP-Teredo server. The syntax of the protocol is given in Section 3. Tunnel Setup Protocol [2] proposes a two phase process: In the first phase, the client authenticates to the tunnel server. If the authentication is successful, the client can request a tunnel establishement with a permanent (or temporary) prefix. The client prefix assignment is done during the TSP session. In TSP-Teredo mode, the TSP protocol is transported using UDP over IPv4, and the UDP port is the Teredo/TSP server port (to be defined). Upon successful authentication and address allocation, the IPv4 mapped (by NAT) address and UDP port of the client from the TSP packet are used to establish an IPv6 over UDP over IPv4 tunnel between the server and client. Parent & Blanchet Expires December 23, 2002 [Page 3] Internet-Draft teredo-tsp June 2002 --------------------------------------------------------------------- Client TSP/UDP/IPv4 Teredo/TSP server | TSP AUTH | | --------------> | | <-------------- | | TSP COMMAND | | --------------> | | <-------------- | | Use IPv4 client address | and UDP client port for | tunnel establishment | | | IPv6/UDP/IPv4 | | <=============> | | tunnel | Figure 1: Client to server initial negociation --------------------------------------------------------------------- 3. TSP Profile for Teredo The TSP profile uses a defined DTD (Appendix A) for the XML format of the message. The DTD contains the description of the tunnel XML message. This message is used by the TSP Teredo compliant host and server to provide the necessary information to establish an IPv6 in UDPv4 tunnel. A complete description of the protocol syntax can be found in TSP [2]. Examples of the client/server exchange are given in Section 5. 3.1 Element 'tunnel' The TSP message is composed of a 'tunnel' element that contains 0 or one server, client or broker elements. The 'tunnel' element is defined with 3 attributes which describes the 'action' requested in the message, the 'type' of tunnel requested, and the 'lifetime' of that tunnel. The following sections define the different 'tunnel' element attributes Parent & Blanchet Expires December 23, 2002 [Page 4] Internet-Draft teredo-tsp June 2002 3.1.1 Attribute 'action' Three values are possible for this attribute: create, delete and info. create: Sent by the client to request a new tunnel or update an existing tunnel. info: Sent by the client to request current properties of an existing tunnel. Also contains tunnel information sent by server to client delete: Sent by client to remove an existing tunnel on the server. 3.1.2 Attribute 'type' Identifies the type of tunnel requested. v6v4: request/allocate an IPv6 in IPv4 [5] tunnel v6udpv4: request/allocate an IPv6 in UDPv4 tunnel v6any: request a tunnel of any type supported. Can only be used when requesting a tunnel 3.1.3 Attribute 'lifetime' Length of time (minutes) when the tunnel is valid. This is not the prefix valid or preferred lifetime. Default is 1440 minutes, or 24 hours. 3.2 Element 'server' This element is used to describe the server tunnel endpoint. The 'server' element contains 2 elements: 'address' and 'router'. The 'address' element is used to send both IPv4 and IPv6 addresses of the server's tunnel endpoint. The 'router' element may be present to provide information for the routing method choosen by the client. 3.3 Element 'client' This element is used to describe the client parameters and will be used by the server to create the appropriate tunnel. This is the only element sent by a client to the server. The 'client' element MUST contain one or more 'address' elements. The server will then return the IPv6 address endpoint and domain name Parent & Blanchet Expires December 23, 2002 [Page 5] Internet-Draft teredo-tsp June 2002 inside the 'client' element when the tunnel is created or updated. The 'client' element MAY contain one 'router' element to ask for a prefix delegation. The 'router' element contains the 'protocol' attribute which specify the routing method to be use between the server and the client. If no attribute is specified the the routing will use static routes. 3.4 Element 'router' This element is used by the client to request a prefix delegation. The 'router' element can be specified with an attribute to specify the routing protocol to be used between the client and server. The 'router' element may contain the following elements: prefix: Used by the client to request a prefix length. Used by the server to specify the prefix allocated. dns_server: Used by the client to request DNS delegation for the requestd prefix. as: Used when BGP routing is negociated. 3.5 Element 'dns_server' This element is used for DNS delegation of the allocated prefix. The 'dns_server' is composed of one or more 'address' elements that specify the name servers used for the delegation. 3.6 Element 'prefix' The 'prefix' element has a 'length' attribute that indicates the prefix length. When sent by the client, this element is used to specify the desired prefix length to the server. When sent by the server, both the prefix and prefix length are specified for the client configuration. 3.7 Element 'address' In this element, the attribute 'type' is used to specify whether this element represents an IPv4 address, an IPv6 address or a domain name. The attribute 'length' represent the prefix length or netmask of the address, if applicable. Parent & Blanchet Expires December 23, 2002 [Page 6] Internet-Draft teredo-tsp June 2002 4. Tunnel encapsulation negociation Assuming that the Teredo/TSP server supports IPv6 in IPv4 tunnels [5] in addition to IPv6 in UDPv4 , the TSP-Teredo server can negociate with the client on the tunnel that will be established. During the TSP command phase, the Teredo/TSP server is able to detect if the client is behind a NAT by comparing the IPv4 address of the client inside the TSP protocol and the source address of the IPv4 header. As shown in Figure 2, the client sends its IPv4 address and the tunnel type requested to the server when requesting a tunnel (command phase). In the example here, the client requested a tunnel type of 'v6any' (did not specify the encapsulation type). The server is then able to compare the client IPv4 address from the received packet to the client IPv4 address in the TSP protocol. The server will offer a IPv6 in UDPv4 --------------------------------------------------------------------- Client NAT Teredo/TSP server 10.0.0.1 10.0.0.1<>9.0.0.1 | | | |
10.0.0.1 | | ------------------------------------>| | | | | IPv4 address in packet (9.0.0.1) | | different from IPv4 address | | in TSP protocol (10.0.0.1): | Offer "v6udpv4" tunnel | | |