Subject: RE: another renumbering question

From: [email-masked]
Date: Wed, 7 Feb 2001 13:47:12 -0600

Common where? Yes for firewalls and extranets I agree.   But that is not the
same paradigm as two face dns for sitelocal addresses as an implementation.
Two different beasts all together.  And the world is not good today to with
all the NAT and Tunnels it is horrible we should be careful to not propogate
such behavior whenever possible with IPv6.

/jim

> -----Original Message-----
> From: ext Brian E Carpenter [mailto:[email-masked]]
> Sent: Wednesday,February 07,2001 2:30 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: another renumbering question
> 
> 
> I didn't mean to say it is required. But I think it is so 
> common these days that
> it's fair to regard it as normal for large intranets.
> 
>    Brian
> 
> [email-masked] wrote:
> > 
> > I disagree that we can assume any site will have two face 
> DNS.  Thats a bad
> > assumption.
> > /jim
> > 
> > > -----Original Message-----
> > > From: ext Brian E Carpenter [mailto:[email-masked]]
> > > Sent: Wednesday,February 07,2001 10:19 AM
> > > To: Robert Elz
> > > Cc: Paul Francis; [email-masked]
> > > Subject: Re: another renumbering question
> > >
> > >
> > > Once you *know* that a host has a site local address, the
> > > address selection draft tells you when to use it.  I've always
> > > assumed that they would be in the DNS along with global addresses.
> > > Presumably large sites will be running two-faced DNS anyway, so
> > > these addresses will never go outside.
> > >
> > >    Brian
> > >
> > > Robert Elz wrote:
> > > >
> > > >     Date:        Tue, 6 Feb 2001 16:24:23 -0800
> > > >     From:        "Paul Francis" <[email-masked]>
> > > >     Message-ID:  <006b01c0909c$528dda60$1300a8c0@dellchan>
> > > >
> > > >   | But I can't recall how it is a host decides when
> > > another host can be reached
> > > >   | via a site-local address, nor can I find where I 
> read that text.
> > > >
> > > > This is still one of life's mysteries I think - several 
> ideas have
> > > > been floated, but nothing yet committed to a draft that I'm
> > > aware of.
> > > >
> > > > The include placing the site locals in the DNS, and 
> having clients
> > > > do a match on the global addresses to see if the site 
> local should
> > > > refer to the same site (one that finds no attraction to 
> me at all).
> > > >
> > > > And having the client send from its site local addr (so the
> > > packet cannot
> > > > leave the site) to the remote global addr an ICMP saying
> > > "tell me your
> > > > addresses", and receiving a list that includes the site
> > > locals for the
> > > > destination (or receiving an ICMP error indicating an
> > > attempt to cross
> > > > the site boundary with a site local source addr).   (If the
> > > source doesn't
> > > > have, or doesn't want to use, its site local addr, then
> > > there's no point
> > > > doing any of this, may as well just use global addr of the
> > > dest a well).
> > > > This one I like - it adds a small delay in communications
> > > the first time
> > > > a connection is attempted to a new node (only for
> > > connections initiated,
> > > > responses would never do this) but that is bounded by the
> > > RTT to the edge
> > > > of the site, which is usually of the order of a couple of ms.
> > > >
> > > > 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-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: Wed, 7 Feb 2001 13:28:33 -0800

> such behavior whenever possible with IPv6.

So Jim, in the absense of two-faced DNS how do you think a host should
decide whether it should use site-local for another host, or do you think
using site-local addresses is a bad idea?

PF

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Feb 2001 16:26:15 -0600

Jim,

Common because of firewalls, even without NATs which I hate as much as you.

Why would any enterprise publish the A record of internalserver.example.com
outside the firewall?

But this is a bit beside the point of Paul's question.

  Brian

---

From: Robert Elz <[email-masked]>
Date: Thu, 08 Feb 2001 13:22:34 +0700

