rfc1475.txt

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

Network Working Group                                        R. Ullmann
Request for Comments: 1475                 Process Software Corporation
                                                              June 1993


                        TP/IX: The Next Internet

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard.  Discussion and
   suggestions for improvement are requested.  Please refer to the
   current edition of the "IAB Official Protocol Standards" for the
   standardization state and status of this protocol.  Distribution of
   this memo is unlimited.

Abstract

   The first version of this memo, describing a possible next generation
   of Internet protocols, was written by the present author in the
   summer and fall of 1989, and circulated informally, including to the
   IESG, in December 1989.  A further informal note on the addressing,
   called "Toasternet Part II", was circulated on the IETF mail list
   during March of 1992.

Table of Contents

   1.       Introduction . . . . . . . . . . . . . . . . . . . . 3
   1.1       Objectives  . . . . . . . . . . . . . . . . . . . . 5
   1.2       Philosophy  . . . . . . . . . . . . . . . . . . . . 6
   2.       Internet numbers . . . . . . . . . . . . . . . . . . 6
   2.1       Is 64 Bits Enough?  . . . . . . . . . . . . . . . . 6
   2.2       Why version 7?  . . . . . . . . . . . . . . . . . . 7
   2.3       The version 7 IP address  . . . . . . . . . . . . . 7
   2.4       AD numbers  . . . . . . . . . . . . . . . . . . . . 8
   2.5       Mapping of version 4 numbers  . . . . . . . . . . . 8
   3.       IP: Internet datagram protocol . . . . . . . . . . . 9
   3.1       IP datagram header format . . . . . . . . . . . .  10
   3.1.1       Version . . . . . . . . . . . . . . . . . . . .  10
   3.1.2       Header length . . . . . . . . . . . . . . . . .  10
   3.1.3       Time to live  . . . . . . . . . . . . . . . . .  10
   3.1.4       Total datagram length . . . . . . . . . . . . .  11
   3.1.5       Forward route identifier  . . . . . . . . . . .  11
   3.1.6       Destination . . . . . . . . . . . . . . . . . .  11
   3.1.7       Source  . . . . . . . . . . . . . . . . . . . .  11
   3.1.8       Protocol  . . . . . . . . . . . . . . . . . . .  11
   3.1.9       Checksum  . . . . . . . . . . . . . . . . . . .  11
   3.1.10      Options . . . . . . . . . . . . . . . . . . . .  11



Ullmann                                                         [Page 1]

RFC 1475                         TP/IX                         June 1993


   3.2       Option Format . . . . . . . . . . . . . . . . . .  12
   3.2.1       Class (C) . . . . . . . . . . . . . . . . . . .  12
   3.2.2       Copy on fragmentation (F) . . . . . . . . . . .  13
   3.2.3       Type  . . . . . . . . . . . . . . . . . . . . .  13
   3.2.4       Length  . . . . . . . . . . . . . . . . . . . .  13
   3.2.5       Option data . . . . . . . . . . . . . . . . . .  13
   3.3       IP options  . . . . . . . . . . . . . . . . . . .  13
   3.3.1       Null  . . . . . . . . . . . . . . . . . . . . .  13
   3.3.2       Fragment  . . . . . . . . . . . . . . . . . . .  14
   3.3.3       Last Fragment . . . . . . . . . . . . . . . . .  14
   3.3.4       Don't Fragment  . . . . . . . . . . . . . . . .  15
   3.3.5       Don't Convert . . . . . . . . . . . . . . . . .  15
   3.4       Forward route identifier  . . . . . . . . . . . .  15
   3.4.1       Procedure description . . . . . . . . . . . . .  15
   3.4.2       Flows . . . . . . . . . . . . . . . . . . . . .  17
   3.4.3       Mobile hosts  . . . . . . . . . . . . . . . . .  17
   4.       TCP: Transport protocol  . . . . . . . . . . . . .  18
   4.1       TCP segment header format . . . . . . . . . . . .  18
   4.1.1       Data offset . . . . . . . . . . . . . . . . . .  19
   4.1.2       MBZ . . . . . . . . . . . . . . . . . . . . . .  19
   4.1.3       Flags . . . . . . . . . . . . . . . . . . . . .  19
   4.1.4       Checksum  . . . . . . . . . . . . . . . . . . .  19
   4.1.5       Source port . . . . . . . . . . . . . . . . . .  20
   4.1.6       Destination port  . . . . . . . . . . . . . . .  20
   4.1.7       Sequence  . . . . . . . . . . . . . . . . . . .  20
   4.1.8       Acknowledgement . . . . . . . . . . . . . . . .  20
   4.1.9       Window  . . . . . . . . . . . . . . . . . . . .  20
   4.1.10      Options . . . . . . . . . . . . . . . . . . . .  20
   4.2       Port numbers  . . . . . . . . . . . . . . . . . .  20
   4.3       TCP options . . . . . . . . . . . . . . . . . . .  21
   4.3.1       Option Format . . . . . . . . . . . . . . . . .  21
   4.3.2       Null  . . . . . . . . . . . . . . . . . . . . .  21
   4.3.3       Maximum Segment Size  . . . . . . . . . . . . .  21
   4.3.4       Urgent Pointer  . . . . . . . . . . . . . . . .  21
   4.3.5       32 Bit rollover . . . . . . . . . . . . . . . .  21
   5.       UDP: User Datagram protocol  . . . . . . . . . . .  22
   5.1       UDP header format . . . . . . . . . . . . . . . .  22
   5.1.1       Data offset . . . . . . . . . . . . . . . . . .  22
   5.1.2       MBZ . . . . . . . . . . . . . . . . . . . . . .  22
   5.1.3       Checksum  . . . . . . . . . . . . . . . . . . .  22
   5.1.4       Source port . . . . . . . . . . . . . . . . . .  22
   5.1.5       Destination port  . . . . . . . . . . . . . . .  22
   5.1.6       Options . . . . . . . . . . . . . . . . . . . .  23
   6.       ICMP . . . . . . . . . . . . . . . . . . . . . . .  23
   6.1       ICMP header format  . . . . . . . . . . . . . . .  23
   6.2       Conversion failed ICMP message  . . . . . . . . .  23
   7.       Notes on the domain system . . . . . . . . . . . .  25
   7.1       A records . . . . . . . . . . . . . . . . . . . .  25



