[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ocean: do not boil
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.
> > >
> > >
> >
> >
>
>