home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1674.txt < prev    next >
Text File  |  1996-05-07  |  6KB  |  97 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          M. Taylor Request for Comments: 1674                               CDPD Consortium Category: Informational                                      August 1994 
  8.  
  9.                      A Cellular Industry View of IPng 
  10.  
  11. Status of this Memo 
  12.  
  13.    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. 
  14.  
  15. Abstract 
  16.  
  17.    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. 
  18.  
  19. Introduction 
  20.  
  21.    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. 
  22.  
  23. Mobility 
  24.  
  25.    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. 
  26.  
  27.    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 
  28.  
  29.  
  30.  
  31. Taylor                                                          [Page 1] 
  32.  RFC 1674            A Cellular Industry View of IPng         August 1994 
  33.  
  34.     deployment wireless technology amplifies the requirement for    topological flexibility. 
  35.  
  36.    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. 
  37.  
  38. Scale 
  39.  
  40.    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. 
  41.  
  42. Addressing 
  43.  
  44.    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. 
  45.  
  46. Security 
  47.  
  48.    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. 
  49.  
  50. Accounting 
  51.  
  52.    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. 
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  Taylor                                                          [Page 2] 
  61.  RFC 1674            A Cellular Industry View of IPng         August 1994 
  62.  
  63.  Route Selection 
  64.  
  65.    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. 
  66.  
  67.    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. 
  68.  
  69. Data Efficiency 
  70.  
  71.    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. 
  72.  
  73.    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. 
  74.  
  75. Transition 
  76.  
  77.    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. 
  78.  
  79. Security Considerations 
  80.  
  81.    See section on Security. 
  82.  
  83. Author's Address 
  84.  
  85.    Mark S. Taylor    Director of System Development    McCaw Cellular Communications, Inc.    Wireless Data Division    10230 NE Points Drive    Kirkland, WA 98033-7869 USA 
  86.  
  87.    EMail: mark.s.taylor@airdata.com 
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95. Taylor                                                          [Page 3] 
  96.  
  97.