Subject: [GROW] Deaggregation by large organizations

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 15 Oct 2014 14:29:25 +0200

We are all familiar with PA (provider aggregatable) and PI (provider independent) address space. But it turns out a new type of IPv6 address space is starting to show up, which I'll call organization deaggregatable (OD) address space (until someone suggests a better name).

How it works is like this: a large organization obtains a large block of IPv6 address space, either as a very large PI block or by becoming a local internet registry (LIR) and getting a regular LIR assignment directly from one of the five regional registries. However, rather than advertising that block in BGP as a single prefix, or perhaps a handful of prefixes, like an ISP would, they subdivide this block within the organization and then many subunits advertise subprefixes though different ISPs. The aggregate may or may not be advertised.

The advantage to the organization is that they have provider independent address space that they'll never have to renumber out of, as well as having a single prefix that identifies all of the organization, which makes filtering easy.

There seem to be two types of organizations that do this: geographically dispersed ones that advertise subprefixes in different locations, such as multinationals, and organizations with very independent subunits but with more limited geographical scope, such as national governments.

This practice, especially if/when it becomes more common, presents two challenges:

1. Large numbers of prefixes may show up in the global routing table. For instance, there is a number plan for all of the German government, which could potentially inject more than 5000 municipality prefixes into the global IPv6 routing table.

2. Filtering. If people want to avoid large numbers of deaggregates in their routing tables, they may employ some kind of filtering, especially if the deaggregates are very long prefixes. This means that packets are no longer reliably delivered to the place announcing a more specific prefix.

Ideally, a set of best practices would be developed that strike a good balance between the needs of large organizations and the needs of the global routing system, and allow everyone to predict the consequences of different kinds of behavior and thus avoid unpleasant surprises.

These are some of the things that could go into such best practices:

- A well-understood maximum prefix length for IPv6, similar to /24 for IPv4.

- An understanding of how the service providers that provide connectivity to multiple subunits of a large organization can work together in order to maximize availability and minimize costs for the organization, the service providers and other network operators.

- A way to provide a point of last resort where traffic for the aggregate can be sent to if more specifics are filtered.

- A set of communities that indicate whether a prefix is a more specific that is covered by an aggregate and/or is safe to filter without loss of connectivity.

- A set of communities that indicate geographical origin of prefixes so remote more specific prefixes can be filtered while local prefixes are kept.

- Guidelines for reserving address space in address plans. Is it better to have free space reserved so existing prefixes can grow, or keep reserved space together so tight prefix length filters are possible and reserved space isn't broken up into small pieces?

Please note that I'm crosspositing this to v6ops and grow initially. If the chairs have any guidance on which working group is more appropriate for this discussion, please let us know and we can drop the other one.

Also note that I haven't been following discussions in both wgs recently, so if this has been discussed previously, my apologies.

Last but not least, this treads on RIR policy. But in my opinion, this is foremost a technical matter with global implications and as such is best discussed within the IETF rather than in the five respective policy development forums.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 15 Oct 2014 13:41:10 +0100

On 15/10/2014 13:29, Iljitsch van Beijnum wrote:
> There seem to be two types of organizations that do this: geographically
> dispersed ones that advertise subprefixes in different locations, such
> as multinationals, and organizations with very independent subunits but
> with more limited geographical scope, such as national governments.

and organisations who have a requirement for traffic engineering, whether 
this requirement is real or imaginary - there are well known examples of each.

Nick

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 15 Oct 2014 14:43:45 +0200

> and organisations who have a requirement for traffic engineering, whether this requirement is real or imaginary - there are well known examples of each.

Right, we should probably add that.

Although I wouldn't expect an organization to deaggregate down to hundreds or thousands of more specifics just for traffic engineering.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 15 Oct 2014 13:46:59 +0100

> Although I wouldn't expect an organization to deaggregate down to hundreds or thousands of more specifics just for traffic engineering.

probably not no, but on the basis of visibility into IXP announcements with 
prefix analysis to see what's going on, some organisations do spectacularly 
bizarre things with no possible rational explanation.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Oct 2014 10:14:02 -0500

On Oct 15, 2014, at 7:29 AM, Iljitsch van Beijnum <[email-masked]> wrote:
> However, rather than advertising that block in BGP as a single prefix, or perhaps a handful of prefixes, like an ISP would, they subdivide this block within the organization and then many subunits advertise subprefixes though different ISPs. The aggregate may or may not be advertised.

Yuck.   Has anybody done an analysis of how this works with RPKI?   Seems like an obvious attack surface if the RPKI isn't present or isn't done right.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 15 Oct 2014 18:04:33 -0400

(man mac-mail and gmail don't play well... I'm not re-formatting this, sorry)

> We are all familiar with PA (provider aggregatable) and PI (provider independent) address space. But it turns out a new type of IPv6 address space is starting to show up, which I'll call organizati…

your OD sounds like (from reading below) like what PI is for, or ...
OD == PI, from what i can tell.

> How it works is like this: a large organization obtains a large block of IPv6 address space, either as a very large PI block or by becoming a local internet registry (LIR) and getting a regular LIR…

sure, this is what enterprises are sort of forced into in the v6
world. They MAY have a contiguous backbone behind their ISP links, or
may not. They MAY have ASN for some/all of their sites, they may not.

They have v6 address space for each office (say a /48 for instance
from a larger /<something>) and they've gotten agreement from their
various ISPs to announce the 48's to the world.

> The advantage to the organization is that they have provider independent address space that they'll never have to renumber out of, as well as having a single prefix that identifies all of the organ…

yup

> There seem to be two types of organizations that do this: geographically dispersed ones that advertise subprefixes in different locations, such as multinationals, and organizations with very indepe…

ok, not clear how the type-o-org matters here. "People do this, see
the routing table."

> 1. Large numbers of prefixes may show up in the global routing table. For instance, there is a number plan for all of the German government, which could potentially inject more than 5000 municipali…

ok <1% growth.

> 2. Filtering. If people want to avoid large numbers of deaggregates in their routing tables, they may employ some kind of filtering, especially if the deaggregates are very long prefixes. This mean…

ok, maybe.. but this depends a bunch on what upstream setup is used as
well. It seems that if there is arbitrary filtering other solutions
will work themselves out (announce aggregate, keep all sites connected
to a single/small-set of isps, etc).

it's messy, but...

> Ideally, a set of best practices would be developed that strike a good balance between the needs of large organizations and the needs of the global routing system, and allow everyone to predict the…

i feel like we sort of have that already, or we know how the global
table works and people live within those constraints.

> - A well-understood maximum prefix length for IPv6, similar to /24 for IPv4.

do we want to draw that line in the sand though? I think so far 'let
operations folks work that out' has worked out pretty well. There's no
official standard in v4, why would we want one in v6?

> - An understanding of how the service providers that provide connectivity to multiple subunits of a large organization can work together in order to maximize availability and minimize costs for the…

"cannibalize customers from your neighbors" isn't what you're looking
for here, eh?
I think TODAY there isn't a problem (nothing is broken, yet) so it's a
bit hard to talk about the 'right' answer here. (sure we could take a
guess, but...)

> - A way to provide a point of last resort where traffic for the aggregate can be sent to if more specifics are filtered.

this, to me, is the 'headquarters' facility announces the aggregate
and maintains a tunneled path to their subunits out over the world.

you could slice/dice this in a number of other ways, clearly. I'm not
sure more complexity is good though.

> - A set of communities that indicate whether a prefix is a more specific that is covered by an aggregate and/or is safe to filter without loss of connectivity.

so, add communities to global routes, because people don't strip these
in ingress as a matter of best practice? (if you don't you REALLY
should consider it, i think)

> - A set of communities that indicate geographical origin of prefixes so remote more specific prefixes can be filtered while local prefixes are kept.

we ran over the geo-prefix rat in SIDR, I don't know that running over
it again is especially great for time management. (see terry
manderson's geo-data-rpki presentations/drafts, in stockholm and 1/2
meetings after/around then)

> - Guidelines for reserving address space in address plans. Is it better to have free space reserved so existing prefixes can grow, or keep reserved space together so tight prefix length filters are…

uhm... this is a bit of a religious debate isn't it? You'd also be
imposing the 'one true way' on people who generally have issues with
that sort of thing. Not to mention how does excel manage ipv6 prefix
splitting? :)

> Last but not least, this treads on RIR policy. But in my opinion, this is foremost a technical matter with global implications and as such is best discussed within the IETF rather than in the five…

i don't see it hitting RIR policy so much, sinc ethe RIR's absolved
themselves of 'routability' of prefixes long ago. 'if you can't reach
your shiney new allocation it ain't ARIN's problem'.

-chris

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Oct 2014 07:09:02 +1300

> Although I wouldn't expect an organization to deaggregate down to hundreds or thousands of more specifics just for traffic engineering.

Not to hundreds, but I would expect a large multinational with operations
in most countries to deaggregate down to something close to one per country,
to keep its traffic patterns reasonably local. That's nothing new.

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 16 Oct 2014 08:53:38 +0200 (CEST)

