On Mon, 2 Jun 2003, Bob Hinden wrote: > 4) The scope of these address is smaller from global unicast address but > larger than site-local. They are scoped in a different manner than > link-local, site-local, and global in that the scope of an individual /48 > prefix is created by a set of adhoc routing agreements and is not limited > by the non-uniqueness of the prefix like site-local. > > From a host's perspective this difference in scope shows up by different > reachability than global unicast and could be handled by default that > way. It is probably better for nodes and applications to treat them > differently from global unicast addresses.
I hope you're not implying that apps should know the difference between the two? That would be broken. The host probably could, though. > A starting point might be to > give them preference over global unicast, but fall back to global unicast > if a particular destination is found to be unreachable. Much of this > behavior can be controlled by how they are allocated to nodes and put into > the DNS. I think a better method would be to give preference to global unicast, ie., reverse the scoping rule to prefer the greatest scope. The communication would still work if a node had only local unicast addresses though, or if global addresses were blocked in a firewall etc. This is particularly important if local addresses like these are ever getting into DNS or the like. > However it is useful if a host can have both types of addresses > and use them appropriately. This creates a host with multiple global > addresses, a form of multihoming. I fail to see how a local and a global address could be considered a form of multihoming. [snip] > I would proposed that the IPv6 w.g. define the address format and default > node and application behavior, and leave the more ambitious address > selection solutions to multi6 or other working groups as appropriate. Yep. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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] --------------------------------------------------------------------
