Subject: RE: DSTM

From: "Christian Huitema" <[email-masked]>
Date: Wed, 23 Jun 2004 09:14:27 -0700

> But when I saw the mail Teredo was going to move without doing
finishing
> all scenarios/analysis docs I thought we were opening the flood gates
> for all mechanisms.  I could be wrong?  But all mechanisms should be
> applied to that entire set of work efforts.

I have two issues with this statement.

First, I don't think we should wait until *all* scenario documents are
completed before we standardize or publish *any* new transition
technology. The bar ought to be lower: we should progress a transition
technology if we agree that it is clearly needed by at least one
scenario. Otherwise, we could keep inventing new scenarios, and we would
always have to wait until yet another scenario analysis is completed.

Second, we have to define what "completed" means. What is the decision
point? We have actually all but completed the "unmanaged networks"
evaluation: we went through the working group last call, and the
document is now on the IESG plate. Based on this scenario, doing work on
Teredo is not spurious.

Now, for the record, I am a strong believer in letting a thousand RFC
bloom and letting the market decide. The IETF WG should not be in the
business of evaluating business cases. We should definitely work on
Teredo, and also ISATAP, DSTM, and tunnel brokers.

-- Christian Huitema

---

From: Tim Chown <[email-masked]>
Date: Wed, 23 Jun 2004 18:53:29 +0100

> document is now on the IESG plate. Based on this scenario, doing work on

Well, we saw recently in the discussion on the enterprise scenarios draft
that I proposed 4 scenarios to be considered, one of which lends itself 
to be addressed by DSTM.   Pekka objected that this was a "minority case",
and I don't know what happened after that.

So we can easily write in a scenario for DSTM in the enterprise draft, and
Jim has expanded already on what that is.   Likewise we can do so for ISATAP.   

Everything hangs on what the WG chair then dictates.   But the fact is that
there are networks out there wanting to run IPv6 only infrastructure
with IPv4 apps/data to be served, so as Marc and Jordi say, this is a real
requirement now.  As such I believe we should work on it in the IETF.  

The question from "on high" is where do we put the focus?  How wide is
our net to be?
 
> Teredo, and also ISATAP, DSTM, and tunnel brokers.

The beauty of the transition toolbox is that everyone can reach in and pick
out a different tool (or tools) for their situation.   Even in similar
scenarios, ISPs may take different paths, e.g. in a recent European NREN
survey, 75% offered a 6to4 relay for their users, 25% tunnel broker(s).

