Subject: RE: Enterprise Analysis DSTM Issue

From: "Bound, Jim" <[email-masked]>
Date: Tue, 9 Aug 2005 22:48:22 -0400

The DSTM authors will get back to the WG and you on our decision
regarding DSTM in a few weeks.

We have and will continue to take WG input and incorporate consensus and
clearly abide by requirements in the IETF to assure our IETF rules of
engagement are followed strictly.  In addition I will respond to Pekka's
excellent technical discussion points as always for some time now. 

Regarding your lack of apology that is fine below, I will take that as a
no and note it to my self.  No reason to further discuss.

Regarding your individual input, opinion, and analysis it is read.

Regarding your view on IPv6 dominant deployment we can just agree to
disagree as two people. I see no point of rehashing again.  Ipv6
dominant networks are a requirement and the WG consenus is that it will
in fact be a reality, as I hear consensus.

Regarding DSTM it does assume a dual stack on all nodes and states that
clearly in the spec and supports IPv6 - in - IPv6 tunneling RFC should
be used.  It is only the IPv4 routing within the DSTM domain that will
not be used and this was an idea supported by the market and that is
input at least to those of us that will drive and assist the market to
use DSTM as an IPv6 Transiton mechanism.  To state DSTM does not support
a dual-stack method is not valid based on the DSTM spec.

