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

From: Robin Whittle <[email-masked]>
Date: Sun, 25 May 2008 19:43:03 +1000

I think the map-encap schemes (LISP, APT, Ivip and TRRP) were all
designed on the assumption that we must solve the routing scaling
problem in IPv4 and the one which would develop if and when IPv6 is
widely adopted.

Here is why I think we can't just solve the future IPv6 problem and
rely on the IPv4 problem being solved - or becoming no longer a
concern - due to most end-users no longer needing IPv4 space.  This
could only be the case after "all" end users have IPv6 addresses and
suitable operating systems and applications.

IPv6 has been available in operating systems for at least 10 years,
but in terms of adoption, it has been a spectacular failure.  This
long-standing pattern of lack of interest among end-users would have
to be dramatically changed if IPv6 was to make the IPv4 routing
scaling problem no longer a concern.

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:

1 - A significant number of new or existing end users (and their
    ISPs) would need to run their Internet services using only
    IPv6 addresses.

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.

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

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.

4 - Before point 2 could be achieved, a very large proportion of
    end-users would need to adopt IPv6 while they use IPv4.  This
    would require many things, including:

     a - ISPs providing both IPv4 and IPv6 space and services.

     b - Easy administration of hosts, routers etc. for handling
         both types of addresses and traffic at once.

     c - Mature, robust, OS support for IPv6 in "all" operating
         systems used by "all" end-users - not just their desktop
         and server computers, but their printers, DSL modems,
         WiFi boxes, VoIP boxes, managed Ethernet switches etc.

     d - "All" (or at least a very high proportion) of applications
         being fully functional in dual stack machines, as well as
         in pure IPv4 and pure IPv6 machines, without glitches or
         extra administration requirements.

    These requirements cannot possibly be met in the near-term, or
    without extreme efforts on the part of application developers -
    and many applications are no longer being developed, so there
    would always be some users who can't do what they want without
    IPv4.

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.

    Currently, there are no such benefits.

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:

    a - Rapid development and deployment of an RRG-suggested
        protocol for IPv6 which will provide a new class of address
        space which can be used for multihoming, TE and portability
        without causing the scaling problems we are trying to solve.

    b - This technology being made available to ISPs and end-users
        in a way by which the end-users gain some convincing
        benefits over the immediate costs and disruption of adopting
        any new system.

    c - By this process, IPv6 adoption growing from essentially zero
        to over 99%, which would provide the essential precondition
        for a significant number of end-users no longer wanting or
        needing IPv4 connectivity or address space.

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.

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

    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.

    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.

    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.

    f - This benefit must exist from the very start, otherwise
        no-one will adopt it.

    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.

    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.

Unless someone has convincing suggestions regarding these benefits,
I believe that there can be no benefit which meets this requirement
- and therefore no way sufficently large numbers of end-users could
be attracted to IPv6 in order to make IPv4 connectivity no-longer
essential for a general purpose Internet service.

Therefore, I argue we need to solve the IPv4 routing scaling problem
directly.

Ideally, the same techniques should solve any future IPv6 routing
scaling problem - however, I think there is no urgency in applying
those techniques to IPv6 as long as its usage remains so low that
the system is far from hitting scaling limits.

  - Robin          http://www.firstpr.com.au/ip/ivip/

--
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: Eliot Lear <[email-masked]>
Date: Sun, 25 May 2008 12:51:02 +0200

Robin,
> scaling problem no longer a concern.

I have heard this many times before, and I would caution you, Robin, and 
this group to not go there for several reasons:

1.  There is no serious Plan B.  Any plan that came to be today likely 
couldn't be fielded.
2.  Sometimes technologies arise before their time.  This was certainly 
the case, for instance, with X.509, which was adopted by the ITU in 
1988, and didn't see widescale deployment afterwards for nearly six 
years for a use that was not particularly envisioned by its creators.
3.  This is really not all that germane to architectural discussions.  
The problems we are discussing will be present in any version of IP or 
anything else that has encoded hierarchy in their addresses and demands 
multiple presences in a network topology.

Eliot

---

From: Randall Atkinson <[email-masked]>
Date: Sun, 25 May 2008 05:18:31 -0700

Earlier, Robin 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".

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

% 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

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

Disagree.  See above.

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

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.

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

