Subject: Globally unique site-locals was [repost] A few comments on Site-Local Useage

From: "Michel Py" <[email-masked]>
Date: Thu, 21 Nov 2002 20:36:15 -0800

Bill,

% Michel Py wrote:
% Rationale: ambiguity is a fail-safe for routes that leak in the DFZ
even
% though they were not supposed to and for ISPs that don't filter them
% even though they were supposed to.
% If we could add to this black hole a preconfigured prefix-list for
each
% peer that would deny FEC0::/10 ge 10 (1) that would likely be good
% enough to let ambiguity go and we would make a step towards globally
% unique site-locals.
% (1) I am thinking about something like the default deny at the end,
% except that it would be at the beginning and would be effective even
% though there is no prefix-list applied to the peer. Something that
would
% require a separate command and a confirmation to de-activate. Why
would
% one want site-locals in BGP anyway?

> Bill Manning wrote:
> per interface or per-peer? (will require a better understanding
> of default behaviour of routing protocols)
> if per-peer, which routing protocol?

That's a good question, and I'm not sure I have a good answer.
Let's try this:

Rationale 1:
This black hole to FEC0::/10 that Bob mentioned earlier is a good idea,
but it does not achieve much in practice as it would be a well-known
mechanism and the hacker would announce FEC0::/11 instead and bypass it.
What we really need is to blackhole the route itself. The same reasoning
applies if the route leak is a result of a snafu from the legit network
admin, because the route being leaked is probably going to be FEC0::/48
or some /48 within the range, which will not go into Bob's blackhole
either.

Rationale 2: Site-locals are routable within the site, which more or
less means allow with IGP, and not routable outside of the site, which
more or less means deny with BGP. I think the answer to "which protocol"
is definitely BGP, and possibly eBGP.
I have not thought the process much but I think that site-locals should
not be carried over iBGP, but over IGP only. Any takers on this?

Thought process:
I thought this as a BGP animal, so naturally it was on a per-peer basis.
The two reasons I would still lean towards this are:
- The amount of peer traffic to match against is very small compared to
the amount of generic traffic.
- Per-interface would require further processing as identifying the
traffic as being BGP, then decapsulating the packet and inspect the
actual route inside, sounds awful to me, NAT-like ALG.

In short:
> per interface or per-peer?
Per-peer.

> if per-peer, which routing protocol?
BGP, possibly eBGP only, to be discussed.

Hope this answers the question,
Michel.

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