[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DSTM


Hi Tim,

At 6:53 PM +0100 6/23/04, Tim Chown wrote: 
 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.


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

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