Disagree.

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

%    Currently, there are no such benefits.

Not running out of address space is a benefit today.

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.

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

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

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

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

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

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

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

%    f - This benefit must exist from the very start, otherwise
%        no-one will adopt it.

Disagree.  The new approach must be incrementally deployable,
however.

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

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

Yours,

Ran
[email-masked]

---

From: Robin Whittle <[email-masked]>
Date: Mon, 26 May 2008 00:42:01 +1000

Hi Randall,

> which things "would need to be true".

OK.

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

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

> %    certainly a very high proportion.

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.

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

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

> % of end-users would need to adopt IPv6 while they use IPv4.

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

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

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

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

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

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

> of such a hypothetical new architecture).

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

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

> Disagree.  See previous comments.

I stand by what I wrote.

> for the Routing RG to propose an architecture only applicable

I stand by what I wrote.

> %        makes IPv4 unnecessary.

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

> Disagree.  The new approach must be incrementally deployable,

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

> 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

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.

> 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

---

From: Randall Atkinson <[email-masked]>
Date: Sun, 25 May 2008 14:36:46 -0700

Earlier, Robin wrote:
% Also:
%
%   Any number of game protocols.

Most people don't play networked games.  Some do.
Gaming protocol developers are already quite good at
(re-)engineering their protocols to work in challenging
environments (e.g. through firewalls that try to block them).

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

The file sharing protocols are among the mot robust out there.
They either will work without change -- or the updates will be
pushed out in very very short time intervals so that they can
resume working.

%   VPN protocols - standard and proprietary.

Well, I disagree at least with respect to IP Security,
which is one I'm slightly familiar with.  MPLS is likely the
most widely used VPN protocol -- and it would be unchanged
as it is at a different protocol layer entirely.

VPN protocols are used by a *minority* of users,
mostly corporate users.

%   VoIP protocols - standard and proprietary.

Again, a small minority of Internet users, and might
well work fine without any change.

%   Subvesion & CVS.

Only used by software developers, who are a smallish
minority of the Internet user base, and these might well
work fine without change.

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

I used to work for a multi-continent residential broadband ISP.
So I've seen traffic usage statistics.  People still in that business
tell me the trends are not wildly different now versus then.

Most residential users, and residential users dwarf corporate Internet
users by numbers, ONLY use email and the web.

A very small number of residential users have deployed some sort
of peer-to-peer system.

(Aside: That tiny number of users consumes an impressive amount of
bandwidth, but the total peer-to-peer user base is really a very small
percentage of the residential broadband users.  This is why broadband
ISPs find the peer-to-peer users frustrating -- they consume a hugely
disproportionate amount of bandwidth.)

% 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 current Internet is NOT fully connected.  It might seem that way
in moments, but really it isn't fully connected.  I know of a number of
sites, particularly in Asia/Pacific or Africa, that have prefixes advertised
only in a limited set of locations to a limited set of upstreams.  This
seems to be due to how BGP peering has de facto been broken into
several different peering regions (e.g. Americas, Europe, Asia/Pacific)
usually requiring the purchase of transit to cause one's prefix to appear
in other regions.

Second, existing protocol translation boxes (think IPv4::IPv6) and proxies
handle email/web/IM protocols just fine.  As noted above, that covers
most Internet users.

% The old model of there being content providers and mail servers -
% and a bunch of end-user clients - doesn't apply any more.

It does for the vast majority of users.

% People are sending video to each other, running game servers
% at home, running P2P programs etc.

Some people are -- but a smallish percentage.

For example, the main video sharing approach is to upload/download
to YouTube -- which only requires web protocols to work properly.

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

The premise of scenario 2 above is wrong -- with the commerically
available protocol translation middleboxes, users can connect to any
machine using the most widely used application protocols.

So comparing the corrected (2) just above with (1), most users
can't even distinguish the difference.

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

I am not inclined to advertise for my competitors, sorry.

It would be worth reading the COMCAST presentations of the past
~2 years at NANOG, RIPE, and likely APRICOT, if one wants to
know more.

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

A DNS proxy is included in the protocol translation gateway,
so one gets back a proxied address that just works.

% 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".

The trick is to avoid repeating the mistake of FTP.  Pass
domain-names in the application protocols, not IP addresses.
Many applications were rewritten to do just this when they
were updated to be IPv6-capable.

