nanog mailing list archives
Re: filtering /48 is going to be necessary
From: Jimmy Hess <mysidia () gmail com>
Date: Fri, 9 Mar 2012 17:20:03 -0600
On Fri, Mar 9, 2012 at 1:31 PM, Owen DeLong <owen () delong com> 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 block. 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
-- -JH
Current thread:
- Re: filtering /48 is going to be necessary, (continued)
- Re: filtering /48 is going to be necessary PC (Mar 09)
- Re: filtering /48 is going to be necessary Bernhard Schmidt (Mar 09)
- Re: filtering /48 is going to be necessary Owen DeLong (Mar 09)
- Re: filtering /48 is going to be necessary Bernhard Schmidt (Mar 09)
- Re: filtering /48 is going to be necessary Owen DeLong (Mar 09)
- RE: filtering /48 is going to be necessary George Bonser (Mar 09)
- Re: filtering /48 is going to be necessary Owen DeLong (Mar 09)
- RE: filtering /48 is going to be necessary George Bonser (Mar 09)
- RE: filtering /48 is going to be necessary George Bonser (Mar 09)
- Re: filtering /48 is going to be necessary Owen DeLong (Mar 10)
- Re: filtering /48 is going to be necessary PC (Mar 09)
- Re: filtering /48 is going to be necessary Jimmy Hess (Mar 09)
- Re: filtering /48 is going to be necessary Sander Steffann (Mar 09)
- Re: filtering /48 is going to be necessary Jimmy Hess (Mar 09)
- Re: filtering /48 is going to be necessary George Herbert (Mar 09)
- Re: filtering /48 is going to be necessary Owen DeLong (Mar 09)
- RE: filtering /48 is going to be necessary Leo Vegoda (Mar 09)
- Re: filtering /48 is going to be necessary Owen DeLong (Mar 09)
- Re: filtering /48 is going to be necessary Joel jaeggli (Mar 09)
- Re: filtering /48 is going to be necessary Randy Bush (Mar 09)
- RE: filtering /48 is going to be necessary George Bonser (Mar 09)
- Re: filtering /48 is going to be necessary Joel jaeggli (Mar 09)