![nanog logo](/images/nanog-logo.png)
nanog mailing list archives
Re: geography to get PI in v6 (was: ULA and RIR cost-recovery)
From: Iljitsch van Beijnum <iljitsch () muada com>
Date: Thu, 25 Nov 2004 14:27:07 +0100
On 25-nov-04, at 13:46, Michael.Dillon () 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.
Current thread:
- Re: who gets a /32 [Re: IPV6 renumbering painless?], (continued)
- Re: who gets a /32 [Re: IPV6 renumbering painless?] Adi Linden (Nov 19)
- Re: who gets a /32 [Re: IPV6 renumbering painless?] Stephen Sprunk (Nov 19)
- Re: who gets a /32 [Re: IPV6 renumbering painless?] Owen DeLong (Nov 19)
- ULA and RIR cost-recovery John Curran (Nov 22)
- RE: ULA and RIR cost-recovery Tony Hain (Nov 23)
- RE: ULA and RIR cost-recovery Owen DeLong (Nov 23)
- RE: ULA and RIR cost-recovery Tony Hain (Nov 24)
- Re: ULA and RIR cost-recovery Steven M. Bellovin (Nov 24)
- RE: ULA and RIR cost-recovery Tony Hain (Nov 24)
- Re: ULA and RIR cost-recovery Michael . Dillon (Nov 25)
- Re: geography to get PI in v6 (was: ULA and RIR cost-recovery) Iljitsch van Beijnum (Nov 25)
- RE: ULA and RIR cost-recovery Måns Nilsson (Nov 29)
- Re: ULA and RIR cost-recovery Daniel Roesen (Nov 29)
- Re: ULA and RIR cost-recovery Leo Bicknell (Nov 29)
- Re: ULA and RIR cost-recovery Owen DeLong (Nov 29)
- Re: ULA and RIR cost-recovery Leo Bicknell (Nov 29)
- Re: ULA and RIR cost-recovery Pekka Savola (Nov 29)
- Re: ULA and RIR cost-recovery Owen DeLong (Nov 29)
- Re: ULA and RIR cost-recovery Pekka Savola (Nov 29)
- Re: ULA and RIR cost-recovery Owen DeLong (Nov 30)
- Re: ULA and RIR cost-recovery Crist Clark (Nov 24)