rfc1475.txt

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

         structure, the 32 bit limit causes more and more aggravation.

2.1  Is 64 Bits Enough?

   Consider:  (thought experiment) 32 bits presently numbers "all" of
   the computers in the world, and another 32 bits could be used to
   number all of the bytes of on-line storage on each computer.  (Most
   have a lot less than 4 gigabytes on-line, the ones that have more
   could be notionally assigned more than one address.)

   So: 64 bits is enough to number every byte of online storage in
   existence today, in a hierarchical structured numbering plan.

   Another way of looking at 64 bits:  it is more than 2 billion
   addresses for each person on the planet.  Even if I have
   microprocessors in my shirt buttons I'm not going to have that many.
   32 bits, on the other hand, was never going to be sufficient:  there
   are more than 2^32 people.



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


2.2  Why version 7?

   It was clearly recognized at the start of this project in 1988 that
   making the address 64 bits implies a new IP header format, which was
   called either "TP/IX" or "IP version 7"; there wasn't anything magic
   about the number 7, I made it up.  Version 4 is the familiar current
   version of IP.  Version 5 is the experimental ST (Stream) protocol.
   ST-II, a newer version of ST, uses the same version number, something
   I was not aware of until recently; I suspected it might have been
   allocated 6.  Besides, I liked 7.

   Apparently (as reported by Bob Braden) the IAB followed much the same
   logic, and may have had the idea planted by the mention of version 7
   in the "Toasternet Part II" memo.  The IAB in June 1992 floated a
   proposal that CLNP, or a CLNP-based design, be Internet Version 7.
   (And promptly got themselves toasted.) However, close inspection of
   the bits shows that CLNP is clearly version 8.

2.3  The version 7 IP address

   The Version 7 IP 64 bit address looks like:

    +-------+-------+-------+-------+-------+-------+-------+-------+
    |      Admin Domain     |        Network        |     Host      |
    +-------+-------+-------+-------+-------+-------+-------+-------+

   Note:  the boundary between "network" and "host" is no more fixed
   than it is today; each (sub)network will have its own mask.  Just as
   the mask today can be anywhere from FF00 0000 (8/24) to FFFF FFFC
   (30/2), the mask for the 64 bit address can reasonably be FFFF FF00
   0000 0000 (24/40) to FFFF FFFF FFFF FFFC (62/2).

   The AD (Administrative Domain), identifies an administration which
   may be a service provider, a national administration, or a large
   multi-organization (e.g.  a government).  The idea is that there
   should not be more than a few hundred of these at first, and
   eventually thousands or tens of thousands at most.  (But note that we
   do not introduce a hard limit of 2^16 here; this estimate may be off
   by a few orders of magnitude.) Since only 1/4th of the address space
   is initially used (first two bits are 01), the remainder can then be
   allocated in the future with more information available.

   Most individual organizations would not be ADs.  In the short term,
   ADs are known to the "core routing"; it pays to keep the number
   smallish, a few thousand given current routing technology.  In the
   long term, this is not necessary.  Big administrations (i.e., with
   tens of millions of networks) get small blocks where needed, or
   additional single AD numbers when needed.



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


   While the AD may be used for last resort routing (with a 24/40 mask),
   it is primarily only an administrative device.  Most routing will be
   done on the entire 48 bit AD+network number, or sub and super-sets of
   those numbers.  (I.e., masks between about 32/32 and 56/8.)

   Some ADs (e.g., NSF) may make permanent assignments; others (such as
   a telephone company defining a network number for each subscriber
   line) may tie the assignment to such a subscription.  But in no case
   does this require traffic to be routed via the AD.

2.4  AD numbers

   AD numbers are allocated out of the same numbering space as network
   numbers.  This means that a version 4 address can be distinguished
   from the first 32 bits of a version 7 address.  This is useful to
   help prevent the inadvertent use of the first half of the longer
   address by a version 4 host.

   There is a non-trivial amount of software that assumes that an "int"
   is the same size and shape as an IP address, and does things like
   "ipaddr = *(int *)ptr".  This usage has always been incorrect, but
   does occur with disturbing frequency.  As IPv7 8 byte addresses
   appear in the application layers, this software will find those
   addresses unreachable; this is preferable to interacting with a
   random host.

   One possible method would be to allocate ADs in the range 96.0.0 to
   192.255.255, using the top 1/4 of the version 4 class A space.  It is
   probably best to allocate the first component downwards from 192, so
   that the boundary between class A and AD can be moved if desired
   later.  This initial allocation provides for 2031616 ADs, many more
   than there should be even in full deployment.

   Eventually, both AD and network will use the full 24 bit space
   available to them.  Knowledge of the AD range should not be coded
   into software.  If it was coded in, that software would break when
   the entire 24 bit space is used for ADs.  (This lesson should have
   been learned from CIDR.)