On Thu, 16 Oct 2014, Brian E Carpenter wrote:

> Not to hundreds, but I would expect a large multinational with 
> operations in most countries to deaggregate down to something close to 
> one per country, to keep its traffic patterns reasonably local. That's 
> nothing new.

Breakouts done from PA space is normal in ARIN-land, but it's less common 
in RIPE land for instance.

We need to make sure renumbering is easy, otherwise we're going to see 
more and more entries going into the DFZ BGP table. The /24 boundary and 
IPv4 scarcity was a natural hindrance for this in IPv4, we need to create 
equal "hindrance" for de-aggregation in IPv6 otherwise I fear that we're 
going to sit with millions of routes in IPv6 DFZ in 10-20 years.

Unless of course this is a cheaper way of handling things than making 
renumbering possible.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 16 Oct 2014 11:40:58 +0200

> ok <1% growth.

What do you mean?

> table works and people live within those constraints.

I've only heard from a few people who do this / want to do this so far, but from what I hear they really want some clarity in this area. Spending a lot of time and money to set all of this up and then discovering your prefixes are filtered is rather suboptimal.

Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 16 Oct 2014 11:43:52 +0200

Let me address a few points that were brought up by different people.

Renumbering:

We had great plans for making renumbering easy in the early days of IPv6. Remember A6 records and bitlabels in the DNS? But none of that went anywhere. The problem isn't so much that we can't push a prefix down the network or update the DNS (although both of these still have challenges associated with them), but that addresses tend to get hardcoded all over the place, starting with firewalls all the way up to homegrown applications. I don't think renumbering addresses this issue, although it could help steer some smaller organizations away from PI.

A prefix length limit for the IPv6 DFZ:

Someone mentioned that this didn't work in IPv6. When Sprint decided to make that /18, that didn't really work. But there's a de facto /24 limit that everyone understands. With IPv6, that would translate into a /48. Obviously no router can hold 2^48 or 2^45 prefixes, so as a backstop against accidental/malicious IPv6 routing table explosion this doesn't help. Even exploding a /28 or so into individual /48s would kill the IPv6 DFZ.

What COULD work is to have prefix length limits depending on the allocation size by the RIRs. Something like:

2100::/16 -> /48
2200::/16 -> /32
2200::/15 -> /29

However, for this to work well the RIRs would have to group allocations of the same size into separate blocks, with the result that it would no longer be possible to reserve space to grow an allocation. (Things like allocating a /48 but reserving a /44 reduce the opportunities for prefix length filtering because now the strictest filter you can make allows 16 x as many prefixes worst case than average case. The worst and average case need to be as close together as possible.)

I'd say that allowing two or three extra bits for traffic engineering for PA blocks would be good. So for the part of the IPv6 space where /29s are allocated, allow /31s or /32s. As traffic engineering incoming traffic by deaggregation requires that different parts of the aggregate all generate similar levels of incoming traffic, this wouldn't usually work for organizations using PI so I'd say don't allow deaggregating below /48.

Geographic communities:

I know this is controversial. "Topology ain't geography". Actually, most of the time there is a significant correlation. If all German cities inject a more specific, do you really need to hear those in Tokyo or Seattle? Just send the traffic to Europe as per the aggregate and let them figure it out there.

Compiling a list of communities that identify regions/countries/cities would allow for experimentation in this place without any downsides that I can see. Don't like this? Filter the communities. There's a handy list that you can copy and paste into your filter.

Injecting an aggregate as a point of last resort:

I think this can be done today and probably is done today. But a document describing how to do it would probably be helpful. I'm thinking along the following lines:

The AoLR (Aggregate of Last Resort) service would entail a service provider announcing the aggregate without necessarily providing connectivity towards all the places announcing more specifics covered by the aggregate. So if ISP A announces the AoLR and ISP B provides connectivity to a more specific, ISP C would send traffic to A as per the aggregate and then A would immediately hand it over to B.

So as part of the AoLR service, a service provider would agree to accept all more specifics that fall under the aggregate (up to an agreed prefix length) from all the networks providing connectivity towards those more specifics. This would be an attractive service for tier-1s to provide, because presumably, they peer with everyone everywhere, so in the case where they receive the traffic over peering and need to deliver it to another service provider over peering, this could probably happen in the same city, so they wouldn't carry the traffic over long distances. But the (sub-)organization(s) in question still gets to buy connectivity from a wider range of smaller service providers.

In practice an organization would contract two or more service providers to provide the AoLR service for redundancy.

Wouldn't they just get PI:

Yes. That's why I think it's important to find a way to give these organizations what they need in a way that keeps the IPv6 DFZ growth on a workable trajectory.

AS numbers:

BGP assumes that an AS always has internal connectivity. This can be accomplished using tunnels, but it's much better to simply have separate AS numbers for each subunit. Would it make sense to allocate ranges of AS numbers to enterprise LIRs? Certainly with 32-bit AS numbers there's no lack of numbers, and this would allow tools to be developed to work on CIDR-like AS number ranges in the future.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 16 Oct 2014 11:43:30 +0100

On 16/10/2014 10:43, Iljitsch van Beijnum wrote:
> Yes. That's why I think it's important to find a way to give these
> organizations what they need in a way that keeps the IPv6 DFZ growth on
> a workable trajectory.

This brings up a more general issue:  IPv6 dfz growth for the last several
years has been linear.

> https://ripe68.ripe.net/presentations/156-2014-05-12-bgp2013.pdf

Even if the curves go the wrong way for a couple of years, there isn't an
issue of much concern here, at least in the short to medium term, and
probably not the longer term either.

Nick

---

From: "Russ White" <[email-masked]>
Date: Thu, 16 Oct 2014 07:39:14 -0400

> I think this can be done today and probably is done today. But a document
> describing how to do it would probably be helpful. I'm thinking along the
> following lines:
> 
> The AoLR (Aggregate of Last Resort) service would entail a service
provider
> announcing the aggregate without necessarily providing connectivity
towards
> all the places announcing more specifics covered by the aggregate. So if
ISP A
> announces the AoLR and ISP B provides connectivity to a more specific, ISP
C
> would send traffic to A as per the aggregate and then A would immediately
> hand it over to B.

Or perhaps something simpler would work here -- bounding longest match.

:-)

Russ

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 16 Oct 2014 13:03:08 +0000

On 10/15/14, 6:04 PM, "Christopher Morrow" <[email-masked]>
wrote:

>>
>>- A set of communities that indicate whether a prefix is a more specific
>>that is covered by an aggregate and/or is safe to filter without loss of
>>connectivity.
>>
>

Right..  Even if we could make the communities not be stripped (not
proposing that), the originator would still not know the policy between
any two ASNs ‹ not even the receive policy of its direct neighbor!   So
the originator still couldn¹t guarantee that the route is in fact covered.

The only way to determine coverage and no connectivity loss is on the
receive side.  There you can look at the incoming routes and determine how
the routes overlap and mark them appropriately according to local policy.

http://tools.ietf.org/html/draft-white-grow-overlapping-routes

Alvaro.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 16 Oct 2014 13:18:44 +0000

On 10/15/14, 11:14 AM, "Ted Lemon" <[email-masked]> wrote:

>> However, rather than advertising that block in BGP as a single prefix,
>>or perhaps a handful of prefixes, like an ISP would, they subdivide this
>>block within the organization and then many subunits advertise
>>subprefixes though different ISPs. The aggregate may or may not be
>>advertised.
>
>Yuck.   Has anybody done an analysis of how this works with RPKI?   Seems
>like an obvious attack surface if the RPKI isn't present or isn't done
>right.

Yup.

I don¹t have an analysis, but it is a common discussion point when
creating ROAs: what should the ROA cover?  Both the max-length of the
advertisement and the origin ASNs could result in a ³validated² attack.

On one hand, creating ROAs that cover exactly what is advertised reduces
the surface, but it can result in a higher operational cost and maybe some
hassle if something different (like a more specific) needs to be
advertised *right now*.  OTOH, creating a more ³flexible² ROA (2100::5/32
-> /48, for example) provides more operational flexibility, but it may in
fact open up the door to ³valid² announcements.

I¹ve worked with LACNIC in some of their RPKI deployments in Latin America
and I suspect that a significant number of people opt for the ³flexible
ROA²..even after we explain the risks.  LACNIC may have some insight in
what is being created right now (with the caveat of course that there¹s
just one place in the world that is in fact filtering).

Alvaro.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 16 Oct 2014 10:11:41 -0400

>>> 1. Large numbers of prefixes may show up in the global routing table. For instance, there is a number plan for all of the German government, which could potentially inject more than 5000 municipa…

5000 is less than 1% of 540k... (I think, math is hard and all that business)
for the (since someone else shot me a note behind the scenes about
this as well) forseable future we'll have v4 + v6 to deal with in a
DFZ device, so call it even at 540k routes today in the table, your 5k
extra is less than 1% of that.

