Subject: RE: DSTM

From: "Bound, Jim" <[email-masked]>
Date: Thu, 24 Jun 2004 03:24:47 -0400

Margaret,

I am sure Tim will respond to your entire mail thread but I want to
respond to a few of your assumptions and questions below. 

> 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 is simply invalid logic and it is none of yours, mine, or the
IETF's business what a free enterprise systems does at all.

The more tools the better.

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

I don't agree at all.  Each mechanism will be used for a solution not
all mechanisms in one network.  I don't know of any user that is that
stupid to use 5 mechanisms at once.  The point you continue to miss is
that there could be 5 different usrs with 5 different needs for
transition and each of the 5 mechanisms are useful to them each
individually as one tool.

Forcing all users to use only X, Y, and Z is absurd and the market,
implementers, and users will reject that IETF view and will simply
ignore the IETF regarding transition and seek the solutions they need
elsewhere.  if that happens we have failed here in the IETF and it will
be recorded as so for sure.

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

And because there are 6 or 8 transitiion mechanisms that do not
duplicate each other does not prevent your statement above.

What the IETF cannot do is try to dictate the policy for deployment in
the market at all.  That is absurd and will be rejected by the people in
the IETF and the market.  It will also cause serious discussions with
the IETF's higher authority for sure.
 
> I have not personally heard any ISP or Enterprise operators 
> indicate their intention to run IPv6-only backbones any time 
> soon.  

Well they do exist because you have not heard of them does not mean they
don't exist.  

Or are you calling us who say this liars?

>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.

It is needed now as much as any mechanism is needed now.

> 
> 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). 

You should comment on the spec then rather than taking general pot-shots
at engineers work in the IETF.

And by the way they are interoperable across multiple OSs and platforms
and in fact saw them running today in a network lab.  Go read the DSTM
web page pointer I sent and download the implementations and test it for
your self.  It works.

> 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?

We should take these questions to specific DSTM thread and I think they
are implementation questions not standards questions, but we could
debate that on such a thread.

Regarding divulging who the users are?  I and no one here has to do that
and no one has done that other than generically for Teredo, 6to4, or any
mechanism. DSTM should not be treated unfairly because you, Pekka, or
Thomas are uninformed of this deploymet. So please don't use that
argument here its a valuing difference issue and I don't want to have to
go there.  I will say the users who are wanting DSTM are Military,
Security Defense Concerns, and Provider type users and world wide and
not in just one geography.  I am sure you realize myself or other DSTM
team members, and others on this list cannot share with you who exactly
they are for confidence reasons.

DSTM will be deployed as priority on Moonv6 as transition mechanism and
across North American, European, and Asian geogrpahys as Moonv6 is now
an International Network Pilot in process for your information.  So we
are not talking about a little lab in the corner of the world or a mom
and pop small business wanting the benefits of DSTM and more importantly
moving to dominant IPv6 backbone networks. And a network does not mean
just the public Internet. 

Regards,
/jim
> Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 24 Jun 2004 07:52:44 -0400

Hi Jim,

I did not mean anything that I said in my previous note as a personal 
attack on you or anyone else involved in the DSTM work.  I think it 
is possible for well-intentioned, reasonable people to have a 
difference of opinion, and I think that is the case here.

In particular, I think that we have a difference of opinion regarding 
three things (1) the effect on the market of having multiple 
solutions/mechanisms to resolve overlapping problems, and (2) the 
purpose and effect of IETF standardization, and (3) whether DSTM is a 
solution that should be standardized in the IETF.

>individually as one tool.

Many stack vendors attempt to write generic implementations that will 
work properly in a wide range of environments.  So, even though each 
network administrator would choose a single mechanism, if there are 
five different mechanisms in widespread use some vendors will need to 
implement all five.  Since one of the good features of IPv6 is that 
it requires no client-side IP stack configuration, there shouldn't be 
a need (and there may be no opportunity) to configure each client to 
know which transition mechanisms are in use on a given network. So, 
if there are five (or more) different mechanisms by which a client 
could obtain an IPv4 or IPv6 connectivity, the client will need to 
know (1) which mechanisms to try in which order, (2) whether to 
continue trying new mechanisms when IP (v4 or v6) connectivity has 
(apparently) been obtained through one of them, and (3) which IP 
address/connectivity mechanism to use for each communication if it 
has obtained connectivity via more than one mechanism.

>be recorded as so for sure.

I do not believe that the IETF has the power to force anyone to do 
anything, nor do I think we should try.

