rfc1678.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 1678     IPng Requirements of Large Corporate Networks   August 1994


Heterogeneity

   Corporate users want the Internet to accommodate multiple protocol
   suites.  Several different protocol suites are growing in use, and
   some older ones will be used for many more years.  Although many
   people wish there were only one protocol in the world, there is
   little agreement on which one it should be.

   Since the marketplace has not settled on one approach to handling
   multiple protocols, IPng should be flexible enough to accommodate a
   variety of technical approaches to achieving heterogeneity.  For
   example, most networking protocols assume they will be the dominate
   protocol that transports all others;  protocol designers should pay
   more attention to making their protocols easily transported by
   others.  IPng needs to be flexible enough to accommodate the major
   multiprotocol trends, including multiprotocol transport networking
   (for an example, see X/OPEN document G306), tunneling (both IP being
   the tunnel and being tunneled), and link sharing (e.g., point-to-
   point protocol and frame relay).  Fair sharing of bandwidth by
   protocols with different congestion control mechanisms is a
   particularly interesting subject.

Flow and Resource Reservation

   Corporate users are becoming more interested in transmitting both
   non-isochronous and isochronous information together across the same
   link.  IPng should coexist effectively with the isochronous protocols
   being developed for the Internet.

   The Internet protocols should take advantage of services that may be
   offered by an underlying fast packet switching service. Constant-
   bit-rate and variable-bit-rate services typically require
   specification of, and conformance to, traffic descriptors and
   specification of quality-of-service objectives from applications or
   users.  The Internet's isochronous protocols should provide
   mechanisms to take advantage of multimedia services that will be
   offered by fast packet switching networks, and must ensure that
   quality-of-service guarantees are preserved all the way up the
   protocol stacks to the applications.  Protocols using available-bit-
   rate services may achieve better bandwidth utilization if they react
   to congestion messages from a fast packet switching network, and if
   they consider consequences of cell discard (e.g., if one cell of an
   IP datagram is discarded, it would be a waste to continue forwarding
   the rest of the cells in that datagram; also, selective retransmit
   should be revisited in this context).

   When the Internet protocol suite allows mixing of non-isochronous and
   isochronous traffic on one medium, it should provide mechanisms to



Britton & Tavs                                                  [Page 5]

RFC 1678     IPng Requirements of Large Corporate Networks   August 1994


   discourage inappropriate reservation of resources; e.g., a Telnet
   connection probably doesn't need to reserve 45Mbps.  Accounting,
   class-of-service, and well-known-port distinctions are possible ways
   to satisfy that requirement.

Mobile Hosts

   Wireless technology opens up opportunities for new TCP/IP
   applications that are specific to mobile hosts.  In addition to
   coordinating with organizations developing wireless standards, the
   IETF also should encourage the specification of new TCP/IP
   applications enabled by wireless, such as connectionless messaging.

   IPng should deal well with the characteristics (delay, error rates4,
   etc.) peculiar to wireless.

Topological flexibility

   Today a TCP/IP host moved to a different subnet needs a new IP
   address.  Such moves and changes can become a significant
   administrative cost.  Moreover, mobile hosts require flexible
   topology.  Note how the wireless world is trying to defeat the subnet
   model of addressing either by proxy or by IPaddress servers.  Perhaps
   IPng needs an addressing model more flexible than subnetting, both to
   reduce the administrative burden and to facilitate roaming users.

   The need to eliminate single points of failure drives the business
   requirement for multi-tail attachment of hosts to networks.
   Corporate users complain that TCP/IP can non-disruptively switch a
   connection from a broken route to a working one only if the new route
   leads to the same adapter on the end system.

Configuration, Administration and Operation

   Businesses would like dynamic but secure updating of Domain Name
   Servers, both to ease moves and changes and to facilitate cutover to
   backup hosts.  In this vein, secure and dynamic interaction between
   DNS and Dynamic Host Configuration Protocol (DHCP, RFC 1541) is
   required.  The IETF should encourage wide deployment of DHCP, and
   then solicit feedback on whether additional configuration
   requirements need to be satisfied.

Policy-Based Routing

   Policy-based routing is a more a solution than a requirement.
   Businesses rarely require a general purpose policy architecture,
   although they do state requirements that policy-based routing could
   satisfy.  For example, corporations do not want to carry for free the



Britton & Tavs                                                  [Page 6]

RFC 1678     IPng Requirements of Large Corporate Networks   August 1994


   transit traffic of other enterprises, and they may not want their
   sensitive data to flow through links controlled by certain other
   enterprises.  Policy-based routing is one possible way to satisfy
   those requirements, but there seems to be a concern that general
   purpose policy-based routing may have high administrative cost and
   low routing performance.

Scaling

   If IPng satisfies the scaling requirement of the Internet, then it
   satisfies it for corporate networks a fortiori.

Conclusions

   Enhancements to the Internet protocol suite, together with wider
   deployment of some of its existing architectures, could satisfy these
   requirement of commercial customers while retaining IPv4.  Expansion
   of the address space eventually will be necessary to allow continued
   Internet growth, but in RFC 1518 Tony Li and Yakov Rehkter have shown
   that from a technical perspective the addressing issue of IPng is not
   an immediate concern.

   Nevertheless, the TCP/IP community should establish a direction for
   enlargement of the address space, because unfounded publicity about
   the address space is scaring away potential TCP/IP users.  If the
   IETF does not provide direction on how its address space will grow,
   then people may use non-standard, and probably incompatible,
   approaches.

Security Considerations

   The IETF should encourage wide deployment of GSS API, and then
   solicit feedback on whether additional security requirements need to
   be satisfied.  Businesses are so concerned about network cost control
   mechanisms that they want them secured against tampering.  IPng
   should not interfer with firewalls, which many corporations consider
   essential.  See other comments on Security throughout this memo.














Britton & Tavs                                                  [Page 7]

RFC 1678     IPng Requirements of Large Corporate Networks   August 1994


Authors' Addresses

   Edward Britton
   IBM Corp.
   E69/503
   P.O.Box 12195
   Research Triangle Park, NC 27709

   Phone: [phone]
   EMail: [e-mail]


   John Tavs
   IBM Corp.
   E69/503
   P.O.Box 12195
   Research Triangle Park, NC 27709

   Phone: [phone]
   EMail: [e-mail]































Britton & Tavs                                                  [Page 8]