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

Wed Sep 3 09:57:05 EDT 2008

 can't speak for the 30k ASN's out there, but the couple dozen I have
touched in the past decade or so are perfectly willing to take a /25 
from me... most will not transit it though.

--bill

On Wed, Sep 03, 2008 at 09:53:48AM -0400, William Herrin wrote:
> 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
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.