%  There are only about 4 pages of material in this Draft.

Go look at the RIPE, NANOG, or APRICOT presentations.

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

Most users don't have universal connectivity today, see above.

Most users only care about email, web, and IM.  So long
as those work (e.g. through a gateway), then they are happy
and they perceive that their Internet service is fine.

% So you need to show why ...

You can believe whatever you wish.  I'm not trying to change
your mind.  Rather, I am pointing out why I don't believe your
conclusions are reasonable given the data available to me.

% I think your view is way too high altitude.

I'm viewing things architecturally, not from an engineering
perspective.  I believe that is the best approach in a Routing RG
context.   Your mileage apparently varies.

Cheers,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 May 2008 14:03:47 +1200

On 2008-05-26 02:42, Robin Whittle wrote:
...
> proportion of other end-users to be fully accessible via IPv6.

s/other end-users/desirable services/

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

However, this isn't very relevant to RRG goals. What is relevant,
IMHO, is divining whether the BGP4 system for IPv4 will hit a
catastrophic scaling limit within a foreseeable timescale. If the
answer is 'yes' we need a first-class solution for IPv4; if the
answer is 'no' we only need a first-class solution for IPv6. Since
my divination skills are weak, it seems safer to seek a first-class
solution for both.

    Brian

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

---

From: Randall Atkinson <[email-masked]>
Date: Sun, 25 May 2008 19:19:20 -0700

Earlier, Brian Carpenter wrote:
% What is relevant, IMHO, is divining whether the BGP4 system
% for IPv4 will hit a catastrophic scaling limit within a foreseeable
% timescale.
%
% If the answer is 'yes' we need a first-class solution for IPv4;
% if the answer is 'no' we only need a first-class solution for IPv6.
%
% Since my divination skills are weak, it seems safer to seek a
% first-class solution for both.

John Scudder (Juniper) had a presentation on BGP and FIB/RIB
scaling at NANOG in Toronto a year or so back (shortly after
the IAB Workshop):

   <http://www.nanog.org/mtg-0702/presentations/fib-scudder.pdf>

His last slide (URL above) is directly on-topic and says (quote):

      We can throw hardware at FIB scaling for at least
      the next decade or so, with existing technology
         • Several bigFIB boxes shipping now

      This provides time to research routing/addressing
      architectures
         • Really don’t want to build Internet on a R/A
           architecture that was hacked up quick under
          deadline pressure

      BGPfree core can protect core (“P”) router FIBs
        • Deployed today

If one believes that, and following Brian's logic above,
then a first-class architectural approach for only IPv6
ought to be sufficient/acceptable as a Routing RG
output.

What do the big router implementers on this list
think about the question of when we will hit a
"catastrophic" scaling limit ?

Yours,

Ran
[email-masked]

---

From: "Tony Li" <[email-masked]>
Date: Sun, 25 May 2008 21:16:04 -0700

|However, this isn't very relevant to RRG goals. What is relevant,
|IMHO, is divining whether the BGP4 system for IPv4 will hit a
|catastrophic scaling limit within a foreseeable timescale. If the
|answer is 'yes' we need a first-class solution for IPv4; if the
|answer is 'no' we only need a first-class solution for IPv6. Since
|my divination skills are weak, it seems safer to seek a first-class
|solution for both.

s/BGP4 system/current routing architecture/

To date, no one has demonstrated a routing architecture that scales without
aggregation, and aggregation is THE sore point.

Can we please not pick on BGP?  It simply confuses the issue.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 May 2008 16:50:12 +1200

> Can we please not pick on BGP?  It simply confuses the issue.

I didn't mean to. I agree the argument applies to all conceivable
EGPs that rely on binary address aggregation, and I'm not aware
of an alternative to that.

   Brian

---

From: Robin Whittle <[email-masked]>
Date: Mon, 26 May 2008 14:53:56 +1000

I am replying to Randall and Brian.

> environments (e.g. through firewalls that try to block them).

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.

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?

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.

Also, ideally, the game developers would add pure IPv6 capabilities,
so any game server or client could interact with any other client or
server, IPv4->IPv6, IPv6->IPv4 and IPv6->IPv6, as well as the
current IPv4->IPv4.  This sounds really complex.

