rfc2894.txt

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

   present given the number of responses which were collected, as
   opposed to M(N)+1 or any greater number.  It is assumed that the a
   priori probability of there being K routers was no greater than that
   of K-1 routers, for all K > M(N).

   When c(N) >= Ct and N >= Nmin, retransmissions of the Command may
   cease.  Otherwise another transmission should be scheduled at a time
   V*T(N) + MaxDelay after the previous (Nth) transmission, or V*T(N)
   after the conclusion of processing responses to the Nth transmission,
   whichever is later.

   One corner case needs consideration.  Divide-by-zero may occur when
   computing p.  This can happen only when no new routers have been
   heard from in the last N-F intervals.  Generally, the confidence
   estimate c(N) will be close to unity by then, but in a pathological
   case such as a large number of routers with reliable communication
   and a much smaller number with very poor communication, the
   confidence estimate may still be less than Ct when p's denominator
   vanishes.  The implementation may continue, and should continue if
   the minimum number of transmissions given in the previous paragraph
   have not yet been made.  If new routers are heard from, p(N) will
   again be non-singular.

   Of course no limited retransmission scheme can fully address the
   possibility of long-term problems, such as a partitioned network.
   The network manager is expected to be aware of such conditions when
   they exist.

8.3.  Additional Assurance Methods

   As a final means to detect routers which become reachable after
   missing renumbering commands during an extended network split, a
   management station MAY adopt the following strategy.  When performing
   each new operation, increment the SequenceNumber by more than one.



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


   After the operation is believed complete, periodically send some
   "no-op" RR Command with the R (Result Requested) flag set and a
   SequenceNumber one less than the highest used.  Any responses to such
   a command can only come from router that missed the last operation.
   An example of a suitable "no-op" command would be an ADD operation
   with MatchLen = 0, MinLen = 0, MaxLen = 128, and no Use-Prefix Parts.

   If old authentication keys are saved by the management station, even
   the reappearance of routers which missed a Sequence Number Reset can
   be detected by the transmission of no-op commands with the invalid
   key and a SequenceNumber higher than any used before the key was
   invalidated.  Since there is no other way for a management station to
   distinguish a router's failure to receive an entire sequence of
   repeated SNR messages from the loss of that router's single SNR
   Result Message, this is the RECOMMENDED way to test for universal
   reception of a SNR Command.

9.  Usage Examples

   This section sketches some sample applications of Router Renumbering.
   Extension headers, including required IPsec headers, between the IPv6
   header and the ICMPv6 header are not shown in the examples.

9.1.  Maintaining Global-Scope Prefixes

   A simple use of the Router Renumbering mechanism, and one which is
   expected to to be common, is the maintenance of a set of global
   prefixes with a subnet structure that matches that of the site's
   site-local address assignments.  In the steady state this would serve
   to keep the Preferred and Valid lifetimes set to their desired
   values.  During a renumbering transition, similar Command messages
   can add new prefixes and/or delete old ones.  An outline of a
   suitable Command message follows.  Fields not listed are presumed set
   to suitable values.  This Command assumes all router interfaces to be
   maintained already have site-local [AARCH] addresses.

   IPv6 Header
      Next Header = 58 (ICMPv6)
      Source Address = (Management Station)
      Destination Address = FF05::2 (All Routers, site-local scope)

   ICMPv6/RR Header
      Type = 138 (Router Renumbering), Code = 0 (Command)
      Flags = 60 hex (R, A)







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


   First (and only) PCO:

      Match-Prefix Part
          OpCode = 3 (SET-GLOBAL)
          OpLength = 4 N + 3 (assuming N global prefixes)
          Ordinal = 0 (arbitrary)
          MatchLen = 10
          MatchPrefix = FEC0::0

      First Use-Prefix Part
          UseLen = 48 (Length of TLA ID + RES + NLA ID [AARCH])
          KeepLen = 16 (Length of SLA (subnet) ID [AARCH])
          FlagMask, RAFlags, Lifetimes, V & P flags -- as desired
          UsePrefix = First global /48 prefix

      . . .

      Nth Use-Prefix Part
          UseLen = 48
          KeepLen = 16
          FlagMask, RAFlags, Lifetimes, V & P flags -- as desired
          UsePrefix = Last global /48 prefix

   This will cause N global prefixes to be set (or updated) on each
   applicable interface.  On each interface, the SLA ID (subnet) field
   of each global prefix will be copied from the existing site-local
   prefix.

