rfc1726.txt

中、英文RFC文档大全打包下载完全版 .

      with each passing decade.  Thus, we believe that it must be
      possible to extend IPng to support new services and facilities.
      Furthermore, it is essential that any extensions can be
      incrementally deployed to only those systems which desire to use
      them. Systems upgraded in this fashion must still be able to
      communicate with systems which have not been so upgraded.



Partridge and Kastenholz                                       [Page 21]

RFC 1726                IPng Technical Criteria            December 1994


      There are several aspects to extensibility:

   5.13.1 Algorithms
         The algorithms used in processing IPng information should be
         decoupled from the protocol itself.  It should be possible to
         change these algorithms without necessarily requiring protocol,
         datastructure, or header changes.

   5.13.2 Headers
         The content of packet headers should be extensible.  As more
         features and functions are required of IPng, it may be
         necessary to add more information to the IPng headers.  We note
         that for IPv4, the use of options has proven less than entirely
         satisfactory since options have tended to be inefficient to
         process.

   5.13.3 Data Structures
         The fundamental data structures of IPng should not be bound
         with the other elements of the protocol.  E.g., things like
         address formats should not be intimately tied with the routing
         and forwarding algorithms in the way that the IPv4 address
         class mechanism was tied to IPv4 routing and forwarding.

   5.13.4 Packets
         It should be possible to add additional packet-types to IPng.
         These could be for, _e._g., new control and/or monitoring
         operations.

      We note that, everything else being equal, having larger,
      oversized, number spaces is preferable to having number spaces
      that are "just large enough".  Larger spaces afford more
      flexibility on the part of network designers and operators and
      allow for further experimentation on the part of the scientists,
      engineers, and developers.  See [7].

   Time Frame
      A framework showing mechanisms for extending the protocol must be
      provided immediately.

5.14 Network Service

   CRITERION
      The protocol must allow the network (routers, intelligent media,
      hosts, and so on) to associate packets with particular service
      classes and provide them with the services specified by those
      classes.





Partridge and Kastenholz                                       [Page 22]

RFC 1726                IPng Technical Criteria            December 1994


   DISCUSSION
      For many reasons, such as accounting, security and multimedia, it
      is desirable to treat different packets differently in the
      network.

      For example, multimedia is now on our desktop and will be an
      essential part of future networking.  So we have to find ways to
      support it; and a failure to support it may mean users choose to
      use protocols other than IPng.

      The IETF multicasts have shown that we can currently support
      multimedia over internetworks with some hitches.  If the network
      can be guaranteed to provide the necessary service levels for this
      traffic, we will dramatically increase its success.

      This criterion includes features such as policy-based routing,
      flows, resource reservation, network service technologies, type-
      of-service and quality-of-service and so on.

      In order to properly support commercial provision and use of
      Internetwork service, and account for the use of these services
      (i.e., support the economic principle of "value paid for value
      received") it must be possible to obtain guarantees of service
      levels.  Similarly, if the network can not support a previously
      guaranteed service level, it must report this to those to whom it
      guaranteed the service.

      Network service provisions must be secure.  The network-layer
      security must generally prevent one host from surreptitiously
      obtaining or disrupting the use of resources which another host
      has validly acquired.  (Some security failures are acceptable, but
      the failure rate must be very low and the rate should be
      quantifiable).

      One of the parameters of network service that may be requested
      must be cost-based.

      As far as possible, given the limitations of underlying media and
      IP's model of a robust internet datagram service, real-time,
      mission-critical applications must be supported by IPng [6].

      Users must be able to confirm that they are, in fact, getting the
      services that they have requested.

   Time Frame
      This should be available within 24 months.





Partridge and Kastenholz                                       [Page 23]

RFC 1726                IPng Technical Criteria            December 1994


5.15 Support for Mobility

   CRITERION
      The protocol must support mobile hosts, networks and
      internetworks.

   DISCUSSION
      Again, mobility is becoming increasingly important.  Look at the
      portables that everyone is carrying.  Note the strength of the
      Apple commercial showing someone automatically connecting up her
      Powerbook to her computer back in the office.  There have been a
      number of pilot projects showing ways to support mobility in IPv4.
      All have some drawbacks.  But like network service grades, if we
      can support mobility, IPng will have features that will encourage
      transition.

      We use an encompassing definition of "mobility" here.  Mobility
      typically means one of two things to people: 1) Hosts that
      physically move and remain connected (via some wireless datalink)
      with sessions and transport-layer connections remaining 'open' or
      'active' and 2) Disconnecting a host from one spot in the network,
      connecting it back in another arbitrary spot and continuing to
      work.  Both forms are required.

      Reference [6] discusses possible future use of IP-based networks
      in the US Navy's ships, planes, and shore installations.  Their
      basic model is that each ship, plane and shore installation
      represents at least one IP network.  The ship- and plane-based
      networks, obviously, are mobile as these craft move around the
      world. Furthermore, most, if not all, Naval surface combatants
      carry some aircraft (at a minimum, a helicopter or two). So, not
      only must there be mobile networks (the ships that move around),
      but there must be mobile internetworks: the ships carrying the
      aircraft where each aircraft has its own network, which is
      connected to the ship's network and the whole thing is moving.

      There is also the requirement for dynamic mobility; a plane might
      take off from aircraft carrier A and land on carrier B so it
      obviously would want to "connect" to B's network.  This situation
      might be even more complex since the plane might wish to retain
      connectivity to its "home" network; that is, the plane might
      remain connected to the ship-borne networks of both aircraft
      carriers, A and B.

      These requirements are not limited to just the navy.  They apply
      to the civilian and commercial worlds as well.  For example, in
      civil airliners, commercial cargo and passenger ships, trains,
      cars and so on.



