[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPv6 transition architecture discussion
- To: "Pekka Savola" <pekkas@netcore.fi>, <v6ops@ops.ietf.org>
- Subject: RE: IPv6 transition architecture discussion
- From: "Bound, Jim" <Jim.Bound@hp.com>
- Date: Sun, 24 Nov 2002 23:46:45 -0500
- Delivery-date: Sun, 24 Nov 2002 20:47:55 -0800
- Envelope-to: v6ops-data@psg.com
- Sender: owner-v6ops@ops.ietf.org
- Thread-index: AcKTr7trD6+oVaGgTA6JFnBlx5EUPAAjA24A
- Thread-topic: IPv6 transition architecture discussion
Pekka,
Inline responses.
/jim
[A people who would give up their freedom out of fear did not deserve it
in the first place. Ben Franklin]
> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: Sunday, November 24, 2002 6:45 AM
> To: v6ops@ops.ietf.org
> Subject: IPv6 transition architecture discussion
>
>
> Hello,
>
> Triggered by extended discussion at the IETF meeting on
> NAT-PT, I think we should try to discuss more about the
> _core_ matters of the transition, for
> example:
>
> 1) how to start enabling v6-capable software in the operating
> systems, and having operating systems v6-enabled, in such a
> fashion that it does not hinder the current usability of v4?
None of the IETFs business you can't tell vendors what and what not to
do in their products.
This is not specifying standards. You cannot tell vendors what to do
with their operating systems either.
>
> A starter for discussion: v6 connectivity is very poor (see
> draft-savola-v6ops-6bone-mess-01 for more). Vendors are
> rightfully afraid (I sure don't want them doing it) to enable
> v6 by default, as connections could easily switch to using
> (badly working) v6.
What vendor told you they are afraid? If you cannot state who that is
then please retract this statement.
All vendors shipping products have web pages and kits to install IPv6.
You might go buy them and test them for yourself. Also all our
interoperability labs are doing this now UNH, ETSI, TAHI, and now China.
This is none of the IETFs businss or v6ops unless that works points to a
protocol or operations problem on the network. If you know of such
cases I am sure the chairs would love to hear them.
>
> Do we need to do something about this or just wait N years to
> operators to do something. Note: this is a chicken-and-egg
> problem, ISP's don't deploy v6 before it's requested (and
> paid for, in some way or another), and the connectivity
> remains poor because v6 isn't really production yet.
ISPs are deploying IPv6 you simply don't know what your talking about.
Right now it is in test bed mode and that will last awhile and it has
nothing to do with anything we can do in the IETF to help at this point.
The one thing we could do is stop wasting mail messages with mail like
this and get some decisions made about SLs, Scenarios, et al. That is
the IETF's job not this diatribe you spew out here all to often, that is
totally irrelevant to the building of standards.
If you want to be part of the deployment mission and effort there are
places to do that and I would be glad to give you pointers offline as
this is not an IETF matter.
>
> 2) are there some cases in the transition which we could
> ignore, to make
> it simpler? In particular, this includes v6-only and v4-only
> interoperation.
This is a valid discussion I agree.
>
> A starter for discussion: v4-only <-> v6-only in a general
> case is complex. IMO we perhaps shouldn't try to solve the
> general problem, as it draws the attention away from more
> important issues. Is it ok to require v6-only nodes will
> only be deployed when they don't need connectivity to v4-only
> nodes (except by proxies -- e.g. TCP/UDP relay or ALG level
> thing is IMO just fine)?
You cannot require anything Pekka. You can only build a draft and
propose a standard. The IETF cannot mandate anything at all to the
market or to those who have built and continuing to build IPv6 features
in products.
>
> For example, in home networking scenario, enabling v6-only
> printers etc. should be trivial _if we require_ TCP/UDP proxy
> e.g. in one dual-stack computer in the network. On the other
> hand, I would imagine it could be ok to just say, if you want
> to use that printer, upgrade your OS, period.
You have to be kidding right? Have you ever shipped a product that a
customer is using? If so you should know that no one in this standards
body or any standards body or even any deployment forum (which has far
more influence and power than the IETF to affect deployment) will EVER
tell a vendors customer what to do with their OS. This is silliness
and borders on outright confusion on your role in the IETF and the role
the IETF will support you in. This will not happen here.
>
> Is it required to be able to communicate between v6-only node
> in your network to v4-only nodes in the general internet?
> The need for this can be mitigated by dual-stack ALG's, like
> web proxies. My suggestion would be that don't deploy v6-only
> nodes, requiring v4 internet access, then.
> Such could still be deployed in internal networks -- most
> v6-only gadgets today don't really require to be accessible
> or to access v4 internet anyway -- and even v4 in the local
> network is also a bit arguable.
Then right a spec for transition. I would hope the chairs tell you to
wait for the scenarios as everyone else is told. Why don't you work on
the scenarios as a working group member.
>
> x) there are probably many other "really important" issues we
> need to have
> some idea of. It's not all that useful to meddle with
> scenario details
> until we have some idea how the big picture should work itself out.
What your asking is the kind of discussions one has when building
products. But I don't agree and the chairs have made it pretty clear we
must work on scenarios. I have come to support that and it makes some
logical sense. The scenarios are about use cases and people deploying
now and that is the big picture.
>
> I think this is something we need to properly discuss now and
> possibly at
> the next meeting.
I simply disagree and strongly do not support this and ask the chairs to
kill 90% of what you suggest as out of scope for this mail list and the
IETF.
/jim
>
> --
> Pekka Savola "Tell me of difficulties surmounted,
> Netcore Oy not those you stumble over and fall"
> Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
>
>
>