Subject: Re: Another way to support Site-Local Addresses

From: Jim Bound <[email-masked]>
Date: Thu, 02 Mar 2000 00:32:40 -0500

Steve,

OK I am done sitting in my corner :---)

>> >If the goal is to add an 8-16 bit site id in the site local prefix between 
>> >FEC0::/10 and FEC0::/48, then why not make it 24 bits?  32 bits?  38 bits?
>> 
>> Thanks for the input we will recall this mail as we proceed.

>If it makes sense to make the site id field larger to avoid collisions at
>multi-site nodes (and the consequent renumbering), then why not go all the
>way and make site ids globally unique?  In other words, assign them via
>registries, perhaps leaving a large block free for local assignment, and with
>site_id == 0 remaining the zeroconf default.  There are 38 bits available so
>they should not be scarce (given that SOHO networks have no use for anything
>other than the site_id == 0 default), and it is likely that they would be inexpensive to lease.
>
>Put another way, why not add globally unique, stable, portable (and
>non-aggregatable) addresses as a formal part of the IPv6 addressing
>architecture?  And move the special treatment of site-local addresses out
>of the forwarding plane and into the configuration and routing protocol
>planes?

I have thought about this hard.  I think 2^^38 + 16bit subnet ID should
be more than capable of doing what you say.  But it does not meet the
req of IPng that an addressing model should support 1 + E15 networks. So
I am not sure we can bite that bullet in the addressing architecture.

That being said though I can think of no "reasonable" duplication of
site-local addresses with 2^^38 + 16bit subnet ID within an organization
where site-local addresses are duplicated.  Except in cases of a network
merger because of business or merger of orgs reasons.  In that case a
rule can be specified that the network merging into the larger network
should renumber to the site it is entering and I still cannot see
breaking the 2^^38 capability.

In other words treat site-local as global across sites within an
organization.  This eliminates the nastiness of site-locals completely.
But most of all it eliminates the nastiness of any applications having
their software architectural paradigm altered in anyway and neither does
it affect the APIs for customers and ISVs moving to IPv6 which is a very
big deal to any future user of IPv6 I can think of.  And the reason it
is good we revisit what we have done here yet again.

Of course if we can get around the IPng 1 + E15 networks req for
site-locals then we can assign them globally.  But I don't think we can
right now????

Whats your response to this Steve B.?

regards,
/jim

--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Thu, 02 Mar 2000 16:54:20 +1100

Date:        Thu, 02 Mar 2000 00:32:40 -0500
    From:        Jim Bound <[email-masked]>
    Message-ID:  <[email-masked]>

  | I have thought about this hard.  I think 2^^38 + 16bit subnet ID should
  | be more than capable of doing what you say.  But it does not meet the
  | req of IPng that an addressing model should support 1 + E15 networks. So
  | I am not sure we can bite that bullet in the addressing architecture.

Hmm - those numbers seem to keep stretching - originally it was 10^12
nodes (see rfc1550), that was increased to 10^15 nodes sometime during the
deliberations.   Since then it has been expressed as 10^15 networks,
and now it has grown to 10^15 sites?

I don't think so - 2^32 sites would be just about enough to be able to
handle, 2^35 easily enough, and 2^38 would allow enormous amounts of room.
That's 30 or so sites for each human on the planet sometime way out in
the future (allowing for population explosion beyond ecological limits
probably).

There's plenty of space in IPv6 site local addressing to stick a globally
unique site number (allocated non hierarchically) if that's what the world
decides to do, this is not an issue that we need to concern ourselves with.

The more I think of it the more I think this might be a sane solution to
several problems.   Doing this would (at an adminstrative cost for sure)
give sites the reasonably permanent identification that has been lacking since
we started on forcing renumbering in IPv4 (and which is continued with IPv6
global addresses - for understandable reasons).   The existance of a known
identifier that you can keep essentially forever just might be a benefit worth
the cost (regardless of it not being useful for global routing).

kre

---

From: Jim Bound <[email-masked]>
Date: Thu, 02 Mar 2000 12:01:00 -0500

>and now it has grown to 10^15 sites?

Not defending it but asking.  I think it sounds like overkill but can't
prove it !!!

>the future (allowing for population explosion beyond ecological limits

Seems right to me too.

>decides to do, this is not an issue that we need to concern ourselves with.

I agree.

>the cost (regardless of it not being useful for global routing).

Good point I think to make this happen documenting benefits like this
will go a long way with the working group and those who care too.

/jim

---

From: Steve Blake <[email-masked]>
Date: Thu, 02 Mar 2000 23:27:17 -0500

> Whats your response to this Steve B.?
I don't thing all site ids must be globally unique.  Allocating locally
assigned site ids randomly out of a >= 32 bit range should reduce the
probability of collision in the scenario you describe above below what
anyone would reasonably care about.

I do think there are a couple of scenarios where truly globally unique
site ids would be useful.  One involves communication among a set of
sites (ex/ extranet partners) where stable addresses are desired so
that TCP sessions can survive upstream provider renumbering, for instance.
The sites could build a topology over a tunnel mesh, and any TCP session
would survive provider renumbering as long as new tunnels came up before
the sessions timed out.  Alternatively, the sites could negotiate for the
provider to route the site local prefixes directly.
  
The other scenario is Fortune 500 multihoming.  In this case the site
local is essentially a portable prefix routed globally.  Routing portable
addresses doesn't scale so this would be limited to those customers willing
to $pay$.

If your proposal goes forward, I would suggest that you consider setting
aside a large site id block that could be used someday for global
assignment.  Let the market decide whether these will ever be allocated.

Regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake                  <[email-masked]>
Ericsson IP Infrastructure                  (919)472-9913
--------------------------------------------------------------------
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]
--------------------------------------------------------------------