Subject: Teredo spec has been published!

From: "Christian Huitema" <[email-masked]>
Date: Fri, 3 Feb 2006 19:13:41 -0800

The Teredo spec has been published as an individual submission:

	RFC4380 
	Teredo: Tunneling IPv6 over UDP through Network Address 
	Translations (NATs)  
	C. Huitema February 2006 ASCII   
	PROPOSED STANDARD

Thanks to the many NGTRANS and V6OPS working group members who reviewed
the spec!

-- Christian Huitema

---

From: haofeng Zhang <[email-masked]>
Date: Sun, 5 Feb 2006 10:56:54 +0800

Great News.
I am expecting the next version of Windows will support Teredo service
proposed by RFC4380.
Also, I think it will be more flexible if a Teredo Client accepts any
reasonable global IPv6 prefix, not only 2001:0000::/32 defined in the
sepcification.

--
Best regards,
Zhang haofeng

---

From: Vincent Jardin <[email-masked]>
Date: Sun, 05 Feb 2006 13:01:58 +0100

> reasonable global IPv6 prefix, not only 2001:0000::/32 defined in the

Yes, it would be very usefull with we can configure the Teredo prefix on
the next update of Windows, instead of having a hard-coded
2001:0000::/32.

Regards,
  Vincent

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 05 Feb 2006 13:14:15 +0100

I don't agree.

If you do so, you break one of the principles of Teredo, and then you do not
longer need an IANA assigned prefix.

The idea is to ensure that all the Teredo clients can talk peer-to-peer.

Regards,
Jordi

> De: Vincent Jardin <[email-masked]>
> Organización: http://www.6wind.com/
> Responder a: <[email-masked]>
> Fecha: Sun, 05 Feb 2006 13:01:58 +0100
> Para: haofeng Zhang <[email-masked]>
> CC: Christian Huitema <[email-masked]>, "[email-masked]"
> <[email-masked]>
> Asunto: Re: Teredo spec has been published!
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Sun, 5 Feb 2006 14:23:28 +0100

> If you do so, you break one of the principles of Teredo, and then you
> do not longer need an IANA assigned prefix.

> The idea is to ensure that all the Teredo clients can talk

I would say there are different problems here:
1/ the transition from Microsoft experimental (3ffe:831f::/32) to IANA 
assigned (2001:0000::/32) prefixes
2/ internal private use of Teredo as a NAT-friendly ISATAP, whereas it 
is defined as a NAT-friendly 6to4 (sort of)

Regarding the Teredo prefixes transition:

I would say it would have been more practical if Windows-based clients 
had accepted any (sensible?) Teredo prefix until the RFC was published, 
which is what my -admittedly hardly used at all- implementation does. 
Similarly, it should have been possible to configure the prefix 
advertised by servers and relays until a post-RFC updates, to ease 
migration of pre-RFC users.

The fact is that they are many Windows users that use pre-RFC Teredo 
clients that only accept 3ffe:831f::/32, probably many of whom not even 
knowingly. As a reference, the www.videolan.org typically receives 
something like 50Gb/day IPv4 traffic, 500Mb/day native IPv6+6to4, 
50Mb/day via pre-RFC Teredo, and absolute zero IANA Teredo. It has 
Teredo relays for both Microsoft experimental and IANA assigned 
prefixes.

If you maintain a relay, you can transition smoothly by putting two 
relays until 6bone is phased out. But for Teredo servers and clients, 
there is no way to transition smoothly at the moment.

Regarding the private use case:

The fact that the prefix has to be a /32 renders, it is almost 
impossible in practice. I would say implementors should obviously use 
and encourage use of the IANA prefix by default. It is arguably useless 
to allow the use of another prefix, but implementations should at least 
accept the experimental prefix until 6bone is phased out for pratical 
reasons discussed above.

A company willing to use Teredo internal as a "NAT-friendly ISATAP" may 
still want to use a different prefix, e.g. for access-control, or 
because it wants to put the servers/relays on private IPv4. However, in 
any case, that would involve a bunch of modifications in contradiction 
to the Teredo RFC in any case, such as:
- allowing Teredo addresses bits 32-63 to differ from the server IPv4 so 
that 64-bits prefix is sufficient, provided all clients can assume the 
others use the same server as themselves,
- ignoring the requirements for mapped and server IPv4 addresses to be 
unicast global.

So... well... there is indeed probably no case for a *RFC-compliant* 
implementation to accept a prefix other than the IANA (and 
experimental) one(s).

