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