Date:        Wed, 07 Feb 2001 16:26:15 -0600
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | Common because of firewalls, even without NATs which I hate as much as you.

Firewalls are no reason for a two faced DNS.   Those are forced upon us by
NAT, because of the re-use of addresses.  With IPv6 we will have no need
to re-use addresses, and so no reason to bother with two faced DNS (which
isn't to say that they may not still be people who would prefer to use it).

  | Why would any enterprise publish the A record of internalserver.example.com
  | outside the firewall?

Why wouldn't they?   Doing so at least allows others to know that they
have been given the correct name of the server, and simply cannot
communicate with it, rather than getting "no such host" from the DNS,
and then making wondering what the cause of that was (maybe the
name I was supposed to use was internal-server.example.com, or maybe
it was internal.server.example.com, or maybe it was intrnlsrvr.example.com
and was just read out over the phone as "internal server").

In any case, two faced DNS is simply not an option to solve the
site local issue - no matter how many large enterprises might happen
to use the things.

The most benefit for site locals will come to those who renumber
most often, not those who hardly ever do.   And those who renumber
most often are the very small sites.   What's more, those are the
sites who hardly ever run their own DNS, it is mostly run for them
(outside of their net) by their ISP.   Two faced DNS simply doesn't
scale to that kind of situation.

Eric's draft at least has the feature that it is mostly feasible,
and (save a couple of hard cases) could possibly work, at the
cost of up to twice as many addresses to return from the DNS

[Aside on another issue: using A6 would certainly help there, with
the assumption that all the internal addressing is the same for the
site locals and globals, only one more "upper level" A6 prefix
record needs to be added to cover a whole site of site-local addresses...]

Two faced DNS has nothing going for it at all, other than that it kind
of looks like what we do now for NAT.   And that's what we should be
trying to avoid, not entrench.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Feb 2001 10:27:34 -0600

Robert Elz wrote:

> Why wouldn't they?   

Truly, you are out of touch with the way large corporate intranets are run.

  Brian

---

From: Greg Maxwell <[email-masked]>
Date: Thu, 8 Feb 2001 11:57:33 -0500 (EST)

> Truly, you are out of touch with the way large corporate intranets are run.

Only because large corporations are out of touch with reality.

Such retarded behavior provides them with no additional security,
theoritically or practically, no matter what the 'security consultants'
sell them on.

---

From: "Paul Francis" <[email-masked]>
Date: Thu, 15 Feb 2001 12:36:25 -0800

> isn't to say that they may not still be people who would prefer to use
it).

It is funny for you to say that with IPv6 we don't need to use re-used
addresses, because a site local address *is* a kind of re-used address.

There is a lot of similarity architecturally between net 10 in IPv4 and site
local addresses
in IPv6.  Niether can be globally routed.  Both spaces are re-used by large
numbers
of sites, and from casual inspection of a site-local address, outside the
context of the inspection point, you can't tell what site it belongs to.
And clearly people feel a need to use them or we wouldn't be
having this discussion.

The reason we aren't forced into two-faced DNS with IPv6 is that *in
addition to* the re-used (aka site-local) addresses, IPv6 nodes also have
global addresses, and these can be leveraged to determine if a given re-used
address is in the same site or a different site.

On a separate note, I know this is probably just digging up dead
discussions, but have people considered creating a new IPv6 space which is
"globally unique but not globally routable" for use in this sort of internal
site communications?  Such an address space would be useful, for instance,
when merging two sites (which, if using site-local addresses, will require
renumbering of one of the sites).

Such addresses (lets call them unique-local addresses) could be put in DNS
without concern for thier being mis-interpreted by other nodes.  Granted
when a node did a DNS lookup, it wouldn't know if a given unique-local
address was in the same site, but it could learn easily by just sending a
packet to that address and either succeeding or getting an ICMP dest
unreachable.

PF

---

From: Robert Elz <[email-masked]>
Date: Fri, 16 Feb 2001 15:04:15 +0700

