rfc2894.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                        M. Crawford
Request for Comments: 2894                                      Fermilab
Category: Standards Track                                    August 2000


                      Router Renumbering for IPv6

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

IESG Note:

   This document defines mechanisms for informing a set of routers of
   renumbering operations they are to perform, including a mode of
   operation in environments in which the exact number of routers is
   unknown. Reliably informing all routers when the actual number of
   routers is unknown is a difficult problem. Implementation and
   operational experience will be needed to fully understand the
   applicabilty and scalability aspects of the mechanisms defined in
   this document when the number of routers is unknown.

Abstract

   IPv6 Neighbor Discovery and Address Autoconfiguration conveniently
   make initial assignments of address prefixes to hosts.  Aside from
   the problem of connection survival across a renumbering event, these
   two mechanisms also simplify the reconfiguration of hosts when the
   set of valid prefixes changes.

   This document defines a mechanism called Router Renumbering ("RR")
   which allows address prefixes on routers to be configured and
   reconfigured almost as easily as the combination of Neighbor
   Discovery and Address Autoconfiguration works for hosts.  It provides
   a means for a network manager to make updates to the prefixes used by
   and advertised by IPv6 routers throughout a site.







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


Table of Contents

   1.  Functional Overview .......................................    2
   2.  Definitions ...............................................    4
       2.1.  Terminology .........................................    4
       2.2.  Requirements ........................................    5
   3.  Message Format ............................................    5
       3.1.  Router Renumbering Header ...........................    7
       3.2.  Message Body -- Command Message .....................    9
           3.2.1.  Prefix Control Operation ......................    9
               3.2.1.1.  Match-Prefix Part .......................    9
               3.2.1.2.  Use-Prefix Part .........................   11
       3.3.  Message Body -- Result Message ......................   12
   4.  Message Processing ........................................   14
       4.1.  Header Check ........................................   14
       4.2.  Bounds Check ........................................   15
       4.3.  Execution ...........................................   16
       4.4.  Summary of Effects ..................................   17
   5.  Sequence Number Reset .....................................   18
   6.  IANA Considerations .......................................   19
   7.  Security Considerations ...................................   19
       7.1.  Security Policy and Association Database Entries ....   19
   8.  Implementation and Usage Advice for Reliability ...........   20
       8.1.  Outline and Definitions .............................   21
       8.2.  Computations ........................................   23
       8.3.  Additional Assurance Methods ........................   24
   9.  Usage Examples ............................................   25
       9.1.  Maintaining Global-Scope Prefixes ...................   25
       9.2.  Renumbering a Subnet ................................   26
   10.  Acknowledgments ..........................................   27
   11.  References ...............................................   28
   12.  Author's Address .........................................   29
   Appendix -- Derivation of Reliability Estimates ...............   30
   Full Copyright Statement ......................................   32

1.  Functional Overview

   Router Renumbering Command packets contain a sequence of Prefix
   Control Operations (PCOs).  Each PCO specifies an operation, a
   Match-Prefix, and zero or more Use-Prefixes.  A router processes each
   PCO in sequence, checking each of its interfaces for an address or
   prefix which matches the Match-Prefix.  For every interface on which
   a match is found, the operation is applied.  The operation is one of
   ADD, CHANGE, or SET-GLOBAL to instruct the router to respectively add
   the Use-Prefixes to the set of configured prefixes, remove the prefix
   which matched the Match-Prefix and replace it with the Use-Prefixes,





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


   or replace all global-scope prefixes with the Use-Prefixes.  If the
   set of Use-Prefixes in the PCO is empty, the ADD operation does
   nothing and the other two reduce to deletions.

   Additional information for each Use-Prefix is included in the Prefix
   Control Operation: the valid and preferred lifetimes to be included
   in Router Advertisement Prefix Information Options [ND], and either
   the L and A flags for the same option, or an indication that they are
   to be copied from the prefix that matched the Match-Prefix.

   It is possible to instruct routers to create new prefixes by
   combining the Use-Prefixes in a PCO with some portion of the existing
   prefix which matched the Match-Prefix.  This simplifies certain
   operations which are expected to be among the most common.  For every
   Use-Prefix, the PCO specifies a number of bits which should be copied
   from the existing address or prefix which matched the Match-Prefix
   and appended to the use-prefix prior to configuring the new prefix on
   the interface.  The copied bits are zero or more bits from the
   positions immediately after the length of the Use- Prefix.  If
   subnetting information is in the same portion of the old and new
   prefixes, this synthesis allows a single Prefix Control Operation to
   define a new global prefix on every router in a site, while
   preserving the subnetting structure.

   Because of the power of the Router Renumbering mechanism, each RR
   message includes a sequence number to guard against replays, and is
   required to be authenticated and integrity-checked.  Each single
   Prefix Control Operation is idempotent and so could be retransmitted
   for improved reliability, as long as the sequence number is current,
   without concern about multiple processing.  However, non-idempotent
   combinations of PCOs can easily be constructed and messages
   containing such combinations could not be safely reprocessed.
   Therefore, all routers are required to guard against processing an RR
   message more than once.  To allow reliable verification that Commands
   have been received and processed by routers, a mechanism for
   duplicate-command notification to the management station is included.

   Possibly a network manager will want to perform more renumbering, or
   exercise more detailed control, than can be expressed in a single
   Router Renumbering packet on the available media.  The RR mechanism
   is most powerful when RR packets are multicast, so IP fragmentation
   is undesirable.  For these reasons, each RR packet contains a
   "Segment Number".  All RR packets which have a Sequence Number
   greater than or equal to the highest value seen are valid and must be
   processed.  However, a router must keep track of the Segment Numbers
   of RR messages already processed and avoid reprocessing a message





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


   whose Sequence Number and Segment Number match a previously processed
   message.  (This list of processed segment numbers is reset when a new
   highest Sequence Number is seen.)

   The Segment Number does not impose an ordering on packet processing.
   If a specific sequence of operations is desired, it may be achieved
   by ordering the PCOs in a single RR Command message or through the
   Sequence Number field.

   There is a "Test" flag which indicates that all routers should
   simulate processing of the RR message and not perform any actual
   reconfiguration.  A separate "Report" flag instructs routers to send
   a Router Renumbering Result message back to the source of the RR
   Command message indicating the actual or simulated result of the
   operations in the RR Command message.

   The effect or simulated effect of an RR Command message may also be
   reported to network management by means outside the scope of this
   document, regardless of the value of the "Report" flag.

