Margaret's draft highlights three failures of site local addressing... (1) The addresses are unreachable outside of their original context.
(2) The addresses may overlap other private address spaces, creating ambiguity. However, it seems to me that #1 is not specific to site local addresses. Instead, it applies to ANY address that is not practically globally routable. What do I mean by "practically globally routable?" That not only is it allowed to be globally routeable, but that there's not a filter somewhere on the way to the default free zone that will kill it. This is an address's 'practical scope' - the area of the internet that it could reasonably apply to. Once we start handing out addresses whose practical scope is less than global, we either need proxies (eg NAT) or multi-homing. Few to none of the limited scope or multi-homing problems are specific to site locals. In fact, site locals have a slight advantage in a multi-homing situation in that they promise that they do not have global scope, and thus may be singled out by address selection algorithms. To my eye, ambiguity problems manifest themselves in three main situations. - Addresses used in the wrong context may arrive at an unintended network or machine. - Reverse name lookups don't work globally scoped ambiguous addresses. - Site border nodes. The IPv6 machine ID helps reduce the likelihood of a misdirected connection actually arriving on an interface (rather than just timing out). Beyond that, it's up to an application to decide whether it wants to consider the failure case where TCP/IP connection is successful but then the machine fails to authenticate itself. Note that this same problem could occur for a variety of other reasons that ambiguous addresses (deliberate spoofing, bad DNS entries, other network configuration problems). Proper reverse name lookups rely on sites using site locals correctly configuring their internal DNS. Forward lookup issues can be trivially solved by putting internal addresses in a localised namespace. Site border nodes are always going to be problematic. Logical partitioning, as in Bob Hinden's draft or Hiroki Ishibashi's implementation, and refusing to allow sites to 'overlap' seems to be an effective way of avoiding these problems. I feel the correct conclusion from Margaret's draft is that there are a number of issues that people using addresses with "site" based practical scope should be aware of. However, that people WILL use firewalls and address filters as one part of security management seems inevitable. Thus it's a useful summary of "these things may break, understand the issues". But despite the title, site-local addresses are only one example of a broader category of addresses that these problems apply to. Site locals as currently specified do add additional issues for architecture (DNS and SBRs) if not correctly managed. However, at the client and application level, most site-local alternatives suggested here (everything except fully provider independent routed addresses, without address-based filtering) fall foul of the same problems as site local addresses themselves. -- 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] --------------------------------------------------------------------
