RE: ocean: do not boil

["Tony Hain" <alh-ietf@tndh.net>]

This was the primary reason I stressed that ngtrans needed to focus on
the dual stack approach first. Even though that is a much simpler
approach, there have been a variety of situations exposed over time to
show that it simply not possible for everyone to take the easy road. The
most obvious case at the moment is the substantial deployment of
IPv4-only NAT CPE that for financial reasons *will not be upgraded*
until the ISP is ready to provide native IPv6 support (in North America
that is looking like ~2006, or in the case of docsis devices much
later). For those end sites that want to move sooner, and don't have a
reasonable option for an alternate ISP, just saying we only support dual
stack is telling them they can't use IPv6 capable apps & appliances for
at least 5 years. This will in turn put a damper on the app development
community, because to get their app deployed in that timeframe they will
have to figure out how to do nat traversal. Once they have gone down
that path, where do they find additional incentive to put in IPv6
support? 

Yes the alternative tools add complexity, but in the grand scheme of
things, is that complexity less than the mess we would end up with if
everyone came up with their own nat traversal schemes? I think it is,
and that we need more than dual stack.

Also, as a meta point, declaring an approach for transition out of scope
before the scenario documents are done is just a bit short sighted.
Indeed there are a few ISPs deploying native service today, and these
will simplify the global transition. To extrapolate from there that dual
stack is all we need is really doing a disservice to the entire effort
to make the transition as smooth as possible for the end site. Just as
there is no single network design that works for all sites, there is no
single transition approach that will work universally. Before deciding
what problem doesn't need to be solved, why don't we get working group
consensus on the problems that the design teams are trying to describe
to see what they believe (due to first-hand experience or customer
feedback) are the real problems existing networks will face as they try
to move.

Tony



> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Randy Bush
> Sent: Saturday, September 21, 2002 6:34 AM
> To: Bob Fink; Jun-ichiro itojun Hagino; Margaret Wasserman
> Cc: v6ops@ops.ietf.org
> Subject: ocean: do not boil
> 
> 
> first, thanks for doing a great job in sunnyvale.  i think it 
> was worth the effort and pains.  of course, time will tell, 
> as we see how the scenarios flesh out.
> 
> but, i have been rather worried by one vector.  
> 
> i don't think we should try to solve the problem of an 
> arbitrary user/service on a pure v6 site/host trying to 
> communicate with a user/service on a pure v4 site/host or vice versa.
> 
> dns is critical infrastructure, and we need to understand how 
> everyone will see the same namespace whether they are on v4 
> or v6 transport [0].  and we have some clues on how to do 
> that, point mono-stack resolvers at dual-stack caching servers.
> 
> but services such as http, smtp, blah, blah, blah just can't 
> be completely transparent, and we *vastly* increase the size 
> of the problem if we try to make them so.
> 
> if i want my web site seen by both v4 and v6 users, then i 
> can connect it to v4 and v6 space and run dual stack.  in 
> fact, i do so today.  as v6 deploys, folk every useful site 
> will do so.
> 
> if i want to send mail to v4 users and i live in a pure v6 
> world, then i can make an arrangement with a dual-stack relay 
> to provide forwarding service to me.  and to receive mail, i 
> can just point an MX naming an A record to a dual-stack 
> forwarding service.
> 
> if i want to play a net.game which is in v6-land, then i need 
> to be at least partially in v6-land.  no magic.  tough patooties.
> 
> trying to make pure v4 sites/hosts communicate for arbitrary 
> services with pure v6 sites/hosts and vice verse is a nice 
> way to make the problem vastly more complicated, the 
> solutions vastly more complex, and the net much less 
> reliable.  let's not go there.
> 
> randy
> 
> ---
> 
> [0] - if you're in private v6 space, i.e. site local or other
>       1918-envy games, use multiple views just as a v4 1918 site
>       does today.
> 
>