filtering /48 is going to be necessary

Owen DeLong owen at delong.com
Sat Mar 10 04:41:00 UTC 2012


This varies from RIR to RIR.

In the ARIN region, you can get assignments or allocations for Multiple Discreet Networks, but, ARIN will often register them as an aggregate in the registration database, so...

In the RIPE region (which is where I believe Sander is), only aggregates are available to the best of my knowledge.

Owen

On Mar 9, 2012, at 3:40 PM, George Herbert wrote:

> If the LIRs cannot get separate allocations from the RIR (and separate
> ASNs) for this usage, something is wrong.
> 
> We want to make things as simple and efficient as possible, but no
> simpler or more efficient, because the curves go back up again at that
> point, and we all suffer.
> 
> 
> -george
> 
> On Fri, Mar 9, 2012 at 3:32 PM, Sander Steffann <sander at steffann.nl> wrote:
>> Hi,
>> 
>>> 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.
>> 
>> 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.
>> 
>> - Sander
>> 
>> 
> 
> 
> 
> -- 
> -george william herbert
> george.herbert at gmail.com





More information about the NANOG mailing list