Subject: RE: Wade through the archives (was Re: another renumbering question)

From: "Christian Huitema" <[email-masked]>
Date: Mon, 19 Feb 2001 19:16:42 -0800

The discussions always ended up on the same kind of conclusion: in
theory it is a fine idea, but we would have to change existing
implementation, and besides it is not easy to allocate unique numbers.
There are basically four ways to allocate random numbers, and none of
them is particularly attractive:

1) Picking numbers at random is easy, but you need a good random
generator, and besides you hit the birthday paradox with 2^^19 entries,
i.e. less than a million. There are way more than 1 million potential
sites.

2) Deriving numbers from other pre-established registries is tempting,
but there are not very many suitable pre-existing registries. IEEE-802
numbers are too large too fit; IPv4 addresses have the right size but
not the right stability.

3) Starting a new registry looks simple on paper, but the practical
problem are not so small -- for example, decide who will be king; find
the right balance between automation and reliability; etc.

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

Now, if you can change that...

-- Christian Huitema

> -----Original Message-----
> From: Paul Francis [mailto:[email-masked]] 
> Sent: Monday, February 19, 2001 2:36 PM
> To: [email-masked]
> Subject: Wade through the archives (was Re: another 
> renumbering question)
> 
> 
> 
> I took Steve up on his suggestion of looking through the 
> archives on this topic.
> 
> With some effort I found three threads, all initiated by 
> Christian, in May '97, Dec '97, and Nov '99.  I saved the 
> relevent messages...you can find them at 
> http://www.aciri.org/francis/IPv6> _site_id_threads.txt if you 
> are so inclined.  This is 
> probably not exhaustive, so if anyone can point me to other 
> threads that would be helpful.
> 
> I didn't see any major ideas in the previous threads that 
> weren't in the latest thread.
> 
> A problem I found when looking over the threads is that a 
> complete picture of what a site ID would be and how it would 
> work was never generated, with the end result that different 
> people were talking about different things and to some extent 
> talking past each other.
> 
> Having read the arguments, I still believe that there is 
> something to be said for the site-ID notion.  The site-ID 
> would be for sites that want to have their own number space 
> for internal communications, with reasonable assurance that 
> nobody else is using the same space.
> 
> The site-ID would not supplant the use of site-locals by 
> other sites who wanted to use them.  Site-locals would remain 
> as defined.
> 
> A site-ID would also not by itself identify what is and is 
> not in a given "site".  In other words, one couldn't take two 
> addresses with site-IDs and, in the absense of any other 
> information (DNS entries or routing tables) say definitively 
> whether they could or could not reach each other using the 
> site-ID addresses.
> 
> I'm inclined to write a draft specifying this so that we can 
> have a focused and consistent (and dare I say difinitive?) 
> discussion about it.  Is there anyone out there who in 
> principle likes the idea of site-IDs and would care to work 
> with me on this?
> 
> Thanks,
> 
> PF
> 
> 
> 
> --------------------------------------------------------------------
> 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-masked]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "Paul Francis" <[email-masked]>
Date: Mon, 19 Feb 2001 20:17:47 -0800

> implementation,

Assuming implementations have to be changed, then this means that it'll take
a few years for the functionality to get out there, but otherwise this is
not a good reason not to do it per se.

But speaking of existing implementations, what would happen if an existing
router advertised to an existing host that one of the host's prefixes
contained a site ID (that is, a site-local with a non-zero 38-bit number).
Presumably the host would accept it?

And, if you were running two-faced DNS, then when the host did a DNS lookup
on another host in the same site (apologies to those of you who hate
two-faced DNS, but lots of folks use it so this would be valuable for at
least some of the community), it would get back a site-ID-based address and
all would be fine, yes?  Same as with site-IDs.

For those sites that don't want to run two-faced DNS but do want site-IDs,
they'd have to wait a few years.  (As it stands today with existing
implementaitons if you don'trun two-faced DNS you can't use site-locals
anyway.)

> and besides it is not easy to allocate unique numbers.