Date:        Thu, 15 Feb 2001 12:36:25 -0800
    From:        "Paul Francis" <[email-masked]>
    Message-ID:  <[email-masked]>

  | It is funny for you to say that with IPv6 we don't need to use re-used
  | addresses, because a site local address *is* a kind of re-used address.

Yes, I know, as often occurs, my wording was not very good.
I agree with your summary of the way things are (or will be)...

  | On a separate note, I know this is probably just digging up dead
  | discussions, but have people considered creating a new IPv6 space which is
  | "globally unique but not globally routable" for use in this sort of internal
  | site communications?

Yes there has been a bunch of discussion about that from time to
time, it is a topic Christian Huitema raises from time to time...

There's no reason these need to be different from site locals
though (all the attributes are there - if only site locals could
have a field in them to add the "globally unique" part).

The chief objection to this, as I understand it, has always been
how such things would get assigned, who would do that, on what
basis, etc.   I can't actually see the difficulty in assigning
consecutive integers to anyone who asks (perhaps using an automated
system much like many mailing lists use for subscriptions - you fill
in the template, send it in, get back e-mail containing a token/passwd
send that back, and your site ID gets returned).

There's 38 bits of empty space in site locals (250 billion numbers
close enough) which would do for this, and '0' could continue to
mean the "undetermined" (not globally unique) site local.

  | Such an address space would be useful, for instance,

There are lots of uses - it would provide a stable I-D for security
associations, ...

  | Such addresses (lets call them unique-local addresses) could be put in DNS
  | without concern for thier being mis-interpreted by other nodes.

Yes, though they still add to the DNS payload when for the vast majority
of users (everyone non-local) they're useless information.

  | Granted
  | when a node did a DNS lookup, it wouldn't know if a given unique-local
  | address was in the same site,

No, considering aggregated sites (with multiple I-Ds) but a simple compare
of her site ID token against mine would catch the majority of cases.

kre

---

From: Steve Deering <[email-masked]>
Date: Fri, 16 Feb 2001 01:28:07 -0800

At 3:04 PM +0700 2/16/01, Robert Elz wrote:
>  | discussions, but have people considered creating a new IPv6 space
>  | which is "globally unique but not globally routable" for use in
>  | this sort of internal site communications?
>
>basis, etc.

