> I've always liked draft-ietf-ipngwg-site-prefixes-05 (the basic idea is > that site-locals are put in the DNS and it specifies a way for a node to > filter out the site-locals when they shouldn't be used). It can be > extended to the situation of an application on one node sending > addresses to an application on another node. The simple idea is to just > send all your global & site-local addresses, then the receiving node > does the same filtering specified by draft-ietf-ipngwg-site-prefixes-05, > and uses draft-ietf-ipv6-default-addr-select-09 to figure out what order > to try the addresses.
I have a lot of problems with that document. - it has a wide impact, because it potentially imposes requirements on all IPv6 apps (not just hosts) and/or encourages hosts to filter DNS results that might be meaningful to apps - one result of this is that each component in a distributed app effectively has a different view of DNS. - like a lot of other proposals, it assumes that DNS TTL is somehow related to the binding between an IP address and the host, or the IP address and the application component. It's not. DNS TTL is related to the binding of a name to a resource record. It says nothing about the lifetime of the binding between an address and a host or application component. - like a lot of other proposals, it assumes that apps get their addresses exclusively from DNS, even if indirectly. this is not the case. - it assumes that all AAAA records returned in an RRset refer to the same host. they don't. they're all bound to the same DNS name, which isn't the same thing. - it assumes that an app should prefer site-local addresses over global addresses. but this breaks for apps that (quite reasonably) use source addresses in referrals to other hosts. - address selection is already broken. by creating yet another address for each host/interface that uses them, site locals make the problem even worse. - it doesn't solve the problem with two-faced DNS - it just moves the problem and makes failures more difficult to diagnose. in both cases the party doing the filtering is not in a position to know whether the addresses will be usable by the party that eventually needs to use them. - it artifically fragments the problem space for apps that use long-running connections into "site-local" apps vs "non-site-local" apps. we really need something that supports reasonably long-running connections for both cases. at the same time we should recognize that no address has ever been permanently bound to either a host or an application. we should just establish reasonable expectations for the lifetime of those bindings. apps that need to keep connections open for longer than that would need to define and implement mechanisms for recovery from address changes. that way we could retain location-independence for apps - i.e. they wouldn't need to care whether they were entirely site-local or not. this is just from a brief scan. we're trying to solve a number of problems by creating a separate name for each distinct situation. I don't think it will work - it's just too hard to keep track of which name to use in which case. this proposal makes a good try but actually just ends up illustrating how difficult the problem really is. Keith -------------------------------------------------------------------- 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] --------------------------------------------------------------------
