rfc1710.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,292 行 · 第 1/4 页

Network Working Group:                                         R. Hinden
Request for Comments: 1710                              Sun Microsystems
Category: Informational                                     October 1994


               Simple Internet Protocol Plus White Paper

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 document was submitted to the IETF IPng area in response to RFC
   1550.  Publication of this document does not imply acceptance by the
   IPng area of any ideas expressed within.  Comments should be
   submitted to the author and/or the [e-mail] mailing
   list.

1. Introduction

   This white paper presents an overview of the Simple Internet Protocol
   plus (SIPP) which is one of the candidates being considered in the
   Internet Engineering Task Force (IETF) for the next version of the
   Internet Protocol (the current version is usually referred to as
   IPv4).  This white paper is not intended to be a detailed
   presentation of all of the features and motivation for SIPP, but is
   intended to give the reader an overview of the proposal.  It is also
   not intended that this be an implementation specification, but given
   the simplicity of the central core of SIPP, an implementor familiar
   with IPv4 could probably construct a basic working SIPP
   implementation from reading this overview.

   SIPP is a new version of IP which is designed to be an evolutionary
   step from IPv4.  It is a natural increment to IPv4.  It can be
   installed as a normal software upgrade in internet devices and is
   interoperable with the current IPv4.  Its deployment strategy was
   designed to not have any "flag" days.  SIPP is designed to run well
   on high performance networks (e.g., ATM) and at the same time is
   still efficient for low bandwidth networks (e.g., wireless).  In
   addition, it provides a platform for new internet functionality that
   will be required in the near future.

   This white paper describes the work of IETF SIPP working group.
   Several individuals deserve specific recognition.  These include
   Steve Deering, Paul Francis, Dave Crocker, Bob Gilligan, Bill



Hinden                                                          [Page 1]

RFC 1710                 SIPP IPng White Paper              October 1994


   Simpson, Ran Atkinson, Bill Fink, Erik Nordmark, Christian Huitema,
   Sue Thompson, and Ramesh Govindan.

2. Key Issues for the Next Generation of IP

   There are several key issues that should be used in the evaluation of
   any next generation internet protocol.  Some are very
   straightforward.  For example the new protocol must be able to
   support large global internetworks.  Others are less obvious.  There
   must be a clear way to transition the current installed base of IP
   systems.  It doesn't matter how good a new protocol is if there isn't
   a practical way to transition the current operational systems running
   IPv4 to the new protocol.

2.1 Growth

   Growth is the basic issue which caused there to be a need for a next
   generation IP.  If anything is to be learned from our experience with
   IPv4 it is that the addressing and routing must be capable of
   handling reasonable scenarios of future growth.  It is important that
   we have an understanding of the past growth and where the future
   growth will come from.

   Currently IPv4 serves what could be called the computer market.  The
   computer market has been the driver of the growth of the Internet.
   It comprises the current Internet and countless other smaller
   internets which are not connected to the Internet.  Its focus is to
   connect computers together in the large business, government, and
   university education markets.  This market has been growing at an
   exponential rate.  One measure of this is that the number of networks
   in current Internet (23,494 as of 1/28/94) is doubling approximately
   every 12 months.  The computers which are used at the endpoints of
   internet communications range from PC's to Supercomputers.  Most are
   attached to Local Area Networks (LANs) and the vast majority are not
   mobile.

   The next phase of growth will probably not be driven by the computer
   market.  While the computer market will continue to grow at
   significant rates due to expansion into other areas such as schools
   (elementary through high school) and small businesses, it is doubtful
   it will continue to grow at an exponential rate.  What is likely to
   happen is that other kinds of markets will develop.  These markets
   will fall into several areas.  They all have the characteristic that
   they are extremely large.  They also bring with them a new set of
   requirements which were not as evident in the early stages of IPv4
   deployment.  The new markets are also likely to happen in parallel
   with other.  It may turn out that we will look back on the last ten
   years of Internet growth as the time when the Internet was small and



Hinden                                                          [Page 2]

