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

From: Jim Bound <[email-masked]>
Date: Tue, 29 Feb 2000 22:49:02 -0500

Francis,

Thanks for you input we will consider it as we work out the details.

/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: Thomas Eklund <[email-masked]>
Date: Fri, 3 Mar 2000 11:28:46 +0100

Just keep in mind that in the future a cellphone will probably be a mobile
IPv6 router with bluetooth link so all the other devices connects via the
phone over bluetooth to the Internet and they want an IP address for their
interfaces on the bluetooth device like a palm pilot... Because if you have
proxy functinality in the phone then it will probably be to big...
In other word if the mobile phone/router autoconfigures it neigbouring
devices it needs at least 1 bit for the router advertisements... And
bluetooth is master/slave based so it fits the ND model very good...:-)

Just a reminder if people start assigning site local addresses from the
global addrresses

/Thomas

> -----Original Message-----
> From: Steve Blake [mailto:[email-masked]]
> Sent: Friday, March 03, 2000 5:27 AM
> To: Jim Bound
> Cc: [email-masked]
> Subject: Re: Another way to support Site-Local Addresses 
> 
> 
> 
> Jim Bound <[email-masked]> wrote:
> 
> > 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.?
> 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.  
> 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

---

From: Scott Bradner <[email-masked]>
Date: Sat, 4 Mar 2000 14:38:16 -0500 (EST)

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

from RFC 1726

5.1 Scale

   CRITERION
      The IPng Protocol must scale to allow the identification and
      addressing of at least 10**12 end systems (and preferably much
      more).  The IPng Protocol, and its associated routing protocols
      and architecture must allow for at least 10**9 individual networks
      (and preferably more).  The routing schemes must scale at a rate
      that is less than the square root of the number of constituent
      networks [10].

      . . .

      We note that one of the white papers solicited for the IPng
      process [5] indicates that 10**12 end nodes is a reasonable
      estimate based on the expected number of homes in the world and
      adding two orders of magnitude for "safety".  However, this white
      paper treats each home in the world as an end-node of a world-wide
      Internet.  We believe that each home in the world will in fact be
      a network of the world-wide Internet.  Therefore, if we take [5]'s
      derivation of 10**12 as accurate, and change their assumption that
      a home will be an end-node to a home being a network, we may
      expect that there will be the need to support at least 10**12
      networks, with the possibility of supporting up to 10**15 end-
      nodes.