[bcop] Deaggregation by enterprise LIR document

On 24 Oct 2014, at 11:21, Jan Zorz @ go6.si <jan at go6.si> wrote:

> Author chose the RFC format and this is ok. We still don't have a "prescribed" format for BCOP documents in our TF and this is also ok - everyone can choose his/her own format and way of putting the content into documents - so don't be shy...

I used the draft format (which looks like an RFC) because I also want to discuss this in the IETF. Here are the main parts of the text:

Abstract

The use of IPv6 addresses by large organizations doesn't fit the commonly used PA/PI dichotomy.  Such organizations may hold a large address block which is deaggregated into subprefixes that are advertised by subunits of the organization.  This document proposes a set of best practices to allow this deaggregation to be controlled through filtering so that on the one hand, the size of the IPv6 global routing table isn't unduly inflated, while on the other hand organizations that seek to deaggregate a large IPv6 address block don't see their reachability limited by remote filters.

1.  Introduction

Generally, two classes of global unicast address prefixes are recognized: provider aggregatable (PA) and provider independent (PI). PA prefixes are the prefixes advertised into the global routing table by ISPs, covering the addresses used by multiple customers of that ISP.  PI prefixes are the address blocks used by a single organization.

However, there is a third class of addresses: the addresses used by large organizations with subunites that independently connect to the internet.  An example are multinational corporations.  Another are national governments.  Such organizations often desire a single IPv6 prefix so the addresses used by subunits are easily recognized as being part of the larger organization in firewalls and router filters.  As such, many of these organizations become "enterprise LIRs" (local internet registries) at one or more of the five regional internet registries (RIRs) that distribute IP addresses.  However, unlike regular LIRs (ISPs), they are not in the business of moving IP packets between locations, and as such different locations or subunits advertise deaggregates (subprefixes) of the organization's LIR PA prefix, often to different ISPs.  This advertisement of deaggregates would be unexpected from regular LIRs, and as such, the deaggregates may be filtered.

Currently, the IPv6 global routing table is small and in no immediate danger of growing beyond what today's routers can handle.  However, without some of the limitations that are present in IPv4, the IPv6 routing table could conceivably grow at a high rate for decades to come, and would then at some point become hard to manage.

This document proposes two mechanisms that will allow organizations that seek to deaggregate an enterprise LIR prefix to enjoy the same level of connectivity as users of PI and PA space while at the same time limiting the impact of this practice on the IPv6 global routing table.  The first mechanism is the establishment of an "aggregate of last resort" (AoLR), the second mechanism is a set of communities that allow deaggregates to be filtered in some parts of a network without loss of reachability.

This document is meant to start a discussion.  As such, it may be split into several documents, and/or the venue for discussion and eventual publication is subject to change.

2.  The aggregate of last resort service

The assumption is that an enterprise LIR allocates addresses from a single block to different organizational subunits, and that these subunits advertise those smaller blocks to the ISPs they use to connect to the internet, where different subunits use different ISPs. For reasons of cost and routing efficiency it's not possible or desired to use an internal network between the subunits or locations to transport traffic to/from the internet from one organizational subunit to another.

One way to run such a network would be for the enterprise to advertise its aggregate in a small number of locations.  The traffic is then delivered to those locations, and then from there sent back to an ISP that has a path to the subunit in question.  However, this has the downside that traffic has to pass through one of the locations advertising the aggregate, using up additional bandwidth and possibly incurring long detours.  For instance, if an organization advertises its prefix in Europe then a third party in the US that sends traffic to one of the organization's offices in the US may see its traffic cross the Atlantic twice.

The solution is to ask one or more ISPs to advertise the aggregate—preferably ones with a large geographic footprint.  By default, networks hand over traffic to a remote network as soon as possible ("hot potato" routing), so in this case the traffic just has to flow to the closest location where the ISP in question has a presence.  If that ISP then connects to an ISP serving the organizational subunit in question, the traffic can be handed over between the two ISPs at the nearest location where they interconnect.

This way, deaggregates only have to be carried by ISPs providing the aggregate of last resort service and the ISPs connecting subunits of the organization.  Because the organization has customer - service provider relationships with each, presumably those ISPs will not filter the deaggregates.


The rest of the document talks about encoding GPS coordinates into BGP communities, which gets a bit detailed.

Iljitsch