Keith Moore wrote:
> > Scope and Address selection:
> I think it's fairly arbitrary to distinguish "internal-only" applications
> from "applications that may include external hosts". How will the
> application know which category it is in? What if different components
> of the application have different ideas about this?
Any application involving transactions between two hosts that doesn't want
to pass name or address information to a third party shouldn't have
problems. In this situation, it's probably safe to pick a site-local if
it's mutually available.
The problem comes if machines A and B start talking, and then machine B
decides to forward A's address (or name) to C, who is outside the site. If
B forwards a site scoped identifier, we've got a problem.
The simplest solution I can see is to make it a user problem - if you want
global connectivity, connect using a global name and thus force a global
address. See notes on DNS.
Alternatively, an application that tries to forward a scoped identifier to a
target outside scope could:
(1) Fail
(2) Attempt to re-establish the session with a more suitable scope.
> > Note: This is IMO the real sticking point of site locals. Globally
> > unique non-routeable addresses have exactly the same problem.
>
> I disagree here for what may be subtle reasons. forgive me for trying
> to explain them again.
>
> My assumption is that if sites expect apps to use site-locals (and
> especially if we don't provide them with good alternatives) then
> customers will demand that many apps be able to operate across site
> boundaries using those addresses, adding considerable complexity to
> those apps and degrading their performance and reliability.
Hmm. I think this assumption is not as robust as it should be. The
presence of a site local prefix could mean:
- There is no global connection, at which point the very concept of
operating across site boundaries is meaningless.
- There is also a global connection, at which point the address selection
rules should use this for external connection.
The case of two disconnected sites merging is handled in the discussion on
renumbering.
IMO, we want to push site local addressing as a (2nd line) mechanism for
internal addressing independent of the global address space. At the point a
network connects to the global internet, a set of global prefixes should be
distributed also. The address selection rules are in place precisely to
deal with this multi-addressed situation.
In fact, once global connectivity exists, site local addresses should be
deprecated and eventually removed, unless the allocating authority (human or
automated) has reason to consider that the global prefix allocation is
"transient".
> OTOH if non-routable globals are available (except perhaps in isolated
> sites where it doesn' t matter) then it becomes much more reasonable for
> many apps to simply use global addresses whenever they are available.
> The app no longer needs to define its own addressing (at least not for
> the purpose of working around SLs). And it is no longer the app's
> responsibility to know about sites or to try to route between those
> sites.
> If the network designers had wanted to provide a connection between
> those networks they would have done so.
For clarity, let's talk about restricted scope and global scope [unique]
addresses. (Site local are restricted scope non-unique addresses.)
I must be missing something. I read this several times, and it still seems
to be one of two situations:
- If apps can tell the difference in scope, then there is functionally no
difference a restricted scope unique or non-unique address.
Except:
- restricted scope unique addresses can site merge, but I have already
suggested that all sites should be configured to handle renumbering
(which is particularly necessary if global prefixes may come and go).
- non-unique addresses don't require a global allocating authority.
- If apps can't tell the difference, then your unique restricted scope
address is from the apps' perspective an unrestricted scope address, which
could lead to some "unexpected" failures due to filtering.
Alternatively, you could instantaneously deprecate all those restricted
scope unique addresses as soon as a global scope address became available,
but that is exactly the reason a network might run site locals and globals
in parallel - to maintain address persistence independent of a dynamic
global address.
What have I missed?
> However it would not really be valid for an app to assume that a
> non-routable address had a reduced scope in comparison to a
> global address, or that such an address was less likely to work.
> On a network with extensive private connections to other networks but
> lots of filtering on its connections to the public internet the app
> might do better with the non-routable address.
So not a site, but a mesh of sites with arbitrary connectivity?
At this level of complexity, why not just use globally routeable prefixes
and configure the routers and filters to pass or block packets correctly?
If the sites were truly "disconnected", or someone particularly wanted to
use a private address space in parallel to the global one, the fec0:.../48
address space has plenty of room for bits 17-32 to be used as "site
identifiers".
Note that I am /not/ working on a model of an isolated network connected to
the global internet via a proxying mechanism (think NAT). I'm assuming that
global connectivity is via true global addressing, and that hosts need to be
able to play nice in a situation where they have both site (restricted) and
global (unrestricted) scoped addresses available.
--
Andrew White [EMAIL PROTECTED]
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