But then, Microsoft is already promising an unspecified extension in 
upcoming Vista, which is the ability to use Teredo from behind a 
symmetric NAT, at the obvious expense of transitive reachability. Also, 
as I already pointed out a long time ago here, Teredo clients assume 
that the server secondary IPv4 address is always next to the server 
primary address, though I could find no mention of that requirement in 
the RFC nor any of the six drafts (I've not read the older "shipworm" 
ones).

-- 
Rémi Denis-Courmont
Student-engineer at the Ecole Centrale Paris
http://www.simphalempin.com/home/infos/cv.shtml.en

---

From: Vincent Jardin <[email-masked]>
Date: Sun, 05 Feb 2006 15:02:58 +0100

Jordi,

Even if you remove the constraint on the hard-coded prefix, the Teredo
clients "can talk peer-to-peer"; it does not break any compatibility,
please can you explain why it would be broken ?

The requirement of being able to configure the Teredo prefix is:
  - control the transition from the previous prefix to the new one,
  - be able to support some private usages of the Teredo prefix
(development, testing, etc.).

I don't say that 2001:0000::/32 should not be the default value, as
recommended by the IANA, but it should be configure-able. It is more a
implementation constraint rather than a standardization constraint.

Regards,
  Vincent

Le dimanche 05 février 2006 à 13:14 +0100, JORDI PALET MARTINEZ a

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 05 Feb 2006 15:17:16 +0100

Hi Remi,

I see your point regarding the transition, but I'm sure Microsoft, which is
where we have the *much much much* higher % of the Clients, Servers and
Relays, will issue an automatic update that will correct it. Also, as the
clients point by default to the Microsoft Teredo Server, something there may
also do "something" regarding this.

May be the Microsoft Patch for the servers will come out first, allowing
some kind of "dual prefix" support until 6bone phase out, then after a few
weeks, the Client update will be made available.

I guess Christian could describe the "transition" plan so other implementers
can follow a similar approach and we don't get 2 disconnected Teredo
"Internets".

Once this Teredo Server/Relay/Client update is available, at least in our
case, which maintain a Server and a Relay, will move to the new prefix. It
will be just a matter of minutes, hopefully, but an "official" procedure
could be very useful.

I'm not sure if it make sense to make a draft for this. It could be possible
to make a draft just to describe it, even if afterwards is not promoted to
RFC. Just in order to ensure that people looking for "Teredo" in the next 6
months for implementing and/or deploying it, make sure to follow the same
"transition" plan.

Regards,
Jordi

> De: Rémi Denis-Courmont <[email-masked]>
> Organización: Élève de l'École Centrale Paris
> Fecha: Sun, 5 Feb 2006 14:23:28 +0100
> Para: <[email-masked]>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 05 Feb 2006 15:29:08 +0100

Hi Vincent,

I mean peer-to-peer across different domains if we allow different prefixes
(except the issue of the transition period from the 6bone one to the RFC
one).

(see my previous email regarding the transition)

In general I'm not sure if it is a good practice to ignore the IANA defines
definitions for prefixes, addresses, ports, etc. If you really want to use a
different one for an experiment, it may be safer to force doing a patch for
it instead of allowing users to arbitrary change it.

Regarding the private usages, it will be probably so easy as to describe
them in a new draft, so implementers can decide if support only the existing
RFC or also the private usages (I guess most of the open source
implementations will be happy to do that).

Regards,
Jordi

> Fecha: Sun, 05 Feb 2006 15:02:58 +0100
> CC: "[email-masked]" <[email-masked]>
>> This electronic message contains information which may be privileged or
>> confidential. The information is intended to be for the use of the
>> individual(s) named above. If you are not the intended recipient be aware
>> that any disclosure, copying, distribution or use of the contents of this
>> information, including attached files, is prohibited.
>> 
>> 
>> 
>> 
>> 
> 
>

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 5 Feb 2006 08:37:31 -0800

> implementations will be happy to do that).

The Teredo specification, as it stands, is largely "good enough". It
could certainly be made even better. But, before we work on a new
solution, it would be nice to understand the new requirements that we
try to address. 

The current specification is designed for the "capital I" Internet, and
the use of a common prefix pretty much derives from that requirement.
The 32 bit length derives from a requirement was to embed the server's
IPv4 address in the prefix. If you don't do that, you end up with a
reliance on a static "IPv4 anycast" address, which would have to be used
as source address for the packets sent by Teredo servers. This was in
fact the original "shipworm" design. It was rejected by the IESG because
using "anycast" as source causes hard management issues. In any case,
obtaining a /32 bit allocation from the IANA was very hard, and I don't
think we will see another one anytime soon.

-- Christian Huitema

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 05 Feb 2006 19:19:30 +0100

