Subject: RE: DSTM

From: "Bound, Jim" <[email-masked]>
Date: Tue, 22 Jun 2004 11:04:08 -0400

Hi Thomas,

In ISP and Enterprise scenarios where client/user has determined that
IPv6 will be dominant routing deployed backbone and node protocol and
reducing use of IPv4 applications except where it must be supported as
legacy (e.g. port has not happened, or port planned later of app).  In
addition the user/client does not want to use any protocol transition
that requires architecturally defined prefix within the IPv6 network
(e.g. 6to4, Teredo).  Users will get IPv4 address for temporary use only
on DSTM hybrid-stack machines and Tunnel End Points to get to router at
the edge.  DSTM tech leaders do not believe this is useful for unmanaged
networks at this time.   DSTM clients can use tunnel-broker client
interface or DHCPv6.

This is spelled out we feel in our draft but will have additional
statements in the draft applicable to the scenarios in draft which will
be sent in a few weeks.

Also see: http://www.dstm.info/  Folks can download on Linux or XP and
test it.  We have PHD research engineer doing scalability testing now
and should have reports completed by end of the summer maybe some
preliminary data for San Diego too from two large IPv6 operational pilot
networks.  It also will work with Tunnel Broker product on the market
today for IPv6 and is being deployed in Enterprise pre-production
network currently.

All these mechanisms require robust testing and for security to
operationally verify implementation.  The current specs for 6to4,
ISATAP, DSTM, Tunnel Broker, NAT-PT, are being verified now with
implementations.  Be good to get RFCs in some form for guidance besides
just 6to4 which will not be used we have learned by all enterprises.
Also Silkroad is now on the radar screen of implementors too with no IPR
requirements at this point in time.  Some are looking at BIA and Socks
too but not as widely.  6over4 appears to be dead because IPv4 multicast
was not widely deployed in the first place.

Regards,

/jim

> -----Original Message-----
> From: Thomas Narten [mailto:[email-masked]] 
> Sent: Tuesday, June 22, 2004 8:00 AM
> To: Bound, Jim
> Cc: [email-masked]
> Subject: Re: DSTM 
> 
> Hi Jim.
> 
> Which of the scernarios that the WG has developed call for 
> DSTM (or something like DSTM)?
> 
> Thomas
> 
>

---

From: Thomas Narten <[email-masked]>
Date: Wed, 23 Jun 2004 07:36:34 -0400

> legacy (e.g. port has not happened, or port planned later of app).

This seems to me to be something that won't be compelling scenario for
quite some time. In other words, not something we need to focus on in
the short term.

Let me repeat the question  I asked previously:

   Which of the scernarios that the WG has developed call for DSTM (or
   something like DSTM)?

One of the purposes of the scenario analysis was to understand which
transition mechanisms were really important so that we could focus on
them. Also, understanding which are the core pieces would help us
label the RFCs more appropriately (e.g., Standards track
vs. experimental).

> In addition the user/client does not want to use any protocol
> transition that requires architecturally defined prefix within the
> IPv6 network (e.g. 6to4, Teredo).

I don't understand this. What is the _technical_ requirement here?_

Thomas