Re: Some IPv6LL operational experience

[Bob Hinden <hinden@xxxxxxxxxxxxxx>]

Joshua,

At 10:24 PM 8/20/2003, Joshua Graessley wrote:

>I realize that as an employee of a company that sells a product and tries 
>to implement standards the IETF blesses to solve problems, my voice 
>doesn't really count, but I wanted to toss in my two cents.

I hope you were being sarcastic, but I think you voice should count a 
lot.  The goal of IETF standardization is interoperability and getting 
operational experience is very important.

>We have been using IPv6LL addresses with some success. The next release of 
>Mac OS X implements something similar to LLMNR that we call mDNS with 
>support for IPv6. For the time being, the only IPv6 addresses we, or most 
>of our customers have, are IPv6LL addresses. This combination of mDNS and 
>IPv6LL addresses works very well. IPv6LL addresses are important to us 
>because a multi-homed host may not have an IP address on every interface. 
>IPv4LL addresses don't work on more than one interface because they lack a 
>scope id. The scope id in IPv6LL addresses makes them much more compelling.
>
>IPv6LL addresses let us enable networking in situations that wouldn't 
>otherwise work. For example, we've implemented IP and IPv6 over Firewire. 
>In most cases, it is unlikely that an IPv4 address will be assigned to the 
>IP over Firewire link. This is usually used in the scenario where two 
>computers are hooked directly together. We can't assign an IPv4LL address 
>to the Firewire interface because it causes a number of problem on a 
>multi-homed host. The IPv6LL address is configured automatically and is 
>always there. Very few people have the skill required to successfully type 
>an IPv6 address, which is why the mDNS component is so important. In 
>addition to allowing users the ability to type a name instead of an 
>address, the question of scope id goes away. The name is resolved using 
>mDNS. The scope id is derived from the interface the response came back 
>from. The application is none the wiser because it gets a full 
>sockaddr_in6 from the call to resolve the name.
>
>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. 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.
>
>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. 
>Sure, connectivity off of the local link for those of us in the US is only 
>for a few elite, but IPv6 on the local link can solve real world problems 
>today and work for everyone.

Thanks for describing this.  The local discovery and communication problem 
is important.  I also think this is an important approach because it uses 
IPv6 in a local environment in a way that adds value without the need for 
it to be available globally.  It adds value without the need for everyone 
else to do it first.

Bob


--------------------------------------------------------------------
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
--------------------------------------------------------------------