Subject: RE: draft-ietf-ipngwg-site-prefixes

From: Richard Draves <[email-masked]>
Date: Thu, 9 Dec 1999 18:15:51 -0800

> That is, I see no relationship at all between what global prefixes
> might exist, and how they are advertised on the various links, and
> what is a "site".  My definition of a site is more along the lines of
> "all those nodes and links configured to route packets for using
> site local addresses" - where there's a block, site locals don't pass
> from this link to that one, then there is a site boundary, where there
> is no block, then the same site continues.   No more, and no less,
> restrictions than that.
> 
> As I said in an earlier message on another topic (which sort of led to
> this one) I don't think we yet really know enough about how we want to
> make use of sites, and site local addresses, to start laying down the
> rules for how they have to be used.

Maybe it's too early to lay down rules, but it's not too early to start
experimenting with different options and at least Erik's draft is a good
start for exploring one option. Can you flesh out an alternative option?

Erik's draft assumes that there is a "site prefix" and you can compare a
global destination address against the site prefix to determine if it is
within the site. Yes this restricts things but it sounds like a reasonable
assumption to me. 

In particular, if the reason you have nodes with both global addresses and
site-local addresses is to protect against renumbering (local communication
using the site-local addresses), then this assumption makes a lot of sense.
The site prefix is the prefix you got from your ISP and that might get
renumbered - it doesn't have to relate to other meanings of the word site
like administrative/protection boundaries.

Rich
--------------------------------------------------------------------
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]
--------------------------------------------------------------------