rfc1971.txt

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

   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 token
               - a link-dependent identifier for an interface that is
                 (at least) unique per link. Stateless address
                 autoconfiguration combines an interface token with a



Thomson & Narten            Standards Track                     [Page 6]

RFC 1971       IPv6 Stateless Address Autoconfiguration      August 1996


                 prefix to form an address. From address
                 autoconfiguration's perspective, an interface token is
                 a bit string of known length.  The exact length of an
                 interface token 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 token will be the same as the interface's
                 link-layer address.

2.1.  Requirements

   Throughout this document, the words that are used to define the
   significance of the particular requirements are capitalized.  These
   words are:

MUST
     This word or the adjective "REQUIRED" means that the item is an
     absolute requirement of this specification.

MUST NOT
     This phrase means the item is an absolute prohibition of this
     specification.

SHOULD
     This word or the adjective "RECOMMENDED" means that there may exist
     valid reasons in particular circumstances to ignore this item, but
     the full implications should be understood and the case carefully
     weighed before choosing a different course.

SHOULD NOT
     This phrase means that there may exist valid reasons in particular
     circumstances when the listed behavior is acceptable or even
     useful, but the full implications should be understood and the case
     carefully weighed before implementing any behavior described with
     this label.

MAY
     This word or the adjective "OPTIONAL" means that this item is truly
     optional.  One vendor may choose to include the item because a
     particular marketplace requires it or because it enhances the
     product, for example, another vendor may omit the same item.









Thomson & Narten            Standards Track                     [Page 7]

RFC 1971       IPv6 Stateless Address Autoconfiguration      August 1996


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 token").  In the simplest case, an interface token
     consists of the interface's link-layer address. An interface token
     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 token 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 8]

RFC 1971       IPv6 Stateless Address Autoconfiguration      August 1996


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 token 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
   token that overrides the default token in such a way that the
   autoconfiguration mechanism can then be applied using the new
   (presumably unique) interface token.  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 9]

RFC 1971       IPv6 Stateless Address Autoconfiguration      August 1996


   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 token.  Thus, if a node has already verified the uniqueness
   of a link-local address, additional addresses created from the same
   interface token 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 10]

RFC 1971       IPv6 Stateless Address Autoconfiguration      August 1996


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 11]

RFC 1971       IPv6 Stateless Address Autoconfiguration      August 1996


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