BCP for multisite multihoming

Thomas Narten narten at us.ibm.com
Tue May 22 18:06:41 CEST 2007

Pekka Savola <pekkas at netcore.fi> writes:

> On Tue, 22 May 2007, Thomas Narten wrote:
> >> 2) Obtain a single /32, and announce /34s (or /36, or /40 or
> >> whatever, if they want to leave room for expansion) from each POP.

> FWIW, at least in RIPE land, the policy still says

> "... by advertising that connectivity through its single aggregated 
> address allocation."

> .. which IMHO requires that you must advertise the aggregate.  It may 
> also be read so that you shouldn't advertise anything else than the 
> aggregate but other interpretations are also possible.

And the original intention was to ensure that an aggregate could be
advertised and that it would work. That is, one couldn't just get a
/32 and then start handing out longer prefixes to anyone who asked,
and then have those longer prefixes in effect be unroutable (because
there was no connectivity via an aggregate) with all of the individual
owners then expecting their individual prefixes to be routable.

And yes, I've heard that the above wording has been interpreted to
mean "do not deaggragate", though that was never the intention. (And,
RIRs would never agree to wording along those lines because it is out
of scope for RIR policy to tell ISPs what they can and cannot route.)

> Personally I don't have a huge problem with people who advertise more 
> routes like above, but I do have a problem if they do not provide a 
> single aggregated allocation that will provide "default" connectivity 
> to operators who do filter more specifics.

I think this is a much more pragmatic starting point than "do not
deaggreate, period."


More information about the ipv6-ops mailing list