ISPs in Asian networks will also likely deploy different solutions because
they appear more keen to move to IPv6 only infrastructure earlier (e.g.
CERNET in China) - do we let them make up their own solutions just because
the WG chair thinks China is a fringe case?  (Ok those were not Pekka's
words, but they're kind of implied ;)

I agree the scenario work needs to be wrapped up, but I think we should cast
a wide net, not a narrow one.   

Tim

---

From: Pekka Savola <[email-masked]>
Date: Thu, 24 Jun 2004 00:40:26 +0300 (EEST)

A new topic to better suit the subject..

> document is now on the IESG plate. Based on this scenario, doing work on

What Christian said. The analysis of 3GPP, Unmanaged and ISP have all
already left this WG (with rough consensus) and are at IESG
evaluation, or beyond the IESG evaluation (and none of documents got
IESG pushback on Teredo/BGPtunnel/etc.).  I fail to see what more one
could expect here.  Does it matter what we decide e.g.  in the
Enterprise document, if Unmanaged, ISP, or 3GPP already requires a
certain kind of mechanism?

There is, however, an argument to be made if a mechanism would be
required in multiple scenarios, where one or more of the scenarios was
not finished yet -- then the question would be what would be the basis
on where to evolve the specification? (for example, let's consider
ISATAP in 3GPP: one could remove direct tunneling support, but then it
might become useless (at least to some) in Enterprise -- for
mechanisms which dependencies it might be worth a bit more of
wait-and-see, but e.g. Teredo has only been proposed in the Unmanaged
scenario.

So IMHO this is an argument for moving forward (if there is consensus,
as there seems to be in Unmanaged and ISP) in all the scenarios which
are already at the IESG (read: when there is consensus in the WG, and
there is no objection at the IESG).  The mechanisms required by
scenarios which are not done yet IMHO cannot go forward at this point.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 23 Jun 2004 23:37:02 -0400

Hi Tim,

>survey, 75% offered a 6to4 relay for their users, 25% tunnel broker(s).

This is also the biggest problem with having a large tool-box of 
transition mechanisms -- everyone can reach in and pick out a 
different tool...  So, in order for a given host implementation or 
piece of networking equipment to operate properly on multiple 
networks, it will need to implement or interoperate with _all_ of the 
tools.

This leads to increased complexity, more security issues, more points 
of failure, larger code sizes, higher costs for networking 
infrastructure, etc.

One of the points of standardization, IMO, is to promote small, 
simple, interoperable implementations.

I think that there is a clear need for a (single, standard) mechanism 
that solves the problem that Teredo solves, and the Teredo approach 
(which was updated over time based on a lot of feedback from security 
people, IAB folks, etc.) is, IMO, a pretty good way to meet that need.

I am less certain that there is a real need for DSTM today. Jim Bound 
and a few others have indicated that they have customers who need 
this, but they won't say who those customers are or what is driving 
them towards this choice.  Without knowing the details of those 
deployment scenarios, I can't have an informed opinion about whether 
DSTM is the best way to meet those customers' needs.

I have not personally heard any ISP or Enterprise operators indicate 
their intention to run IPv6-only backbones any time soon.  I believe 
that this will happen at some point in the future, but I am not 
certain (from my own experience or any direct communication) that 
this is a widespread need today.  If this won't be needed until 
later, I think that we should wait until later to provide it -- when 
we will know more about how IPv6 has been deployed.

However, even if I accept that there is a need for a solution in this 
space now, I have some serious reservations about the DSTM solution 
as it is currently documented.  In particular, I don't know why we 
would want to standardize a solution in this space that includes 
multiple non-interoperable options for how a dual-stack host can 
obtain a temporary IPv4 address (DHCPv6 and TSP).  Would a client 
need to implement both to work on different networks?  And how would 
a client know which one to use in any particular situation?  Would it 
try one and then fail over to the other?

I'm also not sure how/why we need a specific DSTM server at all... 
How is DSTM superior to using a DHCPv6 option to get the 
configuration information needed to set-up a configured IPv4-in-IPv6 
tunnel and then using DHCPv4 over that tunnel?

Margaret

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 24 Jun 2004 11:21:30 +0200

On 24-jun-04, at 5:37, Margaret Wasserman wrote:

> I am less certain that there is a real need for DSTM today.

Good! So we have the chance to be proactive.

> their intention to run IPv6-only backbones any time soon.

Probably because the notion that this could be a viable option hasn't 
entered the brains of the decision makers yet.

If you consider the complexities of building a large IPv4 network, 
especially if you want to avoid NAT but don't have a lot of address 
space, versus the simplicity of building a similar network using IPv6, 
it makes sense that people will want to run an IPv6-only network and 
tunnel IPv4 over it where needed as soon as the necessary mechanisms 
(IPv4-in-IPv6 tunneling, IPv6 DNS resolver discovery) are available and 
all the hardware can handle IPv6 in the fast path. (I had a few 
conversations with vendors at the summit thing last week and many still 
do IPv6 in software.)

> I'm also not sure how/why we need a specific DSTM server at all... How 
> is DSTM superior to using a DHCPv6 option to get the configuration 
> information needed to set-up a configured IPv4-in-IPv6 tunnel and then 
> using DHCPv4 over that tunnel?

I for one am not in favor of making DHCPv6 a dependency.

I also have another problem with DSTM as it is: it depends on a single 
gateway. That's not good. We need redundancy.

It might be better to create an IPv4-in-IPv6 tunneling mechanism that 
treats the IPv6 network as an IPv4 link layer and run standard IPv4 
protocols such as ARP and DHCP over that. (Similar to 6over4 but the 
other way around.) This should work very well in networks that support 
site-wide multicast. (There are some security issues with rogue DHCPv4 
servers but those can be mitigated by filtering broad/multicasts.)

However, we may also want to consider the situation where a user is 
roaming on a standard issue IPv6 network far away, and wants to tunnel 
back home. There are already various VPN solutions that do this for 
IPv4 over IPv4, though, so hopefully we don't have to reinvent the 
wheel here.

One remark about the draft: there are some serious line length issues, 
please fix as this makes some parts very hard to read.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 24 Jun 2004 12:19:05 +0200

On 24-jun-04, at 11:21, Iljitsch van Beijnum wrote:

> protocols such as ARP and DHCP over that.

This also has the advantage that hosts within the same site don't have 
to go through a tunnel server in order to reach eachother.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 24 Jun 2004 14:45:48 +0200

In your previous mail you wrote:

   other way around.)

=> "4over6" won't solve the same kind of problems, for instance
it couldn't help to communicate with an old IPv4-only-for-ever printer.
   
Regards

[email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 24 Jun 2004 15:11:51 +0200

> it couldn't help to communicate with an old IPv4-only-for-ever printer.

So how does DSTM solve this?

I was assuming there would be a v4-over-tunnel cloud and a native v4 
cloud, and obviously some kind of connection between both clouds.

In DSTM there is a single place where this happens: the gateway where 
the tunnels terminate. "4over6" could be more flexible as packets don't 
necessarily flow through a single gateway. We may even provide for some 
kind of "proxy 4over6" tunneling so that IPv4-only hosts in otherwise 
IPv6-only networks may enjoy connectivity.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 24 Jun 2004 16:02:44 +0200

=> yes, your remark that 4over6 is more oriented to direct
communication between dual-stack nodes is in the same kind of ideas...

=> in DSTM there is no need to add this kind of gateways between
the two clouds, i.e., it is built in.

   the tunnels terminate.

=> there is no requirement to have only one gateway. In fact the only
constraint is when the gateway gets automatically the IPv6/IPv4 address
mapping packets from the legacy IPv4 world come back through the same
gateway.

   "4over6" could be more flexible as packets don't 
   necessarily flow through a single gateway. We may even provide for some 
   kind of "proxy 4over6" tunneling so that IPv4-only hosts in otherwise 
   IPv6-only networks may enjoy connectivity.
   
=> I really liked 6over4 so I should like 4over6 too but I am afraid
the arguments against 6over4 apply too to 4over6. And the DSTM space
was already explored: there is nothing that 4over6 can do and DSTM can't.

Regards

---

From: Fred Templin <[email-masked]>
Date: Thu, 24 Jun 2004 09:47:25 -0700

Iljitsch van Beijnum wrote:

>  IPv4 over it where needed as soon as the necessary mechanisms 
> (IPv4-in-IPv6 tunneling, IPv6 DNS resolver discovery) are available 
> and all the hardware can handle IPv6 in the fast path. (I had a few 
> conversations with vendors at the summit thing last week and many 
> still do IPv6 in software.)

IPv6 flows are identified by the 3-tuple of (src, dst, flow_id), i.e.,
there are 128+128+20=276 bits needed for handling IPv6 in the
fast path. Is anyone making CAMs that wide?

Fred
[email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 24 Jun 2004 19:02:39 +0200

> fast path. Is anyone making CAMs that wide?

Wouldn't just src + flowid be enough? And not everyone supports 
initializing the flow label to something else than 0... So it's back to 
port numbers in that case.

But you are assuming the fast path would be some kind of flow 
switching. I wish you wouldn't, as this doesn't work in ISP 
environments where the number of new flows per second is just too high, 
not to mention what happens when worms spit out packets with random 
destinations at high speed.

---

From: Fred Templin <[email-masked]>
Date: Thu, 24 Jun 2004 10:08:46 -0700

Iljitsch van Beijnum wrote:

> initializing the flow label to something else than 0... So it's back 
> to port numbers in that case.

Dunno, but I don't think it can be assumed that port numbers
will be accessible (other than at the endpoints, that is).

Fred
[email-masked]

> environments where the number of new flows per second is just too 
> high, not to mention what happens when worms spit out packets with 
> random destinations at high speed.
>

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 24 Jun 2004 13:24:27 -0400

>> their intention to run IPv6-only backbones any time soon.

- in which part of the planet you talk to?
- in which market are you talking to?

> space, versus the simplicity of building a similar network using IPv6, it
> makes sense that people will want to run an IPv6-only network and tunnel
> (IPv4-in-IPv6 tunneling, 
available now. implemented. I can show you a demo.

> IPv6 DNS resolver discovery) are available and

sorry. don't agree. 
 - many ways to acheive redundancy: anycast discovery, vrrp, etc... 
 - other mechanisms do not have any redundancy: i.e. 6to4 border gateway.

Marc.

> back home. There are already various VPN solutions that do this for IPv4
> over IPv4, though, so hopefully we don't have to reinvent the wheel here.
> 

------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Mon, 28 Jun 2004 18:24:16 +0300

Hello,

I generally agree with Pekka. The original idea was to have the
scenarios/analysis documents stabilized before moving forward. Most of
the documents have stabilized (are at the IESG). I don't believe we need
RFC numbers before going forward. I don't think the IESG will have that
strong objections that the WGs technological choices will be totally
overruled. And if there are (and they have valid points) we'll take care
of them case-by-case.

We (chairs - Pekka and I) are in dialog to find out from our ADs what is
the correct way forward with this. I hope we'll get a proposal for the
way forward from them quite soon. However, I don't think anything will
change in the original way forward: When the scenarios/analysis
documents are done, the work on the solutions can move forward. 
I hope and believe that we are getting close to that time. I'm sorry it
took longer than expected.

Anyways, I don't think it is in our (the chairs) interest or in the
interest of the IESG to be unfair in this (or in any other) point. Let's
be patient for a day or two and let's make sure our scenarios/analysis
documents go forward as planned.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]