[RAM] A curious Internet service offering

RJ Atkinson <rja@extremenetworks.com> Wed, 02 January 2008 16:13 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA6E0-0006tU-8h; Wed, 02 Jan 2008 11:13:48 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA6Dz-0006tO-3s for ram@iab.org; Wed, 02 Jan 2008 11:13:47 -0500
Received: from eastrmmtao101.cox.net ([68.230.240.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JA6Dw-0004p7-U5 for ram@iab.org; Wed, 02 Jan 2008 11:13:47 -0500
Received: from eastrmimpo03.cox.net ([68.1.16.126]) by eastrmmtao101.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20080102161344.VGN129.eastrmmtao101.cox.net@eastrmimpo03.cox.net> for <ram@iab.org>; Wed, 2 Jan 2008 11:13:44 -0500
Received: from [10.30.20.71] ([68.10.115.26]) by eastrmimpo03.cox.net with bizsmtp id YG1w1Y00J0aEP1Q0000000; Wed, 02 Jan 2008 11:01:57 -0500
Message-Id: <FC9DB879-0F83-47F7-9C3D-6C487BAFC330@extremenetworks.com>
From: RJ Atkinson <rja@extremenetworks.com>
To: ram@iab.org
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Wed, 2 Jan 2008 11:13:43 -0500
X-Mailer: Apple Mail (2.915)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Subject: [RAM] A curious Internet service offering
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

(NB: This doesn't directly relate to IRTF RRG work, but it does
relate to routing & addressing futures, so the IAB RAM list
seems to be the right venue for this narrow observation and
any followup discussion that might occur.)

I recently became aware of a large residential broadband operator
in North America that provides no global-scope IP addresses to
its customers.  By default there are no global-scope IP addresses
-- and none are available as an option at any price to residential
broadband subscribers to this particular service.

Instead, this operator deploys a combination/integrated home
gateway at each customer site.  This gateway is managed exclusively
by the network operator.  The only customer option (at time
of installation) is whether wireless is enabled or not.  This
gateway performs NAT/NAPT, has an 802.11 wireless service on the
customer side with WEP and WPA (but NOT 802.11i or WPA2), and
uses DHCP to distribute private (RFC-1918; specifically 192.168.x/24)
IP addresses to whatever devices the customer has on offer.
This CPE box also includes a 4-port Ethernet hub on the inside
of the NAT/NAPT to connect to any wired networks in the house.
Further, there are sundry additional packet/port filters inside
this CPE box.

The net result is that this particular operator isn't really
providing a "dialtone IP" service.  Instead, it is more nearly
a "only web and email access" service.  For example, there are
widespread reports that online gaming (e.g. using XBOX) does
not work with this service.  There are also complaints online
about how various uncommonly used transport-layer ports seem
to be blocked.  The most commonly used ports (DNS, HTTP, HTTPS,
IMAP4, SMTP, POP3) appear to work through this CPE box.  Of
course, VoIP is also blocked -- though this operator does offer
POTS lines via a separate adapter located at the customer premise.

It is unclear to me whether/how this CPE integrated/combination
home gateway is addressed.  One could imagine the CPE box being
inside 10.0/8 and individual customers being inside 192.168.x/24
with NAT/NAPT in the CPE box and then again at some larger gateway
between the local region of this service and the public again.
I don't know for certain whether the CPE box is addressed by
IP, whether it has a private IP address, or whether it has a
global-scope IP address.


NOTE WELL:
The operator has no issues with IPv4 address availability.  This
is simply how they chose to define their service offering.  They
market it as "High-speed Internet".  They believe that customers
actually prefer to have the operator provide this narrower service
rather than a "dial-tone IP" service.


TWO QUICK OBSERVATIONS:
If this becomes a widely used deployment model, and customers accept
this, then there are at least two implications to consider:
   1) IPv4 Address shortages might not be as big an issue as some think.
   2) New services really are only deployable over HTTP/HTTPS.
      Nearly any other new protocol, NAT/NAPT-friendly or not,
      would likely not be usable by these end users.


I find the whole thing quite curious and unexpected.  I am sure
that other folks mileage likely will vary somehwat from my own.



Ran
rja@extremenetworks.com


_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram