rfc2894.txt

RFC 的详细文档！

      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
   Sequence Number.  This is a safe operation only when all
   cryptographic keys previously used to authenticate RR Commands have
   expired or been revoked.  For this reason, the Sequence Number Reset
   message is defined to accomplish both functions.

   When a Sequence Number Reset (SNR) has been authenticated and has
   passed the header check, the router MUST invalidate all keys which
   have been used to authenticate previous RR Commands, including the
   key which authenticated the SNR itself.  Then it MUST discard any
   saved RR Result messages, clear the list of recorded SegmentNumbers
   and reset the Recorded Sequence Number to zero.

   If the router has no other, unused authentication keys already
   available for Router Renumbering use it SHOULD establish one or more
   new valid keys.  The details of this process will depend on whether
   manual keying or a key management protocol is used.  In either case,
   if no keys are available, no new Commands can be processed.

   A SNR message SHOULD contain no PCOs, since they will be ignored.  If
   and only if the R flag is set in the SNR message, a router MUST
   respond with a Result Message containing no Match Reports.  The
   header and transmission of the Result are as described in section 3.

   The invalidation of authentication keys caused by a valid SNR message
   will cause retransmitted copies of that message to be ignored.



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


6.  IANA Considerations

   Following the policies outlined in [IANACON], new values of the Code
   field in the Router Renumbering Header (section 3.1) and the OpCode
   field of the Match-Prefix Part (section 3.2.1.1) are to be allocated
   by IETF consensus only.

7.  Security Considerations

   The Router Renumbering mechanism proposed here is very powerful and
   prevention of spoofing it is important.  Replay of old messages must,
   in general, be prevented (even though a narrow class of messages
   exists for which replay would be harmless).  What constitutes a
   sufficiently strong authentication algorithm may change from time to
   time, but algorithms should be chosen which are strong against
   current key-recovery and forgery attacks.

   Authentication keys must be as well protected as any other access
   method that allows reconfiguration of a site's routers.  Distribution
   of keys must not expose them or permit alteration, and key validity
   must be limited in terms of time and number of messages
   authenticated.

   Note that although a reset of the Recorded Sequence Number requires
   the cancellation of previously-used authentication keys, introduction
   of new keys and expiration of old keys does not require resetting the
   Recorded Sequence Number.

7.1.  Security Policy and Association Database Entries

   The Security Policy Database (SPD) [IPSEC] of a router implementing
   this specification MUST cause incoming Router Renumbering Command
   packets to either be discarded or have IPsec applied.  (The
   determination of "discard" or "apply" MAY be based on the source
   address.)  The resulting Security Association Database (SAD) entries
   MUST ensure authentication and integrity of the destination address
   and the RR Header and Message Body, and the body length implied by
   the IPv6 length and intervening extension headers.  These
   requirements are met by the use of the Authentication Header [AH] in
   transport or tunnel mode, or the Encapsulating Security Payload [ESP]
   in tunnel mode with non-NULL authentication.  The mandatory-to-
   implement IPsec authentication algorithms (other than NULL) seem
   strong enough for Router Renumbering at the time of this writing.

   Note that for the SPD to distinguish Router Renumbering from other
   ICMP packets requires the use of the ICMP Type field as a selector.
   This is consistent with, although not mentioned by, the Security
   Architecture specification [IPSEC].



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


   At the time of this writing, there exists no multicast key management
   protocol for IPsec and none is on the horizon.  Manually configured
   Security Associations will therefore be common.  The occurrence of
   "from traffic" in the table below would therefore more realistically
   be a wildcard or a fixed range.  Use of a small set of shared keys
   per management station suffices, so long as key distribution and
   storage are sufficiently safeguarded.

   A sufficient set of SPD entries for incoming traffic could select

      Field         SPD Entry           SAD Entry
      -------       ---------           ---------
      Source        wildcard            from traffic
      Destination   wildcard            from SPD
      Transport     ICMPv6              from SPD
      ICMP Type     Rtr. Renum.         from SPD
      Action        Apply IPsec
      SA Spec       AH/Transport Mode

   or there might be an entry for each management station and/or for
   each of the router's unicast addresses and for each of the defined
   All-Routers multicast addresses, and a final wildcard entry to
   discard all other incoming RR messages.

   The SPD and SAD are conceptually per-interface databases.  This fact
   may be exploited to permit shared management of a border router, for
   example, or to discard all Router Renumbering traffic arriving over
   tunnels.

