filtering /48 is going to be necessary

Jimmy Hess mysidia at
Fri Mar 9 17:20:03 CST 2012

On Fri, Mar 9, 2012 at 1:31 PM, Owen DeLong <owen at> wrote:
> Let us not forget that there is also the issue of PA /48s being advertised (quasi-legitimately) for some end-user organizations that are multi-homed but choose not to get PI space. It is not uncommon to obtain a PA /48 from provider A and also advertise it from Provider B.

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.

Scenario (1) The end user org  obtains PI address space from a RIR,
and originates their assigned prefix.  The end user org originates
their RIR assigned exact prefix and announces to their upstreams,  who
filter and accept from the end user only routes containing a NLRI of
their exact prefix,  with the prefix length used by the RIR for the PI
blocks from which their assignment(s) had been made.

(2) Same as (1) but The RIR provides some expedited process for the
ISP to obtain and transfer PI space and  AS numbers for the purpose of
their customers'  multihoming - in one step,  so the end user does not
have to figure out the RIR application process  --  E.g.  some RIR
process provides the ISP an option to create PI blocks on demand in
addition to their PA block;  the ISP will not know in advance what AS
number or PI block will be allocated,    the ISP must follow the RIR
rules for the assignment of PI blocks,  and educate their user as
needed,  obtain a signed RSA with the End user, obtain written proof
the user has two ISPs, has provided a network design that includes
multihoming, and a written sound justification for the multi-homing
or the meeting of a criteria requiring multihoming,  provide the End
User's billing contact info to the RIR,  the ISP having pre-payed
registration fees to the RIR  --- should the end user stop using the
ISP that created the block,  responsibility for the PI block and AS
numbers reverts to the end user org.

(3)   The  end user org  who is multi-homed picks a 3rd party
organization to assign to the end user from their PA block.   The 3rd
party org's overall  PA block is multihomed with diverse connectivity,
 and the end user inherits the multihoming  of the 3rd party's PA

  The 3rd party AS is the sole AS that originates  the prefix in the
form of the entire PA block into the DFZ   and then routes the
individually assigned end-user block to the End user  through private
arrangement or peering  with the  End user orgs'  upstreams,

(IOW: the multi-homed users block does not appear as a globally
visible more-specific/deaggregate)

(4) Any of the other methods of achieving multi-homing,  such as
originating an NLRI with a longer prefix than the RIR delegation,
should be rejected by filters.

> Owen

More information about the NANOG mailing list