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 [EMAIL PROTECTED] --------------------------------------------------------------------