One of the problems of relying on proxies (even if the protocol is
amenable to proxying) is that any novel protocol is basically
unusable for all those with an IPv6-only Internet service, until the
proxying capability is installed in their ISP's proxies.

To the extent that significant numbers of end-users had IPv6-only
services, this would be a major disincentive to the development of
new protocols and therefore applications.  Alternatively, to the
extent that these new protocols were not supported by the proxies,
it would be a severe impediment to attracting customers to these
IPv6-only services.

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.

> pushed out in very very short time intervals so that they can

Why, initially, would end-users adopt an IPv6-only service where a
lot of the things they want to do don't work?

Why, initially, would application developers do a major rewrite of
their software, firstly to support IPv6 and secondly to alter the
protocol so it could be proxied between IPv4 and IPv6, when the only
demand for it is from a small number of people who have been foolish
enough to pay for an Internet service which is well known not to
provide the same capabilities as what everyone else uses?

> VPN protocols are used by a *minority* of users,

I imagine there are some basic standard VPN protocols and a bunch of
proprietary ones - such as whatever mechanisms enable someone to
control a Windows machine remotely.

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.

> well work fine without any change.

A small minority???

Hopefully someone else can contribute to this discussion - I think
your assessments are not realistic.

> %   Subversion & CVS.

Subversion apparently has an IPv6 patch.  But my guess is this is
not the same thing as having a protocol which can be proxied so as
to communicate seamlessly between IPv4 and IPv6.

> users by numbers, ONLY use email and the web.

... and various IM programs, VoIP etc.

> A very small number of residential users have deployed some sort

I don't believe it is a "very small number".

http://csdl2.computer.org/comp/proceedings/hicss/2008/3075/00/30750383.pdf

  The Evolution of the Peer-to-Peer File Sharing Industry
  and the Security Risks for Users
  M. Eric Johnson, Dan McGuire, Nicholas D. Willey  2008

  p 2:  Nearly ten million simultaneous users.

  p 4:  13M simultaneous users in June 2006.

  p 5:  30% of broadband users use P2P.
        In 2004, 10% of BB users were involved in P2P at any given
        moment.

> disproportionate amount of bandwidth.)

I think your estimates of the popularity of P2P are way too low.

> usually requiring the purchase of transit to cause one's prefix to appear

This is interesting, and I would appreciate some references.

However it does not address my argument: that a very high proportion
of Internet users (at home, web servers, at work etc.) will need to
have fully functional IPv6 connectivity before significant numbers
of end-users will pay for an IPv6-only service.

> handle email/web/IM protocols just fine.  As noted above, that covers

Please provide some examples.

> It does for the vast majority of users.

I completely disagree.  You haven't given any evidence for why you
think P2P, IM, VoIP etc. is not used by the "vast majority of users".

> Some people are -- but a smallish percentage.

Where is your evidence?

> to YouTube -- which only requires web protocols to work properly.

I agree.

> machine using the most widely used application protocols.

I see no evidence for this.

Please point me to the details of these proxies, ALGs etc., so I can
see what protocols they support.

> can't even distinguish the difference.

I disagree for reasons already stated.

> I am not inclined to advertise for my competitors, sorry.

If you expect me to take your assessment seriously, it needs to be
backed up by independent evidence.

> ~2 years at NANOG, RIPE, and likely APRICOT, if one wants to

Presentations are cheap.  Please point to the actual products which
do this IPv4-IPv6 proxying.

> so one gets back a proxied address that just works.

How do you use an application which is only written for IPv4 (as
many are) on an IPv6-only host?

> were updated to be IPv6-capable.

This does not answer my critique.

P2P programs, VoIP programs etc. can't necessarily rely on there
being a DNS name for the host they need to exchange packets with.
So the protocols exchange IP addresses in the raw.

I don't see how this is amenable to proxying to an IPv6-only host.

> Go look at the RIPE, NANOG, or APRICOT presentations.

The draft is more recent than the presentations.  Internet Drafts
should be more substantial than presentations.

This lists a number of approaches - but they all have problems.

If it is as easy as you say it is to proxy IPv4 <--> IPv6, you
should be able to point me to some actual products which do this
work so I can read their specifications.