RFC 1710                 SIPP IPng White Paper              October 1994


   only doubling every year.  The challenge for an IPng is to provide a
   solution which solves todays problems and is attractive in these
   emerging markets.

   Nomadic personal computing devices seem certain to become ubiquitous
   as their prices drop and their capabilities increase.  A key
   capability is that they will be networked.  Unlike the majority of
   todays networked computers they will support a variety of types of
   network attachments.  When disconnected they will use RF wireless
   networks, when used in networked facilities they will use infrared
   attachment, and when docked they will use physical wires.  This makes
   them an ideal candidate for internetworking technology as they will
   need a common protocol which can work over a variety of physical
   networks.  These types of devices will become consumer devices and
   will replace the current generation of cellular phones, pagers, and
   personal digital assistants.  In addition to the obvious requirement
   of an internet protocol which can support large scale routing and
   addressing, they will require an internet protocol which imposes a
   low overhead and supports auto configuration and mobility as a basic
   element.  The nature of nomadic computing requires an internet
   protocol to have built in authentication and confidentiality.  It
   also goes without saying that these devices will need to communicate
   with the current generation of computers.  The requirement for low
   overhead comes from the wireless media.  Unlike LAN's which will be
   very high speed, the wireless media will be several orders of
   magnitude slower due to constraints on available frequencies,
   spectrum allocation, and power consumption.

   Another market is networked entertainment.  The first signs of this
   emerging market are the proposals being discussed for 500 channels of
   television, video on demand, etc.  This is clearly a consumer market.
   The possibility is that every television set will become an Internet
   host.  As the world of digital high definition television approaches,
   the differences between a computer and a television will diminish.
   As in the previous market, this market will require an Internet
   protocol which supports large scale routing and addressing, and auto
   configuration.  This market also requires a protocol suite which
   imposes the minimum overhead to get the job done.  Cost will be the
   major factor in the selection of a technology to use.

   Another market which could use the next generation IP is device
   control.  This consists of the control of everyday devices such as
   lighting equipment, heating and cooling equipment, motors, and other
   types of equipment which are currently controlled via analog switches
   and in aggregate consume considerable amounts of power.  The size of
   this market is enormous and requires solutions which are simple,
   robust, easy to use, and very low cost.




Hinden                                                          [Page 3]

RFC 1710                 SIPP IPng White Paper              October 1994


   The challenge for the IETF in the selection of an IPng is to pick a
   protocol which meets today's requirements and also matches the
   requirements of these emerging markets.  These markets will happen
   with or without an IETF IPng.  If the IETF IPng is a good match for
   these new markets it is likely to be used.  If not, these markets
   will develop something else.  They will not wait for an IETF
   solution.  If this should happen it is probable that because of the
   size and scale of the new markets the IETF protocol would be
   supplanted.  If the IETF IPng is not appropriate for use in these
   markets, it is also probable that they will each develop their own
   protocols, perhaps proprietary.  These new protocols would not
   interoperate with each other.  The opportunity for the IETF is to
   select an IPng which has a reasonable chance to be used in these
   emerging markets.  This would have the very desirable outcome of
   creating an immense, interoperable, world-wide information
   infrastructure created with open protocols.  The alternative is a
   world of disjoint networks with protocols controlled by individual
   vendors.

2.2. Transition

   At some point in the next three to seven years the Internet will
   require a deployed new version of the Internet protocol.  Two factors
   are driving this: routing and addressing.  Global internet routing
   based on the on 32-bit addresses of IPv4 is becoming increasingly
   strained.  IPv4 address do not provide enough flexibility to
   construct efficient hierarchies which can be aggregated.  The
   deployment of Classless Inter-Domain Routing [CIDR] is extending the
   life time of IPv4 routing routing by a number of years, the effort to
   manage the routing will continue to increase.  Even if the IPv4
   routing can be scaled to support a full IPv4 Internet, the Internet
   will eventually run out of network numbers.  There is no question
   that an IPng is needed, but only a question of when.

   The challenge for an IPng is for its transition to be complete before
   IPv4 routing and addressing break.  The transition will be much
   easier if IPv4 address are still globally unique.  The two transition
   requirements which are the most important are flexibility of
   deployment and the ability for IPv4 hosts to communicate with IPng
   hosts.  There will be IPng-only hosts, just as there will be IPv4-
   only hosts.  The capability must exist for IPng-only hosts to
   communicate with IPv4-only hosts globally while IPv4 addresses are
   globally unique.

   The deployment strategy for an IPng must be as flexible as possible.
   The Internet is too large for any kind of controlled rollout to be
   successful.  The importance of flexibility in an IPng and the need
   for interoperability between IPv4 and IPng was well stated in a



