Subject: (ngtrans) I-D ACTION:draft-ietf-ngtrans-shipworm-07.txt

From: [email-masked]
Date: Thu, 15 Aug 2002 08:15:42 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Next Generation Transition Working Group of the IETF.

	Title		: Teredo: Tunneling IPv6 over UDP through NATs
	Author(s)	: C. Huitema
	Filename	: draft-ietf-ngtrans-shipworm-07.txt
	Pages		: 53
	Date		: 14-Aug-02
	
We propose here a service that enables nodes located behind one or
several IPv4 NATs to obtain IPv6 connectivity by tunneling packets
over UDP; we call this the Teredo service. Running the service
requires the help of 'Teredo servers' and 'Teredo relays'; the
Teredo servers are stateless, and only have to manage a small
fraction of the traffic between Teredo clients; the Teredo relays
act as IPv6 routers between the Teredo service and the 'native' IPv6
Internet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-shipworm-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ngtrans-shipworm-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ngtrans-shipworm-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 15 Aug 2002 09:32:47 -0700

As mentioned in the announcement, I just published a new version of the
Teredo draft. This is a very thorough revision, which is meant to
address and fix the comments from the IESG reviewers, security issues
raised by other reviewers, and scalability issues that we discovered
through modeling, i.e. that traffic through the server exploded as the
proportion of non-Teredo hosts in the Internet increased. The most
visible changes are the following:

1) The anycast address is gone. This was a major contention point in the
operation area, and also proved to be a major deployment blocker.
Instead, we change the address format to include four components: the
Teredo service prefix, the IPv4 address of the server selected by the
Teredo host, the mapped IPv4 address of the Teredo host, and the mapped
port. If peers have "established contact" through the bubble mechanism,
they can send packets directly to the mapped address or mapped port; if
they have not, they can contact the host through the Teredo server,
which will relay.

2) We include a cone NAT optimization, as it turns out that a very large
fraction of the residential gateways are cone NAT. The server helps the
host finding out whether it is behind a cone NAT. In that case, the
"server IPv4 address" component of the Teredo IPv6 address is replaced
by a null address. Peers who want to send packet to a host behind a cone
NAT simply post the packet to the mapped address or mapped port.

3) We specify that the server will never carry any actual traffic, i.e.
will just carry the bubbles used to "establish contact". The actual
traffic will always flow directly between the peers; if connecting
between a Teredo host and an IPv6 peer, the traffic will flow through
the Teredo relay nearest to the peer. This has three kinds of benefits:
it resolves the server scaling issues; it resolves privacy concerns
raised by the possibility for the server to observe the hosts' traffic;
and it helps resolving security concerns that servers could be harnessed
to enable DOS attacks. A negative side effect of this decision is that
we cannot use Teredo behind a "symmetric NAT".

4) We add an MD5 signature to the address mapping exchanges between
client and server, preventing server spoofing and thwarting some DOS and
man-in-the-middle attacks against the client. The scheme is the same as
proposed for STUN. The presence of the signature would actually allow
the same code to be used for Teredo and for an UDP-based tunnel broker;
this part of the design is however only sketched in the draft.

In short, I believe that the new draft resolves the operational and
security concerns associated with the initial design. The draft comes
with an extensive security section, including a detailed threats
analysis.

-- Christian Huitema