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]
--------------------------------------------------------------------