> I've only heard from a few people who do this / want to do this so far, but from what I hear they really want some clarity in this area. Spending a lot of time and money to set all of this up and t…

So, some folk thought: "Hey, not announcing my aggregate and not
providing connectivity between the aggregate announcement and the
little islands I created is a grand plan!" and were surprised when
things went badly...

Do you want a document that says:
  "Sure, announce your aggregate as a bunch of de-aggs, and be sure
there's a fall back ASIDE FROM ::/0 which has reachability to your
islands, if you want to be sure to not run afoul of random isp route
filtering."

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 16 Oct 2014 10:45:23 -0400

On Thu, Oct 16, 2014 at 10:37 AM, Gert Doering <[email-masked]> wrote:
> Hi,
>
> On Thu, Oct 16, 2014 at 10:11:41AM -0400, Christopher Morrow wrote:
> A strong message to that extent would be good :-) - coupled with
> some recommendations how the conflicting goals ("I want all ISPs in
> my neighbourhood to use optimal routing" vs. "someone in Asia might
> not be interested in all in 5k routes for german municipality")
> could be solved.
>

ok, perhaps iljitsch can drop some text into a document so we can get
a good read going and decide whether or not GROW wants to spend cycles
on it?

The problem exists in v4 and v6 and likely will persist in whatever
comes next. It's directly related to routing operations work on the
global intertubes, so it SEEMS like GROW is the 'right place' to
discuss this... we can't go anywhere without text and a draft though.

> I get that question fairly often from "largish networks", and so far,
> I always have to answer "there is no routing police, so it's hard to
> say what is allowed on the Internet and what not" - which is a humorous
> way to say "there is no consensus here what consists 'good' and
> 'responsible'"...

I sort of don't want there to be 'routing police' though :( In a way
this whole debate sounds like something a 'cisco training class' (or
other example) would have covered, or should cover. I suppose it's
fairly experiential at this point though.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 16 Oct 2014 11:20:48 -0400

(apologies for again not reformatting apple-mail->gmail issues)

> Let me address a few points that were brought up by different people.

I think the renumbering ship sailed, and like the titanic had a bad
voyage. You seem to agree.

> Someone mentioned that this didn't work in IPv6. When Sprint decided to make that /18, that didn't really work. But there's a de facto /24 limit that everyone understands.
With IPv6, that would translate into a /48. Obviously no router can
hold 2^48 or 2^45

I suppose there's a question about: "Is a /24 a LAN (/64) or a SITE
(/48)" to be answered still. I believe SITE works better, but :)

prefixes, so as a backstop against accidental/malicious IPv6 routing
table explosion this doesn't help. Even exploding a /28 or so into
individual /48s would kill the IPv6 DFZ.

mostly this is from motherhood + apple-pie bgp neighbor configs
though, right? (max-prefix in particular).

> What COULD work is to have prefix length limits depending on the allocation size by the RIRs. Something like:

This looks, to me, like the 'PA space is >= /32, PI >= /48' in each
region's PA/PI splits... which ends up being fairly stable and fairly
simple prefix-list/etc configs on devices, right? so that seems kind
of sane even. I had thought the cymru folk had something like this in
their templates:

<https://www.team-cymru.org/ReadingRoom/Templates/IPv6Routers/junos.html>

isn't what I was looking for, sadly...and is the only sort of ipv6 /
route-filter related thing I quickly find on their site... perhaps
some room for improvement in this area exists. Should that be an IETF
action or 'get the defacto standards/bcop folk to update their docs
based on the best shared wisdom' ?

> However, for this to work well the RIRs would have to group allocations of the same size into separate blocks, with the result that it would no longer be possible to reserve space to grow an alloca…

my impression (and I stopped paying close attention to ARIN at least
2+ yrs ago) was that RIR's were allocating PA from one large (/23?)
block per RIR and PI from a different...

For my work-location-provider:
  2620:0:1000::/40 - PI /40
  2001:4860::/32 - PA /32
  2607:F8B0::/32 - PA /32

<http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml>

doesn't delineate the difference between 2001:4800::/23 and 2600::/12
and 2620::/23 ... bummer. I suppose this though:
  <https://www.arin.net/knowledge/ip_blocks.html>

is meant to delineate the differences as 'allocation blocks' vs
'assignment blocks'... (I didn't search the same sort of stuff out on
ripe/apnic/etc...)

> I'd say that allowing two or three extra bits for traffic engineering for PA blocks would be good. So for the part of the IPv6 space where /29s are allocated, allow /31s or /32s. As traffic enginee…

sure, this gets into the above 'give me a default understanding of the
iana -> rir ranges + RIR purposes (alloc/assign) and add +N bits for
TE. It's not quite answering the other part of your question about:
"What will the DE gov't do? how will they run their new shiney network
such that they don't have reachability concerns?"

> I know this is controversial. "Topology ain't geography". Actually, most of the time there is a significant correlation. If all German cities inject a more specific, do you really need to hear thos…

this argues for the DE gov't having 1 ISP's for all their cities and
putting the aggregate into BGP as well with the more specifics
no-export'd from the ISP, not for communities, which won't reliably
make it across AS boundaries.

> I think this can be done today and probably is done today. But a document describing how to do it would probably be helpful. I'm thinking along the following lines:

ok

> In practice an organization would contract two or more service providers to provide the AoLR service for redundancy.

this doesn't sound unreasonable, make txt pls appear in draft form,
then email that to grow@ and see what debate happens there.

> BGP assumes that an AS always has internal connectivity. This can be accomplished using tunnels, but it's much better to simply have separate AS numbers for each subunit. Would it make sense to all…

it seems like the AS here is really not relevant, unless you were
thinking that: "AS is a proxy for GEO data." (or AS == SITE) One
thought is that AS provides the mapping to 'authoritative entity for
the routing policy surrounding/using the prefixes originated by the AS
in question', so is it simpler to remember: "DE govt is AS65534" or
"DE gov't could be one of 160 AS numbers" (a range might help, but
ranges imply some idea about growth in the future. Would you have
planned for RU to add Crimea?)

The AoLR (or 'how to be an enterprise that participates in the global
routing system') seems like a good start though.

-chris

---

From: Owen DeLong <[email-masked]>
Date: Wed, 15 Oct 2014 22:41:34 -0700

> 1. Large numbers of prefixes may show up in the global routing table. For instance, there is a number plan for all of the German government, which could potentially inject more than 5000 municipali…

How would this differ from 500 multihomed municipal governments getting PI space?

> 2. Filtering. If people want to avoid large numbers of deaggregates in their routing tables, they may employ some kind of filtering, especially if the deaggregates are very long prefixes. This mean…

I would think that if/when this becomes an issue, the organizations engaging in the behavior will take the necessary steps to get the traffic they care about.
Seems to me that this is the desirable situation as some form of equilibrium will be reached where organizations limit their deaggregates to something they can get adequately routed and operators will limit their routing tables to something they can handle.

> Ideally, a set of best practices would be developed that strike a good balance between the needs of large organizations and the needs of the global routing system, and allow everyone to predict the…

Hard to develop a set of best practices for this that would have any real longevity. The boundary between usable routing table maximum size and oblivion is a moving target. We don't have sufficient experience with this problem in the IPv6 space to really know how far it will extend.

> - A well-understood maximum prefix length for IPv6, similar to /24 for IPv4.

I don't think this helps. The /48 seems to pretty much already be there as a de-facto answer to this question. However, 2^45 routes (unicast is a /3) is probably beyond the capability of any router yet available.

> - An understanding of how the service providers that provide connectivity to multiple subunits of a large organization can work together in order to maximize availability and minimize costs for the…

If you can find answers to this question, they would certainly be beneficial to the community, but I think that scope extends well beyond the deaggregation issue described here and that would be only one aspect of such a document.

> - A way to provide a point of last resort where traffic for the aggregate can be sent to if more specifics are filtered.

There are many ways to do this. Ranging from the simple build a network of tunnels between your sites and anchor the aggregate as a less specific from a few key sites to much more elaborate solutions. These solutions seem to me to be reasonably well known to most network engineers. I don't think a document rehashing them in yet another place is of any particular benefit.

> - A set of communities that indicate whether a prefix is a more specific that is covered by an aggregate and/or is safe to filter without loss of connectivity.

This seems like a reasonably good idea... If you write up an ID for v6ops to do this one simple thing, I would support it.

> - A set of communities that indicate geographical origin of prefixes so remote more specific prefixes can be filtered while local prefixes are kept.

Since geography != topology (and dramatically so in some cases), I think this would do more harm than good in many cases.

> - Guidelines for reserving address space in address plans. Is it better to have free space reserved so existing prefixes can grow, or keep reserved space together so tight prefix length filters are…

There are many documents describing various ways to do sparse allocation and allocation by bisection for IPv6. I have written some that have achieved some distribution. RIPE has one or two at least. I don't think having the IETF rewrite yet another one is particularly useful.

> Please note that I'm crosspositing this to v6ops and grow initially. If the chairs have any guidance on which working group is more appropriate for this discussion, please let us know and we can dr…

The one tidbit that strikes me as useful is, IMHO, something that belongs in v6ops. YMMV.

> Last but not least, this treads on RIR policy. But in my opinion, this is foremost a technical matter with global implications and as such is best discussed within the IETF rather than in the five…

I don't think anything proposed above really treads on RIR policy. It makes recommendations for utilization of address space by end-user organizations, but does not make any attempt to set policy for how those addresses are acquired or what amount of space should be granted in response to such a request.

I'm pretty sure I'm one of the most RIR-oriented people on the planet in any such discussion, so I think you're safe in that regard. (I was, after-all, the leader of the original RIR rebellion against oppressive IETF policies regarding PI for end-users in IPv6).

Owen

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 16 Oct 2014 08:53:38 +0200 (CEST)

---

From: Gert Doering <[email-masked]>
Date: Thu, 16 Oct 2014 16:37:43 +0200

Hi,

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Thu, 16 Oct 2014 16:59:31 +0200

Hi,

> a good read going and decide whether or not GROW wants to spend cycles

That would be nice (as I see the problem but have no cycles to write
something useful).

> discuss this... we can't go anywhere without text and a draft though.

It seems to be made worse by the fact that "this" can be done more
easily with IPv6, as you just can't get enough v4 space to subdivide
it into 5000 globally visible prefixes today - and those entities that
discover the "must have reliability!  must have independence!" mantra
*now* will hit the v6 space...  (given that I see this argument in this
dimension more often from governmental structures who have been hiding
behind single-IPv4-NAT so far).

> fairly experiential at this point though.

I *do* want a routing police, in the sense that "the operator community"
agrees on what is considered "good" and "bad" behaviour, so end users
can ask someone (me, Iljitsch, ...) what to do in their network planning,
and we can tell them

  - if you do *this*, it's "guaranteed" to work
  - if you do *that*, you can be sure that you will be filtered

while today, I have to tell them

  - well, today it is likely to work, but it might stop working tomorrow,
    and there is no document that you could show around to those that
    break your connectivity to show them that "you are doing the right thing"

ISPs develop their own guidelines on prefix-length filtering, some with
better understanding on what they want to achieve, others by using 10 year
old example documents for never-updated filters...

So, yes, guidance, please :-)

Gert Doering
        -- NetMaster

---

From: joel jaeggli <[email-masked]>
Date: Thu, 16 Oct 2014 08:38:23 -0700

> behind single-IPv4-NAT so far).

