A Cellular Industry View of IPng
Wireless carrier networks want mobility, scalability, and reliable accounting built into IPng.
Taylor, M., "A Cellular Industry View of IPng", RFC 1674, DOI 10.17487/RFC1674, August 1994, <https://www.rfc-editor.org/info/rfc1674>.
@misc{rfc1674,
series = {Request for Comments},
number = 1674,
howpublished = {RFC 1674},
publisher = {RFC Editor},
doi = {10.17487/RFC1674},
url = {https://www.rfc-editor.org/info/rfc1674},
author = {M. Taylor},
title = {{A Cellular Industry View of IPng}},
pagetotal = 3,
year = 1994,
month = aug,
} RFC text
Contents
Network Working Group M. Taylor
Request for Comments: 1674 CDPD Consortium
Category: Informational August 1994
A Cellular Industry View of IPng
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This memo is a response to RFC 1550, "IP: Next Generation (IPng)
White Paper Solicitation". The statements in this paper are intended
as input to the technical discussions within IETF, and do not
represent any endorsement or commitment on the part of the cellular
industry, the Cellular Digital Packet Data (CDPD) consortium of
service providers or any of its constituent companies.
Introduction
This is a draft of the requirements for IPng as envisioned by
representatives of the Cellular Digital Packet Data (CDPD) consortium
of service providers. As the leading service providers for this
nascent technology, which will provide the capability for mobility of
native mainstream connectionless network layer-based applications it
is our intention to support whatever form IPng takes. However, there
are several requirements which we feel IPng must meet.
Mobility
Since we will offer mobile services, our primary requirement is that
IPng not inhibit our support of mobility. IPng must not impede
devices from being able to operate anywhere anytime. Applications on
these mobile devices must look and feel the same to the user
regardless of location. NPDUs should be self-contained and not
disallow the redirection inherent to our mobility solution, i.e.,
IPng must be connectionless.
Further, since IPng provides an opportunity for design enhancements
above and beyond IPv4, we propose that native support for mobility be
regarded as an explicit IPng requirement. Local area and wide area
wireless technology creates new opportunities for both TCP/IP and the
Internet. Although the capability for mobility is orthogonal to the
wired or wireless nature of the data link in use, the rapid
deployment wireless technology amplifies the requirement for
topological flexibility.
As a by-product of mobility, the significance of "occasionally-
connected hosts" increases. The ability to accommodate
occasionally-connected hosts in IPng is a requirement.
Scale
In terms of scale, we envision some 20 to 40 million users by the
year 2007. In this context a "user" can be anything from a vending
machine to a "road warrior". These numbers are for North America
alone. Worldwide, we anticipate that IPng should be able to support
billions of "users". Of course, the sparseness of network address
assignments which is necessary for subnetting, etc., dictates that
IPng should support at least tens or hundreds of billions of
addresses.
Addressing
In terms of addressing, we would expect addresses to be hierarchical.
In addition, a node with multiple links should require only a single
address although more than one address should also be possible. The
mapping of names to addresses should be independent of location; an
address should be an address, not a route. Variable-length
addressing is also required to ensure continued protocol (IPng)
extensibility. Administration of address assignments should be
distributed and not centralized as it is now.
Security
IPng should also support security mechanisms which will grow
increasingly important on the proverbial "information highway" for
commercial users. Security services which may optionally be expected
from a Layer 3 entity such as IPng include peer entity
authentication, data confidentiality, traffic flow confidentiality,
data integrity and location confidentiality.
Accounting
The ability to do accounting at Layer 3 is a requirement. The CDPD
specification can be used as a model of the type of accounting
services that we need.
Route Selection
In the voice communications arena, "equal access" and choice of an
"interexchange carrier (IXC)" are issues that must be addressed.
Similar requirements for data may also exist.
Source- and policy-based routing for inter-domain traffic can address
this requirement. IPng must allow the selection of at least the
first transient network service provider based on the source host.
Data Efficiency
The bandwidth of wide area wireless networks is a precious resource,
the use of which must be optimized. IPng must allow optimal use of
the underlying Layer 2 medium. Layer 3 Protocol Control Information
(PCI) should be as condensed as possible. The protocol should be
optimized for data efficiency.
Packet prioritization must also be supported by IPng in order to
optimize the use of low speed networks. This requirement includes
both class and grade of service definitions for flexibility.
Transition
The final requirement for IPng is that it must interoperate with IP
for the foreseeable future. Bridging mechanisms must be supported
and a strategy for the transition from IPv4 to IPng must be defined.
Use of options fields, etc., are one mechanism to support the
requirement for IPng protocols to support IP addresses and headers.
Security Considerations
See section on Security.
Author's Address
Mark S. Taylor
Director of System Development
McCaw Cellular Communications, Inc.
Wireless Data Division
10230 NE Points Drive
Kirkland, WA 98033-7869 USA
EMail: mark.s.taylor@airdata.com
AI ELI5
On this page
§1The Cellular Digital Packet Data Perspective
RFC 1674 presents the view of the Cellular Digital Packet Data (CDPD) consortium, a group of wireless service providers. Mark Taylor from McCaw Cellular explains that as leading providers of nascent mobile data technology, the consortium is committed to supporting whatever form IPng takes, but has several critical requirements.
The RFC frames IPng as an opportunity to design in features for mobility from the start, rather than bolting them on later. The statement represents input for technical discussions but not a commitment from the industry or individual companies.
Wireless carriers say they will use whatever IPng becomes, but they want it designed for phones and mobile devices from the start.
§2Mobility and Scale
The primary requirement is that IPng must not impede mobile devices. IPng must allow devices to operate anywhere anytime, with applications looking and feeling the same regardless of location. NPDUs (network protocol data units) must be self-contained and support redirection; IPng must be connectionless.
CDPD projects 20 to 40 million North American users by 2007 (each could be a vending machine or a road warrior) and billions worldwide. IPng must support tens or hundreds of billions of addresses to account for the sparseness required by subnetting. The consortium also highlights the need to support occasionally-connected hosts that go offline and rejoin.
Phones should work anywhere, even moving between towers. The system should handle billions of devices and not break when a phone goes offline and comes back.
§3Addressing, Security, and Efficiency
IPng addresses should be hierarchical for scalable routing. A node with multiple links should be addressable by a single address (though multiple addresses should also be allowed). Address-to-name mapping should be independent of location: an address is an address, not a route. Variable-length addressing ensures continued protocol extensibility, and address administration should be distributed, not centralized.
Security mechanisms must support peer authentication, data confidentiality, traffic flow confidentiality, data integrity and location confidentiality. Layer 3 accounting is a requirement, following the CDPD model. Policy-based routing and source-based routing should let carriers offer equal access and choice of carrier (comparable to telephone interexchange choice).
Data efficiency is critical since wireless bandwidth is precious. Protocol overhead should be minimized, and packet prioritization (class and grade of service) should be supported.
Addresses should nest like postal codes; security should hide location; the network should track who to bill; routing should let carriers compete; and every bit counts on slow wireless links.
§4Transition and Coexistence
IPng must interoperate with IPv4 for the foreseeable future. Bridging mechanisms must be supported, and a clear transition strategy from IPv4 to IPng must be defined. Option fields and other mechanisms should allow IPng protocols to support IPv4 addresses and headers where necessary.
This requirement acknowledges the reality that wireless infrastructure will grow alongside existing wired networks for years, requiring dual-stack or translation capabilities.
Old Internet and new Internet must work together for a long time, so people can migrate at their own pace.