Partridge and Kastenholz                                       [Page 24]

RFC 1726                IPng Technical Criteria            December 1994


   Time Frame
      The mobility algorithms are stabilizing and we would hope to see
      an IPng mobility framework within a year.

5.16 Control Protocol

   CRITERION
      The protocol must include elementary support for testing and
      debugging networks.

   DISCUSSION
      An important feature of IPv4 is the ICMP and its debugging,
      support, and control features.  Specific ICMP messages that have
      proven extraordinarily useful within IPv4 are Echo Request/Reply
      (a.k.a ping), Destination Unreachable and Redirect.  Functions
      similar to these should be in IPng.

      This criterion explicitly does not concern itself with
      configuration related messages of ICMP.  We believe that these are
      adequately covered by the configuration criterion in this memo.

      One limitation of today's ICMP that should be fixed in IPng's
      control protocol is that more than just the IPng header plus 64
      bits of a failed datagram should be returned in the error message.
      In some situations, this is too little to carry all the critical
      protocol information that indicates why a datagram failed.  At
      minimum, any IPng control protocol should return the entire IPng
      and transport headers (including options or nested headers).

   Time Frame
      Support for these functions is required immediately.

5.17 Private Networks

   CRITERION
      IPng must allow users to build private internetworks on top of the
      basic Internet Infrastructure.  Both private IP-based
      internetworks and private non-IP-based (e.g., CLNP or AppleTalk)
      internetworks must be supported.

   DISCUSSION
      In the current Internet, these capabilities are used by the
      research community to develop new IP services and capabilities
      (e.g., the MBone) and by users to interconnect non-IP islands over
      the Internet (e.g., CLNP and DecNet use in the UK).

      The capability of building networks on top of the Internet have
      been shown to be useful.  Private networks allow the Internet to



Partridge and Kastenholz                                       [Page 25]

RFC 1726                IPng Technical Criteria            December 1994


      be extended and modified in ways that 1) were not foreseen by the
      original builders and 2) do not disrupt the day-to-day operations
      of other users.

      We note that, today in the IPv4 Internet, tunneling is widely used
      to provide these capabilities.

      Finally, we note that there might not be any features that
      specifically need to be added to IPng in order to support the
      desired functions (i.e., one might treat a private network protocol
      simply as another IP client protocol, just like TCP or UDP). If
      this is the case, then IPng must not prevent these functions from
      being performed.

   Time Frame
      Some of these capabilities may be required to support other
      criteria (e.g., transition) and as such, the timing of the
      specifications is governed by the other criteria (e.g., immediately
      in the case of transition).  Others may be produced as desired.

6. Things We Chose Not to Require

   This section contains items which we felt should not impact the
   choice of an IPng.  Listing an item here does not mean that a
   protocol MUST NOT do something. It means that the authors do not
   believe that it matters whether the feature is in the protocol or
   not. If a protocol includes one of the items listed here, that's
   cool. If it doesn't; that's cool too. A feature might be necessary in
   order to meet some other criterion.  Our point is merely that the
   feature need not be required for its own sake.

6.1 Fragmentation

   The technology exists for path MTU discovery.  Presumably, IPng will
   continue to provide this technology.  Therefore, we believe that IPng
   Fragmentation and Reassembly, as provided in IPv4, is not necessary.
   We note that fragmentation has been shown to be detrimental to
   network performance and strongly recommend that it be avoided.

6.2 IP Header Checksum

   There has been discussion indicating that the IP Checksum does not
   provide enough error protection to warrant its performance impact.
   The argument states that there is almost always a stronger datalink
   level CRC, and that end-to-end protection is provided by the TCP
   checksum. Therefore we believe that an IPng checksum is not required
   per-se.




Partridge and Kastenholz                                       [Page 26]

RFC 1726                IPng Technical Criteria