Exactly.  The last thing we want to do is establish yet another numbering
space that needs to be globally administered, which then becomes another
ICANN political football (like our existing global name and numbering
spaces), and for which we have to figure out some sort of allocation
mechanism/policy to prevent anyone from coming along and grabbing
such site IDs by the millions ("Hey, I'm going to be the next McDonalds,
so I'm going to need a million site IDs!  Trust me."), and for which
we'll get dragged into the issue of charging money for site IDs
(initially just to cover the cost of running the allocation service,
of course, but then as a disincentive to grabbing a million addresses,
eventually degrading into a fight to get a piece of the site ID
allocator's revenue stream).  And the other thing that would likely
happen is that sites would obtain these non-globally-routable site IDs
and then a few months later some of them would shop around to find an
ISP who would agree to inject their (unaggregated) site IDs into the
global routing system.  Now maybe these fears are overblown, but looking
at the current state of IP address allocation, DNS name allocation, and
the growth of unaggregated prefixes in the BGP tables sure makes me wary
about going in that direction.

One could possibly finesse the problems of establishing a new
numbering bureaucracy by exploiting an existing one, e.g., by
saying that site can choose, say, one of its own Ethernet addresses
(that is, a globally unique number from a space managed by the
existing IEEE bureaucracy) to stick into the empty field of its
site-locals -- unfortunately, there aren't enough free bits
there to hold an Ethernet address.  How about using IPv4 addresses
for that purpose?  Well, some sites today can't get even one IPv4
address, and that's likely to get worse.  Besides, we already have
half a dozen IPv6 address formats that have IPv4 addresses embedded
in them somewhere, and I shudder to have to explain yet another one.
Use a random number generator?   Well, someone would have to
figure out the Birthday Probability of duplicates and understand
how bad the consequences would be if two sites with the same site ID
got accidentally or intentionally merged, even if it were a very
unlikely event.

And then there may be other counter arguments I've forgotten.  It's
certainly true that we've been over this question a number of times
in the past, so if we're really going to dredge it up again, we
should at least do some digging in the archives to make sure we
don't spend a lot of time rediscovering (or worse, failing to
rediscover) previously identified issues.

Steve the Wet Blanket

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 16 Feb 2001 14:04:49 +0100 (CET)

> And clearly people feel a need to use them or we wouldn't be

I think there are two motivations for site-locals (that not everybody
agrees with):
1. For sites that are isolated i.e. do not have a global prefix.
2. To completely isolate traffic local to a site from site-renumbering events.

I think most people agree with #1, but some think that #1 alone isn't 
necessarily a good enough reason to have site-local addresses
in the architecture.

If we had a mechanism to handle #2 without using site-locals we could avoid
a lot of complexity. But handling #2, in my opinion, requires not only being
able to make long-running TCP connections survive renumbering, but also
somehow dealing with UDP (and TCP) applications which retain IP addresses
longer than the ttl indicated by DNS.
While fixing the applications might be easy in priciple, tracking down
all the places where an application might store an IP address for a longish
time, is quite difficult; much more difficult than the semi-automatic
porting of an application from IPv4 to IPv6.

   Erik

---

From: Robert Elz <[email-masked]>
Date: Sat, 17 Feb 2001 10:52:29 +0700

Date:        Fri, 16 Feb 2001 01:28:07 -0800
    From:        Steve Deering <[email-masked]>
    Message-ID:  <v04220811b6b29a21f524@[10.19.130.188]>

Dear Dr Blanket...

  | Exactly.  The last thing we want to do is establish yet another numbering
  | space that needs to be globally administered,

  | And then there may be other counter arguments I've forgotten.  It's
  | certainly true that we've been over this question a number of times
  | in the past, so if we're really going to dredge it up again, we
  | should at least do some digging in the archives to make sure we
  | don't spend a lot of time rediscovering (or worse, failing to
  | rediscover) previously identified issues.

I remember the arguments, and I don't recall a technical one among them.
They're all this FUD.

What's more, this stuff is an even weaker argument than the arguments
made by those opposed to requiring security (encryption in particular)
in IPv6 - at least there were real (non-technical) problems to be
overcome in that case, rather than just the fear of potential political
problems here.

Now it is probably also true that the technical arguments in favour of
having globally unique non-routable addresses (in addition to the
routable ones) aren't as strong as the technical arguments in favour
of security, but it would be nice if we (more or less technical people)
could confine ourselves to the technical arguments, and ignore this
nonsense about how difficult it will be to assign consecutive integers.
Even more so, if they would not actually be required for anything
to operate (just an enhancement that a site might prefer to have).

kre

ps: but yes, the archives should be checked...

---

From: "Paul Francis" <[email-masked]>
Date: Fri, 16 Feb 2001 08:59:02 -0800

> of her site ID token against mine would catch the majority of cases.

