Tony Hain writes:
> Michael Thomas wrote:
> > So I have a question for those who support
> > connected site locals: what would prevent a new
> > RFC from updating Brian's wording for site locals
> > (if that's the right thing)?
> >
> > I say this because it seems to me that there's a
> > lot of issues being conflated in these arguments
> > and what's sort of frightening to me is that they
> > need to be teased apart. In particular, the desire
> > for provider independent addressing seems to
> > factor in here fairly largely too, and I wonder if
> > the better part of valor might not be to get
> > together a BOF which focuses on the actual real
> > life requirements here. It's possible that site
> > locals in the end might make sense here, but it's
> > also possible that it can be done other ways too
> > (or that the entire problem is totally intractable
> > which is the way it looks to me now).
> >
>
> Some of the uses for SL would be better served by PI addresses, but not
> all.
Well, that's sort of my point. The fact these are
intertwined in many cases seems like a good reason
for prudence. If PI addresses could be made to
work, a *lot* of the motivators for SL would go
away and we could then consider the remaining
cases independently. However, if we allow the
current language it's going to be even more tangled
up if we ever get PI's with an even bigger mess
to sort through, not to mention the spectre of
real deployment too.
> Take the case of a 20,000 node network where half are allowed global
> access and half are not. It is much more complex to sort through a
> 10,000 node list per packet for access filtering than it would be to
> have two entries, SL deny & PA allow. Yes the list of which 10,000 nodes
> are allowed the global prefix has to be maintained, but it can be
> applied according to allocation policy rather than per packet
> processing.
Why couldn't you use a reverse VPN? Ie, an SA is required
between you and the inside edge for external access?
Mike
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
