rfc2462.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,404 行 · 第 1/5 页

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


   deprecated address - An address assigned to an interface whose use is
        discouraged, but not forbidden.  A deprecated address should no
        longer be used as a source address in new communications, but
        packets sent from or to deprecated addresses are delivered as
        expected.  A deprecated address may continue to be used as a
        source address in communications where switching to a preferred
        address causes hardship to a specific upper-layer activity
        (e.g., an existing TCP connection).

   valid address - a preferred or deprecated address. A valid address
        may appear as the source or destination address of a packet, and
        the internet routing system is expected to deliver packets sent
        to a valid address to their intended recipients.

   invalid address - an address that is not assigned to any interface. A
        valid address becomes invalid when its valid lifetime expires.
        Invalid addresses should not appear as the destination or source
        address of a packet. In the former case, the internet routing
        system will be unable to deliver the packet, in the later case
        the recipient of the packet will be unable to respond to it.

   preferred lifetime - the length of time that a valid address is
        preferred (i.e., the time until deprecation). When the preferred
        lifetime expires, the address becomes deprecated.

   valid lifetime - the length of time an address remains in the valid
        state (i.e., the time until invalidation). The valid lifetime
        must be greater then or equal to the preferred lifetime.  When
        the valid lifetime expires, the address becomes invalid.

   interface identifier - a link-dependent identifier for an interface
        that is (at least) unique per link [ADDR-ARCH]. Stateless
        address autoconfiguration combines an interface identifier with
        a prefix to form an address. From address autoconfiguration's
        perspective, an interface identifier is a bit string of known
        length.  The exact length of an interface identifier and the way
        it is created is defined in a separate link-type specific
        document that covers issues related to the transmission of IP
        over a particular link type (e.g., [IPv6-ETHER]).  In many
        cases, the identifier will be the same as the interface's link-
        layer address.

2.1.  Requirements

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [KEYWORDS].




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


3.  DESIGN GOALS

   Stateless autoconfiguration is designed with the following goals in
   mind:

      o Manual configuration of individual machines before connecting
        them to the network should not be required. Consequently, a
        mechanism is needed that allows a host to obtain or create
        unique addresses for each of its interfaces. Address
        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]