2.5  Mapping of version 4 numbers

   Initially, all existing Internet numbers are defined as belonging to
   the NSF/Internet AD, number 192.0.0.








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


   The mapping from/to version 4 IP addresses:

    +-------+-------+-------+-------+-------+-------+-------+-------+
    |      Admin Domain     |        Network        |     Host      |
    +-------+-------+-------+-------+-------+-------+-------+-------+
     [  fixed at A0 00 00  ] [ 1st 24 bits of V4 IP]   [1]   [last 8]

   So, for example, 192.42.95.15 (V4) becomes 192.0.0.192.42.95.1.15.

   And the "standard" loopback interface address becomes
   192.0.0.127.0.0.1.1 (I can see explaining that in 2015 to someone
   born in 1995.)

   The present protocol multicast (192.0.0.224.x.y.1.z) and loopback
   addresses are permanently allocated in the NSF AD.

3.  IP:  Internet datagram protocol

   The Internet datagram protocol is revised to expand some fields (most
   notably the addresses), while removing and relegating to options all
   fields not universally useful (imperative) in every datagram in every
   environment.

   This results in some simplification, a length less than twice the
   size of IPv4 even though most fields are doubled in size, and an
   expanded space for options.

   There is also a change in the option philosophy from IPv4:  it
   specified that implementation of options was not optional, what was
   optional was the existence of options in any given datagram.  This is
   changed in IPv7:  no option need be implemented to be fully
   conformant.  However, implementations must understand the option
   classes; and a future Host Requirements specification for hosts and
   routers used in the "connected Internet" may require some options in
   its profile, e.g., Fragment would probably be required.

   Digression:  In IPv4, options are often "considered harmful".  It is
   the opinion of the present author that this is because they are
   rarely needed, and not designed to be processed rapidly on most
   architectures.  This leads to little or no attempt to improve
   performance in implementations, while at the same time enormous
   effort is dedicated to optimization of the no-option case.  IPv7 is
   expected to be different on both counts.

   Fields are always aligned on their own size; the 64 bit fields on 64
   bit intervals from the start of the datagram.

   Options are all 32 bit aligned, and the null option can be used to



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


   push a subsequent option (or the transport layer header) into 64 bit
   or 64+32 off-phase alignment as desired.

3.1  IP datagram header format

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |version|     header length     |        time to live           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        total datagram length                                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +        forward route identifier                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +        destination address                                    +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +        source address                                         +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        protocol               |           checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        options                                                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A description of each field follows.

3.1.1  Version

   This document describes version 7 of the protocol.

3.1.2  Header length

   The header length is a 12 bit count of the number of 32 bit words in
   the IPv7 header.  This allows a header to be (theoretically at least)
   up to 16380 bytes in length.

3.1.3  Time to live

   The time to live is a 16 bit count, nominally in 1/16 seconds.  Each
   hop is required to decrement TTL by at least one.

   This definition should allow continuation of the useful (even though
   not entirely valid) interpretation of TTL as a hop count, while we



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


   move to faster networks and routers.  (The most familiar use is by
   "traceroute", which really ought to be directly implemented by one or
   more ICMP messages.)

   The scale factor converts the usual version 4 default TTL into a
   larger number of hops.  This is desireable because the forward route
   architecture of version 7 enables the construction of simpler, faster
   switches, and this may cause the network diameter to increase.

3.1.4  Total datagram length

   The 32 bit length of the entire datagram in octets.  A datagram can
   therefore be up to 4294967295 bytes in overall length.  Particular
   networks will normally impose lower limits.

3.1.5  Forward route identifier

   The identifier from the routing protocol to be used by the next hop
   router to find its next hop.  (A more complete description is given
   below.)

3.1.6  Destination

   The 64 bit IPv7 destination address.

3.1.7  Source

   The 64 bit IPv7 source address.

3.1.8  Protocol

   The transport layer protocol, e.g., TCP is 6.  The present code space
   for this layer of demultiplexing is about half full.  Expanding it to
   16 bits, allowing 65535 registered "transport" layers seems prudent.

3.1.9  Checksum

   The checksum is a 16 bit checksum of the entire IP header, using the
   familiar algorithm used in IPv4.

3.1.10  Options

   Options may follow.  They are variable length, and always 32 bit
   aligned, as discussed previously.







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


3.2  Option Format

   Each option begins with a 32 bit header:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | C |F|    type                 |   length                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        option data                 ...          |   padding   |