> Most users don't have universal connectivity today, see above.

This is not addressing my critique.

In the initial situation of the first hundred, first million or
whatever end-users adopting IPv6-only services, they will be the
only users directly reachable from their hosts.

The whole thing about the Internet is that it is global - not
country-specific or restricted in any other way.

> and they perceive that their Internet service is fine.

I think you are imagining users to have simple enough needs that
they would not mind having an IPv6-only service.  I do not think
this matches the real needs of many or most users, for reasons
already stated.

> conclusions are reasonable given the data available to me.

The fact that you believe something is of some interest - but not as
interesting and convincing as knowing why you believe it and being
able to chase up the evidence for your view through independent
references.

> context.   Your mileage apparently varies.

Indeed.  I take an interest in low-level details, as well as the
details of the broader architecture.

   Oh! ye'll take the high road and I'll take the low road,
   And I'll be in Scotland afore ye;

> s/other end-users/desirable services/

What's all this slash stuff?

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

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?

IPv6 has had 10 years to be adopted - and virtually no-one has
adopted it.

As far as I can tell, almost no-one outside the IETF cares about
IPv6. (The Chinese government is keen about it - or at least I have
read material promoting IPv6 in China on this basis - since it wants
to do away with NAT so every citizen has their own IP address in
oder that their activities can be efficiently monitored.  I have
some references somewhere.)

> However, this isn't very relevant to RRG goals.

It certainly would be if there is consensus that it is OK not to
tackle the IPv4 routing scaling problem directly, but instead tackle
it for IPv6 and allow a mass migration to IPv6 take the pressure off
the IPv4 problem.

> What is relevant,
> my divination skills are weak, it seems safer to seek a
> first-class solution for both.

I support a first-class solution for both.

I don't think there is a catastrophic limit.  However, the burden of
the growing DFZ routing table makes DFZ routers more and more
expensive, and so burdens all Internet users with increased ISP
fees.  Meanwhile, end-user networks which want and need portable
address space, multihoming and TE are increasingly unable to get it
due to the barriers erected to them getting PI space, in order to
try to reduce the burden of the bloated DFZ routing table.

The situation will get worse and worse - and I am sure the rate of
worsening will grow around 2010 as fresh IPv4 space runs out and
people start chopping their current assignments into smaller pieces
so it can be used more effectively.

> supernode will not only be outside firewalls and NATs, but will

I don't clearly understand this.

  - Robin

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 26 May 2008 10:07:04 +0200

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.

> to present a serious barrier for the widespread marketability of an

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.

> for a different kind of Internet service than what the rest of the

This is exactly the reason IPv6 has seen so little uptake so far. Then  
again, we still have a billion unused IPv4 addresses. It's no use  
complaining that nobody buys umbrellas when the sun is shining.

> could be amenable to proxying to some host which doesn't have an

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.

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

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

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

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

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

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

> many are) on an IPv6-only host?

First you translate to IPv6, then back to IPv4 again.  :-)

> What's all this slash stuff?

This is how you do search and replace in the vi editor.

> from what the rest of the world uses?

Because we're running out of IPv4 addresses.

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

> proportion of other end-users (including content providers) support

Ask ipv6.google.com.

> IPv6 has had 10 years to be adopted - and virtually no-one has

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.

> I don't clearly understand this.

I understand, but disagree. Supernodes aren't necessarily proxies.

Iljitsch

---

From: "Tony Li" <[email-masked]>
Date: Mon, 26 May 2008 02:18:48 -0700

|What do the big router implementers on this list
|think about the question of when we will hit a
|"catastrophic" scaling limit ?

Well, Ross Callon has been quoted as saying that the Juniper implementation
will have no problems up through many millions of routes.

Now, conceptually, that could happen tomorrow.  However, at the current
growth rates, that's likely to be many years.  

If you believe this, then the issue is real and is strategic, not tactical.
We have the opportunity to Do It Right, and we should.

Tony

---

From: "William Herrin" <[email-masked]>
Date: Mon, 26 May 2008 21:39:39 -0400

> problem in IPv4 and the one which would develop if and when IPv6 is

Speaking for TRRP, this is correct and I consider the assumption valid.

> concern - due to most end-users no longer needing IPv4 space.

