On Sunday, November 24, 2002, at 08:46 PM, Bound, Jim wrote:
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.-----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.
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.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.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.
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.
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.ISPs are deploying IPv6 you simply don't know what your talking about.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.
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.
<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>What your asking is the kind of discussions one has when buildingx) 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.
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.
Perhaps it is too early to be folding the ng-trans working group efforts in to v6-ops?I simply disagree and strongly do not support this and ask the chairs toI think this is something we need to properly discuss now and possibly at the next meeting.
kill 90% of what you suggest as out of scope for this mail list and the
IETF.