The number of autonomous systems present in the internet is a good proxy
for the number of organizations that find this necessary. It is not a
proxy for the number of prefixes each of those ASes choose to advertise
though somewhat less than half of those ASNs advertise one prefix only.

http://www.cidr-report.org/cgi-bin/plot?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp-as-count%2etxt&start=0&end=1413472455&width=0%2e9&height=0%2e3&with=step&ylabel=AS+Count

> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 16 Oct 2014 17:47:31 +0200

>> https://ripe68.ripe.net/presentations/156-2014-05-12-bgp2013.pdf

Growth in IPv6 more specifics was 57% last year...

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 16 Oct 2014 17:05:07 +0100

> Growth in IPv6 more specifics was 57% last year...

1y is an interesting data point, but shouldn't form the basis for a new
policy.  What does the aggregate:more-specifics ratio look like over the
last 5-8 years?

Nick

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 16 Oct 2014 18:21:24 +0200

On 2014-10-16 17:20, Christopher Morrow wrote:
[..]
> of sane even.

You are looking for:
http://www.space.net/~gert/RIPE/ipv6-filters.html

"Update: 2002/09/25. Gert Döring: initial version."

Folks have been using that for 12 years already...

Greets,
 Jeroen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 16 Oct 2014 18:26:24 +0200

> policy.  What does the aggregate:more-specifics ratio look like over the

I haven't checked, but obviously the percentage growth was large and the absolute growth small.

But look at the v4 table. It's a mess, and we have no way to clean it up. Fortunately we can just decommission IPv4 in the foreseeable future. No such luck with IPv6, though, it'll be around for decades to come. And the good thing is that there's so much address space that we CAN make tradeoffs that will keep the routing table healthy, where we weren't in the position to do that with IPv4. It's much better to spend some time making sure we don't repeat the IPv4 mistakes and/or add some new ones rather than wait 10 years and find ourselves in an untenable situation.

Also, from the vantage point of someone who has all their prefixes routed life is good, but there are also people who run into (the possibility) of filtering. A clear message about what can and can't be expected to work with IPv6 would help them a lot.

---

From: Enno Rey <[email-masked]>
Date: Thu, 16 Oct 2014 18:22:57 +0200

Hi,

> little islands I created is a grand plan!" and were surprised when

well, $FOLK might have good reasons to act in that way, based on their business models and network design.

to put it equally bluntly, those folks wonder: "hey, we pay a hell lot of money to our uplink providers and they fail to deliver what we contracted, that is transporting our traffic".
see the examples in https://www.ernw.de/download/RIPE69_Rey_Langner_Slash48_Considered_Harmful_v082_DRAFT.pdf.

best

Enno

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 16 Oct 2014 17:47:41 +0100

> I haven't checked, but obviously the percentage growth was large and the

not obvious: please post data.

Nick

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 16 Oct 2014 18:56:32 +0200

> see the examples in https://www.ernw.de/download/RIPE69_Rey_Langner_Slash48_Considered_Harmful_v082_DRAFT.pdf.

There is a reason why there are PA and PI blocks... or you know, pay for
transiting the aggregate...

Greets,
 Jeroen

---

From: Enno Rey <[email-masked]>
Date: Thu, 16 Oct 2014 18:53:06 +0200

Hi,

> transiting the aggregate...

well ... yes.
not sure to what extent $RIRs act accordingly (have been involved in requesting resources from all five of them in the past and can tell you 1st hand that there's quite some encouraging $LARGE_ENTERPRISES to bec
ome LIRs, in one way or the other). there must be a reason, why - as far as I can tell - _pretty much all_ large German companies have joined the elitist LIR club in the last two years, preparing their IPv6 depl
oyment. RIRs are happily playing that game which is exactly why debate & consensus are needed (and probably Iljitsch brought this to BCOP).

that said, $FOLK would pay for it. $YOUR_EMPLOYER has a product with "we guarantee routing your IPv6 more specifics up to /48 for a monthly $FEE" property? Let me know, I'm sure many $FOLKs would be interested in that.
leaving them "in the dark" and dependent on the goodwill of (my personal perspective, based on statistics from RIPE RIS: outdated) strict filtering doesn't help anybody.

best

Enno

-- 
Enno Rey

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 16 Oct 2014 20:40:37 +0200

On 2014-10-16 18:53, Enno Rey wrote:
>>> to put it equally bluntly, those folks wonder: "hey, we pay a
>>> hell lot of money to our uplink providers and they fail to
>>> deliver what we contracted, that is transporting our traffic". 
>>> see the examples in
>>> https://www.ernw.de/download/RIPE69_Rey_Langner_Slash48_Considered_Harmful_v082_DRAFT.pdf.
>>
>>
>>> 
>>> There is a reason why there are PA and PI blocks... or you know,
>>> pay for transiting the aggregate...
> 
> well ... yes. not sure to what extent $RIRs act accordingly (have
> been involved in requesting resources from all five of them in the
> past and can tell you 1st hand that there's quite some encouraging
> $LARGE_ENTERPRISES to bec ome LIRs, in one way or the other).

As you are the consultant, your job to get them there right?

Nothing the IETF can do about that part.

> there
> must be a reason, why - as far as I can tell - _pretty much all_
> large German companies have joined the elitist LIR club in the last
> two years, preparing their IPv6 depl oyment.

Because they all wanted a /32 PA for near zero paperwork.

> RIRs are happily playing
> that game which is exactly why debate & consensus are needed (and
> probably Iljitsch brought this to BCOP).
> 
> that said, $FOLK would pay for it.

The numbers in your slides show that those companies have more than
enough "resources" to be able to set up a proper network or let some
transit backhaul the traffic.

No need to de-aggregate and burden the rest of the world with that though.

I would blame the consultant for hinting at the wrong solution for their
enterprise...

Greets,
 Jeroen

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 16 Oct 2014 14:58:52 -0400

> Because they all wanted a /32 PA for near zero paperwork.

prior to the 'ipv6 pi' rules changes I think many/some/a-few large
corporations essentially (to get PI) just said: "Yes, my IT department
is a 'service provider' to the rest of the company, can I haz /32?"

see HP as an example of this (from my memory of their reasoning)

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 16 Oct 2014 20:51:38 +0100