Ullmann                                                         [Page 2]

RFC 1475                         TP/IX                         June 1993


   7.2       PTR zone  . . . . . . . . . . . . . . . . . . . .  25
   8.       Conversion between version 4 and version 7 . . . .  25
   8.1       Version 4 IP address extension option . . . . . .  26
   8.1.1     Option format . . . . . . . . . . . . . . . . . .  26
   8.2      Fragmented datagrams . . . . . . . . . . . . . . .  26
   8.3      Where does the conversion happen?  . . . . . . . .  27
   8.4      Hybrid IPv4 systems  . . . . . . . . . . . . . . .  28
   8.5      Maximum segment size in TCP  . . . . . . . . . . .  28
   8.6      Forwarding and redirects . . . . . . . . . . . . .  28
   8.7      Design considerations  . . . . . . . . . . . . . .  28
   8.8      Conversion from IPv4 to IPv7 . . . . . . . . . . .  29
   8.9      Conversion from IPv7 to IPv4 . . . . . . . . . . .  30
   8.10     Conversion from TCPv4 to TCPv7 . . . . . . . . . .  31
   8.11     Conversion from TCPv7 to TCPv4 . . . . . . . . . .  32
   8.12     ICMP conversion  . . . . . . . . . . . . . . . . .  33
   9.       Postscript . . . . . . . . . . . . . . . . . . . .  33
   10.      References . . . . . . . . . . . . . . . . . . . .  34
   11.      Security Considerations  . . . . . . . . . . . . .  35
   12.      Author's Address . . . . . . . . . . . . . . . . .  35

1.  Introduction

   This memo presents the specification for version 7 of the Internet
   Protocol, as well as version 7 of the TCP and the user datagram
   protocol.  Version 7 has been designed to address several major
   problems that have arisen as version 4 has evolved and been deployed,
   and to make a major step forward in the datagram switching and
   forwarding architecture of the Internet.

   The major problems are threefold.  First, the address space of
   version 4 is now seen to be too small.  While it was viewed as being
   almost impossibly large when version 4 was designed, two things have
   occurred to create a problem.  The first is a success crisis:  the
   internet protocols have been more widely used and accepted than their
   designers anticipated.  Also, technology has moved forward, putting
   microprocessors into devices not anticipated except as future dreams
   a decade ago.

   The second major problem is a perceived routing explosion.  The
   present routing architecture of the internet calls for routing each
   organization's network independently.  It is becoming increasingly
   clear that this does not scale to a universal internet.  While it is
   possible to route several billion networks in a flat, structureless
   domain, it is not desireable.

   There is also the political administrative issue of assigning network
   numbers to organizations.  The version 4 administrative system calls
   for organizations to request network assignments from a single



Ullmann                                                         [Page 3]

