possibly noteworthy wrote:
Are you ready to pay $100 a month for residential access to the Internet?

No, but issuing IP addresses based on geographic location is LONG overdue.

possibly noteworthy wrote:

Are you ready to pay $100 a month for residential access to the Internet?

Decius replied:

No, but issuing IP addresses based on geographic location is LONG overdue.

That isn't going to fix things.

Report from the IAB Workshop on Routing and Addressing

Workshop participants concluded that the so-called locator/identifier overload" of the IP address semantics is one of the causes of the routing scalability problem as we see today. Thus a "split" seems necessary to scale the routing system, although how to actually architect and implement such a split was not explored in detail.

... All identifier/locator split proposals require a mapping service that can return a set of locators corresponding to a given identifier. In addition, these proposals must also address the problem of detecting locator failures and redirecting data flows to remaining locators for a multihomed site.

The locator-identifier split represents a fundamental architectural issue and IAB should lead the investigation into understanding of both how to make this architectural change and the overall impact of the change.

See also, Brief Update on The IAB Routing and Addressing Workshop:

deaggregation, multihoming, traffic engineering, power hunger and heat death; "a solution to id/loc split might help solve multihoming and mobility";

Need to find ways to a sustainable future rather than point fixes
The power issue is serious
What if we do try to untangle identities and locators?

Workshop on Locator/Identifier Split

The locator/identifier split is actually a far-reaching change to the Internet architecture, with many tendrils.

Do we need a new network model?

Who Are You? Identity and Location in IP, by Geoff Huston, APNIC

possibly noteworthy wrote:
Are you ready to pay $100 a month for residential access to the Internet?

No, but issuing IP addresses based on geographic location is LONG overdue.

That isn't going to fix things.

... All identifier/locator split proposals require a mapping service that can return a set of locators corresponding to a given identifier. In addition, these proposals must also address the problem of detecting locator failures and redirecting data flows to remaining locators for a multihomed site.

I'm confused. Issuing IP addresses based on geographic location is precisely what these people mean when they talk about the "identifier/locator split." I don't really see the use of IPs as identifiers as being terribly important. That is what the domain name system is for. There is a lot of legacy tied up in it, and we don't really have a good understanding of how to do (or enforce) geographic IPing, but thats what we need to do.

I'm not new to this question. Abaddon and I were about 50% of the way through writing a prototype for using Diffie Helman key exchanges to allow TCP connections to persist through IP address changes, but we stopped when we heard about HIP. I haven't looked at HIP in detail. It was mostly "fuck, someone else figured this out" and we gave up on it. Perhaps I should...

Decius wrote:

I'm confused. Issuing IP addresses based on geographic location is precisely what these people mean when they talk about the "identifier/locator split."

Abaddon and I ... writing a prototype ... to allow TCP connections to persist through IP address changes ...

If by geography you are referring to the Earth, then no, that's not what it means. It's more at topology rather than physical location.

The problems derive not only from host mobility (which HIP attempts to address) but from pervasive multihoming and the drive for provider-independent address space, which is inherently at odds with aggregation.

This is about BGP more than it is about end hosts.

possibly noteworthy wrote:
Decius wrote:

I'm confused. Issuing IP addresses based on geographic location is precisely what these people mean when they talk about the "identifier/locator split."

Abaddon and I ... writing a prototype ... to allow TCP connections to persist through IP address changes ...

If by geography you are referring to the Earth, then no, that's not what it means. It's more at topology rather physical location.

The problems derive not only from host mobility (which HIP attempts to address) but from pervasive multihoming and the drive for provider-independent address space, which is inherently at odds with aggregation.

This is about BGP more than it is about end hosts.

The topology is literally defined by geography. Computers might move but large computer networks generally do not. In order for geographic IPing to solve the problems that multihoming and provider independent space cause for routing table aggregation you have to have municipal peering.

Your IP needs to reflect, at some level, a large region such as a continent, as well as a metropolitan area within it. If everyone in every metro area is roughly in the same space, and its possible for networks to trade traffic at the metro level, then backbone routing tables can be relatively simple. You'll see increased complexity within the metro peering locations, but the scope of the network they have to concern themselves with is smaller. You can have provider independent space, but its tied to your metro area, and it can get aggregated at a higher level so that it doesn't impact backbone complexity.

There really is no other way to organize things.

possibly noteworthy wrote:

This is about BGP more than it is about end hosts.

Decius replied:

The topology is literally defined by geography.

In theory you could design it that way, but this wreaks havoc on the economic model of the Internet. BGP is designed to meet business needs first, and engineering needs second.

