[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPv6 transition architecture discussion



On Sunday, November 24, 2002, at 08:46 PM, Bound, Jim wrote:

-----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.
The IETF and vendors are not two separate entities. Vendors send people to participate in the IETF to help establish standards so we can all cooperate and release products that will work together. The IETF certainly can't tell any vendor what to do or what not to do in a product. That doesn't mean that vendors don't look to the IETF for suggestions. Suggestions on how to deploy IPv6 from the operating system perspective seem to be lacking. 6to4 looks like a good solution, but it doesn't work behind NAT. In addition, people in this working group have strongly advised against any wide deployment of 6to4 hosts.

Apple would like to ship a version of our operating system that does everything it can to get an IPv6 address. This would give our developers an opportunity to make use of IPv6. This strategy only works if we can figure out how to get IPv6 addresses to the majority of our customers. Solutions such as 6to4 and Teredo would allow us to achieve this goal. The vocal people in this working group say that 6to4 and Teredo are bad solutions. They rightly point out that the few 6to4 relays will probably melt down or people will stop running them. In addition, there is no such thing as a Teredo relay deployed today. Teredo and 6to4 work well when there are many relays, which is not the case today.

We look to the IETF for a solution because we can't solve this problem alone. I get the impression from this working group that the working group is of the opinion that the transition mechanism will not work and we should just sit on our thumbs until the ISPs provide us IPv6 connectivity.

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.
We are concerned, I'm not sure I'd say afraid. We have shipped Mac OS X 10.2, with support for IPv6. It isn't really well integrated yet, but it's there. It will assign link-local addresses, listen for routing advertisements, and assign addresses. This is fine because almost no one has IPv6 connectivity. We were considering turning on 6to4 by default when there are no routing advertisements. This working group has dissuaded us from doing so. If we did turn on 6to4, we would want to add some extra smarts to getaddrinfo to list IPv4 addresses first when 6to4 is in use to reduce the load on the relays. If we didn't modify getaddrinfos behavior, websites that used to work, may not work if the relays are down, or it may be very inefficient to communicate with such hosts since 6to4 could send the tunneled packets to a relay just about anywhere.

Based on feedback in this working group and some feedback at the recent IETF in Atlanta, we will probably not be working to get IPv6 connectivity on all Mac OS X hosts.

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.
Why are these optional kits to install IPv6? If vendors really felt comfortable about IPv6, they would ship support built in to the product and it would be enabled by default. The fact is, very few people have IPv6 connectivity. IPv6 connectivity is the exception, not the rule.

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.
Is there any evidence to suggest that IPv6 will some day make the move from testbed to wide deployment? The IETF has a huge amount to do with how quickly IPv6 moves from testbed to deployment. The IETF has drafts defining transition strategies. These transition strategies are important. Without them, IPv6 will never move on from test bed deployment. If people continue to ignore the transition problem and insult those who bring it up, perhaps IPv6 will go the way of OSI.

<SNIP>

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.
<sarcasm>Yes, scenarios are more important since people participating in the IETF will be building scenarios instead of products. After all, it doesn't matter that a something be implemented in a product so long as there's a scenario in which the protocol could be used.</sarcasm>

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.
Perhaps it is too early to be folding the ng-trans working group efforts in to v6-ops?

-josh