Ralph Droms wrote: > Tony - (assuming "they" == IPv6LL) can you explain why IPv6LL > will work while "they don't work in IPv4"? My experience > with IPv4LL has been uniformly bad; I've never intentionally > used an IPv4LL address and the automatic assignment of an > IPv4LL address has on several (many?) occasions silently > interfered with my ability to assign a non-LL address and use > greater internet connectivity. I will admit ignorance and am > happy to hear success stories about IPv4LL.
Not having been there when your interference issues occurred, I can only guess that they were related to the default IPv4 perspective that an interface only has one dynamic address at a time. In that environment it takes explicit effort (user initiated or stack timer) to change the available address. There is no such restriction in an IPv6 environment, so the existence of an IPv6 LL can't interfere with global connectivity. In fact it is much more likely that intermittent global access (such as changing radio attachment points) would interfere with the stablility of an app that is running locally. > > I don't know that some folks "don't want to make the scenario > work". I don't understand the advantage to IPv6LL from the > scenario you described. We can assign IPv4LL addresses today > in a one-link, no router ad-hoc network. But we have to > enter the addresses manually and those addresses get in the > way when full Internet connectivity becomes available. > What's different with IPv6LL? There is no 'get in the way' limitation. Simultaneous support for multiple dynamically acquired addresses is a major advantage of IPv6, as it enables scenarios that are simply not possible in the IPv4 model of a single address at a time. What this bumps into here is the fallacious assumption by some app developers that the routing space is globally flat, so if by chance there is more than one address, every available address can be treated equally. This is not a real problem in the market when only their apps fail, but it is a real problem when they try to prevent other app developers from taking advantage of the opportunities through limitations in the standards. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
