> So we have a site with a globally-routable /48 prefix. Are you saying
> that instead of using site-local addresses in addition to its global
> addresses, the site could use a second /48 global prefix that is not
> globally routable and is filtered at the site boundary?
absolutely.
> This would be silly. It would be just like site-locals except with a
> non-standard prefix.
no, the prefix should be standardized.
> It would work worse than site-locals because
> Default Address Selection wouldn't work properly
Default address selection doesn't work properly anyway, partially because
it favors SLs over globals, and partially because the idea that you can
expect a default address selection rule to work in the absence of information
about the app's requirements, and to do the right things with scoped
addresses, is naive.
> and because of Keith's
> issue of distributed apps that do referrals - those apps wouldn't be
> able to distinguish the two kinds of addresses to do the right thing.
sure they would be able to distinguish them, because the prefix would
be standardized. however "the right thing" is simply to favor
routable globals over non-routable globals but to try all of them -
that way, if two nodes don't manage to connect, it's either because
the net is broken or the net is prohibiting the connection - either
way it's beyond the the app's control. the app is able to do everything
that can possibly be done and with almost zero additional complexity.
compare this to the SL case where the app either has to
a) artifically limit connectivity by filtering SLs when it's not sure
that nodes could connect using them, OR
b) include potentially SLs in referrals
define an addressing scheme for all nodes used by the app
whenever connecting to an SL address check to see whether you're
really connecting to the node you think you're connecting to
and perhaps implement routing across SL boundaries for the case
where the customer demands that the app support it
(which is quite often the case - people do expect apps to work
across site boundaries)
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