Agreed that it isn't easy to allocate unique numbers.  Is that a good enough
reason not to pursue this?  I mean, lets say we design how to do site-IDs
and get buy-in from the gang.  Then we go off to ICANN or whoever, and they
screw it up.  Ok then it was a failure and too bad.  (Or, we go off and
create a renegade registry...that'd be interesting  :-)  (Or, do the
renegade registry first and force ICANN's hand...)

Either way, the exercise would be a learning experience for the IPv6 group,
and the time wasted would mainly be just the poor disillusioned souls that
worked on the draft...

PF

---

From: "Paul Francis" <[email-masked]>
Date: Mon, 19 Feb 2001 20:17:47 -0800

PF

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 20 Feb 2001 11:14:54 +0100 (CET)

> Presumably the host would accept it?

They should since the site-local prefix is fec0::0/10,
but there is some risk that implemetors think that the site-local
prefix is fec0::0/48 (since all those bits are mandated to be zero).
Thus it would make sense to do a quick survey of existing
implementations.

   Erik

---

From: Nathan Lutchansky <[email-masked]>
Date: Tue, 20 Feb 2001 11:18:27 -0500 (EST)

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.

> the birthday paradox, but is almost impossible to conduct at the scale

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

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 20 Feb 2001 10:37:22 -0600

> i.e. less than a million. There are way more than 1 million potential

You don't care about the existence of any pair of duplicates -- only
about a duplication with a site you eventually expose your private
address space to.  If everyone picks an unbiased random site id, and
you connect in that way to N sites, the chance of a duplication is
only around N^2 / 2^19.

If you reserved half the space for the number-tsar to allocate
uniquely and half for random picks, the chance of hitting a
duplication problem (including by connecting to someone with the same
site id as your site and connecting to two which chose the same) is
not more than about N^2 / 2^18 -- 0.1% if you connect 16 sites -- and
far less if you and they are mostly from the unique-numbered camp.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 20 Feb 2001 13:39:06 -0800

Matt,

Your point is good, but there must be something wrong with your math.
Christian's point is (I assume) that with a number space of 2^36, when you
select 2^19 random values you start running into a reasonable risk of two of
those random values being the same.

Your equation (N^2/2^18) doesn't seem to take into account the 2^36 number,
and concludes with a probability (0.1%) that strikes me as very high.  It
would mean that of Christian's 1,000,000 sites, 1000 of them would have this
problem, which is a lot of sites...

Am I not getting something?

PF

----- Original Message -----
From: "Matt Crawford" <[email-masked]>
To: "Christian Huitema" <[email-masked]>
Cc: "Paul Francis" <[email-masked]>; <[email-masked]>
Sent: Tuesday, February 20, 2001 8:37 AM
Subject: Re: Wade through the archives (was Re: another renumbering
question)

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 20 Feb 2001 16:05:01 -0600

> Your point is good, but there must be something wrong with your math.

No, with my eyes.

> Your equation (N^2/2^18) doesn't seem to take into account the 2^36 number,

It doesn't.  My eye seized upon the wrong number.  2^19 should have
been 2^38 throughout.  And then making private-space connections to
16 sites gives you a <= one-in-500-million chance of collision, and
connecting to 256 sites gives <= one-in-2-million.

> Am I not getting something?

Yes, presbyopia.  Lucky you.

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 20 Feb 2001 14:16:43 -0800

> connecting to 256 sites gives <= one-in-2-million.

This is a better number, and one I feel I could live with (by which I mean,
one that would justify the use of random number selection as one of the
alternative methods of assigning these identifiers...)

And I would literally specify, as per Christian's suggestion, that the
number MUST be created by flipping a coin 38 times...

PF

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 21 Feb 2001 07:55:45 -0800

> would be forced to choose a different number.  This guarantees uniqueness.

That is certainly an interesting idea.

The obvious negatives:

1.  Extra load on core DNS, mainly I suppose for just storing the
things---presumably not too many of the actual queries would work thier way
to the core (though some necessarily would).
2.  Extra overhead and delay of the additional query.  For popular sites,
which typically have a very short TTL, the extra query would happen often,
leading to increased load on local DNS server blah blah blah
3.  Having to change the DNS client...buy-in from the DNS community might be
tough.
4.  The weirdness of requesting query x from DNS, and DNS going off and
actually making query y.  Does this actually happen in any other context
today?  Sounds like a major architectural change for DNS...(ah, but then
again it wouldn't be the first time for IPv6....)
5.  Presumably sites that prefered two-faced over this would not want thier
hosts making this extra xxx-site-ipv6.net query.  So there would have to be
some way of switching the behaviour on and off.

I don't know...other reactions?

PF

---

From: Nathan Lutchansky <[email-masked]>
Date: Wed, 21 Feb 2001 11:59:02 -0500 (EST)

Some of these I'd thought of, others I hadn't.  I didn't realize until
afterwards that this would probably need to be run by the DNS groups to
make sure they're OK with it.

> to the core (though some necessarily would).

Essentially this boils down to the question, "Does registering an extra
domain for each site/organization cause extra load on the DNS system,
considering that these extra domains would receive very little core
traffic?"  Two points:

a) As it stands, most companies register not only their primary domain
name, but their domain name in multiple TLDs (com, net, org, plus CCs),
all possible misspellings of their name, their name with various suffixes
like "sucks", a domain or two for each of their products, maybe a name for
each of their regional offices, and so on.  Adding a single name to
correspond to their site's network number will probably be fairly
insignificant.

b) I don't think any registrar will tell you, "No, people should stop
registering domains because the DNS infrastructure won't handle it."  :-)