#0: Don't count your chickens before they hatch. IPv6 may be the
future of the Internet, but that future has yet to arrive. The
possibility of an IIPv4 double-NAT world with lots of little bitty
islands of public IPv4 addresses for servers is still in the cards.

The nasty thing is this: Double-nat is *very* incrementally
deployable, so it could deploy ahead of IPv6 in order to relieve the
pressure and serve as a stopgap after the end of the IPv4 free pool.
But IPv4 exhaustion is the only thing driving IPv6 deployment. Relieve
that pressure and the expense of IPv6 deployment might well stop it
dead.

> aggregation, and aggregation is THE sore point.

TRRP? Though I suppose that's only been proposed, not demonstrated.

> 1.  There is no serious Plan B.  Any plan that came to be today likely

Double-NAT. We add the Class-E space to the existing RFC1918 space and
just like service providers now only offer static IPs to those who
request and pay extra for it, they'll start only giving public IPs to
those who request and pay extra for it. Thus the user's packet gets
natted twice: once at his "broadband router" and once again upstream
at his ISP.

Nobody WANTS to do this, but everybody CAN do it, and they can do it
with COTS systems available now. You may not like it (I sure don't)
but that's plan B and it's VERY SERIOUS.

On Mon, May 26, 2008 at 5:18 AM, Tony Li <[email-masked]> wrote:
> If you believe [Ross Callon] then the issue is real and is strategic, not tactical.

Doing it Right with a capital R and doing it compatibly have ever been
mutually exclusive goals. If we can't find the consensus to pick one,
we should fork the task and let different groups pursue both in
parallel. Trying to compromise between the two rarely seems to end
well.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked] [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: "Ross Callon" <[email-masked]>
Date: Mon, 26 May 2008 23:25:40 -0400

> If you believe this, then the issue is real and is strategic, not 
> tactical. We have the opportunity to Do It Right, and we should.
>
> Tony

I believe that we have the opportunity to "Do It Right", and we should.

Now, what is "right"? and how to get there?  These are not as obvious
(at least not to me and not yet). 

Thanks, Ross

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 27 May 2008 01:17:29 -0700

On May 25, 2008, at 7:19 PM, Randall Atkinson wrote:

>         • Several big FIB boxes shipping now
>
>      BGP free core can protect core (“P”) router FIBs
>        • Deployed today
>

I know little about router implementations, so no answer to the above  
question.
However I wonder whether the question is mainly what scale can/cannot  
be implemented.

As I've heard from a few big operators, their shared issue is the  
scale limitation of their edge boxes --- they could buy a small number  
of core routers that can handle large tables, but they could not  
afford replacing hundreds or even up to thousands edge routers that  
have limited capacity.

just to add the view from another angle,
Lixia

---

From: Pekka Savola <[email-masked]>
Date: Tue, 27 May 2008 12:55:06 +0300 (EEST)

On Tue, 27 May 2008, Lixia Zhang wrote:
> As I've heard from a few big operators, their shared issue is the scale 
> limitation of their edge boxes --- they could buy a small number of core 
> routers that can handle large tables, but they could not afford replacing 
> hundreds or even up to thousands edge routers that have limited capacity.

I have to wonder which edge boxes we're thinking of.  Edges towards 
other ISPs (peering etc.)?  Edges towards customers?  The latter in 
some cases might be easier -- it may not be required to carry the full 
routing table on each and every customer-facing router.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 27 May 2008 06:53:54 -0700

On May 27, 2008, at 2:55 AM, Pekka Savola wrote:

>> scale limitation of their edge boxes --- they could buy a small  
>> number of core routers that can handle large tables, but they could  
>> not afford replacing hundreds or even up to thousands edge routers  
>> that have limited capacity.
>
> some cases might be easier -- it may not be required to carry the  
> full routing table on each and every customer-facing router.

I might have used a wrong word "edge"; someone closer to operations  
might help here.  But the stories I heard are about the ISP routers  
that do carry the full table.

Lixia

---

From: "William Herrin" <[email-masked]>
Date: Tue, 27 May 2008 10:58:06 -0400

> I might have used a wrong word "edge"; someone closer to operations might
> help here.  But the stories I heard are about the ISP routers that do carry
> the full table.

Lixia,

It sounds like you used the right term. "Edge" generally means
customer edge, but in a large operator those customers are often BGP
participants.

If I read you right, what they're saying is that they could accept
upgrading a few very large routers in their core where they talk to
major peers but would find it cost-prohibitive to upgrade all the
routers that talk to what are now BGP customers.

This is a blind alley. See Randy Bush's NANOG presentation, page 47+
http://www.nanog.org/mtg-0710/presentations/Bush-v6-op-reality.pdf

Regards,
Bill Herrin

---

From: Peter Sherbin <[email-masked]>
Date: Tue, 27 May 2008 12:48:24 -0700 (PDT)

> I might have used a wrong word "edge"; someone
> closer to operations might help here.

in the organization that I am familiar with "edge" or distribution router aggregates accesses from customer premise routers. Distribution routers connect upstream to core routers. If I am not mistaken core routers also interconnect peer/transit ISPs.

Thanks,

Peter

--- On Tue, 5/27/08, Lixia Zhang <[email-masked]> wrote:

> From: Lixia Zhang <[email-masked]>
> Subject: Re: [RRG] Consensus? IPv4 scaling problem must be solved directly, not by relying on migration to IPv6
> To: "rrg" <[email-masked]>
> Date: Tuesday, May 27, 2008, 9:53 AM

---

From: Robin Whittle <[email-masked]>
Date: Wed, 04 Jun 2008 17:11:41 +1000

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.

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

> 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

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.

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

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

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

> call my family on my cell phone because they can't be bothered to

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.

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

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

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

> First you translate to IPv6, then back to IPv4 again.  :-)

