rfc1475.txt

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

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


5.1.6  Options

   UDP options, none are presently defined.

6.  ICMP

   The ICMP protocol is very similar to ICMPv4, in some cases not
   requiring any conversion.

   The complication is that IP datagrams are nested within ICMP
   messages, and must be converted.  This is discussed later.

6.1  ICMP 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     type      |     code      |           checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        type-specific parameter                                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        type-specific data               ...                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type and code are well-known values, defined in [RFC792].  The codes
   have meaning only within a particular type, they are not orthogonal.

   The next 32 bit word is usually defined for the specific type,
   sometimes it is unused.

   For many types, the data consists of a nested IP datagram, usually
   truncated, which is a copy of the datagram causing the event being
   reported.  In IPv4, the nested datagram consists of the IP header,
   and another 64 bits (at least) of the original datagram.

   For IPv7, the nested datagram must include the IP header plus 96 bits
   of the remaining datagram (thus including the port numbers within TCP
   and UDP), and should include the first 256 bytes of the datagram.
   I.e., in most cases where the original datagram was not large, it
   will return the entire datagram.

6.2  Conversion failed ICMP message

   The introduction of network layer conversion requires a new message
   type, to report conversion errors.  Note that an invalid datagram
   should result in the sending of some other ICMP message (e.g.,
   parameter problem) or the silent discarding of the datagram.  This
   message is only sent when a valid datagram cannot be converted.



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


   Note:  implementations are not expected to, and should not, check the
   validity of incoming datagrams just to accomplish this; it simply
   means that an error detected during conversion that is known to be an
   actual error in the incoming datagram should be reported as such, not
   as a conversion failure.

   Note that the conversion failed ICMP message may be sent in either
   the IPv4 or IPv7 domain; it is a valid ICMP message type for IPv4.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     type      |     code      |           checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        pointer to problem area                                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        copy of datagram that could not be converted ....      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The type for Conversion Failed is 31.

   The codes are:

        0       Unknown/unspecified error
        1       Don't Convert option present
        2       Unknown mandatory option present
        3       Known unsupported option present
        4       Unsupported transport protocol
        5       Overall length exceeded
        6       IP header length exceeded
        7       Transport protocol > 255
        8       Port conversion out of range
        9       Transport header length exceeded
        10      32 Bit Rollover missing and ACK set
        11      Unknown mandatory transport option present

   The use of code 0 should be avoided, any other condition found by
   implementors should be assigned a new code requested from IANA.  When
   code 0 is used, it is particularily important that the pointer be set
   properly.

   The pointer is an offset from the start of the original datagram to
   the beginning of the offending field.

   The data is part of the datagram that could not be converted.  It
   must be at least the IP and transport headers, and must include the
   field pointed to by the previous parameter.  For code 4, the
   transport header is probably not identifiable; the data should



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


   include 256 bytes of the original datagram.

7.  Notes on the domain system

7.1  A records

   Address records will be added to the IN (Internet) zone with IPv7
   addresses for all hosts as IPv7 is deployed.  Eventually the IPv4
   addresses will be removed.  As mentioned above, the AD
   (Administrative Domain) space is initially assigned so that the first
   4 octets of a v7 address cannot be confused with a v4 address (or,
   rather, the confusion will be to no effect.)

   For example:

   DELTA.Process.COM.      A       192.42.95.68
                           A       192.0.0.192.42.95.1.68

   It is important that the A record be used, to avoid the cache
   consistancy problem that would arise when different records had
   different remaining TTLs.

   Note that if an unmodified version of the more popular public domain
   nameserver is a secondary for a zone containing IPv7 addresses, it
   will erroneously issue RRs with only the first four bytes.  (I.e.,
   192.0.0.192 in the example.) This is another reason to ensure that
   the AD numbers are initially reserved out of the IPv4 network number
   space.  Eventually, zones with IPv7 addresses would be expected to be
   served only by upgraded servers.

7.2  PTR zone

   The inverse (PTR) zone is .#, with the IPv7 address (reversed).
   I.e., just like .IN-ADDR.ARPA, but with .# instead.

   This respects the difference in actual authority:  the NSF/DDN NIC is
   the authority for the entire space rooted in .IN-ADDR.ARPA.  in the
   v4 Internet, while in the new Internet it holds the authority only
   for the AD 0.0.192.#.  (Plus, of course, any other ADs assigned to it
   over time.)

