home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipngwg-addrconf-v2-00.txt < prev    next >
Text File  |  1997-07-30  |  62KB  |  1,397 lines
  1.  
  2. INTERNET-DRAFT                                   Susan Thomson, Bellcore
  3. July 30, 1997                                         Thomas Narten, IBM
  4. <draft-ietf-ipngwg-addrconf-v2-00.txt>                     July 30, 1997
  5.  
  6.                  IPv6 Stateless Address Autoconfiguration                 |
  7.  
  8.  
  9. Status of this Memo
  10.  
  11.    This document is a submission to the ADDRCONF Working Group of the
  12.    Internet Engineering Task Force (IETF). Comments should be submitted
  13.    to the addrconf@cisco.com mailing list.
  14.  
  15.    This document is an Internet Draft.  Internet Drafts are working
  16.    documents of the Internet Engineering Task Force (IETF), its Areas,
  17.    and its Working Groups. Note that other groups may also distribute
  18.    working documents as Internet Drafts.
  19.  
  20.    Internet Drafts are draft documents valid for a maximum of six
  21.    months. Internet Drafts may be updated, replaced, or obsoleted by
  22.    other documents at any time.  It is not appropriate to use Internet
  23.    Drafts as reference material or to cite them other than as a "working
  24.    draft" or "work in progress."
  25.  
  26.    To learn the current status of any Internet Draft, please check the
  27.    1id-abstracts.txt listing contained in the Internet Drafts Shadow
  28.    Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com or
  29.    munnari.oz.au.
  30.  
  31.    Distribution of this memo is unlimited.
  32.  
  33.    This Internet Draft expires February 28, 1998.
  34.  
  35.  
  36. Abstract
  37.  
  38.    This document specifies the steps a host takes in deciding how to
  39.    autoconfigure its interfaces in IP version 6. The autoconfiguration
  40.    process includes creating a link-local address and verifying its
  41.    uniqueness on a link, determining what information should be
  42.    autoconfigured (addresses, other information, or both), and in the
  43.    case of addresses, whether they should be obtained through the
  44.    stateless mechanism, the stateful mechanism, or both.  This document
  45.    defines the process for generating a link-local address, the process
  46.    for generating site-local and global addresses via stateless address
  47.    autoconfiguration, and the Duplicate Address Detection procedure. The
  48.  
  49.  
  50.  
  51. draft-ietf-ipngwg-addrconf-v2-00.txt                            [Page 1]
  52.  
  53. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  54.  
  55.  
  56.    details of autoconfiguration using the stateful protocol are
  57.    specified elsewhere.
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107. draft-ietf-ipngwg-addrconf-v2-00.txt                            [Page 2]
  108.  
  109. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  110.  
  111.  
  112.    Contents
  113.  
  114.    Status of this Memo..........................................    1     |
  115.  
  116.    1.  INTRODUCTION.............................................    3     |
  117.  
  118.    2.  TERMINOLOGY..............................................    5     |
  119.       2.1.  Requirements........................................    9     |
  120.  
  121.    3.  DESIGN GOALS.............................................    9     |
  122.  
  123.    4.  PROTOCOL OVERVIEW........................................   10     |
  124.       4.1.  Site Renumbering....................................   12     |
  125.  
  126.    5.  PROTOCOL SPECIFICATION...................................   13     |
  127.       5.1.  Node Configuration Variables........................   13     |
  128.       5.2.  Autoconfiguration-Related Variables.................   13     |
  129.       5.3.  Creation of Link-Local Addresses....................   14     |
  130.       5.4.  Duplicate Address Detection.........................   15     |
  131.          5.4.1.  Message Validation.............................   16     |
  132.          5.4.2.  Sending Neighbor Solicitation Messages.........   16     |
  133.          5.4.3.  Receiving Neighbor Solicitation Messages.......   17     |
  134.          5.4.4.  Receiving Neighbor Advertisement Messages......   18     |
  135.          5.4.5.  When Duplicate Address Detection Fails.........   18     |
  136.       5.5.  Creation of Global and Site-Local Addresses.........   18     |
  137.          5.5.1.  Soliciting Router Advertisements...............   19     |
  138.          5.5.2.  Absence of Router Advertisements...............   19     |
  139.          5.5.3.  Router Advertisement Processing................   19     |
  140.          5.5.4.  Address Lifetime Expiry........................   21     |
  141.       5.6.  Configuration Consistency...........................   21     |
  142.  
  143.    6.  SECURITY CONSIDERATIONS..................................   22     |
  144.  
  145.    7.  References...............................................   22     |
  146.  
  147.    8.  Acknowledgements.........................................   23     |
  148.  
  149.    9.  APPENDIX A: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION   23|
  150.  
  151.    10.  APPENDIX B: CHANGES SINCE RFC 1971......................   25     |
  152.  
  153.  
  154. 1.  INTRODUCTION
  155.  
  156.    This document specifies the steps a host takes in deciding how to
  157.    autoconfigure its interfaces in IP version 6. The autoconfiguration
  158.    process includes creating a link-local address and verifying its
  159.    uniqueness on a link, determining what information should be
  160.  
  161.  
  162.  
  163. draft-ietf-ipngwg-addrconf-v2-00.txt                            [Page 3]
  164.  
  165. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  166.  
  167.  
  168.    autoconfigured (addresses, other information, or both), and in the
  169.    case of addresses, whether they should be obtained through the
  170.    stateless mechanism, the stateful mechanism, or both.  This document
  171.    defines the process for generating a link-local address, the process
  172.    for generating site-local and global addresses via stateless address
  173.    autoconfiguration, and the Duplicate Address Detection procedure. The
  174.    details of autoconfiguration using the stateful protocol are
  175.    specified elsewhere.
  176.  
  177.    IPv6 defines both a stateful and stateless address autoconfiguration
  178.    mechanism. Stateless autoconfiguration requires no manual
  179.    configuration of hosts, minimal (if any) configuration of routers,
  180.    and no additional servers.  The stateless mechanism allows a host to
  181.    generate its own addresses using a combination of locally available
  182.    information and information advertised by routers. Routers advertise
  183.    prefixes that identify the subnet(s) associated with a link, while     |
  184.    hosts generate an "interface identifier" that uniquely identifies an
  185.    interface on a subnet. An address is formed by combining the two. In
  186.    the absence of routers, a host can only generate link-local
  187.    addresses. However, link-local addresses are sufficient for allowing
  188.    communication among nodes attached to the same link.
  189.  
  190.    In the stateful autoconfiguration model, hosts obtain interface
  191.    addresses and/or configuration information and parameters from a
  192.    server.  Servers maintain a database that keeps track of which
  193.    addresses have been assigned to which hosts. The stateful
  194.    autoconfiguration protocol allows hosts to obtain addresses, other
  195.    configuration information or both from a server.  Stateless and
  196.    stateful autoconfiguration complement each other. For example, a host
  197.    can use stateless autoconfiguration to configure its own addresses,
  198.    but use stateful autoconfiguration to obtain other information.
  199.    Stateful autoconfiguration is described in [DHCPv6].
  200.  
  201.    The stateless approach is used when a site is not particularly
  202.    concerned with the exact addresses hosts use, so long as they are
  203.    unique and properly routable. The stateful approach is used when a
  204.    site requires tighter control over exact address assignments.  Both
  205.    stateful and stateless address autoconfiguration may be used
  206.    simultaneously.  The site administrator specifies which type of
  207.    autoconfiguration to use through the setting of appropriate fields in
  208.    Router Advertisement messages [DISCOVERY].
  209.  
  210.    IPv6 addresses are leased to an interface for a fixed (possibly
  211.    infinite) length of time. Each address has an associated lifetime
  212.    that indicates how long the address is bound to an interface. When a
  213.    lifetime expires, the binding (and address) become invalid and the
  214.    address may be reassigned to another interface elsewhere in the
  215.    Internet. To handle the expiration of address bindings gracefully, an
  216.  
  217.  
  218.  
  219. draft-ietf-ipngwg-addrconf-v2-00.txt                            [Page 4]
  220.  
  221. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  222.  
  223.  
  224.    address goes through two distinct phases while assigned to an
  225.    interface. Initially, an address is "preferred", meaning that its use
  226.    in arbitrary communication is unrestricted. Later, an address becomes
  227.    "deprecated" in anticipation that its current interface binding will
  228.    become invalid. While in a deprecated state, the use of an address is
  229.    discouraged, but not strictly forbidden.  New communication (e.g.,
  230.    the opening of a new TCP connection) should use a preferred address
  231.    when possible.  A deprecated address should be used only by
  232.    applications that have been using it and would have difficulty
  233.    switching to another address without a service disruption.
  234.  
  235.    To insure that all configured addresses are likely to be unique on a
  236.    given link, nodes run a "duplicate address detection" algorithm on
  237.    addresses before assigning them to an interface.  The Duplicate
  238.    Address Detection algorithm is performed on all addresses,
  239.    independent of whether they are obtained via stateless or stateful
  240.    autoconfiguration. This document defines the Duplicate Address
  241.    Detection algorithm.
  242.  
  243.    The autoconfiguration process specified in this document applies only
  244.    to hosts and not routers. Since host autoconfiguration uses
  245.    information advertised by routers, routers will need to be configured
  246.    by some other means. However, it is expected that routers will
  247.    generate link-local addresses using the mechanism described in this
  248.    document. In addition, routers are expected to successfully pass the
  249.    Duplicate Address Detection procedure described in this document on
  250.    all addresses prior to assigning them to an interface.
  251.  
  252.    Section 2 provides definitions for terminology used throughout this
  253.    document. Section 3 describes the design goals that lead to the
  254.    current autoconfiguration procedure. Section 4 provides an overview
  255.    of the protocol, while Section 5 describes the protocol in detail.
  256.  
  257.  
  258. 2.  TERMINOLOGY
  259.  
  260.       IP          - Internet Protocol Version 6.  The terms IPv4 and
  261.                     IPv6 are used only in contexts where necessary to
  262.                     avoid ambiguity.
  263.  
  264.       node        - a device that implements IP.
  265.  
  266.       router      - a node that forwards IP packets not explicitly
  267.                     addressed to itself.
  268.  
  269.       host        - any node that is not a router.
  270.  
  271.       upper layer - a protocol layer immediately above IP.  Examples are
  272.  
  273.  
  274.  
  275. draft-ietf-ipngwg-addrconf-v2-00.txt                            [Page 5]
  276.  
  277. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  278.  
  279.  
  280.                     transport protocols such as TCP and UDP, control
  281.                     protocols such as ICMP, routing protocols such as
  282.                     OSPF, and internet or lower-layer protocols being
  283.                     "tunneled" over (i.e., encapsulated in) IP such as
  284.                     IPX, AppleTalk, or IP itself.
  285.  
  286.       link        - a communication facility or medium over which nodes
  287.                     can communicate at the link layer, i.e., the layer
  288.                     immediately below IP.  Examples are Ethernets
  289.                     (simple or bridged); PPP links; X.25, Frame Relay,
  290.                     or ATM networks; and internet (or higher) layer
  291.                     "tunnels", such as tunnels over IPv4 or IPv6 itself.
  292.  
  293.       interface   - a node's attachment to a link.
  294.  
  295.       packet      - an IP header plus payload.
  296.  
  297.       address     - an IP-layer identifier for an interface or a set of
  298.                     interfaces.
  299.  
  300.       unicast address
  301.                   - an identifier for a single interface. A packet sent
  302.                     to a unicast address is delivered to the interface
  303.                     identified by that address.
  304.  
  305.       multicast address
  306.                   - an identifier for a set of interfaces (typically
  307.                     belonging to different nodes). A packet sent to a
  308.                     multicast address is delivered to all interfaces
  309.                     identified by that address.
  310.  
  311.       anycast address
  312.                   - an identifier for a set of interfaces (typically
  313.                     belonging to different nodes).  A packet sent to an
  314.                     anycast address is delivered to one of the
  315.                     interfaces identified by that address (the "nearest"
  316.                     one, according to the routing protocol's measure of
  317.                     distance).  See [ADDR-ARCH].
  318.  
  319.       solicited-node multicast address
  320.                   - a multicast address to which Neighbor Solicitation
  321.                     messages are sent. The algorithm for computing the
  322.                     address is given in [DISCOVERY].
  323.  
  324.       link-layer address
  325.                   - a link-layer identifier for an interface.  Examples
  326.                     include IEEE 802 addresses for Ethernet links and
  327.                     E.164 addresses for ISDN links.
  328.  
  329.  
  330.  
  331. draft-ietf-ipngwg-addrconf-v2-00.txt                            [Page 6]
  332.  
  333. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  334.  
  335.  
  336.       link-local address
  337.                   - an address having link-only scope that can be used
  338.                     to reach neighboring nodes attached to the same
  339.                     link.  All interfaces have a link-local unicast
  340.                     address.
  341.  
  342.       site-local address
  343.                   - an address having scope that is limited to the local
  344.                     site.
  345.  
  346.       global address
  347.                   - an address with unlimited scope.
  348.  
  349.       communication
  350.                   - any packet exchange among nodes that requires that
  351.                     the address of each node used in the exchange remain
  352.                     the same for the duration of the packet exchange.
  353.                     Examples are a TCP connection or a UDP request-
  354.                     response.
  355.  
  356.       tentative address
  357.                   - an address whose uniqueness on a link is being
  358.                     verified, prior to its assignment to an interface.
  359.                     A tentative address is not considered assigned to an
  360.                     interface in the usual sense. An interface discards
  361.                     received packets addressed to a tentative address,
  362.                     but accepts Neighbor Discovery packets related to
  363.                     Duplicate Address Detection for the tentative
  364.                     address.
  365.  
  366.       preferred address
  367.                   - an address assigned to an interface whose use by
  368.                     upper layer protocols is unrestricted. Preferred
  369.                     addresses may be used as the source (or destination)
  370.                     address of packets sent from (or to) the interface.
  371.  
  372.       deprecated address
  373.                   - An address assigned to an interface whose use is
  374.                     discouraged, but not forbidden.  A deprecated
  375.                     address should no longer be used as a source address  |
  376.                     in new communications, but packets sent from or to    |
  377.                     deprecated addresses are delivered as expected.  A
  378.                     deprecated address may continue to be used as a
  379.                     source address in communications where switching to
  380.                     a preferred address causes hardship to a specific
  381.                     upper-layer activity (e.g., an existing TCP
  382.                     connection).
  383.  
  384.  
  385.  
  386.  
  387. draft-ietf-ipngwg-addrconf-v2-00.txt                            [Page 7]
  388.  
  389. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  390.  
  391.  
  392.       valid address
  393.                   - a preferred or deprecated address. A valid address
  394.                     may appear as the source or destination address of a
  395.                     packet, and the internet routing system is expected   |
  396.                     to deliver packets sent to a valid address to their   |
  397.                     intended recipients.
  398.  
  399.       invalid address
  400.                   - an address that is not assigned to any interface. A
  401.                     valid address becomes invalid when its valid
  402.                     lifetime expires.  Invalid addresses should not
  403.                     appear as the   destination or source address of a
  404.                     packet. In the former case, the internet routing
  405.                     system will be unable to deliver the packet, in the
  406.                     later case the recipient of the packet will be
  407.                     unable to respond to it.
  408.  
  409.       preferred lifetime
  410.                   - the length of time that a valid address is preferred
  411.                     (i.e., the time until deprecation). When the
  412.                     preferred lifetime expires, the address becomes
  413.                     deprecated.
  414.  
  415.       valid lifetime
  416.                   - the length of time an address remains in the valid
  417.                     state (i.e., the time until invalidation). The valid
  418.                     lifetime must be greater then or equal to the
  419.                     preferred lifetime.  When the valid lifetime
  420.                     expires, the address becomes invalid.
  421.  
  422.       interface identifier                                                |
  423.                   - a link-dependent identifier for an interface that is
  424.                     (at least) unique per link [ADDR-ARCH]. Stateless     |
  425.                     address autoconfiguration combines an interface       |
  426.                     identifier with a prefix to form an address. From     |
  427.                     address autoconfiguration's perspective, an           |
  428.                     interface identifier is a bit string of known         |
  429.                     length.  The exact length of an interface identifier  |
  430.                     and the way it is created is defined in a separate    |
  431.                     link-type specific document that covers issues        |
  432.                     related to the transmission of IP over a particular   |
  433.                     link type (e.g., [IPv6-ETHER]).  In many cases, the   |
  434.                     identifier will be the same as the interface's        |
  435.                     link-layer address.
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443. draft-ietf-ipngwg-addrconf-v2-00.txt                            [Page 8]
  444.  
  445. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  446.  
  447.  
  448. 2.1.  Requirements                                                        *
  449.  
  450.    The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,       |
  451.    SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this   |
  452.    document, are to be interpreted as described in [KEYWORDS].
  453.  
  454.  
  455. 3.  DESIGN GOALS
  456.  
  457.    Stateless autoconfiguration is designed with the following goals in
  458.    mind:
  459.  
  460.       o Manual configuration of individual machines before connecting
  461.         them to the network should not be required. Consequently, a
  462.         mechanism is needed that allows a host to obtain or create
  463.         unique addresses for each of its interfaces. Address
  464.         autoconfiguration assumes that each interface can provide a
  465.         unique identifier for that interface (i.e., an "interface         |
  466.         identifier").  In the simplest case, an interface identifier      |
  467.         consists of the interface's link-layer address. An interface      |
  468.         identifier can be combined with a prefix to form an address.
  469.  
  470.       o Small sites consisting of a set of machines attached to a single
  471.         link should not require the presence of a stateful server or
  472.         router as a prerequisite for communicating.  Plug-and-play
  473.         communication is achieved through the use of link-local
  474.         addresses.  Link-local addresses have a well-known prefix that
  475.         identifies the (single) shared link to which a set of nodes
  476.         attach. A host forms a link-local address by appending its        |
  477.         interface identifier to the link-local prefix.
  478.  
  479.       o A large site with multiple networks and routers should not
  480.         require the presence of a stateful address configuration server.
  481.         In order to generate site-local or global addresses, hosts must
  482.         determine the prefixes that identify the subnets to which they
  483.         attach.  Routers generate periodic Router Advertisements that
  484.         include options listing the set of active prefixes on a link.
  485.  
  486.       o Address configuration should facilitate the graceful renumbering
  487.         of a site's machines. For example, a site may wish to renumber
  488.         all of its nodes when it switches to a new network service
  489.         provider.  Renumbering is achieved through the leasing of
  490.         addresses to interfaces and the assignment of multiple addresses
  491.         to the same interface.  Lease lifetimes provide the mechanism
  492.         through which a site phases out old prefixes.  The assignment of
  493.         multiple addresses to an interface provides for a transition
  494.         period during which both a new address and the one being phased
  495.         out work simultaneously.
  496.  
  497.  
  498.  
  499. draft-ietf-ipngwg-addrconf-v2-00.txt                            [Page 9]
  500.  
  501. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  502.  
  503.  
  504.       o System administrators need the ability to specify whether
  505.         stateless autoconfiguration, stateful autoconfiguration, or both
  506.         should be used.  Router Advertisements include flags specifying
  507.         which mechanisms a host should use.
  508.  
  509.  
  510. 4.  PROTOCOL OVERVIEW
  511.  
  512.    This section provides an overview of the typical steps that take
  513.    place when an interface autoconfigures itself.  Autoconfiguration is
  514.    performed only on multicast-capable links and begins when a
  515.    multicast-capable interface is enabled, e.g., during system startup.
  516.    Nodes (both hosts and routers) begin the autoconfiguration process by
  517.    generating a link-local address for the interface. A link-local        |
  518.    address is formed by appending the interface's identifier to the
  519.    well-known link-local prefix.
  520.  
  521.    Before the link-local address can be assigned to an interface and
  522.    used, however, a node must attempt to verify that this "tentative"
  523.    address is not already in use by another node on the link.
  524.    Specifically, it sends a Neighbor Solicitation message containing the
  525.    tentative address as the target. If another node is already using
  526.    that address, it will return a Neighbor Advertisement saying so. If
  527.    another node is also attempting to use the same address, it will send
  528.    a Neighbor Solicitation for the target as well. The exact number of
  529.    times the Neighbor Solicitation is (re)transmitted and the delay time
  530.    between consecutive solicitations is link-specific and may be set by
  531.    system management.
  532.  
  533.    If a node determines that its tentative link-local address is not
  534.    unique, autoconfiguration stops and manual configuration of the
  535.    interface is required.  To simplify recovery in this case, it should
  536.    be possible for an administrator to supply an alternate interface      |
  537.    identifier that overrides the default identifier in such a way that    |
  538.    the autoconfiguration mechanism can then be applied using the new      |
  539.    (presumably unique) interface identifier.  Alternatively, link-local   |
  540.    and other addresses will need to be configured manually.
  541.  
  542.    Once a node ascertains that its tentative link-local address is
  543.    unique, it assigns it to the interface. At this point, the node has
  544.    IP-level connectivity with neighboring nodes.  The remaining
  545.    autoconfiguration steps are performed only by hosts; the
  546.    (auto)configuration of routers is beyond the scope of this document.
  547.  
  548.    The next phase of autoconfiguration involves obtaining a Router
  549.    Advertisement or determining that no routers are present. If routers
  550.    are present, they will send Router Advertisements that specify what
  551.    sort of autoconfiguration a host should do.  If no routers are
  552.  
  553.  
  554.  
  555. draft-ietf-ipngwg-addrconf-v2-00.txt                           [Page 10]
  556.  
  557. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  558.  
  559.  
  560.    present, stateful autoconfiguration should be invoked.
  561.  
  562.    Routers send Router Advertisements periodically, but the delay
  563.    between successive advertisements will generally be longer than a
  564.    host performing autoconfiguration will want to wait [DISCOVERY].  To
  565.    obtain an advertisement quickly, a host sends one or more Router
  566.    Solicitations to the all-routers multicast group.  Router
  567.    Advertisements contain two flags indicating what type of stateful
  568.    autoconfiguration (if any) should be performed. A "managed address
  569.    configuration" flag indicates whether hosts should use stateful
  570.    autoconfiguration to obtain addresses. An "other stateful
  571.    configuration" flag indicates whether hosts should use stateful
  572.    autoconfiguration to obtain additional information (excluding
  573.    addresses).
  574.  
  575.    Router Advertisements also contain zero or more Prefix Information
  576.    options that contain information used by stateless address
  577.    autoconfiguration to generate site-local and global addresses.  It
  578.    should be noted that the stateless and stateful address
  579.    autoconfiguration fields in Router Advertisements are processed
  580.    independently of one another, and a host may use both stateful and
  581.    stateless address autoconfiguration simultaneously.  One Prefix
  582.    Information option field, the "autonomous address-configuration
  583.    flag", indicates whether or not the option even applies to stateless
  584.    autoconfiguration.  If it does, additional option fields contain a
  585.    subnet prefix together with lifetime values indicating how long
  586.    addresses created from the prefix remain preferred and valid.
  587.  
  588.    Because routers generate Router Advertisements periodically, hosts
  589.    will continually receive new advertisements. Hosts process the
  590.    information contained in each advertisement as described above,
  591.    adding to and refreshing information received in previous
  592.    advertisements.
  593.  
  594.    For safety, all addresses must be tested for uniqueness prior to
  595.    their assignment to an interface.  In the case of addresses created
  596.    through stateless autoconfig, however, the uniqueness of an address
  597.    is determined primarily by the portion of the address formed from an   |
  598.    interface identifier.  Thus, if a node has already verified the        |
  599.    uniqueness of a link-local address, additional addresses created from
  600.    the same interface identifier need not be tested individually. In      |
  601.    contrast, all addresses obtained manually or via stateful address
  602.    autoconfiguration should be tested for uniqueness individually. To
  603.    accommodate sites that believe the overhead of performing Duplicate
  604.    Address Detection outweighs its benefits, the use of Duplicate
  605.    Address Detection can be disabled through the administrative setting
  606.    of a per-interface configuration flag.
  607.  
  608.  
  609.  
  610.  
  611. draft-ietf-ipngwg-addrconf-v2-00.txt                           [Page 11]
  612.  
  613. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  614.  
  615.  
  616.    To speed the autoconfiguration process, a host may generate its
  617.    link-local address (and verify its uniqueness) in parallel with
  618.    waiting for a Router Advertisement. Because a router may delay
  619.    responding to a Router Solicitation for a few seconds, the total time
  620.    needed to complete autoconfiguration can be significantly longer if
  621.    the two steps are done serially.
  622.  
  623.  
  624. 4.1.  Site Renumbering
  625.  
  626.    Address leasing facilitates site renumbering by providing a mechanism
  627.    to time-out addresses assigned to interfaces in hosts.  At present,
  628.    upper layer protocols such as TCP provide no support for changing
  629.    end-point addresses while a connection is open. If an end-point
  630.    address becomes invalid, existing connections break and all
  631.    communication to the invalid address fails.  Even when applications
  632.    use UDP as a transport protocol, addresses must generally remain the
  633.    same during a packet exchange.
  634.  
  635.    Dividing valid addresses into preferred and deprecated categories
  636.    provides a way of indicating to upper layers that a valid address may
  637.    become invalid shortly and that future communication using the
  638.    address will fail, should the address's valid lifetime expire before
  639.    communication ends.  To avoid this scenario, higher layers should use
  640.    a preferred address (assuming one of sufficient scope exists) to
  641.    increase the likelihood that an address will remain valid for the
  642.    duration of the communication.  It is up to system administrators to
  643.    set appropriate prefix lifetimes in order to minimize the impact of
  644.    failed communication when renumbering takes place.  The deprecation
  645.    period should be long enough that most, if not all, communications
  646.    are using the new address at the time an address becomes invalid.
  647.  
  648.    The IP layer is expected to provide a means for upper layers
  649.    (including applications) to select the most appropriate source
  650.    address given a particular destination and possibly other
  651.    constraints.  An application may choose to select the source address
  652.    itself before starting a new communication or may leave the address
  653.    unspecified, in which case the upper networking layers will use the
  654.    mechanism provided by the IP layer to choose a suitable address on
  655.    the application's behalf.
  656.  
  657.    Detailed address selection rules are beyond the scope of this
  658.    document.
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667. draft-ietf-ipngwg-addrconf-v2-00.txt                           [Page 12]
  668.  
  669. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  670.  
  671.  
  672. 5.  PROTOCOL SPECIFICATION
  673.  
  674.    Autoconfiguration is performed on a per-interface basis on
  675.    multicast-capable interfaces.  For multihomed hosts,
  676.    autoconfiguration is performed independently on each interface.
  677.    Autoconfiguration applies primarily to hosts, with two exceptions.
  678.    Routers are expected to generate a link-local address using the
  679.    procedure outlined below. In addition, routers perform Duplicate
  680.    Address Detection on all addresses prior to assigning them to an
  681.    interface.
  682.  
  683.  
  684. 5.1.  Node Configuration Variables
  685.  
  686.    A node MUST allow the following autoconfiguration-related variable to
  687.    be configured by system management for each multicast interface:
  688.  
  689.         DupAddrDetectTransmits
  690.  
  691.                        The number of consecutive Neighbor Solicitation
  692.                        messages sent while performing Duplicate Address
  693.                        Detection on a tentative address. A value of zero
  694.                        indicates that Duplicate Address Detection is not
  695.                        performed on tentative addresses. A value of one
  696.                        indicates a single transmission with no follow up
  697.                        retransmissions.
  698.  
  699.                        Default: 1, but may be overridden by a link-type
  700.                        specific value in the document that covers issues
  701.                        related to the transmission of IP over a
  702.                        particular link type (e.g., [IPv6-ETHER]).
  703.  
  704.                        Autoconfiguration also assumes the presence of
  705.                        the variable RetransTimer as defined in
  706.                        [DISCOVERY]. For autoconfiguration purposes,
  707.                        RetransTimer specifies the delay between
  708.                        consecutive Neighbor Solicitation transmissions
  709.                        performed during Duplicate Address Detection (if
  710.                        DupAddrDetectTransmits is greater than 1), as
  711.                        well as the time a node waits  after sending the
  712.                        last Neighbor Solicitation before ending the
  713.                        Duplicate Address Detection process.
  714.  
  715.  
  716. 5.2.  Autoconfiguration-Related Variables
  717.  
  718.    A host maintains a number of data structures and flags related to
  719.    autoconfiguration. In the following, we present conceptual variables
  720.  
  721.  
  722.  
  723. draft-ietf-ipngwg-addrconf-v2-00.txt                           [Page 13]
  724.  
  725. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  726.  
  727.  
  728.    and show how they are used to perform autoconfiguration. The specific
  729.    variables are used for demonstration purposes only, and an
  730.    implementation is not required to have them, so long as its external
  731.    behavior is consistent with that described in this document.
  732.  
  733.    Beyond the formation of a link-local address and using Duplicate
  734.    Address Detection, how routers (auto)configure their interfaces is
  735.    beyond the scope of this document.
  736.  
  737.    Hosts maintain the following variables on a per-interface basis:
  738.  
  739.       ManagedFlag      Copied from the M flag field (i.e., the "managed
  740.                        address configuration" flag) of the most recently
  741.                        received Router Advertisement message. The flag
  742.                        indicates whether or not addresses are to be
  743.                        configured using the stateful autoconfiguration
  744.                        mechanism. It starts out in a FALSE state.
  745.  
  746.       OtherConfigFlag  Copied from the O flag field (i.e., the "other
  747.                        stateful configuration" flag) of the most
  748.                        recently received Router Advertisement message.
  749.                        The flag indicates whether or not information
  750.                        other than addresses are to be obtained using the
  751.                        stateful autoconfiguration mechanism. It starts
  752.                        out in a FALSE state.
  753.  
  754.    A host also maintains a list of addresses together with their
  755.    corresponding lifetimes. The address list contains both
  756.    autoconfigured addresses and those configured manually.
  757.  
  758.  
  759. 5.3.  Creation of Link-Local Addresses
  760.  
  761.    A node forms a link-local address whenever an interface becomes
  762.    enabled.  An interface may become enabled after any of the following
  763.    events:
  764.  
  765.       - The interface is initialized at system startup time.
  766.  
  767.       - The interface is reinitialized after a temporary interface
  768.         failure or after being temporarily disabled by system
  769.         management.
  770.  
  771.       - The interface attaches to a link for the first time.
  772.  
  773.       - The interface becomes enabled by system management after having
  774.         been administratively disabled.
  775.  
  776.  
  777.  
  778.  
  779. draft-ietf-ipngwg-addrconf-v2-00.txt                           [Page 14]
  780.  
  781. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  782.  
  783.  
  784.    A link-local address is formed by prepending the well-known link-
  785.    local prefix FE80::0 [ADDR-ARCH] (of appropriate length) to the
  786.    interface identifier. If the interface identifier has a length of N    |
  787.    bits, the interface identifier replaces the right-most N zero bits of  |
  788.    the link-local prefix.  If the interface identifier is more than 118   |
  789.    bits in length, autoconfiguration fails and manual configuration is
  790.    required.
  791.  
  792.    A link-local address has an infinite preferred and valid lifetime; it
  793.    is never timed out.
  794.  
  795.  
  796. 5.4.  Duplicate Address Detection
  797.  
  798.    Duplicate Address Detection is performed on unicast addresses prior    |
  799.    to assigning them to an interface whose DupAddrDetectTransmits         |
  800.    variable is greater than zero. Duplicate Address Detection MUST take   |
  801.    place on on all unicast addresses, regardless of whether they are
  802.    obtained through stateful, stateless or manual configuration, with     |
  803.    the exception of the following cases:                                  |
  804.       - Duplicate Address Detection MUST NOT be performed on anycast      |
  805.         addresses.                                                        |
  806.       - Each individual unicast address SHOULD be tested for uniqueness.  |
  807.         However, when stateless address autoconfiguration is used,        |
  808.         address uniqueness is determined solely by the interface          |
  809.         identifier, assuming that subnet prefixes are assigned correctly  |
  810.         (i.e., if all of an interface's addresses are generated from the  |
  811.         same identifier, either all addresses or none of them will be     |
  812.         duplicates). Thus, for a set of addresses formed from the same    |
  813.         interface identifier, it is sufficient to check that the link-    |
  814.         local address generated from the identifier is unique on the      |
  815.         link. In such cases, the link-local address MUST be tested for    |
  816.         uniqueness, and if no duplicate address is detected, an           |
  817.         implementation MAY choose to skip Duplicate Address Detection     |
  818.         for additional addresses derived from the same interface          |
  819.         identifier.                                                       |
  820.  
  821.    The procedure for detecting duplicate addresses uses Neighbor
  822.    Solicitation and Advertisement messages as described below. If a
  823.    duplicate address is discovered during the procedure, the address
  824.    cannot be assigned to the interface. If the address is derived from
  825.    an interface identifier, a new identifier will need to be assigned to  |
  826.    the interface, or all IP addresses for the interface will need to be
  827.    manually configured.  Note that the method for detecting duplicates
  828.    is not completely reliable, and it is possible that duplicate
  829.    addresses will still exist (e.g., if the link was partitioned while
  830.    Duplicate Address Detection was performed).
  831.  
  832.  
  833.  
  834.  
  835. draft-ietf-ipngwg-addrconf-v2-00.txt                           [Page 15]
  836.  
  837. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  838.  
  839.  
  840.    An address on which the duplicate Address Detection Procedure is
  841.    applied is said to be tentative until the procedure has completed
  842.    successfully.  A tentative address is not considered "assigned to an
  843.    interface" in the traditional sense. That is, the interface must
  844.    accept Neighbor Solicitation and Advertisement messages containing
  845.    the tentative address in the Target Address field, but processes such
  846.    packets differently from those whose Target Address matches an
  847.    address assigned to the interface. Other packets addressed to the
  848.    tentative address should be silently discarded.
  849.  
  850.    It should also be noted that Duplicate Address Detection must be
  851.    performed prior to assigning an address to an interface in order to
  852.    prevent multiple nodes from using the same address simultaneously.
  853.    If a node begins using an address in parallel with Duplicate Address
  854.    Detection, and another node is already using the address, the node
  855.    performing Duplicate Address Detection will erroneously process
  856.    traffic intended for the other node, resulting in such possible
  857.    negative consequences as the resetting of open TCP connections.
  858.  
  859.    The following subsections describe specific tests a node performs to
  860.    verify an address's uniqueness.  An address is considered unique if
  861.    none of the tests indicate the presence of a duplicate address within
  862.    RetransTimer milliseconds after having sent DupAddrDetectTransmits
  863.    Neighbor Solicitations. Once an address is determined to be unique,
  864.    it may be assigned to an interface.
  865.  
  866.  
  867. 5.4.1.  Message Validation
  868.  
  869.    A node MUST silently discard any Neighbor Solicitation or
  870.    Advertisement message that does not pass the validity checks
  871.    specified in [DISCOVERY]. A solicitation that passes these validity
  872.    checks is called a valid solicitation or valid advertisement.
  873.  
  874.  
  875. 5.4.2.  Sending Neighbor Solicitation Messages
  876.  
  877.    Before sending a Neighbor Solicitation, an interface MUST join the
  878.    all-nodes multicast address and the solicited-node multicast address
  879.    of the tentative address.  The former insures that the node receives
  880.    Neighbor Advertisements from other nodes already using the address;
  881.    the latter insures that two nodes attempting to use the same address
  882.    simultaneously detect each other's presence.
  883.  
  884.    To check an address, a node sends DupAddrDetectTransmits Neighbor
  885.    Solicitations, each separated by RetransTimer milliseconds. The
  886.    solicitation's Target Address is set to the address being checked,
  887.    the IP source is set to the unspecified address and the IP
  888.  
  889.  
  890.  
  891. draft-ietf-ipngwg-addrconf-v2-00.txt                           [Page 16]
  892.  
  893. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  894.  
  895.  
  896.    destination is set to the solicited-node multicast address of the
  897.    target address.
  898.  
  899.    If the Neighbor Solicitation is the first message to be sent from an
  900.    interface after interface (re)initialization, the node should delay
  901.    sending the message by a random delay between 0 and
  902.    MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY].  This serves
  903.    to alleviate congestion when many nodes start up on the link at the
  904.    same time, such as after a power failure, and may help to avoid race
  905.    conditions when more than one node is trying to solicit for the same
  906.    address at the same time. In order to improve the robustness of the
  907.    Duplicate Address Detection algorithm, an interface MUST receive and
  908.    process datagrams sent to the all-nodes multicast address or
  909.    solicited-node multicast address of the tentative address while
  910.    delaying transmission of the initial Neighbor Solicitation.
  911.  
  912.  
  913.  
  914.  
  915. 5.4.3.  Receiving Neighbor Solicitation Messages
  916.  
  917.    On receipt of a valid Neighbor Solicitation message on an interface,
  918.    node behavior depends on whether the target address is tentative or
  919.    not.  If the target address is not tentative (i.e., it is assigned to
  920.    the receiving interface), the solicitation is processed as described
  921.    in [DISCOVERY].  If the target address is tentative, and the source
  922.    address is a unicast address, the solicitation's sender is performing
  923.    address resolution on the target; the solicitation should be silently
  924.    ignored.  Otherwise, processing takes place as described below. In
  925.    all cases, a node MUST NOT respond to a Neighbor Solicitation for a
  926.    tentative address.
  927.  
  928.    If the source address of the Neighbor Solicitation is the unspecified
  929.    address, the solicitation is from a node performing Duplicate Address
  930.    Detection. If the solicitation is from another node, the tentative
  931.    address is a duplicate and should not be used (by either node). If
  932.    the solicitation is from the node itself (because the node loops back
  933.    multicast packets), the solicitation does not indicate the presence
  934.    of a duplicate address.
  935.  
  936.    Implementor's Note: many interfaces provide a way for upper layers to
  937.    selectively enable and disable the looping back of multicast packets.
  938.    The details of how such a facility is implemented may prevent
  939.    Duplicate Address Detection from working correctly.  See the Appendix
  940.    for further discussion.
  941.  
  942.    The following tests identify conditions under which a tentative
  943.    address is not unique:
  944.  
  945.  
  946.  
  947. draft-ietf-ipngwg-addrconf-v2-00.txt                           [Page 17]
  948.  
  949. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  950.  
  951.  
  952.       - If a Neighbor Solicitation for a tentative address is received
  953.         prior to having sent one, the tentative address is a duplicate.
  954.         This condition occurs when two nodes run Duplicate Address
  955.         Detection simultaneously, but transmit initial solicitations at
  956.         different times (e.g., by selecting different random delay
  957.         values before transmitting an initial solicitation).
  958.  
  959.       - If the actual number of Neighbor Solicitations received exceeds
  960.         the number expected based on the loopback semantics (e.g., the
  961.         interface does not loopback packet, yet one or more
  962.         solicitations was received), the tentative address is a
  963.         duplicate. This condition occurs when two nodes run Duplicate
  964.         Address Detection simultaneously and transmit solicitations at
  965.         roughly the same time.
  966.  
  967.  
  968. 5.4.4.  Receiving Neighbor Advertisement Messages
  969.  
  970.    On receipt of a valid Neighbor Advertisement message on an interface,
  971.    node behavior depends on whether the target address is tentative or
  972.    matches a unicast or anycast address assigned to the interface.  If
  973.    the target address is assigned to the receiving interface, the
  974.    solicitation is processed as described in [DISCOVERY]. If the target
  975.    address is tentative, the tentative address is not unique.
  976.  
  977.  
  978. 5.4.5.  When Duplicate Address Detection Fails
  979.  
  980.    A tentative address that is determined to be a duplicate as described
  981.    above, MUST NOT be assigned to an interface and the node SHOULD log a
  982.    system management error.  If the address is a link-local address       |
  983.    formed from an interface identifier, the interface SHOULD be           |
  984.    disabled.
  985.  
  986.  
  987. 5.5.  Creation of Global and Site-Local Addresses
  988.  
  989.    Global and site-local addresses are formed by appending an interface   |
  990.    identifier to a prefix of appropriate length. Prefixes are obtained    |
  991.    from Prefix Information options contained in Router Advertisements.
  992.    Creation of global and site-local addresses and configuration of
  993.    other parameters as described in this section SHOULD be locally
  994.    configurable. However, the processing described below MUST be enabled
  995.    by default.
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003. draft-ietf-ipngwg-addrconf-v2-00.txt                           [Page 18]
  1004.  
  1005. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  1006.  
  1007.  
  1008. 5.5.1.  Soliciting Router Advertisements
  1009.  
  1010.    Router Advertisements are sent periodically to the all-nodes
  1011.    multicast address. To obtain an advertisement quickly, a host sends
  1012.    out Router Solicitations as described in [DISCOVERY].
  1013.  
  1014.  
  1015. 5.5.2.  Absence of Router Advertisements
  1016.  
  1017.    If a link has no routers, a host MUST attempt to use stateful
  1018.    autoconfiguration to obtain addresses and other configuration
  1019.    information. An implementation MAY provide a way to disable the
  1020.    invocation of stateful autoconfiguration in this case, but the
  1021.    default SHOULD be enabled.  From the perspective of
  1022.    autoconfiguration, a link has no routers if no Router Advertisements
  1023.    are received after having sent a small number of Router Solicitations
  1024.    as described in [DISCOVERY].
  1025.  
  1026.  
  1027. 5.5.3.  Router Advertisement Processing
  1028.  
  1029.    On receipt of a valid Router Advertisement (as defined in
  1030.    [DISCOVERY]), a host copies the value of the advertisement's M bit
  1031.    into ManagedFlag. If the value of ManagedFlag changes from FALSE to
  1032.    TRUE, the host should invoke the stateful address autoconfiguration
  1033.    protocol, requesting address information.  If the value of the
  1034.    ManagedFlag changes from TRUE to FALSE, the host should terminate the
  1035.    stateful address autoconfiguration protocol (i.e., stop requesting
  1036.    addresses and ignore subsequent responses to in-progress
  1037.    transactions). If the value of the flag stays unchanged, no special
  1038.    action takes place. In particular, a host MUST NOT reinvoke stateful
  1039.    address configuration if it is already participating in the stateful
  1040.    protocol as a result of an earlier advertisement.
  1041.  
  1042.    An advertisement's O flag field is processed in an analogous manner.
  1043.    A host copies the value of the O flag into OtherConfigFlag. If the
  1044.    value of OtherConfigFlag changes from FALSE to TRUE, the host should
  1045.    invoke the stateful autoconfiguration protocol, requesting
  1046.    information (excluding addresses).  If the value of the
  1047.    OtherConfigFlag changes from TRUE to FALSE, any activity related to
  1048.    stateful autoconfiguration for parameters other than addresses should
  1049.    be halted. If the value of the flag stays unchanged, no special
  1050.    action takes place. In particular, a host MUST NOT reinvoke stateful
  1051.    configuration if it is already participating in the stateful protocol
  1052.    as a result of an earlier advertisement.
  1053.  
  1054.    For each Prefix-Information option in the Router Advertisement:
  1055.  
  1056.  
  1057.  
  1058.  
  1059. draft-ietf-ipngwg-addrconf-v2-00.txt                           [Page 19]
  1060.  
  1061. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  1062.  
  1063.  
  1064.     a) If the Autonomous flag is not set, silently ignore the Prefix
  1065.        Information option.
  1066.  
  1067.     b) If the prefix is the link-local prefix, silently ignore the
  1068.        Prefix Information option.
  1069.  
  1070.     c) If the preferred lifetime is greater than the valid lifetime,
  1071.        silently ignore the Prefix Information option. A node MAY wish to
  1072.        log a system management error in this case.
  1073.  
  1074.     d) If the prefix advertised matches the prefix of an autoconfigured   |
  1075.        address (i.e., one obtained previously via stateless or stateful   |
  1076.        autoconfiguration) in the list of addresses associated with the    |
  1077.        interface, and the valid lifetime in the received RA is both less  |
  1078.        than 2 hours and less than the remaining valid Lifetime in the     |
  1079.        cached entry, ignore the Prefix Information option for the         |
  1080.        purpose of stateless address autoconfiguration.                    |
  1081.  
  1082.     f) If the prefix advertised matches the prefix of an autoconfigured   |
  1083.        address (i.e., one obtained previously via stateless or stateful   |
  1084.        autoconfiguration) in the list of addresses associated with the    |
  1085.        interface, and the preferred lifetime in the received RA is both   |
  1086.        less than 2 hours and less than the remaining preferred Lifetime   |
  1087.        in the cached entry, ignore the Prefix Information option for the  |
  1088.        purpose of stateless address autoconfiguration.                    |
  1089.  
  1090.     g) If the advertised prefix matches the prefix of an autoconfigured
  1091.        address (i.e., obtained via stateless or stateful address
  1092.        autoconfiguration) in the list of addresses associated with the
  1093.        interface, set the preferred timer to that of the option's
  1094.        preferred lifetime, and set the valid lifetime to that of the
  1095.        option's valid lifetime.
  1096.  
  1097.     h) If the prefix advertised does not match the prefix of an address   |
  1098.        already in the list, then form an address (and add it to the
  1099.        list) by appending the interface identifier to the prefix as       |
  1100.        follows:
  1101.  
  1102.        |            128 - N bits               |       N bits           |
  1103.        +---------------------------------------+------------------------+
  1104.        |            link prefix                |  interface identifier  | |
  1105.        +----------------------------------------------------------------+
  1106.  
  1107.  
  1108.        If the sum of the prefix length and interface identifier length    |
  1109.        does not equal 128 bits, the Prefix Information option MUST be
  1110.        ignored. An implementation MAY wish to log a system management
  1111.        error in this case. It is the responsibility of the system
  1112.  
  1113.  
  1114.  
  1115. draft-ietf-ipngwg-addrconf-v2-00.txt                           [Page 20]
  1116.  
  1117. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  1118.  
  1119.  
  1120.        administrator to insure that the lengths of prefixes contained in
  1121.        Router Advertisements are consistent with the length of interface  |
  1122.        identifiers for that link type.
  1123.  
  1124.        In those cases where a site requires the use of longer prefixes
  1125.        than can be accommodated by the interface identifier, stateful     |
  1126.        autoconfiguration can be used.                                     |
  1127.  
  1128.        If an address is formed successfully, the host adds it to the
  1129.        list of addresses assigned to the interface, initializing its
  1130.        preferred and valid lifetime values from the Prefix Information
  1131.        option.
  1132.  
  1133.  
  1134. 5.5.4.  Address Lifetime Expiry
  1135.  
  1136.    A preferred address becomes deprecated when its preferred lifetime
  1137.    expires.  A deprecated address SHOULD continue to be used as a source
  1138.    address in existing communications, but SHOULD NOT be used in new
  1139.    communications if an alternate (non-deprecated) address is available   |
  1140.    and has sufficient scope.  IP and higher layers (e.g., TCP, UDP) MUST  |
  1141.    continue to accept datagrams destined to a deprecated address since a
  1142.    deprecated address is still a valid address for the interface. An
  1143.    implementation MAY prevent any new communication from using a
  1144.    deprecated address, but system management MUST have the ability to     |
  1145.    disable such a facility, and the facility MUST be disabled by          |
  1146.    default.
  1147.  
  1148.    An address (and its association with an interface) becomes invalid
  1149.    when its valid lifetime expires.  An invalid address MUST NOT be used
  1150.    as a source address in outgoing communications and MUST NOT be
  1151.    recognized as a destination on a receiving interface.
  1152.  
  1153.    Note that if a Prefix Information option is received with a preferred
  1154.    lifetime of zero, any addresses generated from that prefix are
  1155.    immediately deprecated. Similarly, if both the advertised deprecated
  1156.    and valid lifetimes are zero, any addresses generated from that
  1157.    prefix become invalid immediately.
  1158.  
  1159.  
  1160. 5.6.  Configuration Consistency
  1161.  
  1162.    It is possible for hosts to obtain address information using both
  1163.    stateless and stateful protocols since both may be enabled at the
  1164.    same time.  It is also possible that the values of other
  1165.    configuration parameters such as MTU size and hop limit will be
  1166.    learned from both Router Advertisements and the stateful
  1167.    autoconfiguration protocol.  If the same configuration information is
  1168.  
  1169.  
  1170.  
  1171. draft-ietf-ipngwg-addrconf-v2-00.txt                           [Page 21]
  1172.  
  1173. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  1174.  
  1175.  
  1176.    provided by multiple sources, the value of this information should be
  1177.    consistent. However, it is not considered a fatal error if
  1178.    information received from multiple sources is inconsistent. Hosts
  1179.    accept the union of all information received via the stateless and
  1180.    stateful protocols. If inconsistent information is learned from
  1181.    different sources, the most recently obtained values always have
  1182.    precedence over information learned earlier.
  1183.  
  1184.  
  1185. 6.  SECURITY CONSIDERATIONS
  1186.  
  1187.    Stateless address autoconfiguration allows a host to connect to a
  1188.    network, configure an address and start communicating with other
  1189.    nodes without ever registering or authenticating itself with the
  1190.    local site. Although this allows unauthorized users to connect to and
  1191.    use a network, the threat is inherently present in the Internet
  1192.    architecture. Any node with a physical attachment to a network can
  1193.    generate an address (using a variety of ad hoc techniques) that
  1194.    provides connectivity.
  1195.  
  1196.    The use of Duplicate Address Detection opens up the possibility of
  1197.    denial of service attacks. Any node can respond to Neighbor
  1198.    Solicitations for a tentative address, causing the other node to
  1199.    reject the address as a duplicate. This attack is similar to other
  1200.    attacks involving the spoofing of Neighbor Discovery messages and can
  1201.    be addressed by requiring that Neighbor Discovery packets be
  1202.    authenticated [RFC1826].
  1203.  
  1204.  
  1205. 7.  References
  1206.  
  1207.  
  1208.    [RFC1826] R. Atkinson.  "IP Authentication Header", RFC 1826, August   |
  1209.              1995.
  1210.  
  1211.    [IPv6-ETHER] M. Crawford. "A Method for the Transmission of IPv6
  1212.              Packets over Ethernet Networks", Internet Draft.
  1213.  
  1214.    [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate          |
  1215.              Requirement Levels", RFC 2119, March 1997.                   |
  1216.  
  1217.    [RFC1112] S. Deering, "Host Extensions for IP Multicasting", RFC
  1218.              1112, August, 1989.
  1219.  
  1220.    [ADDR-ARCH] Hinden, R., and S. Deering, "Internet Protocol Version     |
  1221.              (IPv6) Addressing Architecture", RFC 1884, December 1995.
  1222.  
  1223.    [DHCPv6] Internet Draft, Work in Progress.
  1224.  
  1225.  
  1226.  
  1227. draft-ietf-ipngwg-addrconf-v2-00.txt                           [Page 22]
  1228.  
  1229. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  1230.  
  1231.  
  1232.    [DISCOVERY] Narten, T., Nordmark, E., and W. Simpson, "Neighbor        |
  1233.              Discovery for IP Version 6 (IPv6)", RFC 1970, August 1996.   |
  1234.  
  1235.  
  1236. 8.  Acknowledgements
  1237.  
  1238.    The authors would like to thank the members of both the IPNG and       |
  1239.    ADDRCONF working groups for their input. In particular, thanks to Jim  |
  1240.    Bound, Steve Deering, and Erik Nordmark. In addition, thanks goes to   |
  1241.    John Gilmore for alerting the WG of the "0 Lifetime Prefix             |
  1242.    Advertisement" denial of service attack vulnerability; this document   |
  1243.    incorporates changes that address this vulnerability.
  1244.  
  1245.    AUTHORS' ADDRESSES
  1246.  
  1247.    Susan Thomson                    Thomas Narten
  1248.    Bellcore                         IBM Corporation
  1249.    445 South Street                 P.O. Box 12195
  1250.    Morristown, NJ 07960             Research Triangle Park, NC 27709-2195
  1251.    USA                              USA
  1252.  
  1253.    phone: +1 201-829-4514           phone: +1 919 254 7798
  1254.    email: set@thumper.bellcore.com  email: narten@raleigh.ibm.com         |
  1255.  
  1256.  
  1257.  
  1258. 9.  APPENDIX A: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION        |
  1259.  
  1260.    Determining whether a received multicast solicitation was looped back
  1261.    to the sender or actually came from another node is implementation-
  1262.    dependent.  A problematic case occurs when two interfaces attached to
  1263.    the same link happen to have the same identifier and link-layer        |
  1264.    address, and they both send out packets with identical contents at
  1265.    roughly the same time (e.g., Neighbor Solicitations for a tentative
  1266.    address as part of Duplicate Address Detection messages). Although a
  1267.    receiver will receive both packets, it cannot determine which packet
  1268.    was looped back and which packet came from the other node by simply
  1269.    comparing packet contents (i.e., the contents are identical). In this
  1270.    particular case, it is not necessary to know precisely which packet
  1271.    was looped back and which was sent by another node; if one receives
  1272.    more solicitations than were sent, the tentative address is a
  1273.    duplicate. However, the situation may not always be this
  1274.    straightforward.
  1275.  
  1276.    The IPv4 multicast specification [RFC1112] recommends that the
  1277.    service interface provide a way for an upper-layer protocol to
  1278.    inhibit local delivery of packets sent to a multicast group that the
  1279.    sending host is a member of. Some applications know that there will
  1280.  
  1281.  
  1282.  
  1283. draft-ietf-ipngwg-addrconf-v2-00.txt                           [Page 23]
  1284.  
  1285. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  1286.  
  1287.  
  1288.    be no other group members on the same host, and suppressing loopback
  1289.    prevents them from having to receive (and discard) the packets they
  1290.    themselves send out.  A straightforward way to implement this
  1291.    facility is to disable loopback at the hardware level (if supported
  1292.    by the hardware), with packets looped back (if requested) by
  1293.    software.  On interfaces in which the hardware itself suppresses
  1294.    loopbacks, a node running Duplicate Address Detection simply counts
  1295.    the number of Neighbor Solicitations received for a tentative address
  1296.    and compares them with the number expected. If there is a mismatch,
  1297.    the tentative address is a duplicate.
  1298.  
  1299.    In those cases where the hardware cannot suppress loopbacks, however,
  1300.    one possible software heuristic to filter out unwanted loopbacks is
  1301.    to discard any received packet whose link-layer source address is the
  1302.    same as the receiving interface's.  Unfortunately, use of that
  1303.    criteria also results in the discarding of all packets sent by
  1304.    another node using the same link-layer address. Duplicate Address
  1305.    Detection will fail on interfaces that filter received packets in
  1306.    this manner:
  1307.  
  1308.       o If a node performing Duplicate Address Detection discards
  1309.         received packets having the same source link-layer address as
  1310.         the receiving interface, it will also discard packets from other
  1311.         nodes also using the same link-layer address, including Neighbor
  1312.         Advertisement and Neighbor Solicitation messages required to
  1313.         make Duplicate Address Detection work correctly.  This
  1314.         particular problem can be avoided by temporarily disabling the
  1315.         software suppression of loopbacks while a node performs
  1316.         Duplicate Address Detection.
  1317.  
  1318.       o If a node that is already using a particular IP address discards
  1319.         received packets having the same link-layer source address as
  1320.         the interface, it will also discard Duplicate Address
  1321.         Detection-related Neighbor Solicitation messages sent by another
  1322.         node also using the same link-layer address.  Consequently,
  1323.         Duplicate Address Detection will fail, and the other node will
  1324.         configure a non-unique address. Since it is generally impossible
  1325.         to know when another node is performing Duplicate Address
  1326.         Detection, this scenario can be avoided only if software
  1327.         suppression of loopback is permanently disabled.
  1328.  
  1329.    Thus, to perform Duplicate Address Detection correctly in the case
  1330.    where two interfaces are using the same link-layer address, an
  1331.    implementation must have a good understanding of the interface's
  1332.    multicast loopback semantics, and the interface cannot discard
  1333.    received packets simply because the source link-layer address is the
  1334.    same as the interfaces.                                                |
  1335.  
  1336.  
  1337.  
  1338.  
  1339. draft-ietf-ipngwg-addrconf-v2-00.txt                           [Page 24]
  1340.  
  1341. INTERNET-DRAFT  IPv6 Stateless Address Autoconfiguration       July 1997
  1342.  
  1343.  
  1344. 10.  APPENDIX B: CHANGES SINCE RFC 1971                                   |
  1345.  
  1346.    The following changes, which are also marked with change bars ('|' or  |
  1347.    '*') in the right margin, have been made since RFC 1970:               |
  1348.  
  1349.     o Changed document to use term "interface identifer" rather than      |
  1350.       "interface token" for consistency with other IPv6 documents.        |
  1351.  
  1352.     o Clarified definition of deprecated address to make clear it is OK   |
  1353.       to continue sending to or from deprecated addresses.                |
  1354.  
  1355.     o Reworded section 5.4 for clarity (no substantive change).           |
  1356.  
  1357.     o Added rules to Section 5.5.3 Router Advertisement processing to     |
  1358.       address potential denial-of-service attack when prefixes are        |
  1359.       advertised with very short Lifetimes.                               |
  1360.  
  1361.     o Clarified wording in Section 5.5.4 to make clear that all upper     |
  1362.       layer protocols must process (i.e., send and receive) packets sent  |
  1363.       to deprecated addresses.                                            |
  1364.  
  1365.  
  1366.  
  1367.  
  1368.  
  1369.  
  1370.  
  1371.  
  1372.  
  1373.  
  1374.  
  1375.  
  1376.  
  1377.  
  1378.  
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.  
  1391.  
  1392.  
  1393.  
  1394.  
  1395. draft-ietf-ipngwg-addrconf-v2-00.txt                           [Page 25]
  1396.  
  1397.