Can you point to some examples?

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

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

>> proportion of other end-users (including content providers) support

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.

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

> 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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 11 Jun 2008 11:51:34 +0200

I am reluctant to reply to the group as this isn't really on topic for  
RRG. However, yesterday's discussion also ended up in this territory  
so we may as well finish what we started...

[Please note I wrote part of this message on saturday, not updating  
for drafts posted in the intermediate]

>> Client-server protocols

> ALG which has IPv4 address space.

Full disclosure: together with some others, I've been working on a new  
incarnation of the NAT-PT mechanism that translates from IPv6 to IPv4.  
(We call it "NAT64" along with "DNS64".) Using this mechanism IPv6  
hosts can initiate TCP sessions towards IPv4 hosts and UDP packets can  
flow in both directions after the IPv6 host has sent the first one.

The draft should be out any day now.

Apart from that I advocate using an HTTPS proxy as a transition  
mechanism because it can proxy TCP sessions regardless of the  
appliction and regardless of the IP version the client and the server  
use as long as the proxy is dual stack. An HTTP proxy is of course  
also useful but limited to just HTTP.

> connect to IPv6-only hosts.

Let's address SIP and BitTorrent as the examples of the two classes of  
peer-to-peer applications. The IETF BEHAVE wg has come up with a  
fairly robust system to conquer NATs with SIP in mind: ICE, along with  
a set of requirements for NATs. As long as at least one of the peers  
is behind a BEHAVE-compliant NAT (or several of them), both sides  
implement ICE and there is a "coordination channel" between the two  
peers, the peer-to-peer communication is possible. So SIP-type peer-to- 
peer (where you want to be able to talk to ALL peers) is in good shape.

BitTorrent can't easily use ICE because BitTorrent doesn't allow for  
peers to coordinate their efforts to connect to each other. However,  
with some changes on implementations (not the protocol) a BitTorrent  
client behind a NAT, including one behind a NAT64, can receive  
incoming sessions if the NAT is BEHAVE-compliant.

But none of this is too big of an issue, because BitTorrent-type  
applications don't require that every peer can talk to every other  
peer. As long as there is a decent number of dual stack peers there  
can also be v4-only and v6-only peers and everything works. Note that  
in practice, BitTorrent trackers don't allow IPv6 peers to get their  
IPv6 address through to other peers, but the latest implementations  
support a dynamic hash table based system to find peers without help  
from the tracker and this works well for IPv6 - except that  
connections to IPv6 peers tend to fail in most cases... I guess there  
is firewalling involved here. But even today, I regularly talk to  
BitTorrent peers over IPv6.

> could tolerate the limited utility of an IPv6-only service

