Subject: My Questions on Site-Locals

From: "Sellers, Julian P" <[email-masked]>
Date: Thu, 3 Apr 2003 12:31:41 -0600

Keith's multi-party applications won't work if the parties refer non-global
addresses to each other.  Margaret recommends that everyone use global
addresses, but filter certain prefixes at various administrative boundaries.
How, then, do Keith's applications know which addresses have global scope
and which do not?

A tacit assumption seems to be that applications will not have to deal with
link-local addresses.  I'm aware of the recommendation not to place
link-local addresses in the DNS, but I know of no prohibition of
applications communicating via link-local addresses.  If they may do so, is
this less problematic than using site-local addresses?

Since I know nothing about filtering in routers, can someone tell me why
filtering on FEC0::/10 is more complex than filtering on prefixes chosen by
the local administrator(s)?  And concerning Margaret's point on nesting
sites, could routers not filter within FEC0:0:subn:etid::/64 addresses?

Again citing the disclaimer re my lack of knowledge, the
filtering-on-locally-designated-prefixes method seems unwieldy compared to
the filtering-on-well-known-scope method.  Implementations can allow an
administrator to configure address scope preferences using the well-known
scopes.  Nodes (applications) on the same subnet could then have addresses
of different scopes.  This would be cumbersome at best without well-known
scopes.

Some have complained about the complexity of always disambiguating
site-local addresses by means of their zone identifiers.  This seems
insignificant to me; the same must be done for link-local addresses.  The
zone identifier accompanies the address wherever it goes.  Right?

I understand that sites that merge would have to renumber if their subnet
IDs conflicted.  Some have stated that a disconnected site using site-local
addresses must renumber when it connects to the Internet.  Wouldn't the site
simply add the new prefix(es), and the nodes use the new addresses and/or
site-local addresses based on local configuration?  Connections using
site-local addresses would not be affected by connection to the Internet.

Since so many wise people object to site-local addressing, the problems must
be greater than they appear from behind these cube walls.  But I have not
seen answers to these questions (or maybe I failed to comprehend).  I look
forward to having my horizons expanded.

Julian Sellers
Enterprise Server Communications Engineering
Unisys Corporation

--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Apr 2003 15:14:52 +0200

Julian, I think the one problem we need to avoid is

  What do you do when two occurrences of FEC0::0001/64 exist
  within a single routing domain?

This is the problem created by the current SL definition when
two 'sites' are united by merger or VPN and they both happen
to have a subnet #1.

We shot ourselves in the foot by creating this problem in the
initial IPv6 addressing architecture.

    Brian

---

From: "Christian Schild (JOIN Project Team)" <[email-masked]>
Date: Fri, 4 Apr 2003 15:53:44 +0200

Brian,

> initial IPv6 addressing architecture.

Do we really have to think about this? Is this an architectural design
problem? Is it enough to drop the whole concept?

I think it would be enough to come up with a BCP how to subdivide bits 
11-48 in an intelligent way to prevent above. There were lots of ideas how 
this could be done on this list.

Christian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Apr 2003 16:20:16 +0200

> problem? Is it enough to drop the whole concept?

The architecture today specifies ambiguous subnet prefixes.

> this could be done on this list.

But that is not what the addressing architecture describes today,
and that is where my problem is, not with some future specification.

   Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 04 Apr 2003 09:38:12 -0500

Hi Christian,

>this could be done on this list.

We do need to define some method(s) to produce unique, local,
provider-independent addresses (i.e. MAC address-based or
registry-based).

But, I don't think that we want those local addresses to have
the semantics associated with site-local addressing, so I don't
think that we should allocate them from the current site-local
space (FECO::/10).

Most of the restrictions and complexities associated with scoped
addresses in the scoped addressing architecture (can't be nested,
can't overlap, need zone IDs to disambiguate, etc.) are required
_because_ site local addresses are ambiguous.  If you remove the
ambiguity, why would you want to live with the restrictions?

Let's deprecate the current site-local prefix, and define a
non-ambiguous model for local addressing.

Unique local addresses can, generally, be treated just like any
other addresses.  As long as we make sure that our method of
creating uniqueness retains the property that a longest prefix
match will result in using local address to reach local addresses
and global address to reach global addresses, we shouldn't need
any special handling for these addresses in hosts or routers.

Margaret