geography to get PI in v6 (was: ULA and RIR cost-recovery)

Thu Nov 25 13:27:07 UTC 2004

On 25-nov-04, at 13:46, Michael.Dillon at radianz.com wrote:

>
>> The problem with this scheme is that it's only aggregatable if there's
>> some POP that lots of carriers connect to in the proper geographic
>> areas.  What is the carriers' incentive to show up -- peer? -- at such
>> points, rather than following today's practices?

> Leaving aside the specifics of any particular geopgraphic
> addressing scheme for the moment...

Right. There are several ways to do this.

> If we adopt a geographic addressing scheme for a part of
> the IPv6 space we are really saying that we expect a
> part of the IPv6 network topology to be geographically
> based.

This is what it seems like on first glance. However, if we take a 
different approach we arrive at the same result but with a very 
different mindset.

The idea is that we need to aggregate, because if we let anyone and 
everyone have a PI block without aggregation in IPv6 bad things will 
happen to the global routing table. The obvious thing to aggregate on 
is the ISP used. This is what we do every day. Unfortunately, you don't 
get provider independence this way.

With provider aggragation out the window, it turns out that it doesn't 
really matter much on what you aggregate. For instance, we can 
aggregate on the first byte of the IPv4 address. So all destinations 
that have 192 as the first number in their address are aggregated 
together, just like 193, 194 and so on. Suppose we have three routers:

Router A contains all more specifics for 192/8 and the 193 and 194 
aggregates
Router B contains all more specifics for 193/8 and the 192 and 194 
aggregates
Router C contains all more specifics for 194/8 and the 192 and 193 
aggregates

So all traffic towards any destination within 192/8 will have to flow 
through router A, and so on. This works very well if router A is close 
to the destinations in question, but it gets problematic when there 
aren't any routers covering the aggregate for a certain destination 
close to that destination. So if destination X with address 192.0.0.1 
is in Paris, and router A is also in Paris, this works out great. If 
router A is in London or Frankfurt, this isn't quite optimal but the 
scenic routing isn't too bad. But if router A happens to be in 
Auckland, this is not so great.

There are two ways to solve this:

1. Have router A instances everywhere. This basically means multiplying 
the number of routers by the number of aggregates used. Not so great.
2. Rather than aggregate arbitrarily, do it based on geography so there 
only need to be a few router A instances.

> While it is convenient to think og geographical
> divisions in terms of boundaries, in real world networks
> the geographical divisions are defined by peering points
> which the real world refers to as "major cities". So if
> we do adopt a geographic addressing scheme it makes no
> sense at all for the RIRs to allocate these addresses to
> entities that happen to be inside a specific geographic
> boundary.

No. You are assuming a single aggregation level. But there can be many: 
city, state/province, country, continent. If I have traffic for Amazon, 
all I need to know is that it should make its way across the Atlantic. 
At the US East Coast, there are probably aggregates for all the US 
states, and finally in or close to Seattle all more specifics must be 
present.

Should there not be an interconnect with other networks in Seattle, 
then the more specifics must be present in a wider area. So peering 
within the target area isn't required, although it makes for better 
aggregation of course.

> However, it makes perfect sense to allocate
> these geographic addresses to an entity who is peering
> at one or more of the peering points within a geographic
> boundary.

Peering can change. Geography can't. (Unless you live in an 
earthquake-prone region.)

The advantage of doing geographic aggregation like this (i.e., the 
aggregates are only used within ISP networks and not announced to other 
ISPs) is that everyone can implement the aggregation as desired without 
global coordination, but the PI benefits start as soon as end-users get 
the geographically aggregatable address space. So it makes no sense to 
adopt unaggregatable PI space, geographically aggregatable provider 
independent (GAPI) address space is always better.