Re: [rrg] IPv4 & IPv6 routing scaling problems

[Paul Jakma <[e-mail]>]

On Thu, 4 Feb 2010, Robin Whittle wrote:

> All that is happening with IPv4 is that the last fresh paddocks of
> unused land are now being built upon.  There's plenty of scope for
> squishing houses closer together - and then for building multi-storey
> houses (NAT).   Without NAT, some kind of crunch would occur with
> IPv4 if there was ever a need to connect more than about 3 or 3.5
> billion hosts at any one time.  With NAT, there's no limit.
>
> NAT is not the ideal of any-to-any Internet connectivity, just like
> the crowded suburbs with multi-storey dwellings don't provide all the
> benefits of living in an uncrowded piece of countryside.  But just as
> crowded cities get more crowded, so will IPv4.  The attraction is the
> same for cities as for the choice of which Internet use - most people
> want and need to be where all the other people are.

If we're thinking in terms of analogies, it's important to note where 
they break down. The "build up, cause can't build out" analogy breaks 
down in 2 ways:

1. Earth isn't Trantor yet, many urban areas are still expanding.

    (Indeed, in europe, urban areas in many cases have gotten /less/
     crowded precisely through outward expansion and rehousing people
     from congested slums of the industrial revolution to developments
     and "new towns" in the country side, what we know think of as
     suburbs.)

2. There is no definite limit to building up, though it does
    become more costly to engineer whereas there are definite limits
    to 'building up' in IPv4.

    I.e. we /can/ make bigger and bigger buildings, for a given
    footprint. Whereas there are fixed, fundamental limits to IPv4
    that hard-constrain how many of todays ULPs can go through.

You might respond that the internet would adapt by changing the ULPs 
to better make use of IPv4. E.g. we could make NAT friendly 
transport protocols:

   - Add a "Internal host ID" field to ULP headers, like TCP.
   - Increase the range of the flow^Wport ID

So that a transport address on the internet then becomes some kind 
of 3 tuple:

  (public IP of the concentrator, network specific host ID, flow/service ID)

The core internet routing tables are then constrained to O(|public IP 
space|).

Concentrators can be stateful or stateless at their discretion. If 
concentrators are stateless, you could even have anycast 
concentrators and have a number of concentrators service a single 
concentrator ID.

So basically, your argument is that the locator/identifier split 
should be done by changing transport protocols - retaining IPv4 
compatibility - rather than done by shimming something in to make it 
all transparent to ULPs (map and translate/encap).

I have to say, I kind of agree that changing the transport is the 
best way to go in the long run. It's simpler than map-encap and it 
seems we could as easily upgrade the transport layer on the internet 
as we could move the internet to IPv6 (needed for some map 
translate/encap proposals). Plus, it'd work with either v4 or v6.

Anyway, I guess I'm stating the obvious :)

NB: The upper-layer adaption could also be done without touching the 
transport layer, through higher-level application specific 
multi-plexing. But then we definitely no longer have anything 
resembling the internet, and I assume no one here wants that.

regards,
-- 
Paul Jakma	[e-mail]	Key ID: 64A2FF6A
Fortune:
"The medium is the massage."
-- Crazy Nigel