> 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.
That long expired draft explicitly stated the assumption that all IPv6 nodes had to be modified to filter out site-local addresses from RRsets that contain both globals and site-locals. That was not an outlandish idea when the draft was first written, but today there is enough implementations of IPv6 with deployment starting to happen that that assumption would be a non-starter. One could of course suggest a mechanism where the DNS clients explicitly need to request something different to let the server know that they are capable of filtering site-locals that are in a different site. But personally I feel that adding such things to the DNS (whether it be a new address RRtype or something else) adds far to much complexity and has performance implications, that it makes no sense given the relatively limited benefit of using site-local addresses when global addresses are available. So the approach of putting site-local addresses in the global DNS doesn't seem worth-while. My 2 cents, Erik -------------------------------------------------------------------- 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] --------------------------------------------------------------------
