Hi Margaret, I agree it is useful to consider the problem we are trying to solve, however, my understanding has been that we have been trying to solve the same problem that traditional site-locals were created to solve.
I've generally understood the goals of traditional site-locals were : 1) internal / local / site / friend / entity (take your pick) address space that was independent of the global address space assigned by the (one or more) upstream global connectivity provider(s). 2) no external registration required for this "site local" address space. 3) communications sessions (eg TCP sessions) using these "site local" addresses where impervious to global renumbering events. Traditional site-local addressing (fec0::/48 (:: /10-/48) ) met those goals. However, there were some limitations : 1) the "site" name and explanation in the addressing RFC predominantly implies a geographical scope or size for this address space. While people on the ML have said that the word "site" in "site-local" doesn't really have geographical connotations, it is hard to forget the root English definition of the word. In practical terms, I might build a network which considers the whole of Australia as a site when using site-local addressing, which sounds a bit odd. 2) when two entities using site-local addressing attempt to interconnect or merge their networks there is a good chance of subnet addressing collision, necessitating some amount of renumbering of parts of one or the other entities' networks 3) because site-local addressing is duplicated, there is referral ambiguity once multiple sites are connected together via a single router. There were also DNS issues (Keith is the expert on this problem :-) ). 4) any others I've probably forgotten. 5) oops, forgot about people wanting to use site-local to site-local IPv6 NAT when merging / interconnecting networks, rather than renumbering site-local prefixes. Pekka Savola suggested creating near globally unique site local addressing, by filling the /10 through /48 bits of fec0::/48 with a pseudo random or near unique number, derived from a hash of certain values such as MAC addresses or time of day or other reasonable values. This doesn't seem to be a new idea, Paul Francis proposed the same thing in the following ietf draft (worth a read, covers a lot of what has been coming up in emails recently about GUPIs / (near) unique site local addresses) : http://www.join.uni-muenster.de/drafts/draft-francis-ipngwg-unique-site-local-00.txt I've always assumed that the original goals haven't changed, just that near globally unique site local addressing was a solution which addressed the traditional site-local limitations. My discussions and thoughts on things like naming / use etc have really only been in the context of having a better "site-local" solution. Are we happy with the existing problem definition, that (near) globally unique site local addressing is a better solution for than traditional site-local addressing, or have the recent discussions on near globally unique site local addressing / GUPIs caused us to inadvertently loose focus on our problem definition, making it necessary for us to restate and redefine it ? Regards, Mark. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
