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

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

Hi Iljitsch,

Here is a reply to your message of 26 May:

  http://psg.com/lists/rrg/2008/msg01344.html

> In my opinion, we don't necessarily have to solve the IPv4 situation. A
> reasonable (which is not the same as "ideal") scenario would be that
> IPv4 is largely frozen the way it is at a certain point in time and IPv4
> will continue to be the place where all servers are available, while
> (new) clients are attached to the IPv6 network. Client-server protocols
> are very easy to translate when the clients are on IPv6 and the servers
> on IPv4, the only issue is with peer-to-peer protocols that require each
> peer to be reachable for every other peer.

OK - I guess the IPv6 browser would use some kind of HTTP proxy or
ALG which has IPv4 address space.  In order to conserve IPv4 space,
this ALG etc. could handle many concurrent sessions for many IPv6
clients on one IPv4 address.  I don't know the details of how this
works, but I can imagine it being practical for HTTP - although I
don't know enough about dual stack DNS etc. to fully understand how
it might work.

Many peer-to-peer protocols have to fight their way out from NAT.  I
figure they have a lot of hard-coded IPv4 IP address stuff in them,
and there's no way this can be handled by proxies, ALGs etc. to
connect to IPv6-only hosts.

As I wrote earlier, I can't imagine how ordinary Internet users
could tolerate the limited utility of an IPv6-only service - not
counting cell-phone users, or perhaps new classes of users in
developing countries, including especially China.

Widespread dual-stack IPv6 and IPv4 adoption would provide no
benefit to the IPv4 scaling problem and would surely cause
unacceptable complications for end-users, their applications, high
levels of support calls to ISPs etc.


>> I think that networked games are a big enough category of protocol
>> to present a serious barrier for the widespread marketability of an
>> IPv6-only service.
> 
> I'm not all that interested in counting users, so my question is: how
> many games use peer-to-peer protocols? The ones that I'm familiar with
> (from about a decade ago) are all straightforward UDP client-server
> protocols, which will easily survive translation if the clients are able
> to communicate over IPv6 and there are no referrals. Also, the number of
> servers is very limited, so upgrading them to dual stack doesn't seem
> like much of an issue.

I know next to nothing about games, but the chicken-and-egg problem
remains, as I wrote:

>> Initially, why should all these game developers add messy proxy
>> stuff and IPv6 capabilities to their already immensely complex
>> programs, just to suit a handful of people who have chosen to pay
>> for a different kind of Internet service than what the rest of the
>> world uses?
> 
> This is exactly the reason IPv6 has seen so little uptake so far. 

Yes, and I see no prospect for this changing.


> Then again, we still have a billion unused IPv4 addresses. It's no use
> complaining that nobody buys umbrellas when the sun is shining.

As I wrote in other messages there is plenty of scope for greater
utilisation of IPv4 addresses, especially with map-encap - and
continued or greater use of NAT.  So I can't foresee a time in the
next decade or so when IPv4 space will be so unavailable that it
would be easier to put users on IPv6-only, with all its limitations.

Dual stack would be a support nightmare and for the foreseeable
future would provide no benefit for most users compared to ordinary
IPv4 connectivity, including IPv4 behind NAT.


>> I think it is likely that in order for the system to work, all
>> participants in these multi-player games would need upgraded
>> software - probably the entire protocol would need to change so it
>> could be amenable to proxying to some host which doesn't have an
>> IPv4 address.
> 
> So? AFAIK, these online games cost something like $10 a month. As soon
> as the number of users that only have decent connectivity over IPv6
> rises to even a few percent it's worthwhile to make these updates.

As argued above, I don't foresee when large numbers of users will
have IPv6-only connectivity.  I think IPv6 proponents have some
valid reasons for considering that IPv6 is the only long-term path
for the Internet to take, but I think it is unrealistic to imagine
that there won't be several effective workarounds for the depletion
of fresh IPv4 space, or that IPv4 space will become so scarce before
2020 as to force the widespread adoption of IPv6.


