rfc2462.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,404 行 · 第 1/4 页

        autoconfiguration assumes that each interface can provide a
        unique identifier for that interface (i.e., an "interface
        identifier").  In the simplest case, an interface identifier
        consists of the interface's link-layer address. An interface
        identifier can be combined with a prefix to form an address.

      o Small sites consisting of a set of machines attached to a single
        link should not require the presence of a stateful server or
        router as a prerequisite for communicating.  Plug-and-play
        communication is achieved through the use of link-local
        addresses.  Link-local addresses have a well-known prefix that
        identifies the (single) shared link to which a set of nodes
        attach. A host forms a link-local address by appending its
        interface identifier to the link-local prefix.

      o A large site with multiple networks and routers should not
        require the presence of a stateful address configuration server.
        In order to generate site-local or global addresses, hosts must
        determine the prefixes that identify the subnets to which they
        attach.  Routers generate periodic Router Advertisements that
        include options listing the set of active prefixes on a link.

      o Address configuration should facilitate the graceful renumbering
        of a site's machines. For example, a site may wish to renumber
        all of its nodes when it switches to a new network service
        provider.  Renumbering is achieved through the leasing of
        addresses to interfaces and the assignment of multiple addresses
        to the same interface.  Lease lifetimes provide the mechanism
        through which a site phases out old prefixes.  The assignment of
        multiple addresses to an interface provides for a transition
        period during which both a new address and the one being phased
        out work simultaneously.

      o System administrators need the ability to specify whether
        stateless autoconfiguration, stateful autoconfiguration, or both
        should be used.  Router Advertisements include flags specifying
        which mechanisms a host should use.





Thomson & Narten            Standards Track                     [Page 7]

RFC 2462        IPv6 Stateless Address Autoconfiguration   December 1998


4.  PROTOCOL OVERVIEW

   This section provides an overview of the typical steps that take
   place when an interface autoconfigures itself.  Autoconfiguration is
   performed only on multicast-capable links and begins when a
   multicast-capable interface is enabled, e.g., during system startup.
   Nodes (both hosts and routers) begin the autoconfiguration process by
   generating a link-local address for the interface. A link-local
   address is formed by appending the interface's identifier to the
   well-known link-local prefix.

   Before the link-local address can be assigned to an interface and
   used, however, a node must attempt to verify that this "tentative"
   address is not already in use by another node on the link.
   Specifically, it sends a Neighbor Solicitation message containing the
   tentative address as the target. If another node is already using
   that address, it will return a Neighbor Advertisement saying so. If
   another node is also attempting to use the same address, it will send
   a Neighbor Solicitation for the target as well. The exact number of
   times the Neighbor Solicitation is (re)transmitted and the delay time
   between consecutive solicitations is link-specific and may be set by
   system management.

   If a node determines that its tentative link-local address is not
   unique, autoconfiguration stops and manual configuration of the
   interface is required.  To simplify recovery in this case, it should
   be possible for an administrator to supply an alternate interface
   identifier that overrides the default identifier in such a way that
   the autoconfiguration mechanism can then be applied using the new
   (presumably unique) interface identifier.  Alternatively, link-local
   and other addresses will need to be configured manually.

   Once a node ascertains that its tentative link-local address is
   unique, it assigns it to the interface. At this point, the node has
   IP-level connectivity with neighboring nodes.  The remaining
   autoconfiguration steps are performed only by hosts; the
   (auto)configuration of routers is beyond the scope of this document.

   The next phase of autoconfiguration involves obtaining a Router
   Advertisement or determining that no routers are present. If routers
   are present, they will send Router Advertisements that specify what
   sort of autoconfiguration a host should do.  If no routers are
   present, stateful autoconfiguration should be invoked.

   Routers send Router Advertisements periodically, but the delay
   between successive advertisements will generally be longer than a
   host performing autoconfiguration will want to wait [DISCOVERY].  To
   obtain an advertisement quickly, a host sends one or more Router



Thomson & Narten            Standards Track                     [Page 8]

RFC 2462        IPv6 Stateless Address Autoconfiguration   December 1998


   Solicitations to the all-routers multicast group.  Router
   Advertisements contain two flags indicating what type of stateful
   autoconfiguration (if any) should be performed. A "managed address
   configuration" flag indicates whether hosts should use stateful
   autoconfiguration to obtain addresses. An "other stateful
   configuration" flag indicates whether hosts should use stateful
   autoconfiguration to obtain additional information (excluding
   addresses).

   Router Advertisements also contain zero or more Prefix Information
   options that contain information used by stateless address
   autoconfiguration to generate site-local and global addresses.  It
   should be noted that the stateless and stateful address
   autoconfiguration fields in Router Advertisements are processed
   independently of one another, and a host may use both stateful and
   stateless address autoconfiguration simultaneously.  One Prefix
   Information option field, the "autonomous address-configuration
   flag", indicates whether or not the option even applies to stateless
   autoconfiguration.  If it does, additional option fields contain a
   subnet prefix together with lifetime values indicating how long
   addresses created from the prefix remain preferred and valid.

   Because routers generate Router Advertisements periodically, hosts
   will continually receive new advertisements. Hosts process the
   information contained in each advertisement as described above,
   adding to and refreshing information received in previous
   advertisements.

   For safety, all addresses must be tested for uniqueness prior to
   their assignment to an interface.  In the case of addresses created
   through stateless autoconfig, however, the uniqueness of an address
   is determined primarily by the portion of the address formed from an
   interface identifier.  Thus, if a node has already verified the
   uniqueness of a link-local address, additional addresses created from
   the same interface identifier need not be tested individually. In
   contrast, all addresses obtained manually or via stateful address
   autoconfiguration should be tested for uniqueness individually. To
   accommodate sites that believe the overhead of performing Duplicate
   Address Detection outweighs its benefits, the use of Duplicate
   Address Detection can be disabled through the administrative setting
   of a per-interface configuration flag.

   To speed the autoconfiguration process, a host may generate its
   link-local address (and verify its uniqueness) in parallel with
   waiting for a Router Advertisement. Because a router may delay
   responding to a Router Solicitation for a few seconds, the total time
   needed to complete autoconfiguration can be significantly longer if
   the two steps are done serially.



Thomson & Narten            Standards Track                     [Page 9]

RFC 2462        IPv6 Stateless Address Autoconfiguration   December 1998



4.1.  Site Renumbering

   Address leasing facilitates site renumbering by providing a mechanism
   to time-out addresses assigned to interfaces in hosts.  At present,
   upper layer protocols such as TCP provide no support for changing
   end-point addresses while a connection is open. If an end-point
   address becomes invalid, existing connections break and all
   communication to the invalid address fails.  Even when applications
   use UDP as a transport protocol, addresses must generally remain the
   same during a packet exchange.

   Dividing valid addresses into preferred and deprecated categories
   provides a way of indicating to upper layers that a valid address may
   become invalid shortly and that future communication using the
   address will fail, should the address's valid lifetime expire before
   communication ends.  To avoid this scenario, higher layers should use
   a preferred address (assuming one of sufficient scope exists) to
   increase the likelihood that an address will remain valid for the
   duration of the communication.  It is up to system administrators to
   set appropriate prefix lifetimes in order to minimize the impact of
   failed communication when renumbering takes place.  The deprecation
   period should be long enough that most, if not all, communications
   are using the new address at the time an address becomes invalid.

   The IP layer is expected to provide a means for upper layers
   (including applications) to select the most appropriate source
   address given a particular destination and possibly other
   constraints.  An application may choose to select the source address
   itself before starting a new communication or may leave the address
   unspecified, in which case the upper networking layers will use the
   mechanism provided by the IP layer to choose a suitable address on
   the application's behalf.

   Detailed address selection rules are beyond the scope of this
   document.

5.  PROTOCOL SPECIFICATION

   Autoconfiguration is performed on a per-interface basis on
   multicast-capable interfaces.  For multihomed hosts,
   autoconfiguration is performed independently on each interface.
   Autoconfiguration applies primarily to hosts, with two exceptions.
   Routers are expected to generate a link-local address using the
   procedure outlined below. In addition, routers perform Duplicate
   Address Detection on all addresses prior to assigning them to an
   interface.




Thomson & Narten            Standards Track                    [Page 10]

RFC 2462        IPv6 Stateless Address Autoconfiguration   December 1998


5.1.  Node Configuration Variables

   A node MUST allow the following autoconfiguration-related variable to
   be configured by system management for each multicast interface:

      DupAddrDetectTransmits

                     The number of consecutive Neighbor Solicitation
                     messages sent while performing Duplicate Address
                     Detection on a tentative address. A value of zero
                     indicates that Duplicate Address Detection is not
                     performed on tentative addresses. A value of one
                     indicates a single transmission with no follow up
                     retransmissions.

                     Default: 1, but may be overridden by a link-type
                     specific value in the document that covers issues
                     related to the transmission of IP over a particular
                     link type (e.g., [IPv6-ETHER]).

                     Autoconfiguration also assumes the presence of the
                     variable RetransTimer as defined in [DISCOVERY].
                     For autoconfiguration purposes, RetransTimer
                     specifies the delay between consecutive Neighbor
                     Solicitation transmissions performed during
                     Duplicate Address Detection (if
                     DupAddrDetectTransmits is greater than 1), as well
                     as the time a node waits after sending the last
                     Neighbor Solicitation before ending the Duplicate
                     Address Detection process.

5.2.  Autoconfiguration-Related Variables

   A host maintains a number of data structures and flags related to
   autoconfiguration. In the following, we present conceptual variables
   and show how they are used to perform autoconfiguration. The specific
   variables are used for demonstration purposes only, and an
   implementation is not required to have them, so long as its external
   behavior is consistent with that described in this document.

   Beyond the formation of a link-local address and using Duplicate
   Address Detection, how routers (auto)configure their interfaces is
   beyond the scope of this document.

   Hosts maintain the following variables on a per-interface basis:






Thomson & Narten            Standards Track                    [Page 11]

RFC 2462        IPv6 Stateless Address Autoconfiguration   December 1998


      ManagedFlag      Copied from the M flag field (i.e., the
                       "managed address configuration" flag) of the most
                       recently received Router Advertisement message.
                       The flag indicates whether or not addresses are
                       to be configured using the stateful
                       autoconfiguration mechanism. It starts out in a
                       FALSE state.

      OtherConfigFlag  Copied from the O flag field (i.e., the "other
                       stateful configuration" flag) of the most
                       recently received Router Advertisement message.
                       The flag indicates whether or not information
                       other than addresses is to be obtained using the
                       stateful autoconfiguration mechanism. It starts
                       out in a FALSE state.

                       In addition, when the value of the ManagedFlag is
                       TRUE, the value of OtherConfigFlag is implicitely
                       TRUE as well. It is not a valid configuration for
                       a host to use stateful address autoconfiguration
                       to request addresses only, without also accepting
                       other configuration
                       information.

   A host also maintains a list of addresses together with their
   corresponding lifetimes. The address list contains both
   autoconfigured addresses and those configured manually.

5.3.  Creation of Link-Local Addresses

   A node forms a link-local address whenever an interface becomes
   enabled.  An interface may become enabled after any of the
   following
   events:

      - The interface is initialized at system startup time.

      - The interface is reinitialized after a temporary interface
        failure or after being temporarily disabled by system
        management.

      - The interface attaches to a link for the first time.

      - The interface becomes enabled by system management after
        having been administratively
        disabled.





Thomson & Narten            Standards Track                    [Page 12]

RFC 2462        IPv6 Stateless Address Autoconfiguration   December 1998


   A link-local address is formed by prepending the well-known link-
   local prefix FE80::0 [ADDR-ARCH] (of appropriate length) to the
   interface identifier. If the interface identifier has a length of N
   bits, the interface identifier replaces the right-most N zero bits of
   the link-local prefix.  If the interface identifier is more than 118
   bits in length, autoconfiguration fails and manual configuration is
   required. Note that interface identifiers will typically be 64-bits
   long and based on EUI-64 identifiers as described in [ADDR-ARCH].

   A link-local address has an infinite preferred and valid lifetime; it
   is never timed
   out.

5.4.  Duplicate Address Detection

   Duplicate Address Detection is performed on unicast addresses prior
   to assigning them to an interface whose DupAddrDetectTransmits
   variable is greater than zero. Duplicate Address Detection MUST take
   place on all unicast addresses, regardless of whether they are
   obtained through stateful, stateless or manual configuration, with
   the exception of the following cases:

      - Duplicate Address Detection MUST NOT be performed on anycast
        addresses.