First, I can see a lot of advantages to having unique, non-routable site
prefixes. One big advantage I can see is that VPNs can be created between
arbitrary sites without worry of renumbering either site. If we can find
a way to implement site IDs in a reasonable manner, it would be a big win
for IPv6.
On Mon, 19 Feb 2001, Christian Huitema wrote:
> 4) Combining random allocation with duplicate detection would go past
> the birthday paradox, but is almost impossible to conduct at the scale
> of the Internet...
Why not leverage the global DNS system to do this? DNS can be used to
assign ownership and do duplicate detection, and can also solve the
two-faced DNS problem. Here's how:
Say company.foo. wants one of the 38-bit site-local IDs for their site.
They randomly generate a number (or pick their favorite integer) and
register it as a domain name with a specially-designated suffix. Let's
say the suffix is -site-ipv6.net, and let's say they chose the nice random
number 0x0012345678, so they would register the domain
"x0012345678-site-ipv6.net". If somebody else was using that unique
prefix, company.foo would find this out when they went to register it, and
would be forced to choose a different number. This guarantees uniqueness.
Company.foo can now stack the prefix fec0:1234:5678::/48 on all their
subnets in addition to their provider-based addresses. Now all the hosts
at the site know the site ID.
This is how the site-local DNS problem is solved too. For every lookup
that each host does, it first looks up the same name inside the site-local
DNS zone. To resolve the host www.yahoo.com, a node would first look up
www.yahoo.com.x0012345678-site-ipv6.net. to try and find a site-local
address, but failing that, would look up www.yahoo.com. Presumably,
there wouldn't be a site-local address for www.yahoo.com, but there would
be one for internal-fileserver.company.foo.
Essentially what this scheme does is sequester all of a site's site-local
IP addresses into their own zone, which clients discover by looking at the
prefixes on their link. By registering the zone in global DNS, uniqueness
is preserved.
Some observations:
This wouldn't impact most home/SOHO/unmanaged nodes, because this doesn't
affect behavior when no site-local prefix is present on the link.
Every lookup would cause two DNS resolutions, but presumably this
shouldn't be a big issue because the authoritative servers for the site-ID
zones would be very close to the clients. This extra lookup is the *only*
additional overhead for this scheme.
The only changes required in protocol stacks would be the DNS lookup
functions, getaddrinfo() and friends. Possibly a change would need to be
made if the IPv6 layer didn't accept fec0:: addresses with non-zero
reserved bits.
*Any* domain names could be assigned site-local addresses at each site,
not just ones in the local zones. This has nice implications for
selective proxying systems and private links between sites.
VPNs between arbitrary companies could easily be created. Each company
could add routes for the other company's site-local addresses through the
VPN. For example, company.foo would tunnel using some sort of strong
encryption to partner.foo who has site prefix fec0:8765:4321::/48.
Company.foo could add entries for partner.foo's site-local server IPs into
partner.foo.x0012345678-site-ipv6.net, and partner.foo could add entries
for company.foo's site-local server IPs into
company.foo.x0087654321-site-ipv6.net. Nodes on both networks would use
the VPN transparently with the other site's site-local addresses, and all
connections between the companies would survive global renumbering of both
sites.
Nobody would go and grab a significant portion of the address space for
the same reason that nobody grabs 10^6 domains. And speculating on
site-IDs makes even less sense than speculating on domain names.
Two-faced DNS is optional. If company.foo wanted to hide their site-local
addresses, they would serve x0012345678-site-ipv6.net only to clients at
their site. If they didn't care, they'd simply have their -site-ipv6.net
as an additional zone on their DNS servers. The point is that nodes
outside the site would *never* see the site-local addresses, because
site-local addresses would only be stored in the -site-ipv6.net zones.
If, heaven forbid, we should ever need more than 275 billion site IDs, we
could allocate another prefix besides fec0::/10 for site-locals. This
applies to any scheme that assignes unique site-IDs, however.
The only possible unfortunate side effect that this may have is that, as
Steve pointed out, some unscrupulous ISP may begin advertising site-local
prefixes into the global routing tables. But shouldn't filters on
default-free routers refuse to route to addresses in the fec0::/10 block?
I think the remote possibility of unique site prefixes overloading the
world's routing table is a risk worth taking, since such prefixes might
very well give sites peace of mind that renumbering wouldn't interrupt
local service on their network.
This system is probably the most flexible and low-overhead of all those
proposed in the last week, and requires relatively few changes in existing
code. My apologies if this scheme has been proposed already, but I'm on a
slow link and searching the archives is rather painful. -Nathan
--
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | [EMAIL PROTECTED] | Lithium Technologies |
+------------------------------------------------------------------+
| I dread success. To have succeeded is to have finished one's |
| business on earth... I like a state of continual becoming, |
| with a goal in front and not behind. - George Bernard Shaw |
+------------------------------------------------------------------+
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
