rfc1475.txt

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

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   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A description of each field:

3.2.1  Class (C)

   This field tells implementations what to do with datagrams containing
   options they do not understand.  No implementation is required to
   implement (i.e., understand) any given option by the TCP/IP
   specification itself.

   Classes:

       0        use or forward and include this option unmodified
       1        use this datagram, but do not forward the datagram
       2        discard, or forward and include this option unmodified
       3        discard this datagram

   A host receiving a datagram addressed to itself will use it if there
   are no unknown options of class 2 or 3.  A router receiving a
   datagram not addressed to it will forward the datagram if and only if
   there are no unknown options of class 1 or 3.  (The astute reader
   will note that the bits can also be seen as having individual
   interpretations, one allowing use even if unknown, one allowing
   forwarding if unknown.)

   Note that classes 0 and 2 are imperative:  if the datagram is
   forwarded, the unknown option must be included.

   Class and type are entirely orthogonal, different implementations
   might use different classes for the same option, except where
   restricted by the option definition.

   Also note that for options that are known (implemented by) the host
   or router, the class has no meaning; the option definition totally
   determines the behavior.  (Although it should be noted that the
   option might explicitly define a class dependent behavior.)




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


3.2.2  Copy on fragmentation (F)

   If the F bit is set, this option must be copied into all fragments
   when a datagram is fragmented.  If the F bit is reset (zero), the
   option must only be copied into the first (zero-offset) fragment.

3.2.3  Type

   The type field identifies the particular option, types being
   registered as well known values in the internet.  A few of the
   options with their types are described below.

3.2.4  Length

   Length of the option data, in bytes.

3.2.5  Option data

   Variable length specified by the length field, plus 0-3 bytes of
   zeros to pad to a 32 bit boundary.  Fields within the option data
   that are 64 bits long are normally placed on the assumption that the
   option header is off-phase aligned, the usual case when the option is
   the only one present, and immediately follows the IP header.

3.3  IP options

   The following sections describe the options defined to emulate IPv4
   features, or necessary in the basic structure of the protocol.

3.3.1  Null

   The null option, type 0, provides for a space filler in the option
   area.  The data may be of any size, including 0 bytes (perhaps the
   most useful case.)

   It may be used to change alignment of the following options or to
   replace an option being deleted, by setting type to 0 and class to 0,
   leaving the length and content of the data unmodified.  (Note that
   this implies that options must not contain "secret" data, relying on
   class 3 to prevent the data from leaving the domain of routers that
   understand the option.)

   Null is normally class 0, and need not be implemented to serve its
   function.







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


3.3.2  Fragment

   Fragment (type 1) indicates that the datagram is part of a complete
   IP datagram.  It is always class 2.

   The data consists of (one of) the 64 bit IP address(es) of the router
   doing the fragmentation, a 64 bit datagram ID generated by that
   router, and a 32 bit fragment offset.  The IDs should be generated so
   as to be very likely unique over a period of time larger than the TCP
   MSL (maximum segment lifetime).  (The TCP ISN (initial sequence
   number) generator might be used to initialize the ID generator in a
   router.)

     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                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +          fragmenting router IP address                        +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +          datagram ID                                          +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          offset                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   If a datagram must be refragmented, the original 128 bit address+ID
   is preserved, so that the datagram can be reassembled from any
   sufficient set of the resulting fragments.  The 64 bits fields are
   positioned so that they are aligned in the usual case of the fragment
   option following the IP header.

   A router implementing Fragment (doing fragmentation) must recognize
   the Don't Fragment option.

3.3.3  Last Fragment

   Last Fragment (type 2) has the same format as Fragment, but implies
   that this datagram is the last fragment needed to reassemble the
   original datagram.

   Note that an implementation can reasonably add arriving datagrams
   with Fragment to a cache, and then attempt a reassembly when a
   datagram with Last Fragment arrives (and the the total length is
   known); this will work well when datagrams are not reordered in the



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


   network.

3.3.4  Don't Fragment

   This option (type 3, class 0) indicates that the datagram may not be
   fragmented.  If it can not be forwarded without fragmentation, it is
   discarded, and the appropriate ICMP message sent.  (Unless, of
   course, the datagram is an ICMP message.) There is no data present.

