doc: Add RFC documents

1 files changed, 171 insertions, 0 deletions

diff --git a/doc/rfc/rfc1674.txt b/doc/rfc/rfc1674.txt
new file mode 100644
index 0000000..2a61351
--- /dev/null
+++ b/doc/rfc/rfc1674.txt
@@ -0,0 +1,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]
+
+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]
+
+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]
+