2.  Definitions

2.1.  Terminology

   Address
      This term always refers to a 128-bit IPv6 address [AARCH].  When
      referring to bits within an address, they are numbered from 0 to
      127, with bit 0 being the first bit of the Format Prefix.

   Prefix
      A prefix can be understood as an address plus a length, the latter
      being an integer in the range 0 to 128 indicating how many leading
      bits are significant.  When referring to bits within a prefix,
      they are numbered in the same way as the bits of an address.  For
      example, the significant bits of a prefix whose length is L are
      the bits numbered 0 through L-1, inclusive.

   Match
      An address A "matches" a prefix P whose length is L if the first L
      bits of A are identical with the first L bits of P.  (Every
      address matches a prefix of length 0.)  A prefix P1 with length L1
      matches a prefix P2 of length L2 if L1 >= L2 and the first L2 bits
      of P1 and P2 are identical.








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


   Prefix Control Operation
      This is the smallest individual unit of Router Renumbering
      operation.  A Router Renumbering Command packet includes zero or
      more of these, each comprising one matching condition, called a
      Match-Prefix Part, and zero or more substitution specifications,
      called Use-Prefix Parts.

   Match-Prefix
      This is a Prefix against which a router compares the addresses and
      prefixes configured on its interfaces.

   Use-Prefix
      The prefix and associated information which is to be configured on
      a router interface when certain conditions are met.

   Matched Prefix
      The existing prefix or address which matched a Match-Prefix.

   New Prefix
      A prefix constructed from a Use-Prefix, possibly including some of
      the Matched Prefix.

   Recorded Sequence Number
      The highest sequence number found in a valid message MUST be
      recorded in non-volatile storage.

      Note that "matches" is a transitive relation but not symmetric.
      If two prefixes match each other, they are identical.

2.2.  Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [KWORD].

3.  Message Format

   There are two types of Router Renumbering messages: Commands, which
   are sent to routers, and Results, which are sent by routers.  A third
   message type is used to synchronize a reset of the Recorded Sequence
   Number with the cancellation of cryptographic keys.  The three types
   of messages are distinguished the ICMPv6 "Code" field and differ in
   the contents of the "Message Body" field.








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


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                IPv6 header, extension headers                 /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                 ICMPv6 & RR Header (16 octets)                /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                       RR Message Body                         /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Router Renumbering Message Format

   Router Renumbering messages are carried in ICMPv6 packets with Type =
   138.  The RR message comprises an RR Header, containing the ICMPv6
   header, the sequence and segment numbers and other information, and
   the RR Message Body, of variable length.

   All fields marked "reserved" or "res" MUST be set to zero on
   generation of an RR message, and ignored on receipt.

   All implementations which generate Router Renumbering Command
   messages MUST support sending them to the All Routers multicast
   address with link and site scopes, and to unicast addresses of link-
   local and site-local formats.  All routers MUST be capable of
   receiving RR Commands sent to those multicast addresses and to any of
   their link local and site local unicast addresses.  Implementations
   SHOULD support sending and receiving RR messages addressed to other
   unicast addresses.  An implementation which is both a sender and
   receiver of RR commands SHOULD support use of the All Routers
   multicast address with node scope.

   Data authentication and message integrity MUST be provided for all
   Router Renumbering Command messages by appropriate IP Security
   [IPSEC] means.  The integrity assurance must include the IPv6
   destination address and the RR Header and Message Body.  See section
   7, "Security Considerations".