>> You haven't addressed my argument that there is great scope for the
>> next decade or so making better use of IPv4 space, especially with
>> map-encap - and that this will be cheaper and better than trying to
>> get end-users to pay for a second-rate IPv6-only Internet service.
> 
> Toothpaste doctrine: at some point it starts becoming annoying to
> squeeze harder and harder, you just buy a new tube. IPv4 address
> management is already quite expensive today and that's only going to get
> worse. 

Assuming one of the map-encap schemes is adopted, I disagree entirely.

Any of the map-encap schemes will make it easy and cheap for 1, 2,
4, 8, 16 etc. IP addresses to be used by any end-user network.

These EID prefixes (micronets) will be perfectly portable, suitable
for multihoming and for TE - without burdening the BGP system.
(Ivip will be able to do 1, 2, 3, 4, 5, 6 et., without explicit TE,
but with real-time control of mapping which would enable some new
approaches to TE.)

Since a substantial company or school network could be run on a
single IP address (or maybe 2 or 4), this means it will be easy for
this major class of end-user network to have portable, multihomed
space at very low cost compared to the current rigours of PI space
via an RIR, using today's BGP approach to slicing and dicing space.

> Obviously a lot depends on how many addresses you need. If you
> start with 256 and you need a million, that's a lot worse than if you
> have a million and you need 256.

With map-encap, it should be feasible for end-user networks to
acquire new space in small chunks.  It usually won't be contiguous
space - but I figure that would be an inconvenience, rather than an
impossibility, for many such networks.


>> You are proposing that all these protocols be made amenable to
>> proxying - and that some good souls would promptly write, test and
>> deploy the relevant proxying code for all the ISPs who sell IPv6
>> only services.
> 
>> This does not seem all realistic to me.
> 
> This was done to support NAT, too. The only problem here is the early
> adopter issue: it's hard to be the first when there are no products,
> vendors won't build something until there is a market. But those cycles
> can be broken.

How could this impasse be broken, as long as IPv6 doesn't provide
anything new and useful for large numbers of ordinary end-users?


It is one thing to make a protocol handle IPv4 NAT in some way.

It is another thing entirely to make an IPv4 application (initially
few will be written to work with IPv6) run in a host with IPv6-only
connectivity and then have it work via some ALG which itself must
have IPv4 addresses.   That would be difficult or impossible without
rewriting the protocol.

Furthermore, there is a profound limit to innovation here: any new
or emerging protocol would be useless until the developers made it
amenable to IPv4-IPv6 ALG, PNAT or whatever *and* had reliable code
to do that installed in all the world's ALGs, PNAT boxes etc.


>>> %   VoIP protocols - standard and proprietary.
> 
>>> Again, a small minority of Internet users, and might
>>> well work fine without any change.
> 
>> A small minority???
> 
> Absolutely. I moved to another country, have to pay insane amounts to
> call my family on my cell phone because they can't be bothered to
> install Skype.

VoIP adoption is mainstream.  It is not a "small minority" of users.
 There are lots of VoIP adaptors being sold.  I guess not many any
of them work with IPv6-only or dual-stack.


>> Hopefully someone else can contribute to this discussion - I think
>> your assessments are not realistic.
> 
> It looks like ICE, the mechanism that makes SIP work through NAT, can
> survive IPv4-IPv6 translation with only minor changes if the translator
> behaves in a certain way.

Maybe.  I don't know enough about how VoIP works through NAT to
comment further, but any ALG etc. needs to have IPv4 address space.
 It is all so complicated and "in the network" - burdening ISPs with
a bunch of ALGs to install, maintain, help their customers use etc.


>> ... and various IM programs, VoIP etc.
> 
> Instant messaging is largely client-server. I've been able to use Google
> Talk Jabber through a translator without any problems. File transfers
> don't work, but they usually don't on IPv4, either (for me).

