Brian E Carpenter wrote: > > This doesn't resolve the problem of ambiguous subnet prefixes > when routing domains merge. So it doesn't go far enough IMHO.
That's because dealing with uniqueness and merging is a deployment issue, not an architectural issue. The proposal specifies what the routing system and applications need to know about these restricted deployment addresses for correct general operation. Achieving the uniqueness criteria is actually rather easy. HOW to do it is up to the person deploying the site. Workable solutions include generating unique /64 subnet IDs ( draft-hinden-ipv6-global-site-local-00.txt, draft-white-auto-subnet-00.txt ), generating a /48 based on the MAC of the root router, or allocating a unique /48 from a registry. Of course, if you're in the mood to shoot yourself in the foot, you could number your site from fec0::/48. I think we need to divide the problem space into two parts: - Cleaning up site-local and scopes: - Enforcing the global unrouteability of the FEC0::/10 prefix. - Otherwise removing scope processing from address architecture. - Document recommended ways of allocating FEC0::/10 addresses to 'near-enough' guarantee uniqueness. The first change makes FEC0:://10 the same as any other filtered address, with one little exception - everybody agrees that this is to be filtered. A well-known non-globally-routeable prefix allows applications to make decisions based on scope: "I'd rather use / not use filtered addresses". As a default, I'd recommend the rule "If I have an address in FEC0:://10 and the destination offers FEC0:://10, try that first." Assuming longest-match destination address selection, this will work for both the situation where FEC0:://10 exists and doesn't. Of course, some applications will override this and say "no, don't give me an FEC0:://10". The convenient property is that applications can care if they want to, and otherwise can remain ignorant. The second point deals with the ambiguity problem. -- 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] --------------------------------------------------------------------
