[arin-ppml] IPv4 is depleted today - unrealistic statements about IPv6 inevitability

[William Herrin]

On Wed, Sep 3, 2008 at 5:58 AM, John Curran <jcurran at istaff.org> wrote:
> Just for my understanding, why would /24 remain a realistic lower
> boundary?  Is this assertion based on an assumption that (all) ISP's
> in a post-depletion situation will turn away prospects who show up
> with a /25 or smaller IP block?

John,

It's pretty hard to change. Nearly all of the 30k or so ASes filter at
the /24 boundary today and you'd need nearly all of them to change in
order to support the smaller blocks at the same time as cost pressure
from the growing routing table strongly encourages them to look for
ways to accept fewer routes instead of more.


On Wed, Sep 3, 2008 at 12:47 AM, Stephen Sprunk <stephen at sprunk.org> wrote:
> Yes, one IPv6 route is more expensive than one IPv4 route, due to the simple
> fact that they're longer.  However, it is expected (with a reasonable basis)
> that each org will have fewer IPv6 routes because the RIRs are deliberately
> giving each org far more space than they should ever need, plus reserving
> plenty of room for unexpected growth.  We're looking at an order of
> magnitude reduction, at least, in the number of routes in the DFZ if the
> current folks using PIv4 switched to PIv6.

Stephen,

No, we're not looking at an order of magnitude reduction. That's a
fantasy. After factoring in traffic engineering and multihoming
(neither of which have new magic in IPv6), the best case scenario is
that disaggregation drops from the current 8:1 to a little over 2:1.
Those gains are erased at the starting gate by the longer address
size.


>> And we know that there is no new magic in IPv6 routing: multihoming still
>> requires a unique global route.
>
> For now.  The RRG is working on that part of the problem.

Yes, we are. Shall I tell you what we've found so far?

We've found three broad categories of solutions:

1. Map-encap monolithic push
2. Map-encap pull-cache
3. Total dynamic addressing


Map-encap monolithic push

Map-encap monolithic push is essentially MPLS but in the inter-domain
space. Each AS pushes the minimum number of routes to satisfy
resilience and traffic engineering. All IPv4 and IPv6 prefixes are
then mapped to those routes through an alternate and much more static
distribution system. Packets are encapsulated (think: labeled) in a
tunnel packet which is delivered to the remote AS before
decapsulation.

If you believe as Tony does that the RIB is the first bottleneck, this
approach brings IPv4 routing in line with the best case scenario for
IPv6 routing at a much lower cost than deploying IPv6. Unfortunately,
it does jack for the FIB in either IPv4 or IPv6. Every router at the
border of the core still has to carry and process a full table.


Map-encap pull-cache

Pull-cache takes things another step. Origin-only ASes need no longer
orignate any routes into the system and transit ASes need only
originate one. Traffic engineering is moved into the map, sections of
which are queried (pulled) as needed by small map-encap routers near
the edge. Those routers label the packets with one of the destination
ASes which can handle local delivery.

Since no one router has to deal with the full table, this solves both
the RIB and FIB problems for both IPv4 and IPv6 down to a /32 and /128
level respectively at an expense much less than deploying IPv6. The
problem with this approach is that it requires a DNS-like delay to
pull and cache the map entry when two distant hosts first initiate
communication.


Total dynamic addressing

Do away with static address block assignment entirely. Your ISP
assigns and changes your addresses during operation at its
convenience. This dynamic address assignment is carried directly in
the routing protocol. The same thing happens to it upstream. As the
machine count grows, you get new assignments and the old addresses
rapidly expire. As a small multihomed user you get multiple addresses,
one from each upstream and run a route policy protocol so that
individual machines can make a reasonable choice about which address
to use for any given packet. The largest of users with many
interconnections (the current transit ASes) get their dynamically
assigned and dynaically changed block from a central authority and
route it with a BGP-like protocol.

Total dynamic addressing is a clean-slate solution. To make it work,
we have to jettison TCP and UDP. Layer 4 protocols and above have to
be redesigned to accomodate the fact that the layer-3 addresses no
longer identify the machine in any respect. The layer-3 addresses can
serve only to describe the machine's ephemeral location in the global
network graph.

With this approach, there's no reason the route count would ever again
top 100,000. It's a successor protocol to both IPv4 and IPv6. It
could, in theory, bootstrap itself on any existing IPv4 or IPv6
infrastructure since layer 4 and up care no more about layer 3 than
layer 3 cares about layer 2. But that's the closest relationship it
has with either IPv4 or IPv6.


Here's the thing I want you to realize: deploying IPv6 doesn't help
you with any of the three approaches. The first two solve the routing
problem for both IPv4 and IPv6 while the latter replaces both
protocols. We haven't found -any- realistic approaches to the routing
problem for which IPv6 offers more than a mild convenience versus
doing the same thing with IPv4.


Regards,
Bill Herrin


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