/jim

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]] 
> Sent: Tuesday, August 09, 2005 4:50 PM
> To: Bound, Jim
> Cc: [email-masked]
> Subject: Re: Enterprise Analysis DSTM Issue
> 
> let's clarify on the conversation.
> 
> a) Pekka said that the term "Dual-Stck" was heavily overloaded, and  
> it didn't seem wise for the working group to recommend 
> something that  
> was so unclear.
> 
> b) You said that you had no intention of removing DSTM (your  
> experimental work) from the draft regardless of working group  
> (Pekka's) input, because you had customers interested in running DSTM.
> 
> c) I said that a working group draft needs to reflect working group  
> input, and that if this could not be accomplished then maybe the  
> document should not be a working group document.  That is not a  
> position I plan to apologize for; it is also related to the reason  
> that v6ops doesn't work on transition strategies - the various  
> transition discussions in v6ops did not lead to convergence on a  
> single or small number of recommended strategies.
> 
> d) You now have your back up.
> 
> Pekka's comments originate from the dual use of the term "dual  
> stack". The IETF has a long-standing recommendation that a network  
> should run both IPv4 and IPv6 (network layer forwarding, 
> routing, and  
> so on) natively, allowing end systems to use either protocol 
> with the  
> expectations one would have of any native deployment. This is  
> described as "dual stack" in RFC 1933 and its successor 2893, in  
> several RFCs describing potential transition mechanisms (2765, 2766,  
> and 2767 come quickly to mind). The term "dual stack" is also 
> used by  
> DSTM. But DSTM doesn't actually run two stacks in the network. It  
> runs an IPv6-only network (at least as far as its customers are  
> concerned) and provides a way for IPv4 systems to rendezvous over it  
> and tunnel through it, allowing end systems to run dual stacks. In  
> your words:
> 
>       DSTM [DSTM, DSTM+] is a useful tunneling mechanism for 
> later in  
> the
>       enterprise transition or deployment of IPv6-dominant 
> network links
>       is desired. DSTM is to being submitted as an IETF Experimental  
> RFC.
> 
> Pekka's observation is that while this is mostly transparent to the  
> end system, it is hardly transparent in the network and (being  
> experimental) is not something the IETF is at this time 
> recommending.  
> This reflects my comment to you of perhaps two months ago. I'm all  
> for your draft discussing dual stack mechanisms - mechanisms 
> that use  
> two stacks, consistent with RFC 2893. But recommending DSTM in a  
> working group recommendation is not consistent with its experimental  
> status. RFC 2026 says, in section 4.2.1:
> 
>     The "Experimental" designation typically denotes a specification  
> that
>     is part of some research or development effort.  Such a  
> specification
>     is published for the general information of the Internet technical
>     community and as an archival record of the work, subject only to
>     editorial considerations and to verification that there has been
>     adequate coordination with the standards process (see below).  An
>     Experimental specification may be the output of an organized  
> Internet
>     research effort (e.g., a Research Group of the IRTF), an IETF  
> Working
>     Group, or it may be an individual contribution.
> 
> and in section 3.3:
> 
>     (d)  Limited Use:  The TS is considered to be appropriate for use
>          only in limited or unique circumstances.  For example, the  
> usage
>          of a protocol with the "Experimental" designation should  
> generally
>          be limited to those actively involved with the experiment.
> 
> In other words, an experimental protocol or procedure may be a  
> perfectly good protocol or procedure and may be a candidate for  
> future standardization. It may have customers using it. However, its  
> general utility has not been shown at the point in time that it has  
> been given that status, and the protocol or procedure is not  
> recommended for general deployment until the experiment has been run.
> 
> So, I have two expectations of a working group document: that it  
> reflect the opinions of the working group, and that it reflect the  
> recommendations of the IETF. As you and I discussed in July, the  
> statement
> 
>       Later in the transition process, after the enterprise has
>       transitioned to a predominately IPv6 infrastructure, 
> the architect
>       should implement the Dual-IP Transition Mechanism [DSTM, DSTM+].
> 
> fails the latter point, and from the sound of Pekka's comment, fails  
> the former point as well.
> 
> I appreciate that you are accepting a number of Pekka's other  
> comments. I'd like you to consider carefully his comment 
> regarding DSTM.
> 
> On Aug 9, 2005, at 1:02 PM, Bound, Jim wrote:
> 
> > WG Members,
> >
> > For DSTM we are going to discuss as authors what we want to 
> do here  
> > per
> > Fred's mail telling us we could go away if we leave it in 
> the spec, at
> > least my read of his mail. This will take us a few weeks as some  
> > are on
> > summer vacation.
> >
> > For your information if your new.  DSTM had a minimum of two years  
> > IETF
> > NGTRANS working group discussion, and had discussion before 
> that as  
> > the
> > AIIH proposal.  In fact the authors reduced and altered the DSTM
> > protocol several times per the NGTRANS Chairs input over 
> the years and
> > the WG.
> >
> > There will be a series of DSTM specifications sent for 
> Experimental  
> > RFC
> > in the next 6 months.  At the same time there will be a new industry
> > focus on DSTM, that will be quite rigorous, and produce a set of
> > deployment guidelines including DSTM for the IPv6 Transition.
> >
> > I realize DSTM is not an Experimental RFC now, but that was 
> because we
> > were not sure best path to move the work until about 3 
> weeks ago.  But
> > ISATAP is still awaiting Experimental RFC, was only discussed in  
> > NGTRANS
> > too, not v6ops, and we still need a Tunnel Set Up Protocol.  Yet  
> > both of
> > these are fine to reference in the spec?  If true, is that "fair".
> >
> > DSTM is a mechanism that is part of the plan for several  
> > enterprises, it
> > is a valid reference.
> >
> > No need to respond or support this mail that is not its purpose.   
> > But I
> > want you the WG members to understand our decision or my 
> "individual"
> > decision when it is made in the next few weeks.
> >
> > Also it would have been nice if this could have been 
> brought up when I
> > asked are there other issues in person at the Paris IETF last  
> > week.  We
> > could have all met that care in person then at that IETF event.
> >
> > /jim
> >
>

---

From: Tim Chown <[email-masked]>
Date: Wed, 10 Aug 2005 14:01:30 +0100

> a dual-stack method is not valid based on the DSTM spec.

One option may be to title it 'Dual Stack (Host) Transition Mechanism' to
distinguish it from 'conventional' dual stack where dual stack on the
wire is used (and nodes may be v4 only, v6 only or both).

I think enough people know what DSTM is as to not change the acronym.

Tim

---

From: Stig Venaas <[email-masked]>
Date: Wed, 10 Aug 2005 15:23:26 +0200

> wire is used (and nodes may be v4 only, v6 only or both).