3.3.5  Don't Convert

   The Don't Convert option prohibits conversion from IPv7 to IPv4
   protocol, requiring instead that the datagram be discarded and an
   ICMP message sent (conversion failed/don't convert set).  It is type
   4, usually class 0, and must be implemented by any router
   implementing conversion.  A host is under no such constraint; like
   any protocol specification, only the "bits on the wire" can be
   specified, the host receiving the datagram may convert it as part of
   its procedure.  There is no data present in this option.

3.4  Forward route identifier

   Each IP datagram carries a 64 bit field, called "forward route
   identifier", that is updated (if the information is available) at
   each hop.  This field's value is derived from the routing protocol
   (e.g., RAP [RFC1476]).  It is used to expedite routing decisions by
   preserving knowledge where possible between consecutive routers.  It
   can also be used to make datagrams stay within reserved flows and
   mobile-host tunnels where required.

3.4.1  Procedure description

   Consider 3 routers, A, B, and C.  Traffic is passing through them,
   between two other hosts (or networks), X and Y, packets are going
   XABCY and YCBAX.  Consider only one direction:  routing info flowing
   from C to A, to provide a route from A to C.  The same thing will be
   happening in the other direction.

   An explanation of the notation:

     R(r,d,i,h)    A route that means: "from router r, to go toward
                   final destination d, replace the forward route
                   identifier in the packet with i, and take next
                   hop h."

     Ri(r,d)       An opaque (outside of router r) identifier, that can
                   be used by r to find R(r,d,...).




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


     Flowi(r,rt)   An opaque (outside of router r) identifier, that
                   router r can use to find a flow or tunnel with which
                   the datagram is associated, and from that the route
                   rt on which the flow or tunnel is built, as well as
                   the Flowi() for the subsequent hop.

     Ri(Dgram)     The forward route identifier in a datagram.

   Router C announces a route R(C,Y,0,Y) to router B.  It includes in it
   an identifier Ri(C,Y) internal to C, that will allow C to find the
   route rapidly.  (A table index, or an actual memory address.)

   Router B creates a route R(B,Y,Ri(C,Y),C) via router C, it announces
   it to A, including an identifier Ri(B,Y), internal to B, and used by
   A as an opaque object.

   Router A creates a route R(A,Y,Ri(B,Y),B) via router B.  It has no
   one to announce it to.

   Now:  X originates a datagram addressed to Y.  It has no routing
   information, and sets Ri(Dgram) to zero.  It forwards the datagram to
   router A (X's default gateway).

   A finds no valid Ri(Dgram), and looks up the destination (Y) in its
   routing tables.  It finds R(A,Y,Ri(B,Y),B), sets Ri(Dgram) <-
   Ri(B,Y), and forwards the datagram to B.

   Router B looks at Ri(Dgram) which directly identifies the next hop
   route R(B,Ri(C,Y),C), sets Ri(Dgram) <- Ri(C,Y) and forwards it to
   router C.

   Router C looks at Ri(Dgram) which directly locates R(C,0,Y), sets
   Ri(Dgram) <- 0 and forwards to Y.

   Y recognizes its own address in Dest(Dgram), ignores Ri(Dgram).

   Of course, the routers will validate the Ri's received, particularily
   if they are memory addresses (e.g., M(a) < Ri < M(b), Ri mod N == 0),
   and probably check that the route in fact describes the destination
   of the datagram.  If the Ri is invalid, the router must use the
   ordinary method of finding a route (i.e., what it would have done if
   Ri was 0), and silently ignore the invalid Ri.

   When a route has been aggregated at some router, implicitly or
   explicitly, it will find that the incoming Ri(Dgram) at most can
   identify the aggregation, and it must make a decision; the forwarded
   datagram then contains the Ri for the specific route.  (Note this may
   happen well upstream of the point at which the routes actually



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


   diverge.)

   This allows all cooperating routers to make immediate forwarding
   decisions, without any searching of tables or caches once the
   datagram has entered the routing domain.  If the host participates in
   the routing, at least to the extent of acquiring the initial Ri
   required from the first router, then only routers that have done
   aggregations need make decisions.  (If the routing changes with
   datagrams in flight, some router will be required to make a decision
   to re-rail each datagram.)

3.4.2  Flows

   If a "flow" is to be set up, the identifiers are replaced by
   Flowi(router,route), where each router's structure for the flow
   contains a pointer to the route on which the flow is built.
   Datagrams can drop out of the flow at some point, and can be inserted
   either by the originating host or by a cooperating router near the
   originator.  Since the forward route identifier field is opaque to
   the sending router, and implicitly meaningful only to the next hop
   router, use for flows (or similar optimizations) need not be
   otherwise defined by the protocol.  (One presumes that a router