--On Thursday, December 29, 2016 10:23 +0100 Patrik Fältström
<paf@xxxxxxxxxx> wrote:
> On 29 Dec 2016, at 10:03, John C Klensin wrote:
>
>> I don't particularly dislike IPv6, I just think we've failed
>> to pay enough attention to incentives and barriers. I wish
>> it were otherwise, really I do.
>
> I completely agree with this. But I also see access providers
> and enterprises that regardless of how they have built their
> networks today do run out of IPv4 space. And when they have
> run out they only have a few choices:
>
> 1. Add another layer of NAT
>
> 2. Buy IPv4 addresses
>
> 3. Start running IPv6
Actually, two more options:
4. Run IPv6 (exclusively) in their backbones, converting to
IPv4 islands at their boundaries. The mechanism may be a
variation on NAT, but the architecture is different.
5. Run <something-else> in their backbones, converting to IPv4
islands at the boundaries. It isn't very hard to think about
candidates for <something-else> given that there is no
requirement for interoperation with other ISPs and the key
requirement is support for semi-permanent virtual circuits (or,
if one prefers, channels or tunnels).
Of those five cases, only your (3) implies even the possibility
of end-to-end IPv6.
The flaw in an analysis involving those options is the notion
that we've got a very large number of ISPs with multiple and
varied interconnection arrangements, many hosts and sites that
are multihomed in the traditional sense of advertising one set
of endpoint addresses to the network and letting the routing
system sort things out, etc. However, my impression is that we
are seeing increasing ISP concentration (except, maybe, close to
the edges of the network, where it makes little difference) and
less of that traditional type of multihoming. The latter might
actually be driven by IPv4 address scarcity, but the
alternatives (and alternatives to multiple-prefix IPv6
multihoming) have significant operational advantages too.
> No, we are obviously not ready with [3] yet, but neither [1]
> nor [2] are beautiful situations, and they get worse.
Note that I'm not arguing that (4) or (5) are beautiful either,
only that they (plus (1)) may look more attractive than
large-scale IPv6 deployment to the edges on any give morning,
and perhaps on any given day that is not an IPv6 flag day.
A comparison to the deployment of IPv4 may be helpful. That
deployment incorporated, among other things, the following
characteristics for which there is no IPv6 equivalent that I can
find:
(i) The network was much smaller, much more homogeneous, and
much more operated on a technical basis and with engineering
criteria rather than economic or political ones.
(ii) The new addressing arrangement came with new protocols that
were seen as having significant advantages for interoperability
and network usability.
(iii) The network, measured in any of number of hosts, number of
users, or traffic volume, was much more about peer-to-peer
communications rather than about content distribution or even
many-client/ concentrated server operations.
(iv) The current router-based model had not yet become
completely dominant, so end-to-end really meant end-to-end,
significantly increasing the importance of a global address
space with globally-unique addresses.
(v) Applications protocols were very diverse and their numbers
appeared seemed to be growing (in contrast with "let's run this
over the web, or at least Port 80 / 8080, too"). That diversity
and growth made ALG-type solutions unattractive because they
would inhibit the development and deployment of new
applications. "Run it over the web" not only facilitates
firewall traversal, it lowers the bar to a collection of
networks interconnected by ALGs.
(vi) There was a flag day.
While the latter was certainly significant in promoting /
forcing a speedy transition rather than one that dragged out for
many years, I believe the other issues were very important too,
at least in avoiding massive pushback to IPv4 transition.
> Specifically for the ISPs that do not have any CGN yet, but a
> relatively cheap router in which they terminate one or more
> VLANs for their customers. I encountered one such access
> provider yesterday btw.
>
> And that is why I still see [3] coming, but not yet. We are
> getting closer every year though because the number of things
> that do need IPv4 addresses increase. And even a NAT box do
> not decrease the number of IPv4 addresses much due to the
> number of concurrent flows from clients.
That is where our analyses differ a bit ... and differs more the
more we see the network in terms of concurrent flows from a
large number of clients to a small number of servers (or server
clusters). If we were designing an optimal network architecture
for a CDN, especially a provider-optimized CDN, I suggest it
wouldn't look much like IPv6 or evem IPv6.
> Because of this, I still think we must make [3] easier,
> because when people really need IPv6 we must be done.
We certainly agree about the "must make (3) easier" part. A
different way of stating my concern is that, each few years that
pass when we have not widely deployed IPv6 and have figured out
way to control the pain, the more we may create the perception
that we can manage without IPv6 forever. Whether that is true
or not, the assumption tends to drive decisions whose
side-effect is driving the perceived pain of IPv6 conversion up.
john