RFC 1475                         TP/IX                         June 1993


   authority.  While to some extent this has been alleviated by
   reserving blocks to delegated assignments, the address space is not
   large enough to do this in the necessary general case, with large
   blocks allocated to (e.g.) national authority.

   The third problem is the increasing bandwidth of the networks and of
   the applications possible on the network.  The TCP, while having
   proven useful on an unprecedented range of network speeds, is now the
   limiting factor at the highest speeds, due to restrictions of window
   size, sequence-space, and port numbers.  These limitations can all be
   addressed by increasing the sizes of the relevant fields.  See
   [RFC1323].

   There is also an opportunity to move the technology forward, and take
   advantage of a combination of the best features of the hop-by-hop
   connectionless forwarding of version 4 (and CLNP) as well as the
   pre-established paths of version 5 (and, e.g., the OSI CONS).

   Internet Version 7 includes four major areas of improvement, while at
   the same time retaining interoperation with version 4 with a small
   amount of conversion knowledge imposed on version 7 hosts and
   routers.

      o  It increases the address fields to 64 bits, with sufficient
         space for visible future expansion of the internet.

      o  It adds a numbering layer for administrations, above the
         organization or network layer, as well as providing more
         space for subnetting within organizations.

      o  It increases the range of speeds and network path delays over
         which the TCP will operate satisfactorily, as well as the
         number of transactions in bounded time that can be served by
         a host.

      o  Finally, it provides a forward route identifier in each
         datagram, to support extremely fast path, circuit, or
         flow-based forwarding, or any desired combination, while
         preserving hop-by-hop connectivity.

   The result is not just a movement sideways, deploying a new network
   layer protocol to patch current problems.  It is a significant step
   forward for network layer technology,








Ullmann                                                         [Page 4]

RFC 1475                         TP/IX                         June 1993


1.1  Objectives

   The following are some of the objectives of the design.

  o  Use what has been learned from the IP version 4 protocol, fixing
     things that are troublesome, and not fixing that which is not
     broken.

  o  Retain the essential "look and feel" of the Internet protocol
     suite.  It has been very successful, and one doesn't argue with
     success.

  o  Not introduce concepts that the Internet has shown do not belong
     in the protocol definition.  Best example:  we do not want to add
     any kind of routing information into the addressing, other than
     the administrative hierarchy that has sometimes proved useful.
     Note that the one feature in version 4 addressing (the class
     system) designed to aid routing is now the most serious single
     problem.

  o  Allow current hosts to interoperate, if not universally, at least
     within an organization or larger area for the indefinite future.
     There will be version 4 hosts for 10-15 years into the future,
     the Internet must remain on good terms with them.

  o  Likewise, we must not impose the new version, telling sites they
     must convert to stay connected.  People resist imposed solutions.
     It must not be marketed as something different from IPv4; the
     differences must be down-played at every opportunity.

  o  The design must allow individual hosts and routers to be upgraded
     effectively at random, with no transition plan constraints.

  o  The design must not require renumbering the Internet.  The
     administrative work already accomplished is immense, if it is to
     be done again it will be in assigning NSAPs.

  o  It must allow IPv4 hosts to interoperate without any reduction in
     function, without any modification to their software or
     configuration.  (Universal connectivity will be lost by IPv4
     hosts, but they must be able to continue operating within their
     organization at least.)

  o  It must permit network layer state-free translation of datagrams
     between IPv4 and IPv7; this is important to the previous point,
     and essential to early testing and transitional deployment.

  o  It must be a competent alternative to CLNP.



Ullmann                                                         [Page 5]

RFC 1475                         TP/IX                         June 1993


  o  It must not involve changing the semantics of the network layer
     service in any way that invalidates the huge amount of work that
     has gone into understanding how TCP (for example) functions in
     the net, and the implementation of that understanding.

  o  It must be defined Real Soon; the window of opportunity is almost
     closed.  It will take vendors 3 years to deploy from the time the
     standard is rock-solid concrete.

   I believe all of these are accomplishable in a consistent, well-
   engineered solution, and all are essential to the survival of the
   Internet.

1.2  Philosophy

   Protocols should become simpler as they evolve.

2.  Internet numbers

   The version 4 numbering system has proven to be very flexible,
   (mostly) expandable, and simple.  In short:  it works.  There are two
   problems, neither serious when this specification was first developed
   in 1988 and 1989, but have as expected become more serious:

      o  The division into network, and then subnet, is insufficient.
         Almost all sites need a network assignment large enough to
         subnet.  At the top of the hierarchy, there is a need to
         assign administrative domains.

      o  As bit-packing is done to accomplish the desired network