Agree.

So then let's work in a "transision" plan. I guess we want to make it
coordinated among different implementations, not just the Microsoft one.

I guess Microsoft has some specific thought of how you're going to do that,
and it will be good to coordinate some how, so the current people who has
already deployed Teredo Relays and/or Servers can follow the same criteria.

Can you already tell us something on this, or is still not concreted ?

Regards,
Jordi

> De: Christian Huitema <[email-masked]>
> Fecha: Sun, 5 Feb 2006 08:37:31 -0800
> Para: <[email-masked]>, Vincent Jardin <[email-masked]>
> CC: <[email-masked]>
> Conversación: Teredo spec has been published!
> Asunto: RE: Teredo spec has been published!
>

---

From: Gert Doering <[email-masked]>
Date: Sun, 5 Feb 2006 19:31:09 +0100

Hi,

On Sun, Feb 05, 2006 at 08:37:31AM -0800, Christian Huitema wrote:
[..]
> think we will see another one anytime soon.

Off a slightly different tangent: what sort of routes are expected to
show up from 2001:0000::/32 in the routing table?

I didn't read recent Teredo drafts, but if I remember the concept clearly
enough, the embedded server (relay?) address would make this "one /64
prefix per server", right?

Or will all relays announce the whole /32, effectively anycasting it,
as it is done with 6to4 2002::/32?

(Sorry if this is something obviously answered in the draft - I really
don't have time to read up on the details right now, but I think I'll
have to update my filtering recommendations page).

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  81421

SpaceNet AG                    Mail: [email-masked]
Joseph-Dollinger-Bogen 14      Tel : +49-89-32356-0
D- 80807 Muenchen              Fax : +49-89-32356-234

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 5 Feb 2006 11:20:28 -0800

> show up from 2001:0000::/32 in the routing table?

I would expect a single 2001:0000::/32 route leading to the closest
teredo relay.

> prefix per server", right?

Only a tiny fraction of the traffic goes through the servers. The bulk
of it goes on a direct IPv4 path between the relay and the Teredo host.
The benefits of "per server' /64 routes would be marginal and the impact
on the routing tables would be large.

> as it is done with 6to4 2002::/32?

Yes. With this design, traffic will go from IPv6 host to the closest
Teredo relay and from there on a direct IPv4 path to the Teredo host.
This is expected to be a good approximation of the shortest path between
the IPv6 host and the Teredo host.

-- Christian Huitema

---

From: haofeng Zhang <[email-masked]>
Date: Mon, 6 Feb 2006 10:17:49 +0800

Hi, Christian, Jordi, Vincent:

My reason to raise such a topic is the concern that current Teredo
specification may cause routing problem in the real ISP network, because of
the fact that many ISPs wanna control the routing policy of their own IPv6
network. And this problem may cause ISPs unwilling to deploy Teredo service.

This problem, for example,
1. Based on current Teredo spec, the core router in an IPv6 network shall
advertise 2001:0000::/32 route through BGP4+ to other ASes, to ensure the
connectivity of its own Teredo users. Also, I think it's better for the core
router to also act as a Teredo relay router, otherwise too many static
routes have to be configured. But how can  we expect the IPv6 core router to
have the native IPv4 connection?

2. In some situation, the traffic from a IPv6 server to a Teredo user in ISP
network A may bypass ISP B's network, if the Teredo relay router of ISP B is
nearer to the IPv6 server. So for all network operators, it's hard to
predict and control both the IPv4 routing path and IPv6 routing path.

Actually, We are considering the availability of 6to4 service in our current
IPv6 network construction. Teredo service is using the similarly solution in
IPv6 routing to 6to4.

Vicent gave the good point that 2001:0000::/32 should be the default value,
as recommended by the IANA, but I recommend that this prefix be
configure-able in Teredo server. In such case, the ISP provides the Teredo
server, and the ISP controls IPv6 routing policy.

Best wishes

Haofeng. Zhang

--
Best regards,
Zhang haofeng

---

From: Gert Doering <[email-masked]>
Date: Mon, 6 Feb 2006 10:26:59 +0100

Hi,

> as it is done with 6to4 2002::/32?

Make that 2001::/32 and 2002::/16.

Just to make sure the correct value is in the list archives.

Sorry.

Gert Doering
        -- NetMaster

---

From: Simon Leinen <[email-masked]>
Date: Mon, 06 Feb 2006 10:38:26 +0100

Gert Doering writes:
> Or will all relays announce the whole /32, effectively anycasting
> it, as it is done with 6to4 2002::/32?

2002::/16, you mean.
-- 
Simon.