On Thu, 21 Nov 2002, Christian Huitema wrote: > > I'm assuming that for the intents and purposes of replacing > > "local" site-locals, "nearly unique" site-locals would be enough. > > Not quite.
Depends on what you want. (Perhaps we should try to formulate these better first, but it's more interesting to just pop up some solutions :-). I believe these will allow for all the cases site-locals were used in "limited" cases in the meeting, probably even those in "moderate" on the side. [...] > unreachable does not mean that they could just as well be ambiguous, > because these ambiguous addresses end up leaking in various places: DNS > records, source of ICMP packets, next hop in BGP messages, "received" > headers in mail or "via" headers in SIP, etc. In short, buggy addresses > appear at places where they should not. Ambiguity causes problem, > because you can never debug these problems. I'm not sure what you mean exactly. Suppose someone's fec0:1234:5678::1 leaks to the global DNS somehow. Someone else has fec0:abcd:deff::1 configured in their site. When you configure your sites prefix length as e.g. /48 but still have a null-route (and filters) for fec0::/10, there should be no problems with connections at all -- they don't work as they shouldn't. > I realize that we have a tension between two requirements, uniqueness > which imposes some form of registration, and "free use" which imply > making up the addresses locally and virtually guaranteeing possible > collisions. Maybe we have to embrace the dilemma, and allow for several > types of identifiers, some guaranteed unique and some quasi random. ... > But > you must definitely provide unique numbers to those who are ready to > wait for registration. Which kind of users would require this kind of complete, guaranteed uniqueness? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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] --------------------------------------------------------------------