Yes that might be an idea. Not to be difficult, but a router and, thus a
network of routers, can easily forward IPv6 without having a TCP/IP stack,
so strictly speaking we're misusing the term dual-stack a little bit when
we talk of dual-stack networks too (: Anyway, it's how people use it that
is important, and it's become common to talk of dual-stack networks.

> I think enough people know what DSTM is as to not change the acronym.

Right, might be confusing to change the name again (or go back to the
AIIH name...). I don't care that much about the name though. There are
some people deploying IPv6-only networks today, and I'm sure there will
be more in the future. So I do see the need for IPv4 over IPv6 tunneling.

Stig

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Aug 2005 16:34:54 +0300 (EEST)

> be more in the future. So I do see the need for IPv4 over IPv6 tunneling.

Yeah, but your last sentence was exactly my point.

You don't need the mechanism labeled as DSTM to do "IPv4 over IPv6 
tunneling".

If that's what we wanted, we could just say we need v4-over-v6 and be 
done.

As I said in my earliest mail, I think we now should get the people 
actually doing DSTM deployments or otherwise interested in it to state 
1) what they believe it does, and 2) what are their requirements for a 
solution in more generic terms?

Below is cut'n'pasted from my earlier mail:

As it is, different people use "DSTM" to mean at least the following 
things:
  a) v4-in-v6 tunnels
  b) automatically set-up v4-in-v6 tunnels
  c) automatic set up of v4-in-v6 tunnels when the host
     doesn't have v4 address and an app wants to create a v4 socket
  d) automatic monitoring and tear-down of said v4-over-v6 tunnel
     when the host detects it no longer needs the address/connectivity
  e) plus a number of extensions for even more colorful setups.

We need to separate "use of v4-in-v6 tunnels as a concept" from "DSTM 
the protocol".  Fleshing it out or removing it seem the only choices.

-- 
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: Tim Chown <[email-masked]>
Date: Wed, 10 Aug 2005 14:59:57 +0100

> If that's what we wanted, we could just say we need v4-over-v6 and be 

But you could say the same for other protocols mentioned.
 
My view is that the style of DSTM commentary in 8.4 is good, but 8.1 is
too strong.   We should keep DSTM cited as a 'useful tool for IPv6
dominant infrastructures'.  We can state in the analysis that we need
a protocol for that scenario (#3 of RFC4057) that supports:

  a) v4-in-v6 tunnels
  b) automatic set up of v4-in-v6 tunnels when the host
     doesn't have v4 address and an app wants to create a v4 socket
  c) authentication for tunnel setup

>  e) plus a number of extensions for even more colorful setups.

but these are too specific for the analysis text.

Look at RFC3904.  That cited Teredo as 'work in progress'.  I see no reason
why we can't state what generic problem DSTM is solving (assuming we can agree
that!) and cite DSTM as an example, and 'work in progress'.   We could
even add a recommendation, as per section 7 of RFC3904, saying we should
develop DSTM or something 'DSTM-like'.   

Scenario 3 of Section 3.1 of RFC4057 means we need text for this case.

I could also point out Section 6.2 of RFC3094:

   6.2.  IPv4 Connectivity Requirements 

   Local IPv4 capable hosts may still want to access IPv4-only services.
   The proper way to do this for dual-stack nodes in the unmanaged
   network is to develop a form of "IPv4 over IPv6" tunneling.  There
   are no standardized solutions and the IETF has devoted very little
   effort to this issue, although there is ongoing work with [DSTM] and
   [TSP].  A solution needs to be standardized.  The standardization
   will have to cover configuration issues, i.e., how to provision the
   IPv4 capable hosts with the address of the local IPv4 tunnel servers.

I think this still applies.  If anything, it adds to the case for the
IETF to get active in this issue, via lrw WG or whereever.   So we have
unman and ent cases anting some solution in this space.

-- 
Tim/::1

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Aug 2005 18:31:45 +0300 (EEST)

First note: you may have an assumption that I have something against 
v4-in-v6 tunnels in general.  Even though I don't see the management 
simplicity considerations myself, I don't object to having a simple 
solution.

So, a v4-in-v6 solution is "just OK".  But this is already provided 
under "tunnel broker" section.  I don't see the _other_ requirements 
for the additional DSTM features at least yet.

On Wed, 10 Aug 2005, Tim Chown wrote:
> We can state in the analysis that we need

OK, this is good.  Let's try to separate b) into three:

   b1) automatic set up of v4-in-v6 tunnels

   b2) automatic set up of v4-in-v6 tunnels when the host
      doesn't have v4 address

   b3) automatic set up of v4-in-v6 tunnels when the host
      doesn't have v4 address and an app wants to create a v4 socket

