[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some IPv6LL operational experience


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.


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