It might catch the majority, but there would be enough that it wouldn't
catch that you'd need mechanisms similar to the ones used with site-locals
(ie, compare global prefixes to decide if you are in the same site, or even
have router advertisements or DHCP advertise the prefixes that are within
the site.")  There'd also be the case where a node that was normally
reachable intra-site is temporally not reachable that way, but it reachable
through the global address, so you'd want to be able to catch that too.

So globally-unique-locally-routable prefixes aren't trivial to operate.

PF

---

From: "Paul Francis" <[email-masked]>
Date: Fri, 16 Feb 2001 11:25:00 -0800

> so I'm going to need a million site IDs!  Trust me."), and for which

Speaking rationally, 38 bits of address would allow ICANN to give out 100
prefixes per second for the next 90 years.  They could give them out almost
freely (say, in chunks of 10000 to virtually anyone who asked) without any
concern for running out.  Since the numbers don't have the same value as DNS
names, and since they are not scarce like TLDs, then speaking rationally,
there should be no issue.

Of course there will be issues, but one can't but hope it wouldn't be near
the political football as the other ICANN assignments.

> ISP who would agree to inject their (unaggregated) site IDs into the

This requires collusion between the ISPs (they would have to explicitly
agree to advertise "local" addresses).  This would probably be harder than
getting ISPs to advertise longer prefixes of the existing globally
aggretable addresses, so we probably aren't making the likelihood any worse.

> there to hold an Ethernet address.

You could do this if you really wanted.  You need 46 bits (take away the
group bit and the global bit).  If you use two of the unassigned 3-bit
prefixes for this purpose, then you'd have enough space.  But what a waste!

> How about using IPv4 addresses

IPv4 addresses can't be used this way because they are not owned by sites.
The sites need a number they can own forever no questions asked.

PF

---

From: Steve Deering <[email-masked]>
Date: Sun, 18 Feb 2001 22:28:28 -0800

At 10:52 AM +0700 2/17/01, Robert Elz wrote:
>...it would be nice if we (more or less technical people) could
>confine ourselves to the technical arguments, and ignore this

Those who ignore history....

---

From: Robert Elz <[email-masked]>
Date: Mon, 19 Feb 2001 15:30:34 +0700

Date:        Sun, 18 Feb 2001 22:28:28 -0800
    From:        Steve Deering <[email-masked]>
    Message-ID:  <v04220801b6b66d352afd@[10.19.130.188]>

  | Those who ignore history.... 

There's a difference between noting history, and the attitude
"we tried this once, we had problems, so we will never try anything
like it again"

kre

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 19 Feb 2001 08:27:11 -0600

> prefixes per second for the next 90 years.  They could give them out ...

And when those lazy stick-in-the-mud routing geeks finally figure out
how to route a trillion unaggregatable prefixes, you're all set to
go!  :-)

---

From: "Paul Francis" <[email-masked]>
Date: Mon, 19 Feb 2001 14:36:18 -0800

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

---

From: "Paul Francis" <[email-masked]>
Date: Mon, 19 Feb 2001 14:36:18 -0800

Thanks,

PF

---

From: "Brian Haberman" <[email-masked]>
Date: Tue, 20 Feb 2001 08:03:12 -0500

Paul,
     A couple of points in-lined...

> to some extent talking past each other.

The definition of what a site ID would be was intentionally undefined.
That is, a site ID was supposed to be implementation dependent.
However, we found in developing the APIs and the InetAddress TC that
we needed something a little more concrete.  Now, the site ID is,
in essence, a 32-bit integer.

> assurance that nobody else is using the same space.

What exactly will be reasonable assurance?  If your "site ID registry"
allocates you a unique site ID, why would the site local address
created with that site ID not be globally routable?

> definitively whether they could or could not reach each other using the

If a "site ID registry" is giving out the ID's, I would think it would
be in their best interest to allocate unique numbers.  If two site
local addresses have the same ID in them, why would they not be in
the same site, given the above assumption?

> anyone out there who in principle likes the idea of site-IDs and would care

I used to think that having a unique ID in the site local addresses
would be useful.  However, I gave that up a few years ago after
thinking about what it would take to come up with and manage that
number space.

If anything, I could see allowing an administrator to specify his/her
own ID's.  This would allow the NOC to map its site local addresses
to some administratively controlled "space".

Regards,
Brian

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 20 Feb 2001 08:03:40 -0800

> in essence, a 32-bit integer.

