[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some IPv6LL operational experience
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
> made is by people who think that IPv6 apps don't need to do this, and
> 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
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
> you made similar arguments for v4 link-local addresses, and you were
> 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
> 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
>> exposed to IPv6 and to encourage developers to start supporting IPv6.
> great. let's encourage people to use IPv6 in a dysfunctional way, one
> only works for a limited subset of apps, so that they'll never be able
> 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
> I'm all for enabling ad hoc networks, and I'm all for enabling
> applications. But trying to overload IP to do these is doing real
> 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
> access. An ad hoc network is a different beast than the Internet and
> can't expect apps in general to transparently work on both kinds of
> 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.
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@example.com