RFC 1674 INFORMATIONAL IPNG · WIRELESS · MOBILITY

A Cellular Industry View of IPng

The CDPD consortium's proposed requirements for IPng.

On rfc-editor.org ↗
PUBLISHED
August 1994
AUTHORS
M. Taylor
STREAM
Legacy
NORTH AMERICAN USER ESTIMATE FOR 2007
20 to 40 million
ADDRESS CAPACITY PROPOSED
Tens or hundreds of billions
DOI
10.17487/RFC1674

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
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

ISO Plain Language

On this page
PROBLEMThe CDPD consortium wanted IPng to support mobile devices, large address needs, and the operational requirements of wireless data services.
MECHANISMThe memo lists requirements covering mobility, scale, addressing, security, accounting, route selection, data efficiency, and transition from IPv4.
REQUIREMENTS FROM CDPDIt provides input to IPng technical discussions and explicitly does not represent an industry endorsement or commitment.

§1Mobility for Wireless Devices

The memo presents draft IPng requirements from representatives of the CDPD service-provider consortium. Its primary requirement is that IPng not impede mobility: devices should operate in different locations while applications remain the same for users.

The memo says packets should be self-contained and allow redirection, so IPng should remain connectionless. It also calls for native support for mobility and for occasionally connected hosts.

IPng should allow a device to move without changing how its applications look to the user. The memo also says IPng should accommodate devices that connect only sometimes.

§2Scale, Addressing, and Security

The consortium estimates 20 to 40 million North American users by 2007 and says IPng should support billions of users worldwide and tens or hundreds of billions of addresses. It expects hierarchical, variable-length addresses, distributed administration, and a mapping between names and addresses that is independent of location.

The memo also calls for security services such as peer authentication, data and traffic-flow confidentiality, data integrity, and location confidentiality. It identifies Layer 3 accounting as a requirement.

The consortium expects very large numbers of users and asks for flexible addresses that can be managed across organizations. It also lists security and accounting as requirements.

§3Route Selection and Wireless Efficiency

The memo says source- and policy-based inter-domain routing could support service-provider selection, and IPng should allow selection of at least the first transit provider based on the source host. It also calls for compact Layer 3 protocol information and packet prioritization to use limited wide-area wireless bandwidth efficiently.

The proposed routing features would let traffic selection depend on the source host. The memo also asks IPng to keep overhead low and support packet priorities on limited-bandwidth networks.

§7Transition from IPv4

The memo says IPng must interoperate with IP for the foreseeable future. It calls for bridging mechanisms and a defined transition strategy, and notes that options fields could help new protocols support IP addresses and headers.

The submission is input to IETF technical discussions; it does not represent endorsement or commitment by the CDPD consortium, cellular industry, or constituent companies.

IPng should work alongside IP during a transition. These requirements are a contribution to discussion, not a commitment by the organizations named.

§5References