9.2.  Renumbering a Subnet

   A subnet can be gracefully renumbered by setting the valid and
   preferred timers on the old prefix to a short value and having them
   run down, while concurrently adding adding the new prefix.  Later,
   the expired prefix is deleted.  The first step is described by the
   following RR Command.

   IPv6 Header
      Next Header = 58 (ICMPv6)
      Source Address = (Management Station)
      Destination Address = FF05::2 (All Routers, site-local scope)

   ICMPv6/RR Header
      Type = 138 (Router Renumbering), Code = 0 (Command)
      Flags = 60 hex (R, A)







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


   First (and only) PCO:

      Match-Prefix Part
          OpCode = 2 (CHANGE)
          OpLength = 11 (reflects 2 Use-Prefix Parts)
          Ordinal = 0 (arbitrary)
          MatchLen = 64
          MatchPrefix = Old /64 prefix

      First Use-Prefix Part
          UseLen = 0
          KeepLen = 64 (this retains the old prefix value intact)
          FlagMask = 0, RAFlags = 0
          Valid Lifetime = 28800 seconds (8 hours)
          Preferred Lifetime = 7200 seconds (2 hours)
          V flag = 1, P flag = 1
          UsePrefix = 0::0

      Second Use-Prefix Part
          UseLen = 64
          KeepLen = 0
          FlagMask = 0, RAFlags = 0
          Lifetimes, V & P flags -- as desired
          UsePrefix = New /64 prefix

   The second step, deletion of the old prefix, can be done by an RR
   Command with the same Match-Prefix Part (except for an OpLength
   reduced from 11 to 3) and no Use-Prefix Parts.  Any temptation to set
   KeepLen = 64 in the second Use-Prefix Part above should be resisted,
   as it would instruct the router to sidestep address configuration.

10.  Acknowledgments

   This protocol was designed by Matt Crawford based on an idea of
   Robert Hinden and Geert Jan de Groot.  Many members of the IPNG
   Working Group contributed useful comments, in particular members of
   the DIGITAL UNIX IPv6 team.  Bill Sommerfeld provided helpful IPsec
   expertise.  Relentless browbeating by various IESG members may have
   improved the final quality of this specification.












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


11.  References

   [AARCH]   Hinden, R. and S. Deering, "IP Version 6 Addressing
             Architecture", RFC 2373, July 1998.

   [AH]      Kent, S. and R. Atkinson, "IP Authentication Header", RFC
             2402, November 1998.

   [ANM]     Isaacson, E. and H. B. Keller, "Analysis of Numerical
             Methods", John Wiley & Sons, New York, 1966.

   [ESP]     Kent, S. and R. Atkinson, "IP Encapsulating Security
             Payload (ESP)", RFC 2406, November 1998.

   [IANACON] Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
             October 1998.

   [ICMPV6]  Conta, A. and S. Deering, "Internet Control Message
             Protocol (ICMPv6) for the Internet Protocol Version 6
             (IPv6)", RFC 2463, December 1998.

   [IPSEC]   Kent, S. and R. Atkinson, "Security Architecture for the
             Internet Protocol", RFC 2401, November 1998.

   [IPV6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC 2460, December 1998.

   [IPV6MIB] Haskin, D. and S. Onishi, "Management Information Base for
             IP Version 6: Textual Conventions and General Group", RFC
             2466, December 1998.

   [KWORD]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [ND]      Narten, T., Nordmark, E. and W. Simpson, "Neighbor
             Discovery for IP Version 6 (IPv6)", RFC 2461, December
             1998.

   [OSPFMIB] Baker, F. and R. Coltun, "OSPF Version 2 Management
             Information Base", RFC 1850, November 1995.










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


12.  Author's Address

   Matt Crawford
   Fermilab MS 368
   PO Box 500
   Batavia, IL 60510
   USA

   Phone: [phone]
   EMail: [e-mail]









































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


Appendix -- Derivation of Reliability Estimates

   If a population S of size k is repeatedly sampled with an