Heh!  When I first read this last sentence, I thought "I didn't know it was
that clearly defined", went off to RFC2373 to check it out, but once again
found no concept of site ID.  So I looked again at your paragraph and saw
that you are talking about the API.  I didn't realize that there was a
notion of site ID in the API, so my apologies for using that term
incorrectly.  I picked it up from one of Deering's recent messages, not
realizing its specific meaning.  (Even having read through some of the
archives, I didn't catch that the term site id refered to a number that
crosses the API.)

[..... time elapsed as I look at the API documents to check up on this ....]

Well, I looket at the latest versions of RFCs 2553 and 2292, and I still
don't see anything about a well-defined 32-bit site id.

RFC2253 says:

"The mapping of sin6_scope_id to an interface or set of interfaces is left
to implementation and future specifications on the subject of site
identifiers."

and RFC2292, in a section labeled "Open issues" says:

"What about site names and site ids?  Need for interfaces to map?   Requires
that site-prefixes pass name - does name need to use DNS format to handle
character sets?"

So I remain more confused than ever.  Could you please tell me where I can
read about 32-bit site IDs, and after I've read up I'll try to address your
comments.

Thanks,

PF

---

From: Steve Deering <[email-masked]>
Date: Tue, 20 Feb 2001 12:05:37 -0800

At 8:03 AM -0800 2/20/01, Paul Francis wrote:
>realizing its specific meaning.

My fault.  In my email, I used the term site ID to refer to what you
were proposing, i.e., a value to stick into site-local addresses between
the 10-bit format prefix and the SLA field.  I had overlooked the fact
that we have also used the term site ID for the local identifier that
a multi-sited node uses to distinguish between the different sites to
which it is attached (an identifier that is never sent outside a node;
a particular case of a scope zone identifier).  Brian was referring to
the latter.

Steve

---

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

>   I had overlooked the fact that we have also used the term site ID
> for ... a particular case of a scope zone identifier

If we're going to worry about overloaded terminology, let's back up
and worry about "scope".    :-/
--------------------------------------------------------------------
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 14:09:34 -0800

> created with that site ID not be globally routable?

It would not be globally routable "by definition"...  That is, the prefix
would be recognized by routers as non-globally routable and they would
refuse to route them.  But as you are suggesting since they are in fact
globally unique, ISPs could decide some day to route on them.  But they'd
pretty much all have to agree to do it.  By the same token they could agree
to route on larger globally aggregatable prefixes if they so desired, so the
potentiallity of huge routing tables is there whether or not a site-id
registry is created.

> the same site, given the above assumption?

Because they might be from a previous single site that split, for instance.
Conversely, if two different sites merged you would have a situation where
two machines with different "site ids" were in fact in the same site.  So
you'd need other mechanisms to determine when in fact two nodes were in the
same site.

In this regard, "site id" is the wrong term (and not the term I originally
started with).  A better term is "globally unique locally routable" address,
or GULR address.

PF

---

From: Robert Elz <[email-masked]>
Date: Wed, 21 Feb 2001 12:00:35 +0700

Date:        Tue, 20 Feb 2001 14:09:34 -0800
    From:        "Paul Francis" <[email-masked]>
    Message-ID:  <[email-masked]>

  | It would not be globally routable "by definition"...  That is, the prefix
  | would be recognized by routers as non-globally routable and they would
  | refuse to route them.

no, you can't do that with site local - the block has to be done by
configuration, where the administrator tells the router that a site
boundary exists, otherwise you end up just having link local addresses
with a lot of extra bits set...

This means that it will always be technically possible to explode the
site boundaries, and route using this new kind of address, if people
wanted to (whatever the address type is called).

  | so the
  | potentiallity of huge routing tables is there whether or not a site-id
  | registry is created.

This is certainly true - unique site locals (or GULRs or whatever) might add
to the pressure a little but they don't create it, and nor does anyone have
to take any notice of it.   Their purpose is not for wire are routing.
That just needs to be made very clear.

kre