Again, every IM protocol would need to be universally supported by
the world's IPv4-IPv6 ALGs etc. before it could be usable (assuming
widespread IPv6-only adoption).

Alternatively, all major IM protocols would need to be amenable to
IPv4-IPv6 ALGs and these would need to be deployed and made
transparently accessible in any IPv6-only service - otherwise it
would be impossible to sell the service enough for IPv6-only
services to begin widespread adoption.  But how could an ALG or
proxy be transparently found by an unmodified IPv4-only application
running on an IPv6-only host?   How could an IPv4-only application
work at all in an IPv6-only host?


>>> A very small number of residential users have deployed some sort
>>> of peer-to-peer system.
> 
>> I don't believe it is a "very small number".
> 
> BitTorrent will use IPv6 if/when available and discovers IPv6 peers
> using a dynamic hash table even if the tracker won't accept IPv6 or FQDN
> referrals. (Which was originally part of the protocol but optimized away
> in later changes.) In BitTorrent-like peer-to-peer applications you also
> don't need each peer to be able to talk to every other peer, just as
> long as there are a few that are double stack it works fine.

But wouldn't a BitTorrent program on an IPv6-only host be limited to
talking to other programs with IPv6-only, or dual stack, access?
That would greatly limit the scope of the programs.


>> How do you use an application which is only written for IPv4 (as
>> many are) on an IPv6-only host?
> 
> First you translate to IPv6, then back to IPv4 again.  :-)

Can you point to some examples?


>>> s/other end-users/desirable services/
> 
>> What's all this slash stuff?
> 
> This is how you do search and replace in the vi editor.

Thanks.  My Unix geek credentials are not as developed as those of
some folks on the RRG - I avoid vi and use Midnight Commander.


>>> This is the key point. For an IPv6-only client to be happy, the
>>> services (s)he wishes to reach must be accessible via IPv6.
>>> That is a vastly easier and more realistic goal than Robin
>>> describes. It even has a built-in economic incentive, since
>>> the service providers want clients*.
> 
>> But why would service providers go to a lot of trouble to make their
>> sites available to an initially small number of people who chose to
>> pay for a Internet service which is technically totally different
>> from what the rest of the world uses?
> 
> Because we're running out of IPv4 addresses.

I doubt IPv4 space will be so scarce for another decade or two.


> Or because once you get everything on IPv6, you don't have to deal with
> any problems caused by NATs and filters in ISPs. IPv6 is the ultimate
> NAT traversal system. 

Indeed - its just that at present there's almost no-one to
communicate without some kind of ALG to the IPv4 Internet.


> If I were building a corporate network from
> scratch I'd run all the internal stuff IPv6-only with translation at the
> edge. This may have some initial challenges, but it's much more future
> proof than messing with IPv4.

Do you have any examples of a school, company, university,
corporation etc. who does this?

They would need all their apps to be IPv6 capable, and for them to
run nicely like this - and I guess they would need IPv6 capable
printers, WiFi devices etc.


>> Why would those users adopt such a service before a very large
>> proportion of other end-users (including content providers) support
>> their kind of service?
> 
> Ask ipv6.google.com.

One day, I will try IPv6 connectivity.  At present, I am sure it
wouldn't enable me to do anything significant I can't do now, except
try out a few IPv6-only services such as this.


>> IPv6 has had 10 years to be adopted - and virtually no-one has
>> adopted it.
> 
> IPv6 is the second most successful layer 3 protocol in history. There
> was a time when I joked that more people run CLNP (in order to use the
> IS-IS routing protocol) than IPv6, but I don't think that's the case
> anymore. Nearly every time a Mac user configures their Apple wifi base
> station this happens over IPv6.

Still, almost no-one has adopted it.  The run-out of fresh blocks of
IPv4 space is the only thing on the horizon which might prompt IPv6
adoption.  However I believe this won't be anything like a strong
enough reason to make the leap to a new, incompatible, largely
separate, IPv6 Internet - since the whole thing about the (IPv4)
Internet is that it connects to all other end-users' computers.


