Subject: [RRG] Host changes & user costs of adopting map-encap addresses

From: Robin Whittle <[email-masked]>
Date: Thu, 14 Feb 2008 18:13:40 +1100

In "Re: [RRG] Why delaying initial packets matters", Tony Li wrote
of my agreement with Lars Eggert's: "Deploying something new at the
network layer that might require changes to host stacks or
applications to maintain performance at current levels would be a
non-starter.":

> Oh good, so then we can cancel IPv6 too?

IPv6 has been available for a decade or so and hardly anyone uses
it.  As far as I know, no-one uses it exclusively.  The problem is
not so much with IPv6 but that there's no backwards compatible
upgrade from IPv4.

Host operating systems and applications (in some or many cases?)
need to be upgraded, and all routers need to be upgraded or have a
second layer of configuration added to them.  Then there needs to be
IPv6 space, if your ISP could provide it - and in general that has
meant no portability or multihoming.  All this effort for no obvious
benefit, until the end user finds there are sites or services which
work best, or only, on IPv6.  This hasn't happened, nor is it likely
to happen any time soon, because IPv4 does the job fine.

In msg 282, Feb 8th, Tony also wrote:

> The incentive for everyone is to deploy a scalable routing
> architecture that serves us for the long term.  Regardless of the
> proposal that RRG puts forward, it's thermodynamically impossible
> that it will have no cost.  There will be deployment costs,
> forwarding plane changes, and a mapping subsystem to support.

We should reduce the end-users costs of adopting the new address
space as much as possible.  I think our task includes:

1 - Create an architecture which solves the routing scalability
    problem for multihomed, transport engineering end-users who
    also want and need number portability.

2 - Make the architecture as elegant, open and extensible as we
    can.

3 - Ideally, have the architecture solve other problems and/or
    provide new services, such as mobility with optimal or near
    optimal path lengths.

4 - Make the new kind of address space have as few downsides
    as possible for end-users of all sizes.  (See my msg 275:
    Large companies with PI, small with map-encap space?)

I think we should aim to have the direct costs borne by ISPs - and
perhaps larger end-users who currently have PI space, and who would
reduce costs and get more flexibility by migrating their space to
the map-encap scheme (or giving it up and adopting a separate
map-encap set of addresses).  Then, the rest of the end-users will
feel no direct incremental cost in adopting the new kind of address
space.  Ideally, they will do so en-masse because there are
immediate overall benefits, even if the space costs them more than
the PA space they currently use.

End-users ultimately pay all the expenses of ISPs, so the end-users
pay in the end.  But everyone benefits in the long run, because the
BGP system can be left to run merrily for many more years without
bloat in the number of DFZ routes, and because even end-users who
don't adopt the space will benefit from cheaper, better services
provided by end-users who do adopt it.

> Having a functioning Internet for our great grandchildren is
> the benefit and without that, the hosting companies are simply out
> of business.

Sure, but no company is going to put resources into IPv6 or some new
map-encap scheme just because of purported long-term benefits to
humanity.

We need to make the map-encap scheme an immediately positive
experience for all the end-users who adopt it, because we want it to
be very widely used, by end-users large and small.  I think this can
be done, and I think the benefits of the new kind of address space
will make it a marketable, potentially profitable, business
proposition for the organisations (typically ISPs) who provide it.

The new scheme will be incrementally deployable, with immediate
benefits to the early adoptors.  This is not the case with IPv6,
which is why it is hardly used at all.  But that is not the fault of
IPv6, since no-one has been able to think of any incrementally
deployable upgrade from IPv4.

The ITR - ETR infrastructure is a very powerful tool which has never
been contemplated before.  I wonder if a good map-encap architecture
could be used as part of some migration plan from IPv4, in ways we
have not thought of before.

  - Robin

--
to unsubscribe send a message to [email-masked] 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

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 14 Feb 2008 10:41:08 +0100

> not so much with IPv6 but that there's no backwards compatible

http://rnrt-infradio.lip6.fr/indexEnglish.html
http://www-rp.lip6.fr/~leroux/meshdv/index.html

Pure IPv6, no IPv4 backup, and it works......

Luigi

Luigi Iannone

[email-masked]

---

From: Robin Whittle <[email-masked]>
Date: Thu, 14 Feb 2008 21:36:27 +1100

I wrote of IPv6:

> As far as I know, no-one uses it exclusively.  

> Pure IPv6, no IPv4 backup, and it works...... 

IPv6 works, but this system is intended only for a specific set of
users in a small geographic area - not for global accessibility of a
website, server etc. via the Internet which was what I was intending
to refer to.  Maybe there was something special about IPv6 which
provides and advantage for this project, but I didn't see it in a
cursory look at these sites.

I don't want to rehash the IPv6 debate other than to say that for
the majority of end-users, IPv6 connectivity can't replace IPv4
connectivity since they need connectivity via a wide variety of
protocols with the majority of other end-users who only have IPv4.

IPv6 (or any other alternative to IPv4) brings no direct benefits to
early adoptors unless they have a special purpose in mind which IPv6
suits better than IPv4, or unless they absolutely can't get the IPv4
address space they need.

So in terms of mass adoption of IPv6 dual-stack and of IPv6 alone,
for ordinary users who need global Internet connectivity, IPv6 or
any other alternative to IPv4 is not incrementally deployable.

A good map-encap will be incrementally deployable, fully backwards
compatible and will provide immediate benefits to end-users who
adopt it.  If we get the architecture right, we won't have to cajole
anyone into using it.

 - Robin