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