On Thursday, August 21, 2003, at 6:56 , Keith Moore wrote:
Applications that perform referrals may fail, but I'm not aware of any of these that are currently shipping and support IPv6. IPv6 is a new beast, we don't have to be as concerned about applications making stupid assumptions.
you have it exactly opposite. one of the major drivers for IPv6 will
be apps that cannot run over IPv4+NAT, and an important class of these
will be apps that do referrals. and the stupid assumptions that are being
made is by people who think that IPv6 apps don't need to do this, and by
people who think that currently shipping IPv6 apps are representative
of future usage of IPv6.
That is your opinion, and you're welcome to have an opinion. I do wish you wouldn't bash it over the head of anyone with a differing opinion and use it to derail IETF working groups.
Is it invalid to base assumptions on what can be observed? IPv6 has been deployed for a while now. There are applications that support IPv6. This applications work well with IPv6. This applications have to deal with IPv6LL addresses because IPv6LLs have existed for as long as most stable implementations have existed. I'm not sure why you are so concerned about the negative impact of IPv6LL addresses when almost every shipping implementation of IPv6 has implemented IPv6LLs and no one has had serious problems with them.
In my opinion, speculating on the wonderful ways that IPv6 could be used (but isn't presently) and making assumptions that the ways in which IPv6 might possibly be used and outlawing any other uses is a foolish thing.
My posting to this list was not intended to elicit so many responses and drive the working group in to another mindless yelling match. I wanted to share my experience. We have found a real world use for IPv6LLs. It works, it doesn't appear to cause any harm. With our use of mDNS, it is nearly transparent to most applications.
If you try to remove IPv6LL you will get push back from the industry. If you try to deprecate APIs, such as removing the scope id, when there is no clear reason why, you will get push back. This working group may do these things to satisfy the loud and obnoxious people on the list. It will drive the IETF further in to irrelevancy as vendors stop paying attention to and participating in the IETF. These are not threats, these are observations.
If we explain that IPv6 link local addresses work
this way and here's a list of limitations, that's good enough. The
advantages of IPv6 link-local addresses far outweigh the disadvantages.
you made similar arguments for v4 link-local addresses, and you were wrong
there also.
Again, that is your opinion. The major difference between IPv4LL and IPv6LL is that IPv6LL is a part of IPv6 from the start. There are no applications that are developed for IPv6 that don't experience IPv6LL addresses. It doesn't matter how the developer tests the application, if there are any IPv6 addresses, there will be an IPv6LL addresses. If a developer runs in to problems, the developer will work around them or suffer public humiliation and financial ruin when they release a sub-par product. Pointing the finger and saying "I can't make it work because there's this extra address there that's easy to identify as link-local and I just can't figure out how to ignore it" isn't going to cut it.
v6 link-locals make good sense as a mechanism to provide uniform (independent of link technology), inherently link-local services, like ND/RA. they are usable by a limited class of applications, but not applications in general.
Does it not make sense to use them in that "limited class of applications"? They sure work well for ssh, even when the rest of the network is falling apart. As long as there are link-locals and the local link is working, ssh can work. http will work as well, along with many network file systems and games. To suggest that the use of IPv6LL for anything other than ND/RA is unholy is just ridiculous.
IPv6LL is a major selling point. IPv6LL is a sneaky way to get everyone
exposed to IPv6 and to encourage developers to start supporting IPv6.
great. let's encourage people to use IPv6 in a dysfunctional way, one that
only works for a limited subset of apps, so that they'll never be able to
realize the real advantages of IPv6.
How is it dysfunctional? It solves real problems and it works. Stop driving this working group in to the weeds Keith.
Quite often, you compare the harm this will cause to the harm that NAT causes. I don't think you're right, but if you are, I suggest you start taking a different approach. NAT is a huge pain. The biggest pain stems from the fact that the IETF shunned the idea instead of embracing it. Instead of developing a standard so that all NATs behave the same, the IETF ignored NATs. NATs are very popular because they solve a problem. If the IETF had blessed NAT we may have consistent behavior in NATs and we may have a standard method of poking holes through NATs to make peer to peer applications, such as video chat, work.
I've said it before and I'll say it again. IPv6LLs are useful. We will use them. The industry will use them. There is nothing you can do to prevent that, just as there is nothing you can do to stop the spread of NATs. Embrace it, and you may just have an opportunity steer it in a direction that will be less destructive. Condone it and you will lose control.
I'm all for enabling ad hoc networks, and I'm all for enabling link-specific
applications. But trying to overload IP to do these is doing real harm.
There's nothing wrong with using the packet format on an ad hoc network, the
problem is it's the expectation that apps have that IP equates to Internet
access. An ad hoc network is a different beast than the Internet and you
can't expect apps in general to transparently work on both kinds of network.
At the very least you need an API to allow apps to declare whether they work
on one kind or both. And the default needs to be the Internet.
Sure, connectivity off of the local link for those of us in the US is only for a few elite,
until native v6 service is available, anybody can still run 6to4.
No they can't. A large number of people use NAT. You can't use 6to4 if you're stuck behind NAT. Oh, that's right, NAT doesn't fit in to your model of the internet.
-josh
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