Hinden                                                          [Page 4]

RFC 1710                 SIPP IPng White Paper              October 1994


   message to the sipp mailing list by Bill Fink, who is responsible for
   a portion of NASA's operational internet.  In his message he said:

      "Being a network manager and thereby representing the interests of
      a significant number of users, from my perspective it's safe to
      say that the transition and interoperation aspects of any IPng is
      *the* key first element, without which any other significant
      advantages won't be able to be integrated into the user's network
      environment.  I also don't think it wise to think of the
      transition as just a painful phase we'll have to endure en route
      to a pure IPng environment, since the transition/coexistence
      period undoubtedly will last at least a decade and may very well
      continue for the entire lifetime of IPng, until it's replaced with
      IPngng and a new transition.  I might wish it was otherwise but I
      fear they are facts of life given the immense installed base.

      "Given this situation, and the reality that it won't be feasible
      to coordinate all the infrastructure changes even at the national
      and regional levels, it is imperative that the transition
      capabilities support the ability to deploy the IPng in the
      piecemeal fashion...  with no requirement to need to coordinate
      local changes with other changes elsewhere in the Internet...

      "I realize that support for the transition and coexistence
      capabilities may be a major part of the IPng effort and may cause
      some headaches for the designers and developers, but I think it is
      a duty that can't be shirked and the necessary price that must be
      paid to provide as seamless an environment as possible to the end
      user and his basic network services such as e-mail, ftp, gopher,
      X-Window clients, etc...

      "The bottom line for me is that we must have interoperability
      during the extended transition period for the base IPv4
      functionality..."

   Another way to think about the requirement for compatibility with
   IPv4 is to look at other product areas.  In the product world,
   backwards compatability is very important.  Vendors who do not
   provide backward compatibility for their customers usually find they
   do not have many customers left.  For example, chip makers put
   considerable effort into making sure that new versions of their
   processor always run all of the software that ran on the previous
   model.  It is unlikely that Intel would develop a new processor in
   the X86 family that did not run DOS and the tens of thousands of
   applications which run on the current versions of X86's.

   Operating system vendors go to great lengths to make sure new
   versions of their operating systems are binary compatible with their



Hinden                                                          [Page 5]

RFC 1710                 SIPP IPng White Paper              October 1994


   old version.  For example the labels on most PC or MAC software
   usually indicate that they require OS version XX or greater.  It
   would be foolish for Microsoft come out with a new version of Windows
   which did not run the applications which ran on the previous version.
   Microsoft even provides the ability for windows applications to run
   on their new OS NT.  This is an important feature.  They understand
   that it was very important to make sure that the applications which
   run on Windows also run on NT.

   The same requirement is also true for IPng.  The Internet has a large
   installed base.  Features need to be designed into an IPng to make
   the transition as easy as possible.  As with processors and operating
   systems, it must be backwards compatible with IPv4.  Other protocols
   have tried to replace TCP/IP, for example XTP and OSI.  One element
   in their failure to reach widespread acceptance was that neither had
   any transition strategy other than running in parallel (sometimes
   called dual stack).  New features alone are not adequate to motivate
   users to deploy new protocols.  IPng must have a great transition
   strategy and new features.

3. History of the SIPP Effort

   The SIPP working group represents the evolution of three different
   IETF working groups focused on developing an IPng.  The first was
   called IP Address Encapsulation (IPAE) and was chaired by Dave
   Crocker and Robert Hinden.  It proposed extensions to IPv4 which
   would carry larger addresses.  Much of its work was focused on
   developing transition mechanisms.

   Somewhat later Steve Deering proposed a new protocol evolved from
   IPv4 called the Simple Internet Protocol (SIP).  A working group was
   formed to work on this proposal which was chaired by Steve Deering
   and Christian Huitema.  SIP had 64-bit addresses, a simplified
   header, and options in separate extension headers.  After lengthly
   interaction between the two working groups and the realization that
   IPAE and SIP had a number of common elements and the transition
   mechanisms developed for IPAE would apply to SIP, the groups decided