On 16/10/2014 17:53, Enno Rey wrote:
> not sure to what extent $RIRs act accordingly (have been involved in
> requesting resources from all five of them in the past and can tell you
> 1st hand that there's quite some encouraging $LARGE_ENTERPRISES to
> become LIRs, in one way or the other). there must be a reason, why - as
> far as I can tell - _pretty much all_ large German companies have joined
> the elitist LIR club in the last two years, preparing their IPv6
> deployment. RIRs are happily playing that game which is exactly why
> debate & consensus are needed (and probably Iljitsch brought this to
> BCOP).
> 
> that said, $FOLK would pay for it. $YOUR_EMPLOYER has a product with "we
> guarantee routing your IPv6 more specifics up to /48 for a monthly $FEE"
> property? Let me know, I'm sure many $FOLKs would be interested in that.
> leaving them "in the dark" and dependent on the goodwill of (my personal
> perspective, based on statistics from RIPE RIS: outdated) strict
> filtering doesn't help anybody.

this whole email ... isn't even wrong.

Nick

---

From: Enno Rey <[email-masked]>
Date: Thu, 16 Oct 2014 21:42:40 +0200

Hi,

> Nothing the IETF can do about that part.

Iljitsch initially submitted this to BCOP... which could be a place to discuss it.
that said, you're fully right, IETF has never cared for "enterprise needs" (not implying they should, just noting), and hence - imho - done quite some harm to global IPv6 deployment. but that's another topic.

> Because they all wanted a /32 PA for near zero paperwork.

or because RIRs encouraged them to do so, in several ways?
potential reasoning I leave up to the imagination of the reader...

> transit backhaul the traffic.

thanks for the generous advice what a "proper network" is. much appreciated.

> I would blame the consultant for hinting at the wrong solution for their

given all those organizations do the same silly stuff, seems they are all consulted to by a unified group of consultants not possessing your enormous amount of wisdom and of large scale enterprise network experience.
so what's your practical advice to solve the apparent dilemma Iljitsch pointed out and thereby substantial contribution to the debate? thanks in advance &

have a good one

Enno

-- 
Enno Rey

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 16 Oct 2014 22:08:16 +0200

> is a 'service provider' to the rest of the company, can I haz /32?"

I was refering above to companies that would be fine with a /48 or even
a /40 or similar.

In the end though, it does not matter if they have a /32 or a /40 or a
/48; all those will use 1 routing slot.

The only case it will use more is when they de-aggregate...

> see HP as an example of this (from my memory of their reasoning)

HP and other similar companies likely need more than a /32 if they do
proper hierarchical routing between their sites...

Hence why quite a few companies have requested multiple prefixes from
multiple RIRs...

Greets,
 Jeroen

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 16 Oct 2014 22:16:09 +0100

> Growth in IPv6 more specifics was 57% last year...

Here's a graph which shows the percentage of more-specifics between 2003
and today from Geoff Huston's web site:

http://goo.gl/QA0xud

Eyeballing the graph, it's not clear where the figure of 57% came from.  In
terms of trajectories, there doesn't seem to be a major problem either.

Nick

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 17 Oct 2014 14:22:07 +0200

On 17 Oct 2014, at 11:11, Marc Binderberger <[email-masked]> wrote:

>> If all German cities inject a 
>> more specific, do you really need to hear those in Tokyo or Seattle? Just 
>> send the traffic to Europe as per the aggregate and let them figure it out 
>> there.

> ... it's likely that for an US ISP X, peering with European ISPs Y and Z who 
> carry the various deaggregate plus aggregate from Germany, all the European 
> prefixes have this peering router as next hop (let's say we have 
> next-hop-self).

> What about BGP on this peering router doing some auto-aggregation in such a 
> case?  Has this been discussed?  It would avoid geographic communities and 
> would simply follow the BGP topology: if the deaggregates result in the same 
> forwarding information than the aggregate just keep the aggregate.

Yes, this would be another way to address the issue. However, this introduces a new complication: the presence of prefix Y in the table depends on the presence of prefix X. Currently, that's taboo in BGP.

Note that filtering according to geographic communities could be done within an AS, removing the need for inter-AS coordination (beyond propagating the communities). So for instance a network that spans the US could carry European more specifics on the east coast and Asian more specifics on the west coast, if they feel that having both sets of more specifics everywhere would inflate their routing tables too much.

> (2) the problem of ever-growing routing tables and de-aggregation is not new. 
> After so many years I'm wondering if the answer is that this cannot be solved 
> with BGP/routing alone

Look at the work in the IRTF routing research group. There are possibilities to address this, but so far there's always been significant resistance against the tradeoffs such solutions would require.

Iljitsch

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Oct 2014 10:35:32 +1100

In message <[email-masked]>, Owen DeLong writes:
> 
> On Oct 16, 2014, at 02:43 , Iljitsch van Beijnum <[email-masked]> wrote:
> 
> > We had great plans for making renumbering easy in the early days of IPv6. Remember A6 records and bit
> labels in the DNS? But none of that went anywhere. The problem isn't so much that we can't push a prefi
> x down the network or update the DNS (although both of these still have challenges associated with them
> ), but that addresses tend to get hardcoded all over the place, starting with firewalls all the way up 
> to homegrown applications. I don't think renumbering addresses this issue, although it could help steer
>  some smaller organizations away from PI.
> 
> They never went anywhere because they focused on solving the easy part of the renumbering problem while
>  utterly and completely ignoring the hard part.
> 
> Easy part: Changing your stuff.
> Hard part: Updating all of the prefix lists, filters, firewall rules, VPN configurations, and other con
> figuration elements in systems not under your control that contain your prefixes (partner VPNs, peer ro
> uters, etc.).

Owen this a collective response to the list.

Not all that hard at all.  Just send signed update requests.  I did
that with email over a decade ago.  You just have to have something
listening for them that verifies the signature and updates the
system.

Write a draft "Remote Firewall Update Request Protocol" and submit
it.

The alternative is stop worrying about the remote address and use
security at the application layer.

Or complain to your vendor that you can't use a hostname in the
configuration file element.  In many cases it doesn't require
anything more than looking up a address in the DNS before the
operation.  Yes, I need to fix the masters clause in named to support
this.  We already do something similar for NOTIFY messages so it
is possible to do this.

For masters clauses there is a bootstrap problem to deal with but
it is not impossible.  Just sending periodic NOTIFY messages will
work.  Named has had support to do this for 1 1/2 decades now to
allow for a a stealth master behind a dial on demand link.  It would
send a notify periodically.  That would bring up the line.  The
slave would refresh and transfer if required.  When that was complete
the idle timer on link would drop it.

This just used standard signalling designed by the IETF in a different
way.

Stop expecting someone else to *find* and fix these issues for you.
You know what the issues are.  Ask your vendors to fix them.  If
they need to co-ordinate they should know where to go to do it.

Mark