Computers might move but large computer networks generally do not.

This is not entirely true. But there is more to dynamic topology than "moving".

In order for geographic IPing to solve the problems that multihoming and provider independent space cause for routing table aggregation you have to have municipal peering.

Your IP needs to reflect, at some level, a large region such as a continent, as well as a metropolitan area within it.

It sounds like you're describing Steve Deering's IPv6 Metro Addressing:

We propose a scheme for allocating IPv6 Geographic Addresses for use in the Internet, as an alternative to the scheme recommended in [PROV]. This scheme is consistant with the IPv6 Addressing Architecture [ARCH] and uses the "100" Format Prefix. The essence of our scheme is that the IPv6 addresses allocated to a particular "leaf" routing domain, such as a campus, a corporate site, or a personal residence, have a prefix which identifies the country and city in or near which the leaf domain attaches to a transit routing domain, such as a regional or wide-area network. Such IPv6 addresses are similar to plain old telephone numbers, which start with country and city codes (or "area codes" in North America; we forgo the "area" terminology to avoid confusion with the previous use of that word). Unlike the current practice in the telephone system, however, we allow more than one "carrier" to offer transit delivery service into, out of, and within the geographic scope of a single city code. IPv6 addresses based on city codes identify where leaf domains obtain their transit service; they do not identify the carriers providing the service.

See also, more recently, eFIT: A Proposal for Scalable Internet Routing & Addressing:

Our measurement studies of the global Internet routing system show that prefix de-aggregation has led to the DFZ routing table size growing at a rate which is much faster than the Internet itself. The main causes of prefix de-aggregation include user site multihoming and traffic engineering. We propose to move Internet service providers to a separate address space as an effective solution to the routing scalability problem. We discuss different means to provide the mapping service between user and provider address spaces and the pros and cons of each approach, as well... [ Read More (0.2k in body) ]

possibly noteworthy wrote:
In theory you could design it that way, but this wreaks havoc on the economic model of the Internet.

In some respects, provider independent IP addressing "wreaks havoc" on the economic model of ISPs. If its a question of whether the interests of users or the interests of transit providers should dominate policy, the answer is that users will eventually win. I don't buy the idea that its impossible to organize ISPs.

There are other schemes, and they are quite compelling, but they are still in the research stages.

I haven't read that paper. I will. It seems odd that there would be some sort of magic routing fairy dust that would make a problem like this go away. There must be some sort of tradeoff...

Decius wrote:

It seems odd that there would be some sort of magic routing fairy dust that would make a problem like this go away. There must be some sort of tradeoff ...

Yes, of course. Two things:

1) From the paper I referenced before:

Compact routing schemes comprise a set of algorithms that aim to make a good tradeoff between stretch versus the amount of storage required at each vertex for routing tables. Stretch refers to the (usually worst-case) multiplicative factor increase of path length between a pair of vertices under a particular routing scheme versus the length of the shortest existing path between the same pair. The most efficient stretch-3 routing scheme for generic (arbitrary) graphs currently known is due to Thorup-Zwick [3], which we will simply refer to as “the TZ scheme.” It is known to be optimal, up to a logarithmic factor, for per-node memory utilization.

This tradeoff has been known since at least 1977; see

L. Kleinrock and F. Karnoun. Hierarchical routing for large networks; performance evaluation and optimization. Computer Networks, 1:155-174, 1977.

That paper is apparently not online.

From a JHU paper:

The compact routing problem considers a tradeoff of stretch for [routing table, and packet header] space, in the setting where each node locally stores its own routing tables. The stretch of a compact routing algorithm is defined as the maximum stretch over the routes for all pairs of nodes in the network. Clearly if each node stores the O(log n)-bit name of the next node along the shortest path to node TI, for all v E G, this complete routing table gives all shortest path distances. The resulting routing scheme uses O(n log n) space at every node, and has optimal stretch one. This paper answers the question: what is the minimum achievable stretch of any compact routing scheme with sublinear space at each node?

2) The best known schemes are static. Work is progressing on schemes for dynamic networks. See Compact Routing With Name Independence: (shorter version here)

This paper is concerned with compact routing schemes for arbitrary undirected networks in the name-independent model first introduced by Awerbuch, Bar-Noy, Linial and Peleg. A compact routing scheme that uses local routing tables of size ~O(n*exp(1/2)), O(log^2 n)-sized packet headers, and stretch bounded by 5 is obtained, where n is the number of nodes in the network. Alternative schemes reduce the packet header size ... at the cost of either increasing the stretch ... or increasing the table size ...

... In this paper, we have... [ Read More (0.1k in body) ]