1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
|
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
Taylor [Page 1]
^L
RFC 1674 A Cellular Industry View of IPng August 1994
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.
Taylor [Page 2]
^L
RFC 1674 A Cellular Industry View of IPng August 1994
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
Taylor [Page 3]
^L
|