> NONE of the things proposed in those days did anything at all to address the hard part.
> 
> > Someone mentioned that this didn't work in IPv6. When Sprint decided to make that /18, that didn't re
> ally work. But there's a de facto /24 limit that everyone understands. With IPv6, that would translate 
> into a /48. Obviously no router can hold 2^48 or 2^45 prefixes, so as a backstop against accidental/mal
> icious IPv6 routing table explosion this doesn't help. Even exploding a /28 or so into individual /48s 
> would kill the IPv6 DFZ.
> > 
> Because the 4.3 billion routes in the first category won't be a problem somehow?
> 
> Also, 2200::/16 and 2200::/15 overlap. Did you mean 2300::/16? If I apply longest match rule to what yo
> u've put above, that's the effective result. If you meant something else, I'm not sure how to divine th
> at from what you wrote.
> 
> > However, for this to work well the RIRs would have to group allocations of the same size into separat
> e blocks, with the result that it would no longer be possible to reserve space to grow an allocation. (
> Things like allocating a /48 but reserving a /44 reduce the opportunities for prefix length filtering b
> ecause now the strictest filter you can make allows 16 x as many prefixes worst case than average case.
>  The worst and average case need to be as close together as possible.)
> 
> I think overall, that would be worse than what we have today.
> 
> > I'd say that allowing two or three extra bits for traffic engineering for PA blocks would be good. So
>  for the part of the IPv6 space where /29s are allocated, allow /31s or /32s. As traffic engineering in
> coming traffic by deaggregation requires that different parts of the aggregate all generate similar lev
> els of incoming traffic, this wouldn't usually work for organizations using PI so I'd say don't allow d
> eaggregating below /48.
> 
> What about multihomed customers? Do you want all multihomed customers to be forced into getting their s
> pace directly from RIRs and not from LIRs?
> 
> There are currently many cases where organizations obtain a /48 (or larger) from their ISP and subseque
> ntly choose to connect to an additional ISP and advertise the PA space as an independent route through 
> both ISPs. Many ISPs cooperate in this process and allow this behavior. It does not change the number o
> f routes in the routing table, but it can be less expensive for the customer if they choose to go that 
> way.
> 
> Obviously, at their first renumbering event, it makes sense for them to renumber into PI, but this can 
> prevent them from having to undergo renumbering while they remain connected to the initial provider wit
> hout actually affecting the global routing table any more than getting PI would.
> 
> > Geographic communities:
> > 
> > I know this is controversial. "Topology ain't geography". Actually, most of the time there is a signi
> ficant correlation. If all German cities inject a more specific, do you really need to hear those in To
> kyo or Seattle? Just send the traffic to Europe as per the aggregate and let them figure it out there.
> 
> Spend much time in Asia or Africa or the Caribbean?
> 
> Sure, in the case of Germany, you probably don't need them in Tokyo or Seattle. OTOH, if you get a bunc
> h of more specifics coming out of Rwanda, it might actually be significant to have them in Germany, Par
> is, and Brussels.
> 
> Where, exactly would you draw these lines and how would you go about handling the necessary exceptions?
> 
> Europe and the US are rich with exchange points and peering density. The rest of the world, less so to 
> varying degrees resulting in more significant differences between topology and geography, often in ways
>  that are not necessarily obvious.
> 
> > Compiling a list of communities that identify regions/countries/cities would allow for experimentatio
> n in this place without any downsides that I can see. Don't like this? Filter the communities. There's 
> a handy list that you can copy and paste into your filter.
> 
> For these communities to be useful, they'd have to be transitive and people would have to agree to appl
> y them to their prefixes. What happens in the case of "vigilante" tagging where some other AS decides t
> o start applying these tags to my routes even though I specifically don't want that?
> 
> > I think this can be done today and probably is done today. But a document describing how to do it wou
> ld probably be helpful. I'm thinking along the following lines:
> 
> It is already BCP for networks that have the ability to do so. It's not a separate service or anything,
>  you just source the aggregate from one or more locations where you have the ability to forward the tra
> ffic as needed.
> 
> > The AoLR (Aggregate of Last Resort) service would entail a service provider announcing the aggregate 
> without necessarily providing connectivity towards all the places announcing more specifics covered by 
> the aggregate. So if ISP A announces the AoLR and ISP B provides connectivity to a more specific, ISP C
>  would send traffic to A as per the aggregate and then A would immediately hand it over to B.
> 
> This assumes that A:
> 	1.	Is willing ot accept the more specifics from B.
> 	2.	Is willing to provide (likely unbillable) transit for the customer in question.
> 	3.	Has a peering relationship with all ISP Bs for the given customer.
> 
> In my experience, ISPs are usually hesitant to take responsibility for forwarding traffic they can't bi
> ll in some way.
> 
> Item 3 is an even more difficult problem to solve.
> 
> Most organizations, instead of depending on such a service simply build the necessary tunnels to provid
> e their own AoLR capabilities as needed when they don't have internal circuits for the task.
> 
> > So as part of the AoLR service, a service provider would agree to accept all more specifics that fall
>  under the aggregate (up to an agreed prefix length) from all the networks providing connectivity towar
> ds those more specifics. This would be an attractive service for tier-1s to provide, because presumably
> , they peer with everyone everywhere, so in the case where they receive the traffic over peering and ne
> ed to deliver it to another service provider over peering, this could probably happen in the same city,
>  so they wouldn't carry the traffic over long distances. But the (sub-)organization(s) in question stil
> l gets to buy connectivity from a wider range of smaller service providers.
> 
> Tier-1s in my experience not only don't usually peer with everyone everywhere, they often try to avoid 
> peering with anyone they consider "beneath them" as a tactic to try and force those organizations to bu
> y services from them.
> 
> Again, I don't see the ISPs wanting to do what you describe since there would be cost, but little benef
> it to them.
> 
> > Yes. That's why I think it's important to find a way to give these organizations what they need in a 
> way that keeps the IPv6 DFZ growth on a workable trajectory.
> 
> I think the IPv6 DFZ growth is already on a workable trajectory. If we could eliminate the massive IPv4
>  routing table, then IPv6 is nowhere near outpacing router memory capacity growth for the foreseeable f
> uture.
> 
> The problem is surviving in the interim while we need IPv4 on a global basis. The reality is that I thi
> nk IPv4 routing table bloat is eventually going to be the primary driver for IPv6 adoption. I think thi
> s will occur much faster than most people imagine because I believe that the fragmentation of the IPv4 
> table in the transfer market is going to make IPv4 routing progressively more untenable until it essent
> ially collapses under its own weight. At that point, the remaining laggards will scramble to deploy IPv
> 6 as quickly as possible and the IPv4 table will, largely, evaporate rather quickly.
> 
> > AS numbers:
> > 
> > BGP assumes that an AS always has internal connectivity. This can be accomplished using tunnels, but 
> it's much better to simply have separate AS numbers for each subunit. Would it make sense to allocate r
> anges of AS numbers to enterprise LIRs? Certainly with 32-bit AS numbers there's no lack of numbers, an
> d this would allow tools to be developed to work on CIDR-like AS number ranges in the future.
> 
> Yes... I'm all for going back to the definition of an AS as a contiguous collection of networks with an
>  identical routing policy. With 32 bits, I think we have enough ASNs to accomplish this globally.
> 
> Owen
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Matthew Petach <[email-masked]>
Date: Thu, 16 Oct 2014 17:59:07 -0700

> they need to co-ordinate they should know where to go to do it.

Or, y'know, we could just get PI space,
multihome via BGP, and save ourselves
all that headache...

...just sayin'...

Matt

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Oct 2014 12:05:52 +1100

In message <CAEmG1=[email-masked]>, Matthew Petach writes:
> --089e013a14fa48fd43050593df5a
> Content-Type: text/plain; charset=UTF-8
> 

And when we can support 40 billion routes, PI becomes a viable
solution.  Yes, this is the level that PI needs to be able to scale
to for it to be a actual solution.  Yes, mutiple routes for every
single person on the planet.

Until then we need to work towards making renumbering work so PI
isn't needed.

Mark

---

From: Matthew Petach <[email-masked]>
Date: Thu, 16 Oct 2014 18:18:34 -0700

On Thu, Oct 16, 2014 at 6:05 PM, Mark Andrews <[email-masked]> wrote:

>
> In message <CAEmG1=
> [email-masked]>, Matthew
> Petach writes:
> > > In message <[email-masked]>, Owen
> DeLong
> > > writes:
> > > >
> > > > On Oct 16, 2014, at 02:43 , Iljitsch van Beijnum <[email-masked]
> >
> > > wrote:
> > > >
> > > > labels in the DNS? But none of that went anywhere. The problem isn't
> so
> > > much that we can't push a prefi
> > > > x down the network or update the DNS (although both of these still
> have
> > > challenges associated with them
> > > > ), but that addresses tend to get hardcoded all over the place,
> starting
> > > with firewalls all the way up
> > > > They never went anywhere because they focused on solving the easy
> part
> > > of the renumbering problem while
> > > > figuration elements in systems not under your control that contain
> your
> > > prefixes (partner VPNs, peer ro
> > > > uters, etc.).
> > >

The probability of us figuring out how to scale
the routing table to handle 40 billion prefixes
is orders of magnitude more likely than solving
the headaches associated with dynamic host
renumbering.  That ship has done gone and
sailed, hit the proverbial iceberg, and is gathering
barnacles at the bottom of the ocean.
It is an ex-solution.
It is pushing up the daisies.
It has gone to meet its working group.
It is no more.

(with apologies to Monty Python)

Matt

---

From: Marc Binderberger <[email-masked]>
Date: Fri, 17 Oct 2014 02:11:32 -0700

Hello Nick and Iljitsch,

fairly stable baseline of 20-30%, which may be acceptable if it stays there. 
Although peaks of 70% (is the 100% a graph problem?) seem to be a reason 
_for_ filtering.

Now what I'm wondering

(1) is there a need to carry all the deaggregates? Because if you are far 
enough away they may "look the same as the aggregate". To use Iljitsch' 
example ...

> I know this is controversial. "Topology ain't geography". Actually, most of 
> the time there is a significant correlation. If all German cities inject a 

What about BGP on this peering router doing some auto-aggregation in such a 
case?  Has this been discussed?  It would avoid geographic communities and 
would simply follow the BGP topology: if the deaggregates result in the same 
forwarding information than the aggregate just keep the aggregate. Your 
routing table would have deaggregates for your own region but only aggregates 
for the other, more distant regions.

(2) the problem of ever-growing routing tables and de-aggregation is not new. 
After so many years I'm wondering if the answer is that this cannot be solved 
with BGP/routing alone (?)  Otherwise you would have found a solution 
meanwhile :-)
And we have the - understandable and growing - needs of Enterprises, who 
de-aggregate their PA addresses when they are LIR, or request PI addresses 
per location.