8.  Conversion between version 4 and version 7

   As noted in the description of datagram format, it is possible to
   provide a mostly-transparent bridge between version 4 and version 7.

   This discusses TCP and ICMP at the session/transport layer; UDP is a
   subset of the TCP conversion.  Most protocols at this layer will



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


   probably need no translation; however it will probably be necessary
   to specify exactly which will have translations done.

   New protocols at the session/transport layer defined over IPv7 should
   have protocol numbers greater than 255, and will not be translated to
   IPv4.

   Most of the translations should consist of copying various fields,
   verifying fixed values in the datagram being translated, and setting
   fixed values in the datagram being produced.  In general, the
   checksum must be verified first, and then a new checksum computed for
   the generated datagram.

8.1  Version 4 IP address extension option

   A new option is defined for IP version 4, to carry the extended
   addresses of IPv7.  This will be particularily useful in the initial
   testing of IPv7, during a time when most of the fabric of the
   internet is IPv4.  An IPv7 host will be able to connect to another
   IPv7 host anywhere in the internet even though most of the paths and
   routers are IPv4, and still use the full addressing.  This will
   continue to work until non-unique network numbers are assigned, by
   which time most of the infrastructure should be IPv7.

8.1.1  Option format

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  type (147)   | length = 10   |     source IPv7 AD number     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  ...          | src 7th octet |     destination IPv7 AD       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  number ...   | dst 7th octet |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The source and destination are in IPv4 order (source first), for
   consistancy.  The type code is 147.

8.2  Fragmented datagrams

   Datagrams that have been fragmented must be reassembled by the
   converting host or router before conversion.  Where the conversion is
   being done by the destination host (i.e.,  the case of a v7 host
   receiving v4 datagrams), this is similar to the present fragmentation
   model.

   When it is being done by an intermediate router (acting as an
   internetwork layer gateway) the router should use all of source,
   destination, and datagram ID for identification of IPv4 fragments;



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


   note that destination is used implicitly in the usual reassembly at
   the destination.  When reassembling an IPv7 datagram, the 128 bit
   fragment ID is used as usual.

   If the fragments take different paths through the net, and arrive at
   different conversion points, the datagram is lost.

8.3  Where does the conversion happen?

   The objective of conversion is to be able to upgrade systems, both
   hosts and routers, in whatever order desired by their owners.
   Organizations must be able to upgrade any given system without
   reconfiguration or modification of any other; and IPv4 hosts must be
   able to interoperate essentially forever.  (IPv4 routers will
   probably be effectively eliminated at some point, except where they
   exist in their own remote or isolated corners.)

   Each TCP/IP v7 system, whether host or router, must be able to
   recognize adjacent systems in the topology that are (only) v4, and
   call the appropriate conversion routine just before sending the
   datagram.

   Digression:  I believe v7 hosts will get much better performance by
   doing everything internally in v7, and using conversion to filter
   datagrams when necessary.  This keeps the usual code path simple,
   with only a "hook" right after receiving to convert incoming IPv4
   datagrams, and just before sending to convert to IPv4.  Routers may
   prefer to keep datagrams in their incoming version, at least until
   after the routing decision is made, and then doing the conversion
   only if necessary.  In either case, this is an implementation
   specific decision.

   It must be noted that any forwarding system may convert datagrams to
   IPv7, then back to IPv4, even if that loses information such as
   unknown options.  The reverse is not acceptable:  a system that
   receives an IPv7 datagram should not convert it to IPv4, then back to
   IPv7 on forwarding.

   The preferred method for identifying which hosts require conversion
   is to ARP first for the IPv7 address, and then again if no response
   is received, for the IPv4 address.  The reservation of ADs out of the
   v4 network number space is useful again here, protecting hosts that
   fail to properly use the ARP address length fields.

   On networks where ARP is not normally used, the method is to assume
   that a remote system is v7.  If an IPv7 datagram is received from it,
   the assumption is confirmed.  If, after a short time, no IPv7
   datagram is received, a v7 ICMP echo is sent.  If a reply is received



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


   (in either version) the assumption is confirmed.

   If no reply is recieved, the remote system is assumed not to
   understand IPv7, and datagrams are converted to IPv4 just before
   transmitting them.

   Implementations should also provide for explicit configuration where
   desired.

8.4  Hybrid IPv4 systems

   In the course of implementing IPv7, especially in constrained
   environments such as small terminal servers, it may be useful to
   implement the IPv4 address extension option directly, thereby
   regaining universal connectivity.

   This may also be a useful interim step for vendors not prepared to do
   a major rework of an implementation; but it is important not to get
   stalled in this step.

   A hybrid IPv4 + address extension system does n