rfc2894.txt

中、英文RFC文档大全打包下载完全版 .

   each interface.  The Match Report has the following format.


















Crawford                    Standards Track                    [Page 12]

RFC 2894              Router Renumbering for IPv6            August 2000


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         reserved          |B|F|    Ordinal    |  MatchedLen   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         InterfaceIndex                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                        MatchedPrefix                        -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fields:

   B           A one-bit flag which, when set, indicates that one or
               more fields in the associated PCO were out of bounds.
               The bounds check is described in section 4.2.

   F           A one-bit flag which, when set, indicates that one or
               more Use-Prefix parts from the associated PCO were not
               honored by the router because of attempted formation of
               a forbidden prefix format, such as a multicast or
               loopback address.

   Ordinal     Copied from the Prefix Control Operation whose
               MatchPrefix matched the MatchedPrefix on the interface
               indicated by InterfaceIndex.

   MatchedLen  The length of the Matched Prefix.

   InterfaceIndex
               The router's numeric designation of the interface on
               which the MatchedPrefix was configured.  This MUST be
               the same as the value of ipv6IfIndex which designates
               that index in the SNMP IPv6 MIB General Group [IPV6MIB].

   It is possible for a Result message to be larger than the Command
   message which elicited it.  Such a Result message may have to be
   fragmented for transmission.  If so, it SHOULD be fragmented to the
   IPv6 minimum required MTU [IPV6].







Crawford                    Standards Track                    [Page 13]

RFC 2894              Router Renumbering for IPv6            August 2000


4.  Message Processing

   Processing of received Router Renumbering Result messages is entirely
   implementation-defined.  Implementation of Command message processing
   may vary in detail from the procedure set forth below, so long as the
   result is not affected.

   Processing of received Router Renumbering Command messages consists
   of three conceptual parts: header check, bounds check, and execution.

4.1.  Header Check

   The ICMPv6 checksum and type are presumed to have been checked before
   a Router Renumbering module receives a Command to process.  In an
   implementation environment where this may not be the case, those
   checks MUST be made at this point in the processing.

   If the ICMPv6 length derived from the IPv6 length is less than 16
   octets, the message MUST be discarded and SHOULD be logged to network
   management.

   If the ICMPv6 Code field indicates a Result message, a router which
   is not a source of RR Command messages MUST discard the message and
   SHOULD NOT log it to network management.

   If the IPv6 destination address is neither an All Routers multicast
   address [AARCH] nor one of the receiving router's unicast addresses,
   the message MUST be discarded and SHOULD be logged to network
   management.

   Next, the SequenceNumber is compared to the Recorded Sequence Number.
   (If no RR messages have been received and accepted since system
   initialization, the Recorded Sequence Number is zero.)  This
   comparison is done with the two numbers considered as unsigned
   integers, not as DNS-style serial numbers.  If the SequenceNumber is
   less than the Recorded Sequence Number, the message MUST be discarded
   and SHOULD be logged to network management.

   Finally, if the SequenceNumber in the message is greater than the
   Recorded Sequence Number or the T flag is set, skip to the bounds
   check.  Otherwise the SegmentNumber MUST now be checked.  If a
   correctly authenticated message with the same SequenceNumber and
   SegmentNumber has not already been processed, skip to the bounds
   check.  Otherwise, this Command is a duplicate and not a Test
   Command.  If the R flag is not set, the duplicate message MUST be
   discarded and SHOULD NOT be logged to network management.  If R is
   set, an RR Result message with the P flag set MUST be scheduled for
   transmission to the source address of the Command after a random time



Crawford                    Standards Track                    [Page 14]

RFC 2894              Router Renumbering for IPv6            August 2000


   uniformly distributed between 0 and MaxDelay milliseconds.  The body
   of that Result message MUST either be empty or be a saved copy of the
   Result message body generated by processing of the previous message
   with the same SequenceNumber and SegmentNumber.  After scheduling the
   Result message, the Command MUST be discarded without further
   processing.

4.2.  Bounds Check

   If the SequenceNumber is greater than the Recorded Sequence Number,
   then the list of processed SegmentNumbers and the set of saved Result
   messages, if any, MUST be cleared and the Recorded Sequence Number
   MUST be updated to the value used in the current message, regardless
   of subsequent processing errors.

   Next, if the ICMPv6 Code field indicates a Sequence Number Reset,
   skip to section 5.

   At this point, if T is set in the RR header and R is not set, the
   message MAY be discarded without further processing.

   If the R flag is set, begin constructing an RR Result message.  The
   RR header of the Result message is completely determined at this time
   except for the Checksum.

   The values of the following fields of a PCO MUST be checked to ensure
   that they are within the appropriate bounds.

   OpCode      must be a defined value.

   OpLength    must be of the form 4N+3 and consistent the the length
               of the Command packet and the PCO's offset within the
               packet.

   MatchLen    must be between 0 and 128 inclusive

   UseLen, KeepLen
               in each Use-Prefix Part must be between 0 and 128
               inclusive, as must the sum of the two.

   If any of these fields are out of range in a PCO, the entire PCO MUST
   NOT be performed on any interface.  If the R flag is set in the RR
   header then add to the RR Result message a Match Report with the B
   flag set, the F flag clear, the Ordinal copied from the PCO, and all
   other fields zero.  This Match Report MUST be included only once, not
   once per interface.