Combining this, should the de-aggregation step not be done with a different 
technology? LISP comes to my mind (biased, as I'm working on it) or in 
general a "de-aggregation overlay". The overlay would need gateways to the 
BGP world and would announce one aggregate prefix only while the de-aggregate 
prefixes would be limited to the particular Enterprise overlay network and 
would not show up in BGP.

Regards, Marc

---

From: Randy Bush <[email-masked]>
Date: Fri, 17 Oct 2014 09:58:48 -0700

[ not pickin' on you, nick ]

trying to find protein in this whole thread.

in the long run, why will v6 not suffer the <your expletive about
reasons goes here> same deaggregation which is about half of the v4
routing table?

maybe if we start filtering now.  but we know how well that went in ipv4
when their suits called our suits and said "we pay you to let us contact
<deaggregator>.

96 more bits, no magic (and 64 of those bits are allocated to relative
vacuum)

randy

---

From: Gert Doering <[email-masked]>
Date: Fri, 17 Oct 2014 19:07:59 +0200

Hi,

> policy.  What does the aggregate:more-specifics ratio look like over the

http://www.space.net/~gert/RIPE/weekly/2014/41/

has a breakdown "last year" and "last 5 years" of "LIR exact", "LIR 
more-specific", "non-LIR" (=PI), "non-LIR more-specifics" - look for
the heading "Routing Table by Class of Prefix".

The "LIR exact" curve is fairly linear, while the "more specific" curve
is growing stronger than linear.  No predictions here, though.

(You've propably seen this slide deck before - it's the "IPv6 routing
table talk" numbers fed into a daily-updated cronjob)

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Oct 2014 07:13:27 +1300

> reasons goes here> same deaggregation which is about half of the v4

I see no reason why it will be fundamentally different unless sites
start using the multi-prefix model of addressing, which would change
the game by allowing a site to be in multiple aggregates simultaneously.
I don't know exactly what impact that would have, but it would change
the game.

Alternatively we could abolish capitalism.

   Brian

---

From: Randy Bush <[email-masked]>
Date: Fri, 17 Oct 2014 11:18:49 -0700

> the game by allowing a site to be in multiple aggregates

and deaggregate them all :(

> Alternatively we could abolish capitalism.

no, just capitalization

randy

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 17 Oct 2014 21:45:40 +0100

> trying to find protein in this whole thread.

thin pickings :-(

> reasons goes here> same deaggregation which is about half of the v4

It might, but it won't matter as much because the number of baseline ipv6
allocations will be a whole pile lower.  Here's why.

1. retrospectively: the RIR policies of not handing out piecemeal
allocations based on 2Y policy means that most organisations will never
need a second allocation outside their /32.  If you look at existing RIR
allocations, many of them are to the same organisations.  Looking at:

ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt

There are:

	7564 LIRs with ipv4 allocations outside 185/8
	19856 ipv4 allocations outside 185/8

so the average # of allocations per LIR is ~2.62 for pre-last /8 addresses.

Over all allocations, the numbers are 24416 allocations and 10134 LIRs.
I.e. the last /8 policy has dramatically increased the number of LIRs with
a single allocation.  Possibly this is related to lack of PI space.

RIPE has allocated 8069 ipv6 prefixes to 7849 LIRs, i.e. an allocation rate
of 1.02.  This includes last /8 assignments from RIPE's silly policy of
requiring an ipv6 allocation for a last /8 assignment.

This indicates that virtually all LIRs are staying within the bounds of
their original allocations.  This will reduce future pressure on the number
of prefixes in the dfz.

2. in future: there are 10398 LIRs listed in alloclist.  Of these, 7849 or
almost exactly 75% of LIRs already have IPv6 allocations.  So assuming that
all RIPE LIRs will have an ipv6 allocation in future, that's growth from
8069 to ~10700 + one for each new LIR.

3. further deaggregation of the ipv4 dfz will be driven by the market
economics of address holders splitting up their net blocks.

4. down the road, if we can get RIPE to stop its silly policy of requiring
an ipv6 allocation in order to get an ipv4 allocation from the last /8,
this will further reduce pressure on the overall number of allocations,

> when their suits called our suits and said "we pay you to let us contact

The baseline for starting to deaggregate will be much lower for ipv6 and
there will be much less pressure in future to deaggregate.

I haven't looked at the other RIR figures.  No doubt they differ in
numbers, but my hunch is that they tell a similar story.

Nick

---

From: Pedro Andres Aranda Gutierrez <[email-masked]>
Date: Sat, 18 Oct 2014 06:15:28 +0200

Just my .002.
Maybe it could help in the discussion to make a distinction between subnets
of an AS and different ASes.
Clearly there is no solution for the latter. And for the first, there will
be lots of controversy ;-)
IPv6 BPs could mandate best aggregates only.

/PA

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 18 Oct 2014 11:06:09 +0200

> IPv6 BPs could mandate best aggregates only.

You can't *mandate* anything in BGP until you have a way to
effectively enforce it regardless if this is v4 or v6 or v9.

It is not the problem of folks in shorts and sandals who type in BGP
policies, but as Randy said those in suits who care about their
respective businesses.

Today at most we can have Geoff very nicely illustrating the picture
at next RIPE or NANOG. But he does not have a way to issue fine
tickets to offenders :)

Best,
r.

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 18 Oct 2014 11:09:20 +0100

> effectively enforce it regardless if this is v4 or v6 or v9.

it's a common misconception that bgp is a stick to beat people with, and
that the RIRs are the routing police.

Nick

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 20 Oct 2014 17:58:50 -0400

> so the average # of allocations per LIR is ~2.62 for pre-last /8 addresses.

wow, there are 4454 LIR allocations inside 185/8 :) with: 4568
distinct prefixes.
(that's probably reasonably expected though)

> a single allocation.  Possibly this is related to lack of PI space.

is this also skewed because 'space is getting short, make sure to get
your requests in NOW!' behavior? (or 'scarcity got people's
attention')

I guessed (so probably not the best judge for science) that 62/8 was
being allocated for a longer bit of time, it seems:
 Apr 1997 -> Mar 2011

There are 671 allocations in this space though, across 457 LIRs or
1.49 prefixes/LIR... so it seems that the numbers oscillate a bit
inside of the buckets, interesting I suppose. (perhaps not super
germaine though)

NOTE: why don't v6 allocations in that file have 'ALLOCATED PA' in
their entries?
    20121123    185.11.8.0/22   ALLOCATED PA
    20101023    2a02:2718::/29

despite:
inet6num:       2a02:2718::/29
netname:        YE-PTC-20101023
descr:          Public Telecommunication Corporation
country:        ye
org:            ORG-PTC4-RIPE
admin-c:        YAA330-RIPE
admin-c:        IIA13-RIPE
tech-c:         MRA220-RIPE
status:         ALLOCATED-BY-RIR
mnt-by:         RIPE-NCC-HM-MNT

> their original allocations.  This will reduce future pressure on the number

I also wonder how much the spread of LIR/org really is? for MDN or
other uses of 'oops, I need another /32'.

> there will be much less pressure in future to deaggregate.

why is that? I thought geoff's numbers/reasons for deaggregation were
linked more to TE (perceived or supposed) than anything else? (maybe a
bunch of 'redistributed connected' as well)

-chris

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 20 Oct 2014 23:08:03 +0100

> NOTE: why don't v6 allocations in that file have 'ALLOCATED PA' in

because there are only two types of v6 blocks: ALLOCATED PA and ASSIGNED
PA.  The assignments aren't in that document and for v4, there are several
types of status: ASSIGNED PA, ASSIGNED PI, ALLOCATED PA, ALLOCATED PI,
EARLY REGISTRATION OR LIR-PARTITIONED.

> bunch of 'redistributed connected' as well)

the baseline is lower because we're starting off with a situation where
most LIRs have been allocated all the ipv6 address space they will ever need.

The deaggregation pressure will be lower because the only deaggregation
pressure will be from TE and there will be no need to slide-n-dice IPv6
address blocks in future asset sales, and no last /20 per RIR.  IPv4 space
has deaggregation pressure from last /8 assignments, from TE requirements
and will have future pressure from asset sales.  Once divided, the
allocations will be impossible to reaggregate.

Nick

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Oct 2014 07:41:43 +0900

> pressure will be from TE

funny, that was not the case with v4 four years ago

    Luca Cittadini, Wolfgang Mühlbauer, Steve Uhlig, Randy Bush, Pierre
    Francois, Olaf Maennel, Evolution of Internet Address Space
    Deaggregation: Myths and Reality, in IEEE Journal on Selected Areas
    in Communications, Vol. 28, No. 8, October 2010.

there seems to be a lot of deagg because of the perception that it
reduces the threat of mis-origination of one's routes.  asia/pac is the
poster child for this but the competition is keen, see geoff's reports.

tl;dr (from the abstract):

    The impact of “bad guys” on routing table size growth and BGP churn
    has not changed for the worse in recent years. Rather, it increases
    at the same pace as the Internet itself.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 21 Oct 2014 01:14:57 +0100

> poster child for this but the competition is keen, see geoff's reports.

this could be highly entertaining in the ipv6 world.

Nick

---

From: Gert Doering <[email-masked]>
Date: Thu, 23 Oct 2014 10:41:32 +0200

Hi,

> barnacles at the bottom of the ocean.

What I find scary in this statement is the underlying "one solution must
fit all users" mentality.

I can fully see and understand Owen's point that in an *enterprise*
environment, renumbering is truly hard, because you need to get lots of
other people that have no real interest to renumber stuff in their config
files - and yes, vendors of <whatever> that could handle DNS lookups and
combinations of "get prefix from DNS, attach <localbit>, put result into
usage" would be truly nice, but indeed, that should have been specced
15 years ago to be available now (maybe).

OTOH, there's the large mass of SOHO style users, where "dynamic host
renumbering" *really* is a non-issue.  I've gone there and tested it
in a homenet testbed with two IPv6 uplinks, so multi-homing and 
src-based routing thrown in - it works.  It needs polishing and some
IETF work here and there (SAS failover comes to mind, and labels-to-
prefixes) but it works better than "IPv4 with two providers" today,
for that particular class of users.

PI(-ish) "for everybody" is just not the right solution for non-technical-
savy users that would just not know that these funny numbers they received
from one of their providers are relevant, and lose them - thus, when changing
providers, would get new ones anyway.  And what do they need static addresses
for, anyway, as long as some sort of "register and lookup" mechanism exist
(mDNS, DNS, SIP, ...) to find the address when needed?

No, Owen's home does not qualify for a typical "SOHO" network, and most
likely, none of the other readers.  Ask yourself, what is needed to make
the network on your parent's home work (assuming those are not network
engineers).

Gert Doering
        -- NetMaster

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 25 Oct 2014 16:07:00 +0200

On 25 Oct 2014, at 15:09, Ray Hunter <[email-masked]> wrote:

> This is natural behaviour, unless there's a less blunt instrument applied to managing BGP routing table size than simply restricting maximum prefix length per peer.

Please have a look at my draft. I think that establishing an aggregate of last resort coupled with BGP communities that allow for selectively filtering deaggregates covered by an aggregate in the places where they aren't desired helps both big organizations and network operators.

If a big organization hires two tier-1 ISPs, for instance, and then makes sure that the ISPs that its organizational subunits select for their connectivity interconnect with the ISPs announcing the AoLR (as peers or as customers), only networks that get paid need to carry the deaggregates. Which is good for the ISPs that get paid (obviously), for the ones that don't get paid (no deaggregates) and for the organization (they know who to blame for connectivity issues).

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 26 Oct 2014 12:05:22 +0100

On 25 Oct 2014, at 16:43, Ray Hunter <[email-masked]> wrote:

> I'm not convinced your draft is in line with my own understanding of how multinationals I know either use, or want to use the Internet, and why the de-aggregation occurs in the first place.

> I'd thus like to see more data on where/why the de-aggregation is occurring.

Yes, that would be good to know. I guess when I have some time I'll take the Fortune 500 and see what they inject in the global routing table.

However, it's still early days for IPv6 so what we see today isn't necessarily a reflection of what's needed in the future.

> Internet "offload" is a common requirement for low value traffic, in conjunction with a private high quality internal Intranet for corporate apps like design tools, with both networks active simultaneously.

> My thinking is that SADR, and running multiple (PA) prefixes within an enterprise will address this requirement. So each sub unit would carry both the multinational/global PI space and one or more local PA space prefixes obtained from the local ISP. Only the local PA space would be advertised out of each break out. That would be and prevent the need for de-aggregate routes to be advertised back into the individual ISPs serving the sub unit satellite sites.

Do you have any examples of networks doing this? Using multiple addresses is not easy.

> Equally GRE tunnels or IPSEC tunnels over Internet are already common-practice to create virtual enterprise networks.

But that doesn't mean you want all your employees in Europe browsing the web through a tunnel to North America.

> > 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.

> I don't think enterprises want to be tied to ISP's at all.

What do you mean? That they run their own network? Or that they can switch ISPs easily? No reason the latter couldn't be accomplished with the aggregate of last resort service.

> I don't know of any small set of ISPs that can economically provide service in 50+ countries in some sort of coordinated aggregate ISP manner.

Simple. Pay ISPs 1 and 2 to announce the aggregate. Then go look for ISPs 3 - 50 and tell them if they want your business, they have to interconnect with 1 and 2 (as customers or peers, you do't care). 1 and 2 need to be present globally or close to it but not necessarily locally, while 3+ need to be available locally but not necessarily globally.

> > In theory, a user in Tokyo could connect to the internet in Madrid. In practice, this is is exceedingly rare.

> I don't agree with this observation. I know of many cases e.g. where a break in/out for a 3rd party from China is made in Europe. Or where a US based company manages systems remotely in Europe, LATAM, Asia Pacific, and the US and has regional links to the customer (with a break in/out per region).

Can you provide IP addresses that can be tracerouted?

> My particular worry with aggregates of last resort would be that with longest prefix match matching, it's becoming increasingly easy for longer prefixes to hijack important enterprise aggregates. So advertising an aggregate of last resort, whilst allowing sub units to advertise longer prefixes to other ISPs, might not be such a great idea for security.

I guess the draft adds one issue here: an attacker could inject a longer prefix but add communities that cause it to be filtered before it reaches certain places so the hijacking is less obvious.

But unless you want the IPv4 table to be 14M /24s and the IPv6 table be some unholy number of /48s, the real solution to prefix hijacking needs to be found elsewhere.

---

From: Ray Hunter <[email-masked]>
Date: Sat, 25 Oct 2014 15:09:51 +0200

> Or perhaps something simpler would work here -- bounding longest match.

No.
Now we've "solved" the address space issue, we focus back on routing 
table size angst. History repeats.

My (tiny) datapoint on multinationals is that they're simply grabbing 
/32's (or as big as possible space) from multiple registries as soon as 
possible: remembering how much of a battle it was in IPv4 to get PI 
space properly routed, and assuming that this same discussion would 
resurface in IPv6, and that maximum prefix length would once again 
become a hot topic..... short prefixes are "better". Get 'em now while 
you can.

This is natural behaviour, unless there's a less blunt instrument 
applied to managing BGP routing table size than simply restricting 
maximum prefix length per peer. e.g. RIR charge being dependent on the 
number of global routing slot entries, rather than purely on address 
space allocation size.

And yes, of course, de-aggregation is a potentially serious DOS vector.

Meanwhile, renumbering is still hard.

-- 
Regards,
RayH

---

From: Ray Hunter <[email-masked]>
Date: Sat, 25 Oct 2014 16:43:31 +0200

> Iljitsch van Beijnum <mailto:[email-masked]>
> 25 October 2014 16:07
>
> Please have a look at my draft. I think that establishing an aggregate 
> of last resort coupled with BGP communities that allow for selectively 
> filtering deaggregates covered by an aggregate in the places where 
> they aren't desired helps both big organizations and network operators.
>
> If a big organization hires two tier-1 ISPs, for instance, and then 
> makes sure that the ISPs that its organizational subunits select for 
> their connectivity interconnect with the ISPs announcing the AoLR (as 
> peers or as customers), only networks that get paid need to carry the 
> deaggregates. Which is good for the ISPs that get paid (obviously), 
> for the ones that don't get paid (no deaggregates) and for the 
> organization (they know who to blame for connectivity issues).
>
I'm not convinced your draft is in line with my own understanding of how 
multinationals I know either use, or want to use the Internet, and why 
the de-aggregation occurs in the first place.

Particularly my perception does not seem to fit the assumption of Section 2.

 > 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.

Internet "offload" is a common requirement for low value traffic, in 
conjunction with a private high quality internal Intranet for corporate 
apps like design tools, with both networks active simultaneously.

My thinking is that SADR, and running multiple (PA) prefixes within an 
enterprise will address this requirement. So each sub unit would carry 
both the multinational/global PI space and one or more local PA space 
prefixes obtained from the local ISP. Only the local PA space would be 
advertised out of each break out. That would be and prevent the need for 
de-aggregate routes to be advertised back into the individual ISPs 
serving the sub unit satellite sites.

Equally GRE tunnels or IPSEC tunnels over Internet are already 
common-practice to create virtual enterprise networks.

I don't think enterprises want to be tied to ISP's at all. The hope/ 
dream is that once a prefix enters the global routing table, then it 
will be globally reachable.
I don't know of any small set of ISPs that can economically provide 
service in 50+ countries in some sort of coordinated aggregate ISP manner.

Equally, Section 3 seems to assumes that the customer/enterprise 
relationship is regional, which IMVHO is not always the case. 
www.myenterprise.com needs to be world wide reachable, but with local 
content delivered by CDN or local servers.

 > In theory, a user in Tokyo could connect to the internet in Madrid. 
In practice, this is is exceedingly rare.

I don't agree with this observation. I know of many cases e.g. where a 
break in/out for a 3rd party from China is made in Europe. Or where a US 
based company manages systems remotely in Europe, LATAM, Asia Pacific, 
and the US and has regional links to the customer (with a break in/out 
per region).

My particular worry with aggregates of last resort would be that with 
longest prefix match matching, it's becoming increasingly easy for 
longer prefixes to hijack important enterprise aggregates. So 
advertising an aggregate of last resort, whilst allowing sub units to 
advertise longer prefixes to other ISPs, might not be such a great idea 
for security.

-- 
Regards,
RayH