I think that it is our role to put forth what we think are 
technically and architecturally sound, useful, interoperable 
standards that make the Internet work better and promote our shared 
IETF values like the openness of the Internet, end-to-end security, 
privacy and end-user empowerment.  If people find our standards to be 
valuable, relevant and trustworthy they will use them.

Lots of other groups also develop standards, or de facto standards, 
for the Internet (the W3C, 3GPP, the IEEE, Microsoft...) and more 
power to them!

>the market at all.

I agree, and I don't think that we try to do this.  By choosing to 
standardize one thing and not another, or by publishing documents as 
Information or BCP RFCs, we do offer our advice to the market 
regarding what we (the IETF) consider to be sound, useful and 
interoperable solutions.  But, we certainly don't try to dictate what 
vendors can or cannot implement, nor do we have any means to dictate 
what users will/will not deploy.

>Or are you calling us who say this liars?

Jim, I did not mean to imply that the people you have talked to do 
not exist!  And, I don't think that you are a liar.

I merely said that I can't assess the needs of users that I don't 
know in scenarios that have not been described to me in detail.  I 
have not (personally) talked to someone who has told me that they are 
deploying a large IPv6-only network.

>at engineers work in the IETF.

I believe that the paragraph above is a comment on the spec...

The specification for DSTM includes two separate mechanisms to obtain 
an IPv4 address -- DHCPv6 and TSP.  There doesn't seem to be a 
mandatory-to-implement mechanism on either end, and the two 
mechanisms are not interoperable with each other.  So, it is quite 
possible to build a TSP-only DSTM client and a DHCPv6-only DSTM 
server (or vice versa) that are both fully compliant with the DSTM 
spec but which will not interoperate with each other.

So, for example, if a vendor wants to write a client implementation 
that can work in both types of DSTM environment, it will need to 
include client support for both flavors of DSTM.  How will it know 
which one to try first?  Should it try both, even if the first one 
seems to work?  If they both work and provide different configuration 
information, which information should the node use?  If it uses both 
sets of information, how will it decide which connectivity path to 
use for each communication?

Even if you were to remove one of the mechanisms from the DSTM draft, 
it won't resolve the larger issue that we're creating regarding how 
an IPv6 host comes up on the network and how it chooses between the 
multiple methods of IPv6 connectivity and address configuration that 
may be available.

>debate that on such a thread.

Since the subject of this thread is "Re: DSTM", I am not sure that it 
can get more DSTM-specific than that!  :-)

>just the public Internet.

I am very happy for you and for others that have worked so hard on 
DSTM that people are using it.

It isn't necessarily the case, though, that the IETF should 
standardize everything that people choose to use.  Nor, is it the 
case that people should only use things that are standardized in the 
IETF.

Please note that I don't consider it my decision (alone) whether DSTM 
is or is not standardized by the IETF.  It is my personal opinion 
that we should not standardize DSTM (at least as currently 
documented) because of the technical/deployment issues that I have 
stated above and in my earlier message.  However, it is quite 
possible that the consensus of the v6ops WG will not agree with me.

Before we can fruitfully make that decision, though, we need to 
document the expected deployment scenarios in an enterprise scenario 
document, and we need to reach WG consensus on that document.  Then 
we can talk about whether DSTM applies to one or more of the expected 
scenarios and whether it is the best solution, technically and 
architecturally, to address any of those scenarios.

Margaret

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Thu, 24 Jun 2004 17:25:14 +0200

Hi Margaret, all,

Regarding your comment on the different mechanisms selection, please see http://www.watersprings.org/pub/id/draft-palet-v6ops-auto-trans-00.txt (and provide inputs !). By the way this document has disappeared from the RFC editor, not sure why ! (someone can provide some hint or what to do about it ?).

Regarding this thread in general, I've customers asking for only IPv6 deployment. If this is a solution I buy it ;-) I must recognize I've not played myself with DSTM, but it seems so, and clearly a fair decision needs to be taken with any transition mechanism if is the available solution for any identified scenario.

We can't rely in only a few 100% perfect mechanisms, or it will be too late. Similarly we can't rely in just 3, 4 or 5 mechanisms if they don't cover all the identified scenarios. I agree that as less mechanism we have, as better, but it seems that the 4 already identified are not enough ? Then what we are waiting for ? Deploying non-standard mechanisms ? No thanks, if we can avoid it.

I asked this in the last meetings ... What the rest believe ?

Regards,
Jordi

----- Original Message ----- 
From: "Margaret Wasserman" <[email-masked]>
To: "Bound, Jim" <[email-masked]>; "Tim Chown" <[email-masked]>; <[email-masked]>
Sent: Thursday, June 24, 2004 1:52 PM
Subject: RE: DSTM

> architecturally, to address any of those scenarios.

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line 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.