Re: [RRG] Long term clean-slate only for the RRG?

["William Herrin" <bill@herrin.us>]

On Sat, Jun 28, 2008 at 2:10 PM, David Conrad <drc@virtualized.org> wrote:
> The idea I've heard repeated is along the lines of the following scenario:
>
> a) IPv4 address space becomes more expensive as the free pool exhausts
> b) People with IPv4 space realize they can use NAT, renumber to private
> space, and sell off their IPv4 holdings.  This results in all an ISPs
> customers only needing a single PA address each.  The ISP can also offer a
> hosting service in which multiple customers share a single IP address in a
> virtual host web/smtp/whatever farm (each service being an additional cost,
> of course).
> c) ISPs buy up the freed up IPv4 address space and use it to assign single
> public addresses to their customers.  Given the use of NAT, renumbering
> impact is limited to the ISP, thus it is feasible that ISPs can trade
> address blocks with each other in order to obtain larger contiguous blocks
> and reduce announcements.
>
> In the end of this scenario, you have something that looks a bit like a
> final-state loc/id split albeit asymmetric instead of map-encap symmetric.
> Scaling concerns are greatly reduced (although not eliminated as 4 billion
> doesn't go as far as it used to).  Multi-homing (of a sort) is implemented
> by having multiple addresses from different providers on the CPE NAT box and
> playing stupid DNS games (e.g., short TTLs and dropping A RRs when
> connectivity failure is detected).

Hi David,

That boils down to: economic pressures recover PI space and reduce the
AS to announcements ratio. DNS games solve the small-player
multihoming problem.

I'll take the latter part first: operationally, DNS games for
multihoming has been demonstrated to be inadequate. The past decade
has seen the opposite movement: where services tolerant of spreading
load to multiple IP addresses like http and DNS itself have been
pulled back inward via things like anycasting and load balancers which
make multiple web servers appear under the same address. Things like
DNS SRV records which were supposed to help avoid this are virtually
unused. Customer rejection of DNS for resilience and local traffic
engineering is unambiguous.

That's not to say that DNS has been useless in this space. Services
like Akamai prove otherwise. However, DNS's positive impact has been
limited and very application dependent.

For the first part, I'd point out that the number of existing PI
assignments actually routed on the Internet is not sufficient to make
the problem equation meaningfully different. Further, the economic
pressures are all wrong for it happen: ISPs and Universities are poor.
Contractors are rich. The pressure will be to roll the residential
users of your /16 into several /24's fronting NATs and then sell the
other /24's in the /16 to small-but-well-funded projects that
absolutely-must-have reliability and can easily afford another $10k to
$50k to get it.

At the very least, this NAT approach is less likely to be valid than
the status quo.


>> 1. Status Quo.
>
> I might argue that this isn't stable in the long term due to the way RIR
> policies are defined.

I'd like to agree but the numbers point the other direction. My best
guess is that under the status quo the IPv4 route table will finally
stabilize somewhere between 6M and 8M prefixes. The /24 restriction
can't be effectively eliminated under the status quo. With /24 as the
longest announceable prefix, the theoretical maximum number of routes
is 33M but the conditions which would push routes to more than 25% of
that max are fantastically improbable.

IPv6 could add an effectively unbounded addition to that, but unless
it gains a heck of a lot of momentum from somewhere, ditching
bare-on-the-wire IPv6 to keep your router costs down remains an easy
choice.

The point is that 8M prefixes is actually doable under the status quo
approach. It would keep all the negative factors of the status quo and
gain some additional indirect cost but it's within the bounds of
doable.


>> 2. New IP layer-4 protocols and change everything up to layer 7.
>
> Agreed, although I'd hope that a new IP would implement some form of loc/id
> split.

Subnet mask is a kind of LOC/ID split as well. Let's not broaden to
the LOC/ID-split concept to a point where it doesn't usefully describe
anything.

IMO, LOC/ID split means a layer-3 change so that the layer-3 node
identity is structurally separate from the network location. Things
like map-encap and ermpi6 ( http://bill.herrin.us/network/ermpi6.html
) qualify as LOC/ID split.

I suggest that's conceptually different than removing ID from layer 3
altogether so that the layer-3 addressing represents -only- network
location while node identity is established at a higher layer in the
stack.

Regards,
Bill


-- 
William D. Herrin ................ herrin@dirtside.com bill@herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg