Re: [RRG] Consensus? IPv4 scaling problem must be solved directly, not by relying on migration to IPv6

[Robin Whittle <rw@firstpr.com.au>]

Hi Randall,

You wrote:

> % In order for IPv6 adoption to play a significant role in the
> % reduction of the IPv4 routing scaling problem, several things
> % would need to be true:
> 
> I disagree with the set of conclusions you reached about
> which things "would need to be true".

OK.


> % 1 - A significant number of new or existing end users (and their
> %    ISPs) would need to run their Internet services using only
> %    IPv6 addresses.
> 
> No.  A significant number of ISPs would need to support IPv6,
> which either is true now or will be true before the IETF
> processes could generate new standards based on a Routing
> RG architectural recommendation.
> 
> There is no need for "only IPv6" above.

OK - the end-users need to use IPv6 only addresses, so they are not
requiring IPv4 address space.  I was mistaken to write that ISPs
need to be IPv6 only.


> % 2 - With the possible exception of cell-phone end-users (who have
> %    telco-provided operating systems and applications on their
> %    devices) no ordinary end-users can be happy with their Internet
> %    service unless it provides full connectivity to "all" other
> %    Internet hosts, using the full range of applications which
> %    other Internet users use.
> 
> Most Internet users don't use most applications/protocols.  In fact,
> for the overwhelming majority of users, the set of application
> protocols that need to work properly is quite limited.
> 
> Roughly speaking, this is the set that most users care about:
> Email:  POP3, IMAP4, SMTP
> Web:    HTTP, HTTPS
> IM:       various proprietary IM protocols, Jabber

Also:

   Any number of game protocols.

   Any number of P2P file sharing, real-time video streaming etc.
   protocols.

   VPN protocols - standard and proprietary.

   VoIP protocols - standard and proprietary.

   Subvesion & CVS.



> %    "All" means something close to 100%.  Maybe 99.9% or so -
> %    certainly a very high proportion.
> 
> Disagree.  See above.

I don't understand your disagreement.

What I meant is that for any ordinary end-user to be happy with
having only an IPv6 address - they would need some very high
proportion of other end-users to be fully accessible via IPv6.

This is the central point in my argument, and if you think that most
end-users would be happy to have an Internet service in which they
couldn't communicate with 20%, 10%, 1% or whatever of other
end-users, please explain why.

The old model of there being content providers and mail servers -
and a bunch of end-user clients - doesn't apply any more.  People
are sending video to each other, running game servers at home,
running P2P programs etc.

If an end-user has a choice between two services:

  1 - IPv4 or IPv4 dual-stack with IPv6 - which connects directly
      to essentially every server and home-user computer on Earth.

  2 - IPv6-only, which does not connect to some subset of hosts -
      servers, home or office machines etc. - even if the subset
      is a fraction of a percent.

then I believe most end-users will only adopt the first one.


> % 3 - Due to the use of a large variety of application protocols,
> %    including many game protocols, those using UDP, P2P protocols
> %    etc. it is entirely infeasible to construct any kind of gateway
> %    or proxy system between IPv4 and IPv6.  Furthermore, the
> %    protocols are not necessarily amenable to proxying etc. and
> %    the applications generally have no facility for using a proxy.
> 
> I believe some of my competitors have already shipped boxes
> that do provide very complete gateway/proxy capabilties
> between IPv4 and IPv6.  As I have commented elsewhere
> in the past, this has been the most requested IPv6 "feature"
> that I've been hearing for several years now.  I assume my
> counterparts at other suppliers are hearing similar messages.

Please provide some specific details of these proxies, what
protocols they work with etc.

I understand there is no problem with email, but when a host
application gets a raw IPv4 address (as it would in P2P or many VoIP
applications) or if a DNS lookup returns only an IPv4 address, the
application needs to send packets to it and receive from the host at
that address.  I don't see how it can do this if it only has an IPv6
address - *unless* the protocol and the application is specifically
designed to work with some kind of proxy, and AFAIK, most of them
are not.

If you rely on proxies, those proxies need to understand each
application protocol - and even then, some protocols would not be at
all amenable to proxying.

If you rely on proxies, ALGs etc. then you would have a situation in
which no-one could write a new application and have it work in
general unless it was recognised and supported by the world's "IPv4
to IPv6 proxy servers".


> One might also want to examine the sundry presentations
> made in the past ~2 years by folks who work for COMCAST,
> which is a large (US) cable-modem ISP.  They have said
> they plan to buy such proxy/gateway boxes and deploy
> them in their ISP network.

OK.  Please point me to the specific details of where this is
actually happening.  I tried:

  http://www.google.com/search?as_q=comcast+IPv6&as_epq=Alain+Durand

and found this discussion indicating that nothing much is actually
happening yet with Comcast providing IPv6 services:

http://www.dslreports.com/forum/r19723219-Connectivity-Comcast-and-IPv6

This is pertinent:

  http://tools.ietf.org/html/draft-durand-v6ops-natv4v6v4-01

     . . . the current situation is that almost none of the content
     and services available on the Internet are accessible over
     IPv6.  This will probably change in the future, but for now,
     one has to make the assumption that most of the traffic
     generated by (and to) broadband customers will be sent to (and
     originated by) IPv4 nodes.

  Two complex NAT approaches are rejected.

  Regarding Application Level Gateways:

     Although IPv4->IPv4 ALGs are now fairly well understood, there
     is little experience with IPv4->IPv6 or IPv6->IPv4 ALGs.

  There are only about 4 pages of material in this Draft.  I would
  appreciate you reading it and pointing me to instances of real
  proxies, ALGs etc. which really work to enable an end-user without
  only an IPv6 address to communicate freely with IPv4 hosts.


> % 4 - Before point 2 could be achieved, a very large proportion
> % of end-users would need to adopt IPv6 while they use IPv4.
> 
> Disagree.

OK, but why?

Why would any ordinary end-user want to pay for an Internet service
which did not have the full global connectivity all (IPv4) services
have today?  (The only example I can think of is a cellphone user
who is happy with whatever functions the inbuilt applications
provide via IPv6.)


> % 5 - Before there is ubiquitous IPv6 adoption, all the impetus for
> %    point 4 would need to come from some benefit that IPv6
> %    provides for adopters, while they still have IPv4 addresses.
> 
> Disagree.  Also see above point about the existence today,
> I believe, of IPv4::IPv6 bi-directional proxy/gateway boxes.

This is way too high level.  In order to convince me, you need to
point me to specific examples of these things, what they do, how
they are being used now etc.

I stand by all I wrote, except for the correction noted above that
ISPs don't need to be IPv6-only.

Before almost any end-user would be happy with an IPv6 only service,
virtually all other end-users must have a reliable IPv6 service.
Until that point, there is no real advantage in having IPv6 in
addition to IPv4, because everything an end-user wants to do works
fine via IPv4.

So you need to show why most end-users would adopt IPv6, while using
IPv4 - because only at that stage ("most" means 99%, 99.9% or
whatever) could any ordinary end-user be happy with an IPv6 only
service.  Only then could IPv6 make some contribution to reducing
the IPv4 routing scaling problem.


> %    Currently, there are no such benefits.
> 
> Not running out of address space is a benefit today.

There are plenty of IPv4 addresses available if the space is used
more efficiently.

  http://www.isi.edu/~johnh/PAPERS/Heidemann08a.pdf
  http://www.firstpr.com.au/ip/host-density-per-prefix/

My loose estimate is that about 220 million active IPv4 addresses in
use today, of 1.7 billion BGP advertised addresses.  Something like
3 to 3.7 billion could be advertised.  All the map-encap systems
would enable IPv4 space to be sliced and diced much more finely -
and so be used more efficiently.

For a long time to come, it will be easier to find and efficiently
use IPv4 space than to convince large numbers of paying customers to
accept a second-rate service without an IPv4 address - while
competitors offer the full IPv4 service for much the same price.


> Having an improved IPv6 architecture that enabled a more
> scalable routing system would be a significant benefit -- and
> would incent ISPs to promote faster IPv6 adoption/transition
> in the global marketplace.

Not if end-users don't want the service - and they won't want it
until most (99.9% or whatever) of other end-users are reachable via
IPv6.


> % 6 - Therefore, if IPv6 adoption is to solve the IPv4 routing scaling
> %     problem in any timeframe such as 2013 or whatever, then a number
> %     of hurdles must be overcome, including:
> 
> To quote Rumsfeld,
> 
>     If one starts with a faulty premise, and then proceeds quite
>     logically down a path of reasoning, one can hardly avoid
>     reaching a faulty conclusion.

I think your view is way too high altitude.  If you look closely at
the details, I think you will find that an IPv6 only service is
unsellable until most end-users have IPv6.  Then I think you will
accept something like what I wrote below about the challenge of
getting most end-users to adopt IPv6 dual stack, while IPv4 provides
them with perfectly adequate Internet connectivity.


> % 7 - To achieve this, there would have to be some unique
> %  benefits for  end-users, since they will only adopt IPv6
> %  if it provides immediate, direct, benefits.  The characteristics
> %  of these benefits would need to include:
> 
> %    a - The benefit could only exist via IPv6 - otherwise, someone
> %        will make it available via IPv4 and then no end-user would
> %        have a reason to adopt IPv6.
> 
> Address space will remain a reason for folks to migrate to IPv6
> over time, regardless of what is done here.

Not for a long time.  There is plenty of space left in IPv4 and this
will be found and used as with the increasing business pressures for
fuller utilisation.  To do this without a map-encap scheme (or some
other scheme which slices and dices IPv4 space without worsening
routing scaling problems) would result in an explosion of advertised
prefixes and a dramatic increase in the growth rate of the number of
advertised prefixes.  The map-encap schemes are a great way of using
address space more efficiently than is possible with the current /24
limits on IPv4 BGP.  (This not a BGP technical restriction - it is
administrative, but unlikely to be relaxed.)


> That noted, if the Routing RG were (hypothetically) to recommend
> changes only to the IPv6 architecture, that would create a
> separate reason for users to move to IPv6 (to gain the benefits
> of such a hypothetical new architecture).

There is no reason for users to adopt IPv6 alone until most other
users have IPv6.


> %    b - The benefit must exist in a dual-stack arrangement, since
> %        until IPv6 adoption is ubiquitous, all end-users will need
> %        and have IPv4 connectivity.  (Therefore it must be greater
> %        than whatever burdens dual stack imposes on users,
> %        administrators and ISPs.)
> 
> Not at all obvious to me.

The benefit in having IPv6 has to be in a dual-stack situation,
since in the transition period (before 99.9% of end-users have IPv6,
and so before any end-users could seriously contemplate not having
an IPv4 address) there must be a reason to adopt IPv6 while also
having an IPv4 address.


> %    c - The benefit must apply to the great majority of end-users.
> %        If it only applies to some subset, such as those who are
> %        interested in games, or real-time video, then this would
> %        not attract the very high proportion of end-users (99.9%
> %        etc.) which we need in order for any end-users to be able
> %        to do without IPv4 address space.
> 
> Disagree.  See previous comments.

I stand by what I wrote.

> %    d - The benefit must be directly tied to the new RRG-suggested
> %        protocols.  Otherwise people could get the benefits via
> %        IPv6 without the new protocols.
> 
> Not necessarily, though again you present a possible rationale
> for the Routing RG to propose an architecture only applicable
> to IPv6.

I stand by what I wrote.


> %    e - The benefit must be compelling.  Yet it must be something
> %        which is impossible with most Internet communication -
> %        which will take place via IPv4 until the 99.9% IPv6 adoption
> %        makes IPv4 unnecessary.
> 
> Disagree.

I stand by what I wrote.  I don't know how I could have been clearer
in explaining my argument.


> %    f - This benefit must exist from the very start, otherwise
> %        no-one will adopt it.
> 
> Disagree.  The new approach must be incrementally deployable,
> however.

There's a lot of disagreement about what "incrementally deployable"
means!


> %    g - The benefit cannot result from greater efficiency or
> %        reliability, since IPv4's efficiency is greater than that
> %       of IPv6, and because for the vast majority of end-users,
> %        IPv4's reliability is perfectly adequate.
> 
> Disagree with all of the above.  Most commercial users are
> not really happy with current levels of IP network reliability
> or availability.  

I am thinking mainly of home and small office users, for whom I
assume current IPv4 levels of reliability are adequate.

For larger end-users, I agree with you that there is a need for
better multihoming, such as faster response times, multihoming for a
larger number of probably smaller end-users etc.  This is a primary
goal of the RRG, and the map-encap schemes can provide it just as
well for IPv4 as for IPv6.

In order for IPv6 to be widely adopted while most end-users rely on
IPv4 for their main Internet communications, my argument is that the
IPv6 addition (with the RRG improvements) must provide some unique
benefits above and beyond what they get from IPv4, or from IPv6
without RRG improvements - otherwise we will never get to the
situation where most end-users have adopted fully scalable IPv6.
Only when that occurs will IPv6 help at all with the IPv4 routing
scaling problem by allowing large numbers of end users to have a
fully functional Internet service without using IPv4 address space.

> Something that would improve either/both
> of those would be very interesting to commercial users.
> Similarly, ISPs go to great lengths to avoid residential user
> downtime (because fielding the inevitable trouble phone
> calls is expensive, among other reasons).  So there is also
> strong interest in improved reliability/availability among
> residential users.

Yes, but this can all be done with RRG improvements to IPv4 too.

My critique is about the barriers to fixing the IPv4 scalability
problem solely by making IPv6 more scalable and having so many
end-users adopt IPv6 connectivity (initially dual stack) that at
some point in time, sufficient end-users will not want IPv4 space
that the IPv4 scaling problem will be solved.


> %    h - The benefit must therefore involve some new application
> %        capability, or some new service capability, which physically
> %        can't be done via IPv4 or via IPv6 without the RRG-suggested
> %        new protocols.
> 
> Disagree.  Your premises were faulty, I believe, so the conclusions
> are also faulty, unfortunately.

I would appreciate you taking a more detailed interest in what I
wrote and citing precise details of how end-users with IPv6 only
services can run the wide range of protocols currently in use so as
to communicate with IPv4 hosts.

 - Robin

--
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