Subject: Another way to support Site-Local Addresses

From: Jim Bound <[email-masked]>
Date: Fri, 25 Feb 2000 12:19:24 -0500

Is anyone interested in working on such a draft as below with me.  We
don't have to have it ready until IETF 48 in Pittsburgh so we have time
to work on it.

Objective of the Draft:

Using Kre's archtype model that we can embed site-identifiers in IPv6
addresses we develop a draft that proposes to use 2bytes of the IPv6
adddres (could use 1byte if we believe sites will not be greater than
256) which would heuristically determine based on net admin org/site
administrator what the site identifier would be based on the adddress.

Rules to try and achieve:

  1. Site-Local addresses are to contain a site-identifier which is 
     unique across all sites of an organization.
  2. Orgs cannot connect a new site from mergers or the like to 
     the existing site "set" without first renumbering those site
     addresses.

Benefits of working on this draft:

  1.  Simplify the concept of site-identifier for IPv6 Addresses so
      it is inherent in the address of an interface.  We should follow
      the rules specified in draft-ietf-ipngwg-scoped-routing-02.txt by
      Brian Haberman.
  2.  Permits what we know now as Multisited nodes to not have to
      replicate data or other identifiers for sitelocal addresses
      the site-identifier part would be unique across an Organization.
      I am here assuming site is below organization as an abstraction.
  3.  Applications for IPv6 do not have to be affected by sitelocal 
      addresses.  This part stays transparent to IPv6 at least.
  4.  getipnodebyname is not dead and we do not need to parse 
      site-identifiers on command lines or in our APIs.  Clearly
      though we move to recommend to use getaddrinfo for other 
      benefits.

I can't do this by myself and am looking for co-authors.

I think it imperative we do this work and present it as an alternative
to the current direction to resolve this within the IETF.  

p.s. Kre - Love to have you help us with this if you still think its a
good idea?

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: Steve Blake <[email-masked]>
Date: Mon, 28 Feb 2000 10:13:46 -0500

>      the existing site "set" without first renumbering those site

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?

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake                  <[email-masked]>
Ericsson IP Infrastructure                  (919)472-9913

---

From: Jim Bound <[email-masked]>
Date: Mon, 28 Feb 2000 12:04:36 -0500

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

regards,
/jim

---

From: Steve Blake <[email-masked]>
Date: Mon, 28 Feb 2000 15:40:51 -0500

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

Regards,

---

From: Jim Bound <[email-masked]>
Date: Mon, 28 Feb 2000 19:22:28 -0500

Steve,

That was a mouthful and an idea I need to go off in a corner and put my
engineering hat on and think about... If I agree and it will work that
is pretty awesome.

thanks
/jim

---

From: Robert Elz <[email-masked]>
Date: Tue, 29 Feb 2000 17:23:51 +1100

Date:        Mon, 28 Feb 2000 15:40:51 -0500
    From:        Steve Blake <[email-masked]>
    Message-ID:  <[email-masked]>

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

That has been suggested before, and certainly hasn't been ruled out.

How to assign these ids (random from a large space and rely upon
probabilities, assigned from a registry, ...) was something that was
never really discussed, because we didn't ever get to the stage of
agreeing to do any kind of id.

In hindsight, that might have been a mistake - leaving the details to
later and attempting to agree upon a general principle leaves too much
room for feelings of unease "but how will...  that isn't specified yet ...
then Idon't like this idea much, drop it" type responses.

Perhaps this time, if this is to go round the mill one more time, it
will be better to do a complete spec, starting with the trivial details,
and not worry so much about wasting time on something which might end
up in the dustbin later.

kre

---

From: Francis Dupont <[email-masked]>
Date: Tue, 29 Feb 2000 09:59:48 +0100

In your previous mail you wrote:

=> I am *not* in favor of this if the site-local address format is
not changed too in the address architecture document, ie. I think
it is bad to have "internal" and "external" formats for site-local
addresses (this was tried for link-local addresses and has been shown
to be a bad idea).
 I have nothing against an embedded site-identifier if this is in
addressing specs and site-identifiers are (near) globally unique
(mobility needs this).

=> this already exists for site-local socket addresses (sin6_scope_id).

   
=> for me this is a last attempt to save getipnodebyname() but
getipnodebyname() was killed when you decided to not modify it
(in fact it is killed only for multisited nodes).

Regards

[email-masked]

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 29 Feb 2000 08:35:54 -0600

> architecture?

Such a small nose ... such a big camel!