Subject: (ipv6) The meaning of "site"

From: "Michel Py" <[email-masked]>
Date: Fri, 1 Nov 2002 20:08:04 -0800

Mark,

>>> Mark Smith wrote
>>> Obviously my last two models don't really fit the idea that
>>> site-local addressing is to cover a single geographical site.
 
>> Richard Draves wrote:
>> Why do you think that site-local addressing is tied to
>> geography in any way?

> A few reasons :
> 1) because of the name ?! the word "site" in common English
> has geographical connotations.
> 2) the explanation in the Scoped Addressing Architecture
> RFCs / drafts : draft-ietf-ipngwg-scoping-arch-04.txt
> [snip]

While I fully agree with your reading of the RFC and the English
connotation of the word "site", it appears to be an unwritten convention
that says that a site is a /48. This leads to some semantic confusion in
the case of organizations that get a /48 and are spanned over several
physical locations that could be separated by hundreds or thousands of
miles.

When discussing multihoming topics, we refer to a multihomed multi-site
organization as an organization that needs to announce different
prefixes for each location (which kinda conflicts with the "site = /48"
rule for such organizations that get a single /48) opposed to a
multihomed single-site organization.

In the old days where the usable space for site-locals was a /48, I
would have agreed that site-locals would need to include some notion of
geography for large organizations that requires more than a /48.

However, since today the usable space for site-locals is /10, it is
likely that some organizations, even if their address space is multiple
/48s, will configure only one site using site-local addresses.

I am not lobbying for any definition of "site" (although I would not
mind a more precise definition) but it appears to me that the common use
for the word has slipped from the way it is written in the part of the
RFC you quoted closer to the administrative boundary of an organization.

Michel

--------------------------------------------------------------------
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: Mark Smith <[email-masked]>
Date: 02 Nov 2002 16:58:32 +1100

Hi Michel,

> physical locations that could be separated by hundreds or thousands of

Agreed.

The 54 bits for subnet allocation in a site-local address tends to
strongly suggest that a site-local addressing boundary is not a
geographical boundary.

The huge number of subnet bits also tends to suggest that within the
administrative boundaries of a connected network, only one instance of
SL addressing should exist.

For simplicity reasons, my IPv6 network would have a single instance of
site-local addressing, and if I had to merge it with another IPV6
network using site-local addressing, I would be working towards
achieving a single site-local addressing instance again, as part of the
process of merging the networks. Merging the two networks won't be
hassle free, but at least a number of IPv6's features will make it a lot
less of a hassle.

However, I believe a lot of non-IPv6 ML subscribed people (eg your
typical net admin) would take the name "site-local" (and the associated
definition) literally, ending up with a lot of separate SL address space
instances in their network. They will not like the network addressing
complexity IPv6 appeared to have forced upon them.

I think there could be value in coming up with a more appropriate name
and definition. 

While the name "site-local" is obviously not the only cause of confusion
and concern about site-local addressing, I don't think it helps.

If a more expressive name and definition is decided upon, it can also 
help make a number of related questions easier to answer.

For example, people will understand better where multi-site routers
typically would or wouldn't be used, which makes questions such as
whether multi-site support should be a requirement of a router
implementation simpler.

Thanks,
Mark.