What are the requirements, exactly?

> but these are too specific for the analysis text.

Maybe, maybe not -- but we need to figure out what's the thing that 
people are looking for.

> develop DSTM or something 'DSTM-like'.

Yes, but Teredo has a very clear applicability and scenarios.

[More or less automatic] IPv4-in-IPv6 tunneling also can also be 
argued for.  That can be solved with a tunnel broker; DSTM specifies 
much more.

So, the point here is, do we just need [automatic] v4-in-v6 tunnel 
set-up mechanism (provided by tunnel brokers), or something more (it 
isn't clear _what_, exactly).

> unman and ent cases anting some solution in this space.

Yes, there is no doubt v4-in-v6 tunneling is needed.  A standards 
track solution already exists (RFC 2473).   But if you need more, 
tunnel server/broker concept is widely used, and I believe that's what 
lrw is aiming to solve.

---

From: Fred Baker <[email-masked]>
Date: Wed, 10 Aug 2005 09:00:33 -0700

On Aug 10, 2005, at 6:34 AM, Pekka Savola wrote:
> We need to separate "use of v4-in-v6 tunnels as a concept" from  
> "DSTM the protocol".  Fleshing it out or removing it seem the only  
> choices.

So what I hear you arguing for, which I think is consistent with  
Tim's comments, is that this section should say that we require a  
tunneling solution which might use a variety of tunnel approaches  
including virtual circuit networks including MPLS, IP/IP, IP/GRE,  
IPSEC Tunnel Mode, and so on, and that in addition a common  
rendezvous mechanism is required. DSTM is an example of a rendezvous  
mechanism, as are the DNS-ALG in NATPT, the mechanism in Silkroad,  
and so on, and v6tc-or-whatever is chartered to come up with that  
mechanism.

Am I correct?

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Aug 2005 20:18:24 +0300 (EEST)

On Wed, 10 Aug 2005, Fred Baker wrote:
>> We need to separate "use of v4-in-v6 tunnels as a concept" from "DSTM the 
>> protocol".  Fleshing it out or removing it seem the only choices.
>
> So what I hear you arguing for, which I think is consistent with Tim's 
> comments, is that this section should say that we require a tunneling 
> solution which might use a variety of tunnel approaches including virtual 
> circuit networks including MPLS, IP/IP, IP/GRE, IPSEC Tunnel Mode, and so on, 
> and that in addition a common rendezvous mechanism is required. DSTM is an 
> example of a rendezvous mechanism, as are the DNS-ALG in NATPT, the mechanism 
> in Silkroad, and so on, and v6tc-or-whatever is chartered to come up with 
> that mechanism.
>
> Am I correct?

Yes, but I think this still misses the point.  I don't have strong 
objections to v4-in-v6 tunneling (whatever the encapsulation), BUT the 
main point is that referring to DSTM as an example of either v4-in-v6 
or v4-in-v6 rendezvous function is misleading.

If we want to refer to a protocol or a rendezvous function for 
v4-in-v6 tunnels, we can just refer to RFC2473 and TSP (they're 
already referred to in the document)?  The first describes the 
encapsulation ("configured v4-in-v6 tunneling"), the second also more 
of the rendezvous (+address assignment) function.  Both are pretty 
straightforward protocol specifications, easy to implement 
interoperably if you need to, and the scope of the specs is well 
understood.

Referring to DSTM is misleading because its specification seems like a 
mix between a paper describing a relatively straightforward v4-in-v6 
concept (though this might or might not have been obvious 5 years ago) 
and a protocol specification.  And:

  a) I have not seen a justification for a concept document (we should 
consider including the appropriate discussion in this doc, if the 
concept needs more discussion)

  b) The spec is not useful as a protocol specification; while it can 
probably be used to create an implementation, it doesn't seem 
sufficient to create interoperable implementations, and it's not clear 
what's actually required for the implementations and what's not.

As rewriting an external spec (the area of which would be under 
discussion for softwires BOF/WG) is out of scope for this WG (though I 
might be willing to help off-list in the interest of clearing up the 
confusion)..

My question is now: is there something missing in ent-analysis with 
regards to the description of the v4-in-v6 tunnel concept?