If IPv6 actually did something that was impossible with IPv4 - and
if this was of real value to a significant number of end-users -
then perhaps IPv6 could be widely adopted within five years.

Since IPv6 is less efficient than IPv4 - longer headers, bloated 128
bit addresses etc. - any such advantage won't come from efficiency
or handling some application protocol that can't be run on IPv4.

The only way I can think of IPv6 being widely adopted is if it was
the only way to do global video, streaming media, VoIP etc. delivery
with full QoS.

To do this the global IPv6 DFZ and all other routers would need to
be part of some global financial settlement scheme so that a user
somewhere requesting a QoS reservation would pay the router's
operator for the bandwidth they were reserving on each such router
in the path.

Maybe there is something inherent in IPv6 which makes this feasible
when it is not for IPv4.  Perhaps the fact that the IPv6 global
network is so undeveloped at present means that re-inventing it on a
commercial global QoS basis would be more feasible than trying to
convert the IPv4 network to support paid-for QoS.

This is the only thing I can imagine being strong enough to give
sufficient ordinary users motivation to get IPv6 connectivity.  Even
then, how long would it take before a sufficiently high proportion
of end-users (99%, 99.9%??) including everyone who runs servers, has
IPv6 addresses?  Only then could ordinary end-users do without IPv4.


>>> * This argument applies to peer-to-peer services too. It slightly
>>> increases the desirable properties of a supernode - the ideal
>>> supernode will not only be outside firewalls and NATs, but will
>>> also be dual stacked.
> 
>> I don't clearly understand this.
> 
> I understand, but disagree. Supernodes aren't necessarily proxies.

I didn't understand the term "supernode" or the overall meaning of
the paragraph.  Now I looked it up:

  http://en.wikipedia.org/wiki/Supernode_(networking)

    In peer-to-peer networking, a supernode works as one of that
    network's relayers and proxy servers, handling data flow and
    connections for other users. This usually requires a fairly
    fast Internet connection with a lot of bandwidth and a modest
    amount of CPU time, as a lot of data will invariably pass
    through the supernode and needs to be processed.

    Some peer-to-peer designs allow for the user to choose whether
    they ever want to be treated as supernodes; others do not. Skype
    by default is configured as a supernode, an issue that has
    caused controversy.

Re-reading Brian's message:

   http://psg.com/lists/rrg/2008/msg01333.html

I understand that he meant that P2P networks would need a number of
dual-stack "supernode" hosts which would somehow handle the traffic
between IPv4 and IPv6 nodes, doing appropriate translation.

Still, the while P2P system would need to be engineered for both
IPv4 and IPv6, with specific arrangements so an IPv4-only node could
know how to contact an IPv6-only node.  This would involve
identifying that IPv6-only node, presumably by its IP address, and
also identifying one or more supernodes to do the translation.
Typically it would matter where the supernode and the IPv6-only node
are located, since  the supernode should be not too far from
whatever physical path packets might otherwise take between the two
nodes.

How many of today's P2P protocols have this sort of sophistication?
  I imagine few do.

What would be the motivation to do a fundamental rewrite of the
protocols to do this?  The chicken and egg problem again: no demand
from users yet, but no users will adopt IPv6 until all their
protocols work fine.

This new version of a P2P protocol would only be supported by new
client programs, or those which are automatically updated.  (I guess
this could be quite a high proportion over a year or so.)  Also,
some of these P2P systems are based on a published protocol to which
multiple authors write multiple clients - so many or most of these
independent authors would need to adopt the new version of the
protocol in their updated clients.  The new version probably
wouldn't support existing clients work with IPv6-only nodes - so the
network would be more complex with two classes of IPv4 client to
consider: those which could talk to IPv6-only nodes and those which
couldn't.

 - 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