RE: ocean: do not boil

["Bound, Jim" <Jim.Bound@hp.com>]

I agree with Tony too.
/jim

> -----Original Message-----
> From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se]
> Sent: Monday, September 23, 2002 5:52 PM
> To: 'alh-ietf@tndh.net'; 'Randy Bush'; 'Bob Fink'; 'Jun-ichiro itojun
> Hagino'; 'Margaret Wasserman'
> Cc: v6ops@ops.ietf.org
> Subject: RE: ocean: do not boil
> 
> 
> I can't agree more. 
> 
> Hesham
> 
>   > -----Original Message-----
>   > From: Tony Hain [mailto:alh-ietf@tndh.net]
>   > Sent: Monday, September 23, 2002 11:43 PM
>   > To: 'Randy Bush'; 'Bob Fink'; 'Jun-ichiro itojun Hagino'; 
> 'Margaret
>   > Wasserman'
>   > Cc: v6ops@ops.ietf.org
>   > Subject: RE: ocean: do not boil
>   > 
>   > 
>   > 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.
>   > > 
>   > > 
>   > 
>   > 
> 
>