[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
> >
> >
>
>