> leading to increased load on local DNS server blah blah blah

Like I said in the proposal, the authoritative server for the site-local
zone will likely be very close to all the clients doing lookups in that
zone.  We would expect that site-local queries never leave the site.

> 3.  Having to change the DNS client...buy-in from the DNS community might be

Oh, yeah, and A6/DNAME don't require changing the DNS client at all.  If
we're tacking on features, we may as well do it all up front.  This can be
just another modification required for IPv6 support.

> again it wouldn't be the first time for IPv6....)

Kind of.  This is along the same lines as domain search paths.  If I type
"http://www" into my browser, the DNS resolver will return the address for
www.litech.org even though I clearly did not type "litech.org" in the
address.  It might even return the address for www.litech.internal, even
if what I expected was www.litech.org.

Note that domain search paths are configured via DHCP, and thus are set at
a site-level rather than individually for each host.  (Although each host
is able to modify this if desired.)

> some way of switching the behaviour on and off.

I'm a bit unclear on what you mean by "two-faced" DNS then.  I'm assuming
that you mean that queryes for addresses inside the company.foo domain
would be answered differently depending on the IP address of the queryer.

My proposal would achieve exactly this, by having all clients inside the
site obtain addresses from the company.foo.x0012345678-site-ipv6.net zone
instead of the real company.foo zone.  If two-faced DNS is desirable to
"hide" the addresses from hosts outside the site, then the DNS servers for
x0012345678-site-ipv6.net could easily be configured to only allow queries
from site-local addresses.

The other possible interpretation for two-faced DNS is that hosts inside
the site would use addresses in a separate domain, like company.internal
as described in the BIND documentation, and that company.internal would
only be available to hosts inside the site.  My proposal is analogous to
this, only the internal-only zone is registered globally, and clients
automatically look up addresses inside the zone without manual
configuration.

Hope this clears things up.  -Nathan

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 21 Feb 2001 10:49:35 -0800

> registering domains because the DNS infrastructure won't handle it."  :-)

yeah, I know the registrars are happy to take your money.  I was thinking of
the actual core machines.

> if what I expected was www.litech.org.

Heh, I didn't know about this.  I just tried it (from home), and sure enough
got the home page of my ISP!  So what happened?  Did my browser "complete"
the URL for me, or did DNS do it?

me type http://www ---> browser expands to gethostbyname(www.myisp.com), DNS
do query(www.myisp.com), or
me type "http://www" ---> browser do "gethostbyname(www)", DNS expands to
query(www.myisp.com)

I would guess the former, but nothing will surprise me these days...are DNS
clients "intelligently" expanding DNS queries for us now?

> My proposal would achieve exactly this, by having all clients inside the

