> Pekka Savola wrote:
> > On Tue, 29 Oct 2002, Brian Haberman wrote:
> >
> >>>Note that KAME only supports this through manual configuration (and a
> >>>fix) -- clarified in off-the-list discussion.
> >>>
> >>>To be compliant with the paragraph:
> >>>
> >>> Routers must not forward any packets with site-local source or
> >>> destination addresses outside of the site.
> >>>
> >>>Note: it does not say 'packets from the site' (implying configuration of
> >>>the site) but 'with site-local source'. That strongly implies explicit
> >>>configuration will not satisfy.
> >>
> >>I don't read it that way at all. I interpret that to mean, if the
> >>router is configured as a site-border router it must not forward those
> >>packets out of the site.
> >
> >
> > That kind of interpretation is easy (== activation logic in the
> > implementation is simple) , but really, totally useless I believe.
>
> That depends on the model you believe. If we take Margaret's proposal
> that, by default, a node is in one site (you treat SLs as globals) then
> explicit config is needed to have a border router. In this scenario,
> the site-local zone ids are all the same.
>
> The other case is where each interface is in different site (that makes
> SLs equivalent to link-locals) and the site-local zone ids are all
> unique.
There is also the case where the number of sites < number of interfaces
and number of sites != 1.
e.g.
interfaces 1 and 4 are in site 1
interfaces 2 and 5 are in site 2
interface 3 is in site 3
You have to allow SL traffic between 1 and 4 also between
2 and 5 but not between any other combination of interfaces.
Mark
> >
> > The promise of using site-locals is that they will not propagate globally.
> >
> > Routers must make sure they don't do that, even without being configured
> > as site-border routers.
>
> That would require routers to always act as a site border router.
>
> >
> > If this wasn't true, nobody should be able to use site-locals even without
> > relatively clean conscience, as nobody could be sure there _is_ a router
> > that's blocking illegally-sourced site-locals from coming to my site or
> > vice versa.
> >
> > The paragraph requires clarification for sure.
>
> How about removing it?
>
> >
> >
> >>The behavior is as defined in Section 5 of the scoped addr arch which
> >>is all interfaces are in the same site, unless explicitly configured
> >>by an administrator.
> >
> >
> > Scoped arch draft is irrelevant from the perspective of addrarch
> > (independence) IMO.
>
> What I meant is that any discussion similar to that paragraph should
> be in the scoped addr arch.
>
> >
> >
> >>>1) node just blindly configures fec0::1 and starts sending traffic using
> >>>it, testing how far it will go.
> >>>
> >>>A valid scenario here could be that site-locals would be used inside one
> >>>link only -- no config at all in the router -- but the route must disallow
> >>>propagation of site-locals through default route if something fails.
> >>
> >>That does not follow from the discussion in scoped addr arch. Of
> >>course, this should be clarified in addr arch when we decide on the
> >>SL content of that document.
> >
> >
> > Better: _addrarch_ shouldn't say anything at all like that because we
> > don't know how to do it (or can't write it down).
>
> Agreed.
>
> >
> >
> >>>You may ask: how is this possible? we don't have any site-border
> >>>discovery mechanisms?
> >>>
> >>>I say: exactly, that's why the paragraph is so ridiculous!
> >>>
> >>>The only easy and compliant implementation I could think of would be
> >>>discarding all site-locals unless some links are explicitly configured to
> >>>be part of a site.
> >>
> >> From the discussion I have read, it seems that it would be more that
> >>we are assuming that all interfaces are in the same site unless
> >>explicitly configured.
> >
> >
> > The risk of site-local leakage is _way_ too big that way.
>
> My statement is based on the proposal that site-locals be restricted
> to disconnected networks.
>
> Brian
>
>
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [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]
--------------------------------------------------------------------