Simple: IPv4 gets worse as it becomes harder to find addresses to  
connect new users / services and NAT increases, IPv6 gets better as  
implementations mature and it's more widely deployed. Not-so-good IPv4  
+ not-so-good IPv6 is certainly better than either on its own, and at  
some point IPv6 on its own may be sufficient for some types of use.

You have to realize that except for HTTP(S) which is easily proxied,  
most applications only talk to a fixed server. So with an HTTP proxy  
and your mail and IM etc servers on IPv6 you can get a LOT of work  
done without IPv4.

> levels of support calls to ISPs etc.

Yes, and if you don't leave the house you don't have to pay high  
petrol prices and the risk of car accidents is reduced by many orders  
of magnitude. IPv4 is heading towards a brick wall, life is going to  
get more complicated, there is no way around that.

> utilisation of IPv4 addresses

If you're chased by a lion it's a good idea to run faster. But when  
you plan a trip to Africa, you'd probably be better off with better  
anti-lion protection than good running shoes.

Better IPv4 utilization is a dead end. If you absolutely need to delay  
the inevitable it can make sense, but you need to move to IPv6 at some  
point anyway, so basically any effort to keep IPv4 running longer is  
money down the drain.

> especially with map-encap - and

That would sound more convincing if we weren't burning up 150 - 200  
million new IPv4 addresses every year.

> have IPv6-only connectivity.

Note that I was talking about only having DECENT connectivity over  
IPv6. They probably still have IPv4 but optimized for HTTP.

> 4, 8, 16 etc. IP addresses to be used by any end-user network.

Who cares? That just means that you can move to another hosting  
service without touching your DNS records. I have a private server  
hosted somewhere. I have the .1 address. The .2 address belongs to  
someone else. Keep counting a /18s worth. Basically what this will do  
is make the minimum usable address block 16 - 256 times smaller. But  
"only" 135k people are advertising a minimum sized block today. That's  
only a /7. Freeing up 255/256th of a /7 is barely worth the effort and  
much more easily done by reclaiming a few of the 10 /8s the US  
government has, which aren't even all announced in the routing system.

Really, this "prefixes will get longer as IPv4 runs out" idea has no  
merit, neither as something to work towards nor as something to  
protect against. Yes, deaggregation will continue but not in a  
radically different manner than it has the past years.

> anything new and useful for large numbers of ordinary end-users?

As soon as you need IPv6 for just one little thing that means you'll  
have IPv6 connectivity which can then be used for other things as  
well. If IPv6 is sufficiently easy to get then it's a very good  
mechanism to work around NAT because it allows arbitrary numbers of  
systems to be reachable from the outside world at a well-known address/ 
port, while with NAT that usually requires per-host/service settings.

> have IPv4 addresses.   That would be difficult or impossible without

Forget ALGs. They're only needed for legacy stuff.

The v4-v6-v4 stuff is actually not all that hard. Either you translate  
to IPv6 with SIIT and then back to IPv4 with NAT-PT/NAT64 or you  
tunnel. Because you're only talking to IPv4 destinations the problem  
with general IPv4->IPv6 translation that you can't express 128 bits in  
32 bits doesn't occur.

> to do that installed in all the world's ALGs, PNAT boxes etc.

The BEHAVE NAT work has advanced sufficiently that if a NAT behaves  
somewhat reasonably (and many already do) and the clients support some  
extra stuff (ICE) these problems largely go away.

> the world's IPv4-IPv6 ALGs etc. before it could be usable

Didn't you read what I said? I can use Google Talk (or any other  
Jabber  based IM) through a translator TODAY with the client that  
comes with my OS. Actual IM (not file transfers and audio/video) is  
client/server so it works without trouble.

> That would greatly limit the scope of the programs.

Yes, and mostly no. I only talk to the IPv6-capable peers, the IPv4- 
only peers only talk to the IPv4-capable peers. In the venn diagram  
you'll see they overlap in the form of the dual stack peers. Basically  
you only need to get one copy of the file from the IPvX-only part to  
the dual stack part and you're in business. This will start working  
reliably with only a few percent dual stack peers.

> Can you point to some examples?

No.  :-)

> The run-out of fresh blocks of
> separate, IPv6 Internet

Well, either we need it and therefore we start using it, or we don't  
and therefore we don't. In both cases there is no problem.