If we could find appropriate description, maybe we wouldn't need the 
references to DSTM and all would be clearer to the reader.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 10 Aug 2005 19:19:41 +0200

On Wed, Aug 10, 2005 at 06:31:45PM +0300, Pekka Savola wrote:
[...]
> What are the requirements, exactly?

If you have sufficient amount of IPv4 addresses you could probably
use several mechanisms where you set up tunnels and assign addresses
to every client in the network. As I understand it, DSTM is in
particularly useful when you have hosts that rarely need IPv4
communications, you have enough IPv4 addresses to serve the hosts
using IPv4 at any given time, but not for all the IPv4-capable
hosts simultaneously. Hence the idea of being triggered by apps
trying to use IPv4 (e.g. creation of v4 socket).

I'm not sure b2 makes sense above. You could automatic setup
v4-in-v6 tunnel when hosts boots provided you have enough IPv4
addresses. However, I think IPv6-only core only makes sense if
IPv4 is rarely used. In that case it makes sense to have tunneling
state only when needed. And as I said above, this may also make
sense if you have lack of addresses. So the tunnel setup and the
assignment of IPv4 address should only be done when needed. One
way of detecting need, is request an IPv4 socket.

I think several networks could manage with little IPv4 traffic
already today. In particular if you have dual-stack mailservers,
dual-stack web proxies etc. You would only need IPv4 to the
internet when using more rare applications.

There are also some networks today that struggle getting enough
IPv4 addresses for the network infrastructure...

Stig

---

From: Fred Baker <[email-masked]>
Date: Wed, 10 Aug 2005 10:47:49 -0700

It is very refreshing to find technical discussion regarding a  
document in progress on this list. We need to do more of it.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Aug 2005 21:50:05 +0300 (EEST)

> trying to use IPv4 (e.g. creation of v4 socket).

First off, the mechanism which triggers the activation of the tunnel 
is purely a local decision (no bits on the wire), right?  So, it's not 
clear that this even requires a protocol specification. (Especially if 
the protocol specification doesn't really help the implementor in 
implementing the algorithm.)

But I'm not sure that v4 access is triggered by apps can even work 
(the number of possible failure modes is one reason why I've been very 
troubled by the approach).

For example, almost all server apps try to create a socket both for v6 
and v4 when they start up.  Many client programs also do similar 
things. Are you saying that the hosts would not have any of these 
applications or couldn't use them without lots of manual configuration 
(i.e., forcing to use only v6 socket) ?

In fact, this dynamic setup when a v4 socket creation is attempted 
could even be undesirable.  There have certainly been folks which 
don't want to enable v6 when apps try to create v6 sockets (some 
systems have done this automatically).  It seems clear that the same 
also holds for v4.  I.e., a quick failure in the socket loop might be 
better (and intended) than trying to obtain the address.

[...]
> IPv4 addresses for the network infrastructure...

Yes, but one could say that those networks are also the ones who are 
most likely to use private addresses and NAT.

Given that the assumption is that v6 is already deployed basically 
everywhere (at least in the enterprise):
  1) public v4 addresses are typically needed by public server apps or
     some p2p softwares and similar
  2) p2p softwares and similar are also the ones which have most
     profits of being ported to v6
  3) public server apps are those (e.g., the enterprise web servers)
     which require very high amount of reliability.  Would you as
     a system/network admin trust a transition mechanism to
     automatically get [often dynamic] address (and update DNS etc.)
     using mechanisms like this?

That is, frankly, I don't think there is really big justification for 
dynamic "enablement" due to address space scarcity.  Private addresses 
would be just fine in those deployments AFAICS.  So whether to enable 
the tunnels dynamically or not seems to be just a matter of whether 
you want all the hosts which you know should run v4 apps to get 
connectivity reliably w/o complexity at the startup (or some locally 
defined) time.

In other words, IMHO "dynamic setup" seems like an interesting problem 
(e.g., to be fussed about by geeks like you and me :), but not 
something we need to solve.. Less is More.

---

From: Suresh Satapati <[email-masked]>
Date: Thu, 11 Aug 2005 11:53:34 -0700

> way of detecting need, is request an IPv4 socket.

Not being judgemental about DSTM, one could argue such a method
of detection is outside the scope of this wg, or maybe even outside the
scope of IETF.