Re: Some IPv6LL operational experience

[Joshua Graessley <jgraessley@xxxxxxxxx>]

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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------