8.  Implementation and Usage Advice for Reliability

   Users of Router Renumbering will want to be sure that every non-
   trivial message reaches every intended router.  Well-considered
   exploitation of Router Renumbering's retransmission and response-
   directing features should make that goal achievable with high
   confidence even in a minimally reliable network.

   In one set of cases, probably the majority, the network management
   station will know the complete set of routers under its control.
   Commands can be retransmitted, with the "R" (Reply-requested) flag
   set in the RR header, until Results have been collected from all
   routers.  If unicast Security Associations (or the means for creating
   them) are available, the management station may switch from multicast
   to unicast transmission when the number of routers still unheard-from
   is suitably small.






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


   To maintain a list of managed routers, the management station can
   employ any of several automatic methods which may be more convenient
   than manual entry in a large network.  Multicast RR "Test" commands
   can be sent periodically and the results archived, or the management
   station can use SNMP to "peek" into a link-state routing protocol
   such as OSPF [OSPFMIB].  (In the case of OSPF, roughly one router per
   area would need to be examined to build a complete list of routers.)

   In a large dynamic network where the set of managed routers is not
   known but reliable execution is desired, a scalable method for
   achieving confidence in delivery is described here.  Nothing in this
   section affects the format or content of Router Renumbering messages,
   nor their processing by routers.

   A management station implementing these reliability mechanisms MUST
   alert an operator who attempts to commence a set of Router
   Renumbering Commands when retransmission of a previous set is not yet
   completed, but SHOULD allow the operator to override the warning.

8.1.  Outline and Definitions

   The set of routers being managed with Router Renumbering is
   considered as a set of populations, each population having a
   characteristic probability of successful round-trip delivery of a
   Command/Result pair.  The goal is to estimate a lower bound, P, on
   the round-trip probability for the whole set.  With this estimate and
   other data about the responses to retransmissions of the Command, a
   confidence level can be computed for hypothesis that all routers have
   been heard from.

   If the true probability of successful round-trip communication with a
   managed router were a constant, p, for all managed routers then an
   estimate P of p could be derived from either of these statistics:

      The expected ratio of the number of routers first heard from after
      transmission (N + 1) to the number first heard from after N is
      (1 - p).

      When N different routers have been heard from after M
      transmissions of a Command, the expected total number of Result
      messages received is pNM.  If R is the number of Results actually
      received, then P = R/MN.

   The two methods are not equivalent.  The first suffers numerical
   problems when the number of routers still to be heard from gets
   small, so the P = R/MN estimate should be used.





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


   Since the round-trip probability is not expected to be uniform in the
   real world, and the less-reliable units are more important to a
   lower-bound estimate but more likely to be missed in sampling, the
   sample from which P is computed is biased toward the less-reliable
   routers.  After the Nth transmission interval, N > 2, neglect all
   routers heard from in intervals 1 through F from the reliability
   estimate, where F is the greatest integer less than one-half of N.
   For example, after five intervals, only routers first heard from in
   the third through fifth intervals will be counted.

   A management station implementing the methods of this section should
   allow the user to specify the following parameters, and default them
   to the indicated values.

   Ct      The target delivery confidence, default 0.999.

   Pp      A presumptive, pessimistic initial estimate of the lower
           bound of the round-trip probability, P, to prevent early
           termination.  (See below.)  Default 0.75.

   Ti      The initial time between Command retransmissions.  Default 4
           seconds.  MaxDelay milliseconds (see section 3.1) must be
           added to the retransmission timer.  Knowledge of the
           routers' processing time for RR Commands may influence the
           setting of Ti.  Ti+MaxDelay is also the minimum time the
           management station must wait for Results after each
           transmission before computing a new confidence level.  The
           phrase "end of the Nth interval" means a time Ti+MaxDelay
           after the Nth transmission of a Command.

   Tu      The upper bound on the period between Command
           retransmissions.  Default 512 seconds.

   The following variables, some a function of the retransmission
   counter N, are used in the next section.

   T(N)    The time between Command transmissions N and N+1 is V*T(N) +
           MaxDelay, where V is random and roughly uniform in the range
           [0.75, 1.0].  T(1) = Ti and for N > 1, T(N) = min(2*T(N-1),
           Tu).

   M(N)    The cumulative number of distinct routers from which replies
           have been received to any of the first N transmissions of
           the Command.