Crawford                    Standards Track                    [Page 15]

RFC 2894              Router Renumbering for IPv6            August 2000


   Note that MinLen and MaxLen need not be explicitly bounds checked,
   even though certain combinations of values will make any matches
   impossible.

4.3.  Execution

   For each applicable router interface, as determined by the A and S
   flags, the Prefix Control Operations in an RR Command message must be
   carried out in order of appearance.  The relative order of PCO
   processing among different interfaces is not specified.

   If the T flag is set, create a copy of each interface's configuration
   on which to operate, because the results of processing a PCO may
   affect the processing of subsequent PCOs.  Note that if all
   operations are performed on one interface before proceeding to
   another interface, only one interface-configuration copy will be
   required at a time.

   For each interface and for each Prefix Control Operation, each prefix
   configured on that interface with a length between the MinLen and
   MaxLen values in the PCO is tested to determine whether it matches
   (as defined in section 2.1) the MatchPrefix of the PCO.  The
   configured prefixes are tested in an arbitrary order.  Any new prefix
   configured on an interface by the effect of a given PCO MUST NOT be
   tested against that PCO, but MUST be tested against all subsequent
   PCOs in the same RR Command message.

   Under a certain condition the addresses on an interface are also
   tested to see whether any of them matches the MatchPrefix.  If and
   only if a configured prefix "P" does have a length between MinLen and
   MaxLen inclusive, does not match the MatchPrefix "M", but M does
   match P (this can happen only if M is longer than P), then those
   addresses on that interface which match P MUST be tested to determine
   whether any of them matches M.  If any such address does match M,
   process the PCO as if P matched M, but when forming New Prefixes, if
   KeepLen is non-zero, bits are copied from the address.  This special
   case allows a PCO to be easily targeted to a single specific
   interface in a network.

   If P does not match M, processing is finished for this combination of
   PCO, interface and prefix.  Continue with another prefix on the same
   interface if there are any more prefixes which have not been tested
   against this PCO and were not created by the action of this PCO.  If
   no such prefixes remain on the current interface, continue processing
   with the next PCO on the same interface, or with another interface.






Crawford                    Standards Track                    [Page 16]

RFC 2894              Router Renumbering for IPv6            August 2000


   If P does match M, either directly or because a configured address
   which matches P also matches M, then P is the Matched Prefix.
   Perform the following steps.

      If the Command has the R flag set, add a Match Report to the
      Result message being constructed.

      If the OpCode is CHANGE, mark P for deletion from the current
      interface.

      If the OpCode is SET-GLOBAL, mark all global-scope prefixes on the
      current interface for deletion.

      If there are any Use-Prefix parts in the current PCO, form the New
      Prefixes.  Discard any New Prefix which has a forbidden format,
      and if the R flag is set in the command, set the F flag in the
      Match Report for this PCO and interface.  Forbidden prefix formats
      include, at a minimum, multicast, unspecified and loopback
      addresses.  [AARCH]  Any implementation MAY forbid, or allow the
      network manager to forbid other formats as well.

      For each New Prefix which is already configured on the current
      interface, unmark that prefix for deletion and update the
      lifetimes and RA flags.  For each New Prefix which is not already
      configured, add the prefix and, if appropriate, configure an
      address with that prefix.

      Delete any prefixes which are still marked for deletion, together
      with any addresses which match those prefixes but do not match any
      prefix which is not marked for deletion.

      After processing all the Prefix Control Operations on all the
      interfaces, an implementation MUST record the SegmentNumber of the
      packet in a list associated with the SequenceNumber.

      If the Command has the R flag set, compute the Checksum and
      schedule the Result message for transmission after a random time
      interval uniformly distributed between 0 and MaxDelay
      milliseconds.  This interval SHOULD begin at the conclusion of
      processing, not the beginning.  A copy of the Result message MAY
      be saved to be retransmitted in response to a duplicate Command.

4.4.  Summary of Effects

   The only Neighbor Discovery [ND] parameters which can be affected by
   Router Renumbering are the following.





Crawford                    Standards Track                    [Page 17]

RFC 2894              Router Renumbering for IPv6            August 2000


      A router's addresses and advertised prefixes, including the prefix
      lengths.

      The flag bits (L and A, and any which may be defined in the
      future) and the valid and preferred lifetimes which appear in a
      Router Advertisement Prefix Information Option.

      That unnamed property of the lifetimes which specifies whether
      they are fixed values or decrementing in real time.

   Other internal router information, such as the time until the next
   unsolicited Router Advertisement or MIB variables MAY be affected as
   needed.

   All configuration changes resulting from Router Renumbering SHOULD be
   saved to non-volatile storage where this facility exists.  The
   problem of properly restoring prefix lifetimes from non-volatile
   storage exists independently of Router Renumbering and deserves
   careful attention, but is outside the scope of this document.

5.  Sequence Number Reset

   It may prove necessary in practice to reset a router's Recorded