[151042] in North American Network Operators' Group
Re: filtering /48 is going to be necessary
daemon@ATHENA.MIT.EDU (Sascha Lenz)
Sat Mar 10 04:42:11 2012
From: Sascha Lenz <slz@baycix.de>
In-Reply-To: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl>
Date: Sat, 10 Mar 2012 10:41:04 +0100
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Hi all,
> Hi,
>=20
>> What should happen is this "quasi-legitimate" method of
>> multi-homing should just be declared illegitimate for IPv6, to
>> facilitate stricter filtering. Instead, what should happen is the
>> multi-homing should be required to fit into one of 3 scenarios, so
>> any announcement with an IPv6 prefix length other than the
>> RIR-allocated/assigned PA or PI block size can be treated as TE and
>> summarily discarded or prioritizes when table resources are scarce.
>=20
> Splitting the allocation can be done for many reasons. There are known =
cases where one LIR operates multiple separate networks, each with a =
separate routing policy. They cannot get multiple allocations from the =
RIR and they cannot announce the whole allocation as a whole because of =
the separate routing policies (who are sometimes required legally, for =
example when an NREN has both a commercial and an educational network). =
Deaggregating to /48's is not a good idea, but giving an LIR a few bits =
(something like 3 or 4) to deaggregate makes sense.
yes, that's my point for years now - probably filter /48s from =
allocations
(because end-users CAN get IPv6 PI assignments now everywhere i think), =
but do allow some
"sub-allocations" in the DFZ for such mentioned reasons. Because for the =
latter
there are no real "nice" solutions atm. (or probably update the policies =
to be able to acquire multiples
allocations without hassle in such cases, but OTOH it doesn't=20
matter to the routing table, another prefix is another prefix)
It's much nicer to have, say, one /40 in the table aggregating some =
(routing-)separated /48 customers
than to have 200 /48 PI prefixes in that AS if each customer needs to =
get their own PI space if you
cannot split the allocation.
I thought that would be a good middle ground (combined with RIR RR based =
filters perhaps of course).
...but it seems like you even need to accept /48 from everywhere =
nowadays based on the
initial postings *sigh*
Not even I do like that, although i never was a big fan of strict =
filtering.
But it all comes down to this most likely, the internet is a distributed =
being, and RIRs
don't control routing. So /48 just will become the new /24 and some =
people will give us the good old "told you so!".
--=20
Mit freundlichen Gr=FC=DFen / Kind Regards
Sascha Lenz [SLZ-RIPE]
Senior System- & Network Architect
