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
| | |
| <address type="ipv4">10.0.0.1</address> |
| ------------------------------------>|
| |
| | IPv4 address in packet (9.0.0.1)
| | different from IPv4 address
| | in TSP protocol (10.0.0.1):
| Offer "v6udpv4" tunnel
| |
| <tunnel ... type="v6udpv4" ...> |
| <------------------------------------ |
...
Figure 2: Server detecting if client behind NAT
---------------------------------------------------------------------
Parent & Blanchet Expires December 23, 2002 [Page 7]
Internet-Draft teredo-tsp June 2002
5. Teredo/TSP client and server negociation examples
The following example demonstrates a client connecting to a Teredo/
TSP server to request a tunnel creation.
In the first phase, the server announces its capabilities (can
provide both IPv6 in IPv4 and IPv6 in UDP in IPv4 tunnels) and the
client authenticates.
In the second phase, the client requests a tunnel creation to
transport IPv6 inside IPv4 without specifing the exact encapsulation
(v6any) (the client may not know if it is behind a NAT or not). The
client also sends its IPv4 address to the server. At this stage, the
server is able to determine whether 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.
In the example below, the server detected that the client is behind a
NAT so a v6 over UDPv4 tunnel is negociated to the client (offered
tunnel type is v6udpv4).
Parent & Blanchet Expires December 23, 2002 [Page 8]
Internet-Draft teredo-tsp June 2002
-- Successful TCP Connection --
C:VERSION=1.1 CR LF
remove attribute. add tunnel=v6udpv4
S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=DIGEST-MD5 CR LF
C:AUTHENTICATE ... CR LF
S:200 Authentication successful CR LF
C:Content-length: ... CR LF
<tunnel action="create" type="v6any">
<client>
<address type="ipv4">10.1.1.1</address>
</client>
</tunnel> CR LF
S: Content-length: ... CR LF
200 OK CR LF
<tunnel action="info" type="v6udpv4" lifetime="1440">
<server>
<address type="ipv4">206.123.31.114</address>
<address type="ipv6">3ffe:b00:c18:ffff:0000:0000:0000:0000</address>
</server>
<client>
<address type="ipv4">10.1.1.1</address>
<address type="ipv6">3ffe:b00:c18:ffff::0000:0000:0000:0001</address>
</client>
</tunnel> CR LF
In the next example, the server determines that the client is not
behind a NAT so the client is offered a standard IPv6 in IPv4 tunnel
[ref].
Parent & Blanchet Expires December 23, 2002 [Page 9]
Internet-Draft teredo-tsp June 2002
-- Successful TCP Connection --
C:VERSION=1.1 CR LF
S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=DIGEST-MD5 CR LF
C:AUTHENTICATE ... CR LF
S:200 Authentication successful CR LF
C:Content-length: ... CR LF
<tunnel action="create" type="v6any">
<client>
<address type="ipv4">9.1.1.1</address>
</client>
</tunnel> CR LF
S: Content-length: ... CR LF
200 OK CR LF
<tunnel action="info" type="v6v4" lifetime="1440">
<server>
<address type="ipv4">206.123.31.114</address>
<address type="ipv6">3ffe:b00:c18:ffff:0000:0000:0000:0000</address>
</server>
<client>
<address type="ipv4">9.1.1.1</address>
<address type="ipv6">3ffe:b00:c18:ffff::0000:0000:0000:0001</address>
</client>
</tunnel> CR LF
This example shows a client requesting a tunnel and an 48-bit IPv6
prefix. The server detected that the client is behind a NAT so a
Teredo tunnel is negociated to the client (offered tunnel type is
v6udpv4).
Parent & Blanchet Expires December 23, 2002 [Page 10]
Internet-Draft teredo-tsp June 2002
-- Successful TCP Connection --
C:VERSION=1.1 CR LF
S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=DIGEST-MD5 CR LF
C:AUTHENTICATE ... CR LF
S:200 Authentication successful CR LF
C:Content-length: ... CR LF
<tunnel action="create" type="v6v4" type="v6udpv4">
<client>
<address type="ipv4">10.1.1.1</address>
<router>
<prefix length="48"/>
</router>
</client>
</tunnel> CR LF
S: Content-length: ... CR LF
200 OK CR LF
<tunnel action="info" type="v6udpv4" lifetime="1440">
<server>
<address type="ipv4">206.123.31.114</address>
<address type="ipv6">3ffe:b00:c18:ffff:0000:0000:0000:0000</address>
</server>
<client>
<address type="ipv4">10.1.1.1</address>
<address type="ipv6">3ffe:b00:c18:ffff::0000:0000:0000:0001</address>
<router>
<prefix length="48">3ffe:0b00:c18:1234::</prefix>
</router>
</client>
</tunnel> CR LF
6. Differences between TSP-Teredo and Teredo
This proposal describes how Teredo can use TSP to provide new
services to clients. This section describes some of the new features
and differences in Teredo with TSP:
o Client can be a host or a router. As a router, the client can
receive an IPv6 prefix from the server.
o The IPv6 address (and prefix) assigned to the client is taken from
the global address space available to the service provider. There
is no need to embed the IPv4 and the UDP port number inside the
IPv6 address assigned to the client.
o The client IPv6 address and prefix are fixed. This has many
Parent & Blanchet Expires December 23, 2002 [Page 11]
Internet-Draft teredo-tsp June 2002
benefits such as permitting the client to deploy services that
require stable IPv6 addresses.
o If the NAT mapping for the client change, the tunnel needs to be
re-established through TSP. But the client IPv6 address does not
change.
o The client IPv6 address doesn't contain information that can be
considered sensitive (NAT mapping of the client, firewall state).
o Client IPv6 traffic is always routed to its associated TSP/Teredo
server. This is similar to an environment where clients dialup to
the enterprise NAS. This may lead to sub-optimal IPv6 routing
compared with stateless Teredo where the IPv6 traffic is routed to
the closest Teredo relay.
o Client is authenticated.
7. Security considerations
TBD
References
[1] Blanchet, M., "IPv6 over IPv4 profile for Tunnel Setup Protocol
(TSP)", draft-vg-ngtrans-tsp-v6v4profile-00 (work in progress),
July 2001.
[2] Blanchet, M., "Tunnel Setup Protocol (TSP)", draft-vg-ngtrans-
tsp-00 (work in progress), July 2001.
[3] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs",
draft-ietf-ngtrans-shipworm-05 (work in progress), February
2002.
[4] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel
Broker", RFC 3053, January 2001.
[5] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC 2893, August 2000.
Parent & Blanchet Expires December 23, 2002 [Page 12]
Internet-Draft teredo-tsp June 2002
Authors' Addresses
Florent Parent
Viagenie inc.
2875 boul. Laurier, bureau 300
Sainte-Foy, QC G1V 2M2
Canada
Phone: +1 418 656 9254
EMail: Florent.Parent@viagenie.qc.ca
URI: http://www.viagenie.qc.ca/
Marc Blanchet
Viagenie inc.
2875 boul. Laurier, bureau 300
Sainte-Foy, QC G1V 2M2
Canada
Phone: +1 418 656 9254
EMail: Marc.Blanchet@viagenie.qc.ca
URI: http://www.viagenie.qc.ca/
Appendix A. IPv6 over UDPv4 tunnel DTD
Parent & Blanchet Expires December 23, 2002 [Page 13]
Internet-Draft teredo-tsp June 2002
<?xml version="1.0"?>
<!DOCTYPE tunnel [
<!ELEMENT tunnel (server?,client?,broker?)>
<!ATTLIST tunnel action (create|info|list) #REQUIRED >
<!ATTLIST tunnel type (v6v4|v6udpv4|v6any) #REQUIRED >
<!ATTLIST tunnel lifetime CDATA "1440" >
<!ELEMENT server (address+,router?)>
<!ELEMENT client (address+,router?)>
<!ELEMENT broker (adress+)>
<!ELEMENT router (prefix?,dns_server?,as?)>
<!ATTLIST router protocol (rip|bgp) "">
<!ELEMENT dns_server (address+)>
<!ELEMENT as EMPTY>
<!ATTLIST as number CDATA #REQUIRED>
<!ELEMENT prefix (#PCDATA)>
<!ATTLIST prefix length CDATA #REQUIRED>
<!ELEMENT address (#PCDATA)>
<!ATTLIST address type (ipv4|ipv6|dn) #REQUIRED>
<!ATTLIST address length CDATA "">
]>
Parent & Blanchet Expires December 23, 2002 [Page 14]
Internet-Draft teredo-tsp June 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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 assigns.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Parent & Blanchet Expires December 23, 2002 [Page 15]