Summary answer to both of kre's points: If one could go and get a prefix under 2000::/3 today that was not tied to an ISP, that would be just fine. But one can't, for good reasons, so the only solution I see is a lightweight way to get a PI prefix that isn't ambiguous. Bob's proposal is the best I've seen for this. That's all I can say, because your arguments are basically sound, but we don't live in a perfect world.
Brian Robert Elz wrote: > > Date: Sun, 08 Jun 2003 13:57:35 +0200 > From: Brian E Carpenter <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > > | I don't think so, as far as the DFZ goes. What *will* happen, whatever > | we do, is exactly what happens today - zillions of VPNs and private > | static routes for inter-enterprise connections, that are quite > | independent of the public routing tables summarized in the DFZ. > > Yes, for those who want to use non-routable addresses for this purpose, > having a means by which conflicts can be avoided would be a nice advantage. > > However, someone needs to explain to me why an IPv6 VPN would want to > use non-routable addresses particularly? Why not just use the global > addresses that the sites already have. > > In the IPv4 world, there's a simple answer - the sites are using 1918 > addresses (frequently) internally, and linking, at least parts of, their > internal nets is the aim. So, their 1918 addresses are what they want to > exchange - which works iff there are no allocation conflicts (which happens > only by chance). > > But in IPv6, everyone is going to have global addresses, why can't they > just be used for VPNs? > > If the answer is "because we use 1918 addresses in IPv4" then I think > we have some education to do. > > If the answer is "we want address stability in our group, even if some of > the members have to change their routable prefixes", then that's fine, but > for this, wouldn't the right answer be to simply create a new prefix for > the VPN, and use that one? That is in this new address space that's being > created, the organisations that are creating a VPN pick one prefix that > is not in use by any of them (with 2^38 or more prefixes, minimum, to > choose from, that can't be hard) and assign that to all nodes that are > participating in the VPN (allocating subnets from it to the organisations). > > If things are done that way, then it is no longer even relevant that > more than one of the organisations happens to have randomly selected the > same prefix - and there is then no longer any requirement that there > be any kind of (pre-existing) uniqueness for this particular usage. > > Brian also said (in a different message): > > | To be more precise, we are going to define them in a way that makes them > | extremely likely to be unique, and then treat them as if they are > | mathematically unique. To me, that's good enough. > > It would be, but that's the very thing I don't think we should be doing. > If we treat them as if they're unique, someone will forget that they're > not, and start doing something which actually assumes the uniqueness. > > Unless we can demonstrate that they are, and must be, unique (to work, or > be useful) we really have to make it very very plain that they are not > unique. > > kre -------------------------------------------------------------------- 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] --------------------------------------------------------------------
