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

RE: Some IPv6LL operational experience



Josh,

Your describing a scenario for operations I believe is similar to ND,
Addrconf, Router Communications, DHCPv6, et al and using LLs for
Firewire or IEEE 1394 or USB are clear correct use of IPv6.  No
disagreement from me technically and the company I work for builds lots
of devices like this too.  It is a clear advantage of IPv6.  I never
said it was not.

But those who take this same argument you have provided so well and then
extrapolate that its ok to use SIP, SQUID, Streaming Media, Oracle et al
in the Enterprise for Ipv6 with LLs is a stretch and I would argue
missing the point.  

So what you state I agree with.  But as Keith has stated they are not
useful as app use adress.

Now I am hearing this "ad-hoc" generalization and no technical depth or
explanation.  That I do not buy and consider it sophist rhetoric in the
debate thus far and await some real technical input.

thanks
/jim


> -----Original Message-----
> From: Joshua Graessley [mailto:jgraessley@apple.com] 
> Sent: Thursday, August 21, 2003 1:24 AM
> To: ipng@sunroof.eng.sun.com
> Subject: Some IPv6LL operational experience
> 
> 
> 
> 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.
> 
> 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.
> 
> -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
> --------------------------------------------------------------------
> 

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