"Applications should not need to know scope of addresses" I think this requirement is misleading.
To invent some terminology, any address is both 'architecturally scoped' and 'functionally scoped'. * Architectural scoping: Over what scope is the address valid, in design? * Functional scoping: Over what scope is the address valid, in use? As Tony points out, an address may be globally unique, but not routeable on the global internet. This may be unwanted (broken links, bad routes) or wanted (explicit filters). Now, either we mandate that the model presented to applications is that the node has ONLY one address, or applications need to deal with the fact that both they and their target may have more than one address, and that these addresses may not be equally useful. This applies both to single and multiple interface multihoming. And exists already, in both IPv4 and IPv6. Applications need to deal with functional address scope, at least to the extent of retrying other source-destination combinations if the first fails. How does architectural scoping fit in? >From one perspective, architectural scoping is just a special case of functional scoping. Not only is this address functionally scoped, but we architecturally intend this to happen. Applications can ignore this information if they wish - functional scoping recovery will handle it. Or they can use it to bias their address selection choices. The unique issue raised by architectural scoping is ambiguity. However, most people who want site local addresses see this as a virtue. And again, there's no gain to applications by removing architecturally scoped addresses - functional scoping may mean that although A <-> B and B <-> C, A <-!-> C with the same addresses. There are a few situations where site-local addresses are very useful. If used outside those situations, they do not impose significant additional pain on applications. Applications already need to consider multiple addresses that may not be completely interchangeable. -- Andrew White [EMAIL PROTECTED] -------------------------------------------------------------------- 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] --------------------------------------------------------------------
