Subject: RE: (ngtrans) moving to IPv6

From: "Bound, Jim" <[email-masked]>
Date: Tue, 19 Mar 2002 10:40:32 -0500

Margaret,

All this working group can do is provide tools and then provide how they
"might" be used in a scenario.  To think we can define every potential
use or mandate any use for transition is pure folly.

Do you agree?

In fact at this time the industry, vendors, and users are way ahead of
the NGTRANS group and scenarios are all ready being packaged and
delivered to deploy IPv6 as we speak.  My hope is that those vendor
solutions are good input to the continued NGTRANS process.

But the market is now far ahead of where we are in this working group
and cannot wait for us.  For example ISATAP, DSTM, and Teredo will be
deployed and in CY 2002.

thanks
/jim

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Tuesday, March 19, 2002 8:57 AM
> To: D. J. Bernstein
> Cc: [email-masked]
> Subject: Re: (ngtrans) moving to IPv6
> 
> 
> 
> 
> >If you want IPv6 to succeed as a global network, you have to 
> figure out
> >how to make an IPv6 address just as useful as an IPv4 address. How do
> >you plan to do that, Keith?
> 
> This is, in part, the role of the ngtrans WG.  We are 
> developing tools and techniques that are intended to 
> prevent the balkanization of the Internet when some 
> hosts are using IPv4-only, some are dual stack, and
> some are using IPv6-only.
> 
> *Magic* moments don't just happen.  They are brought
> about by careful planning and hard work.
> 
> We know that we haven't solved all of the problems in 
> this area, and we welcome your input to identify and
> solve the remaining problems.  
> 
> Over the next several months, we will be exploring 
> transition scenarios and working on an overall 
> architecture for IPv6 transition.
> 
> We expect that many of the individual transition 
> tools that we have developed will have important 
> places in that architecture, and our experience with 
> these tools has helped us to understand the types of 
> problems that need to be solved, and some options for 
> solving them.  But we agree that a grab-bag of transition 
> tools is not sufficient to bring about an organized and 
> effective IPv6 transition.
> 
> >The way to make IPv6 addresses work is to teach every 
> Internet computer
> >how to talk to IPv6 addresses---not just as an option that 
> the sysadmin
> >might configure, but as something that's automatically 
> enabled as part
> >of regular software/hardware upgrades.
> 
> Not all IP nodes are subject to "regular" software/
> hardware upgrades.  
> 
> Even when nodes are upgradeable, end users are constrained 
> by what their software/hardware providers choose to supply
> to them.  It is not realistic to believe that all software
> and/or hardware providers will make IPv6 available at the
> same time.
> 
> So, we are assuming a long time period during which IPv4-only,
> dual stack and IPv6-only nodes will coexist on _the_ Internet
> (not two Internets -- one Internet simultaneously supporting
> two different versions of the Internet Protocol).
> 
> >Will this be done overnight? Of course not. But it is the crux of the
> >IPv6 transition. I remain astonished that this WG didn't settle the
> >details years ago.
> 
> History aside, there is no time like the present...
> 
> You have mentioned a goal state of having all Internet nodes
> "talk to IPv6 addresses".  Do you have a concrete proposal 
> for how we can reach that point?
> 
> Margaret
> 
> 
> 
> 
> 
> 
> 
> >---D. J. Bernstein, Associate Professor, Department of Mathematics,
> >Statistics, and Computer Science, University of Illinois at Chicago 
> 
>

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 19 Mar 2002 11:05:21 -0500

>solutions are good input to the continued NGTRANS process.

Don't you think that it makes sense for us to work with these
people, document the conclusions that they have come to, and
make sure that our tools are well-suited to address the situations
in which they will be used?

Margaret

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 20 Mar 2002 10:20:10 -0500

Tony,

This will be done.

thanks
/jim

> From: Tony Hain [mailto:[email-masked]]
> Sent: Tuesday, March 19, 2002 7:07 PM
> To: Bound, Jim; Margaret Wasserman
> Subject: RE: (ngtrans) moving to IPv6
> 
> 
> Jim,
> 
> You are correct that the IETF can not and should not try to define
> specific deployment strategies for a particular network. Vendors will
> need to work closely with their customers to identify the details in
> these cases. On the other hand, there are general deployment 
> models that
> many networks use, and it is appropriate for ngtrans to show at least
> one configuration of the tool set that can be used for that general
> model.
> 
> Yes the market is trying to move beyond where the IETF is, but it is
> still necessary for ngtrans to provide some degree of 
> guidance about an
> appropriate use of the tools. This will not prevent vendors 
> from showing
> their customers how a particular configuration of the tool set will
> apply to a specific environment. There is no reason to wait for the
> IETF. On the contrary, please help distill and document the general
> models used so the overall pace of deployment can step up by reducing
> the current level of confusion.
> 
> Tony
> 
> 
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Bound, Jim
> > Sent: Tuesday, March 19, 2002 11:46 AM
> > To: Margaret Wasserman
> > Subject: RE: (ngtrans) moving to IPv6
> >
> >
> >
> > Yes and we are here working in NGTRANS.
> >
> > But let me try to explain a problem.
> >
> > The customer and vendor (or vendors in the case of
> > partnerships) develop
> > an IPv6 deployment strategy.  Part of that (and only part 
> of that) is
> > Transition and how to use mechanisms developed in the IETF 
> and out of
> > the IETF in some cases (custom vendor tools for transition etc...).
> > Right now it would be illegal for either to share this with
> > the IETF in
> > the form it is as a deployment strategy.   So what we would 
> have to do
> > is publish it as a white paper which is what I suggested for
> > example for
> > DSTM.
> >
> > Another point.  The solutions developed are not generic and
> > specific to
> > each customers needs and deployment rate and financial 
> commitment.  We
> > don't work on things like that in the IETF we try to solve
> > all potential
> > problems that may not be needed by different cases.  Working with
> > customers each one is precious and gets to solve problems 
> differently.
> > Clearly when a bunch of them do it the same way thats
> > wonderful for any
> > vendor, and will be the case usually.
> >
> > What the IETF role is here is to building the standard 
> mechanisms that
> > will work with IPv6.  Defining how the market deploys with 
> them is out
> > of scope for the IETF IMO and besides the processes here 
> simply cannot
> > now keep up with the speed, rate, or acceleration of 
> adoption the IETF
> > is too slow now for deployment.  The market cannot wait any longer.
> >
> > But I do believe getting us folks that are building real 
> products and
> > working with real customers and doing product transition
> > tools is a good
> > idea.  But to often thats not the people selected for 
> design teams in
> > the IETF and thats to bad and another reason its too slow.
> >
> > regards,
> > /jim
> >
> 
>