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

[Randall Atkinson <rja@extremenetworks.com>]

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


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