I basically meant this.  (I'm not quite clear as to whether internal dns
servers actually pay attention to the IP address of the queryer, or rather
if they just assume that if they got a query, it must have come from inside
since the firewall prevents them from coming from outside.  I would have
assumed the latter.

From what I know so far, I believe it may be possible for a site to use
GULRs today without any changes to any existing implementations, as long as
they use two-faced DNS.  The ability to do this is very attractive for
obvious reasons.  It is probably mainly for that reason that I'm disinclined
towards the part of your idea that requires change to the DNS client.

The part of your scheme that uses site-ipv6.net simply for the purpose of
helping guarantee uniqueness, however, is very nice.  I don't think everyone
would want to use it (rather they would just be lazy and flip the coins but
not register), but those that do would at least have some legitimate legal
claim to the number, should the issue arrise in the future.

Another attractive part of this aspect of your scheme is that it would put
pressure on ICANN to create a true registry for the GULR identifiers.  The
pressure would come from people that are outraged at having to pay for a
domain name that they don't in fact intend to use as a domain name.  So at
some point the site-IPv6.net's would be grandfathered into a "true"
registry.

PF

---

From: Nathan Lutchansky <[email-masked]>
Date: Wed, 21 Feb 2001 15:00:03 -0500 (EST)

> the actual core machines.

Oh, right.  Those.  But I still think it's negligible considering how much
other stuff gets registered for immeasurably little benefit.

> the URL for me, or did DNS do it?
[...]
> clients "intelligently" expanding DNS queries for us now?

This is a resolver feature, and AFAIK they've supported this from the
beginning.  It's the "domain search path".  Check the manpage for
resolver(5).  Essentially, if there are fewer than two dots in any name
you're trying to resolve, the resolver will attempt to append every domain
in your search path and resolve the result before trying to resolve the
name alone as a FQDN.

I'm not sure if this behavior is specified in an RFC or not, but every IP
stack/resolver I've encountered has this feature.  The search path is a
parameter that can be passed via DHCP, or configured locally in
/etc/resolv.conf in Un*x or in the network control panel in Windows.

> towards the part of your idea that requires change to the DNS client.

Yes, with two-faced DNS you could use GULRs right now.  But two-faced DNS
is inconvenient for certain situations like mobile IP and multisite nodes.
Which DNS server would a multisite node query?  If it needed to get GULR
addresses for both sites, it would need to have more complicated changes
to its DNS resolver than my proposal would require.  Or it would have to
run a full DNS server locally.

In fact, you could implement my proposal today without two-faced DNS by
simply setting the threshhold for search-path lookups higher than 2 dots,
and inserting the unique prefix domain as the first entry in the search
path.  Of course, you'd have to configure this on every host at your site.

The advantage to modifying the resolvers is to hard-code (literally) the
format for the unique-local domains.  Maybe folks in Australia start using
x0012345678-site-ipv6.net.au instead of the official suffix.  Maybe Big
Rich Company(R) accidentally registers and uses x0012345678-site-ip6.net
(misspelled), then a few years down the road tries to take the domain
x0012345678-site-ipv6.net away from the real registered owner.  Or worse,
tries to merge sites with them.  It is conflicts like these that we are
trying to avoid, and we can enforce the use of the correct format now if
we provide an immediate incentive for getting it right the first time.

> claim to the number, should the issue arrise in the future.

[They'd have to flip 38 coins then, eh?  :-) ]

That was the original motivation behind using domains in the first place.
But the more incentive we can find for sites to register, the more likely
it will be to work.  Modifying resolvers to allow hosts to auto-configure
themselves for site-local resolution is a nice incentive, and having
actual data in the domains also ensures that the contact and NS
information for the domains will remain up-to-date in the whois database.

> some point the site-IPv6.net's would be grandfathered into a "true"

While it would be nice to simply have a TLD (kinda like .arpa) or other
dedicated repository for these registrations, we all know how likely it is
that such an entity would be created at this stage.  All the other
arguments against a new repository, such as measures to prevent an
individual from grabbing the whole space, are already resolved for an
established system like DNS.  Perhaps at some point in the future we will
have enough motivation and operational experience to move to a better
method of registration.

Regarding the difficulty in modifying the resolvers...  I think that would
take the addition of maybe 10 lines of code, don't you?  -Nathan

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 21 Feb 2001 14:30:31 -0800

> information for the domains will remain up-to-date in the whois database.

You know, I only now realized that most of your scheme is with respect to
the usage of site-locals, not GULRs.  My last couple messages in response to
your scheme were concerning GULRs only, so please disregard them...

PF

---

From: Nathan Lutchansky <[email-masked]>
Date: Wed, 21 Feb 2001 17:58:19 -0500 (EST)

> your scheme were concerning GULRs only, so please disregard them...

This is my mistake.  I've been using the terms "site-local" and
GULR/unique-local interchangably, when in fact they are two separate
terms.

The site-ipv6.net zone would be used to store addresses within a site's
GULR prefix.

Your responses to my earlier messages are valid, as far as I can tell.
-Nathan