--- E:/Documents/ipso/ietf/draft-ietf-6lowpan-nd-12.txt	Thu Aug 26 12:33:59 2010
+++ E:/Documents/ipso/ietf/draft-ietf-6lowpan-nd-co.txt	Thu Aug 26 12:29:56 2010
@@ -7,15 +7,15 @@
 Intended status: Standards Track                             IP Infusion
 Expires: February 4, 2011                                    E. Nordmark
                                                             Oracle, Inc.
                                                           August 3, 2010
 
 
     Neighbor Discovery Optimization for Low-power and Lossy Networks
-                        draft-ietf-6lowpan-nd-12
+                        draft-ietf-6lowpan-nd-CO
 
 Abstract
 
    The IETF 6LoWPAN working group defines IPv6 for low-power and lossy
    networks (LLNs) such as IEEE 802.15.4.  This and other similar link
    technologies have limited or no usage of multicast signaling due to
    energy conservation.  In addition, the wireless network may not
@@ -713,16 +713,15 @@
    hop-limit=255 check.
 
 3.5.  Neighbor Cache Management
 
    The use of explicit registrations with lifetimes plus the desire to
    not multicast Neighbor Solicitation messages for hosts imply that we
    manage the Neighbor Cache entries slightly differently than in
-   [RFC4861].  This results in three different types of NCEs and the
-   types specify how those entries can be removed:
+   [RFC4861].
 
 
 
 
 
 Shelby, et al.          Expires February 4, 2011               [Page 13]
 
@@ -733,35 +732,19 @@
                          [RFC4861] that allow for garbage collection
                          when low on memory.
 
    Registered:           Entries that have an explicit registered
                          lifetime and are kept until this lifetime
                          expires or they are explicitly unregistered.
 
-   Tentative:            Entries that are temporary with a short
-                         lifetime, which typically get converted to
-                         Registered entries.
-
-   Note that the type of the NCE is orthogonal to the states specified
-   in [RFC4861].
-
-   When a host interacts with a router by sending Router Solicitations
-   this results in a Tentative NCE.  Once a node successfully registers
-   with a Router the result is a Registered NCE.  As Routers send RAs to
-   hosts, and when routers optionally receive RA messages or receive
-   multicast NS messages from other Routers the result is Garbage-
-   collectible NCEs.
 
    Neighbor Cache entries on Routers can additionally be added or
    deleted by a routing protocol used in the 6LoWPAN.  This is useful if
    the routing protocol carries the link-layer addresses of the
-   neighboring routers.  Depending on the details of such routing
-   protocols such NCEs could be either Registered or Garbage-
-   collectible.
-
+   neighboring routers.  
 
 4.  New Neighbor Discovery Options
 
    This section defines new Neighbor Discovery message options used by
    this specification.  The Address Registration Option is mandatory,
    whereas the Authoritative Border Router Option and 6LoWPAN Context
    Option are optional.
@@ -786,76 +769,73 @@
 
 
    same option is included in corresponding Neighbor Advertisement (NA)
    messages with a Status field indicating the success or failure of the
    registration.  This option is always host initiated.
 
    The ARO is reused for the optional multihop Duplicate Address
-   Detection from 6LRs to 6LBRs, in which case it has a different
+   Detection from 6LRs to 6LBRs, in which case it may have a different
    Length.  In that case one or more AROs can be included in an NS.
 
    The ARO is required for reliability and power saving.  The lifetime
    field provides flexibility to the host to register an address which
    should be usable (continue to be advertised by the 6LR in the routing
    protocol etc.) during its intended sleep schedule.
 
    The sender of the NS also includes the EUI-64 of the interface it is
    registering an address from.  This is used as a unique ID for the
    detection of duplicate addresses.  It is used to tell the difference
    between the same node re-registering its address and a different node
    (with a different EUI-64) registering an address that is already in
-   use by someone else.
-
-   When the ARO is used by hosts an SLLA option MUST be included and the
-   address that is registered MUST be the IPv6 source address for the
-   Neighbor Solicitation message.  Thus the Registered Address field is
-   omitted and the Length field MUST be two.  When the ARO is used for
-   the optional multihop DAD between a 6LR and a 6LBR then there is no
-   SLLA option, the Registered Address field is included and the Length
-   field MUST be four.
-
+   use by someone else.   
+   
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |     Type      |    Length     |    Status     |   Reserved    |
+   |     Type      |    Length     |    Status     |   LLALength   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Reserved            |     Registration Lifetime     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                            EUI-64                             +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
-   +                 Registered Address (Optional)                 +
+   +                 Registered Address                            +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
+   |                                                               |
+   +                 Tenative Link-Layer Address                   +
+   |                                                               |  
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
 
 Shelby, et al.          Expires February 4, 2011               [Page 15]
 
 Internet-Draft          ND Optimization for LLNs             August 2010
 
 
    Fields:
 
    Type:          TBD1
 
    Length:        8-bit unsigned integer.  The length of the option in
-                  units of 8 octets. 2 without or 4 with the Registered
-                  Address.
+                  units of 8 octets. 4 without any link-layer address.
 
    Status:        8-bit unsigned integer.  Indicates the status of a
                   registration in the NA response.  MUST be set to 0 in
                   NS messages.  See below.
+			
+   LLALength:     8-bit unsigned integer. Number of bytes of the 
+                  link-layer address that is valid.
 
    Reserved:      This field is unused.  It MUST be initialized to zero
                   by the sender and MUST be ignored by the receiver.
 
    Registration Lifetime:  16-bit unsigned integer.  The amount of time
                   in a unit of 10 seconds that the router should retain
                   the Neighbor Cache entry for the sender of the NS that
@@ -866,14 +846,22 @@
 
    Registered Address:  128-bit optional field.  MUST NOT be sent by a
                   host.  Used for the optional router-router
                   registrations on behalf of a host.  Carries the host
                   address, which was contained in the IPv6 Source field
                   in the original NS that contained the option sent by
                   the host.
+			
+   Tenative Link-Layer Address: Variable length but must be multiple of 8 bytes.
+				  Only the first LLALength bytes are valid, any remaining
+				  bytes MUST be initilized to zero by the sender and
+				  MUST be ignored by the receiver. If the address
+				  registration succeeds, this will be the corresponding
+				  link-layer address associated with the registered
+				  IPv6 address. Used to update the neighbour cache.
 
    The Status values used in Neighbor Advertisements are:
 
           +--------+--------------------------------------------+
           | Status |                 Description                |
           +--------+--------------------------------------------+
           |    0   |                   Success                  |
@@ -1207,25 +1195,30 @@
    The host triggers sending Neighbor Solicitation (NS) messages
    containing an ARO when a new address is configured, when it discovers
    a new default router, or well before the Registration Lifetime
    expires.  Such an NS MUST include a Source Link-Layer Address (SLLA)
    option, since the router needs to record the link-layer address of
    the host.  An unspecified source address MUST NOT be used in NS
    messages.
+   
+   The NS used by hosts for address registration purposes MUST use
+   the link-local address which is based on the EUI-64 contained in
+   the ARO as the source. This address is formed according to section
+   7 of [RFC4944].
+   
 
 5.5.2.  Processing a Neighbor Advertisement
 
    A host handles Neighbor Advertisement messages as specified in
    [RFC4861], with added logic described in this section for handling
    the Address Registration option.
 
    In addition to the normal validation of a Neighbor Advertisement and
    its options, the Address Registration option is verified as follows
-   (if present).  If the Length field is not two, the option is silently
-   ignored.  If the EUI-64 field does not match the EUI-64 of the
+   (if present). If the EUI-64 field does not match the EUI-64 of the
    interface, the option is silently ignored.
 
    If the status field is zero, then the address registration was
 
 
 
 Shelby, et al.          Expires February 4, 2011               [Page 22]
@@ -1355,15 +1348,15 @@
 6.  Router Behavior for 6LR and 6LBR
 
    Both 6LRs and 6LBRs maintain the Neighbor Cache [RFC4861] based on
    the Address Registration Options they receive in Neighbor
    Advertisement messages from hosts, Neighbor Discovery packets from
    other nodes, and potentially a routing protocol used in the 6LoWPAN
    as outlined in Section 3.5.  Note that the handling of ARO from other
-   routers (with Length=4) is specified in Section 8.
+   routers is specified in Section 8.
 
    The routers SHOULD NOT garbage collect Registered Neighbor Cache
    entries (see Section 3.4) since they need to retain them until the
    Registration Lifetime expires.  Similarly, if Neighbor Unreachability
    Detection on the router determines that the a host is UNREACHABLE
    (based on the logic in [RFC4861]), the Neighbor Cache entry SHOULD
    NOT be deleted but be retained until the Registration Lifetime
@@ -1419,23 +1412,15 @@
    information or different, from different 6LBR, then it will need to
    keep those prefixes and context information separately so that the
    RAs the 6LR sends will maintain the association between the ABRO and
    the prefixes and context information.  The router can tell which 6LBR
    originated the prefixes and context information from the 6LBR Address
    field in the ABRO.  When a router has information tied to multiple
    ABROs, a single RS will result in multiple RAs each containing a
-   different ABRO.
-
-   A Router Solicitation might be received from a host that has not yet
-   registered its address with the router.  Thus the router MUST NOT
-   modify an existing Neighbor Cache entry based on the SLLA option from
-   the Router Solicitation.  However, a router MAY create a Tentative
-   Neighbor Cache entry based on the SLLA option.  Such a Tentative
-   Neighbor Cache entry SHOULD be timed out in TENTATIVE_NCE_LIFETIME
-   seconds unless a registration converts it into a Registered NCE.
+   different ABRO. 
 
    A 6LR or 6LBR MUST include a Source Link-layer address option in the
    Router Advertisements it sends.  That is required so that the hosts
    will know the link-layer address of the router.  Unlike in [RFC4861],
    the maximum value of the RA Router Lifetime field MAY be up to 0xFFFF
    (18 hours).
 
@@ -1467,48 +1452,46 @@
 
    A router handles Neighbor Solicitation messages as specified in
    [RFC4861], with added logic described in this section for handling
    the Address Registration option.
 
    In addition to the normal validation of a Neighbor Solicitation and
    its options, the Address Registration option is verified as follows
-   (if present).  If the Length field is not two, or if the Status field
-   is not zero, then the Neighbor Solicitation is silently ignored.
-   Note that Section 8.2 specify optional behavior for a 6LBR for other
-   Length field values.
+   (if present).  If the Status field is not zero, then the Neighbor
+   Solicitation is silently ignored. Note that Section 8.2 specifies
+   optional behavior for a 6LBR.
 
    If the source address of the NS is the unspecified address, or if no
    SLLA option is included, then any included ARO is ignored, that is,
    the NS is processed as if it did not contain an ARO.
 
 6.5.1.  Checking for Duplicates
 
    If the NS contains a valid ARO, then the router inspects its Neighbor
-   Cache on the arriving interface to see if it is a duplicate.  If
-   there is no Neighbor Cache entry for the IPv6 source address of the
-   NS, then it isn't a duplicate.  If there is such a Neighbor Cache
-   entry and the EUI-64 is the same, then it isn't a duplicate either.
-   Otherwise it is a duplicate address.  Note that if multihop DAD
-   (Section 8.2) is used then the checks are slightly different to take
-   into account Tentative Neighbor Cache entries.
+   Cache on the arriving interface to see if it is a duplicate. If there
+   is no Neighbor Cache entry for the IPv6 registered address in the ARO,
+   then it isn't a duplicate. If there is an entry that matches, but the
+   EUI-64 also matches, then it isn't a duplicate either. 
 
    In the case it is a duplicate address then the router responds with a
    unicast Neighbor Advertisement (NA) message sent to the source link-
    layer address (from the Source Link-Layer Address (SLLA) option) of
    the NS.  The NA is formatted with a copy of the ARO from the NS, but
    with the Status field set to one to indicate it was a duplicate.  In
    this case there is no modification to the Neighbor Cache.
 
 6.5.2.  Updating the Neighbor Cache
 
    If ARO did not result in a duplicate address being detected as above,
    then if the Registration Lifetime is non-zero the router creates (if
    it didn't exist) or updates (otherwise) a Neighbor Cache entry for
-   the IPv6 source address of the NS.  If the Neighbor Cache is full and
-   a new entry needs to be created, then the router responds with a
+   the IPv6 registered address in the ARO.  This Neighbor Cache entry
+   uses the tenative link-layer address field in the ARO as the
+   link-layer address for the Neighbor Cache entry.  If the Neighbor Cache
+   is full and a new entry needs to be created, then the router responds with a
 
 
 
 Shelby, et al.          Expires February 4, 2011               [Page 27]
 
 Internet-Draft          ND Optimization for LLNs             August 2010
 
@@ -1531,18 +1514,14 @@
 
    Should the Registration Lifetime in a Neighbor Cache entry expire,
    then the router MUST delete the cache entry.
 
    The addition and removal of Registered Neighbor Cache entries would
    result in notifying the routing protocol.
 
-   Note: If the optional multihop DAD (Section 8.2) is used, then the
-   updating of the Neighbor Cache is slightly different due to Tentative
-   NCEs.
-
 6.5.3.  Address Resolution between Routers
 
    There needs to be a mechanism somewhere for the routers to discover
    each other's link-layer addresses.  If the routing protocol used
    between the routers provides this, then there is no need for the
    routers to use the Address Registration option between each other.
    Otherwise, the routers MAY use the ARO.  When routers use ARO to
@@ -1856,63 +1835,40 @@
    multihop DAD needs to be repeated against the 6LBRs to ensure that
    the entry for the address in the 6LBRs does not time out, but that
    can be done asynchronously with the response to the hosts.  For
    instance, by tracking how much is left of the lifetime the 6LR
    registered with the 6LBRs and re-registering with the 6LBR when this
    lifetime is about to run out.
 
-   For the synchronous multihop DAD the 6LR performs some additional
-   checks to ensure that it has a Neighbor Cache entry it can use to
-   respond to the host when it receives a response from a 6LBR.  This
-   consists of checking for an already existing (Tentative or
-   Registered) Neighbor Cache entry for the registered address with a
-   different EUI-64.  If such a Registered NCE exists, then the 6LR
-   SHOULD respond that the address is a duplicate.  If such a Tentative
-   NCE exists, then the 6LR SHOULD silently ignore the ARO thereby
-   relying on the host retransmitting the ARO.  (This is needed to
-   handle the case when multiple hosts try to register the same IPv6
-   address at the same time.)  If no Neighbor Cache entry exists, then
-   the 6LR MUST create a Tentative Neighbor Cache entry with the EUI-64
-   and the SLLAO.  This entry will be used to send the response to the
-   host when the 6LBR responds.
-
    When a 6LR receives a Neighbor Solicitation containing an Address
    Registration option with a non-zero Registration Lifetime and it has
    no existing Registered Neighbor Cache entry, then with this mechanism
    the 6LR will invoke synchronous multihop DAD.
 
    The 6LR will unicast a new Neighbor Solicitation message to one or
-   more 6LBRs, where the NS contains an ARO with the host's address in
-   the Registered Address field.  This NS will be forwarded by 6LRs
-   until it reaches the 6LBR, hence its IPv6 hop limit field might be
-   less than 255 when received by the 6LBR.  The 6LBR will respond with
-   a Neighbor Advertisement message containing an ARO, which might have
-   a hop limit less than 255 when it reaches the 6LR.
+   more 6LBRs, where the NS contains a copy of the ARO from the host.
+   This NS will be forwarded by 6LRs until it reaches the 6LBR, hence
+   its IPv6 hop limit field might be less than 255 when received by
+   the 6LBR.  The 6LBR will respond with a Neighbor Advertisement
+   message containing an ARO, which might have a hop limit less than
+   255 when it reaches the 6LR.
 
    When the 6LR receives the NA from the 6LBR containing a ARO, it will
-   look for a matching (same IP address and EUI-64) (Tentative or
-   Registered) Neighbor Cache entry.  If no such entry is found then the
-   ARO is silently ignored.  If an entry is found and the ARO had
-   Status=0 then the 6LR will mark the Tentative Neighbor Cache entry as
-   Registered.  In all cases when an entry is found then the 6LR will
-   respond to the host with an NA, copying the Status field from the ARO
-   it received from the 6LBR.
-
-
+   form an IPv6 address based in the EUI-64 in the ARO and the link-local
+   prefix, as specified in section 7 of [RFC4944]. It will then send a 
+   NA to this IPv6 address, with a copy of the ARO received from the 6LBR.
+   
+   If the ARO had a Status=0, the 6LR will additionally put a new entry
+   in it's Neighbor Cache as per section 6.5.2.
 
 
 Shelby, et al.          Expires February 4, 2011               [Page 34]
 
 Internet-Draft          ND Optimization for LLNs             August 2010
 
-
-   A Tentative Neighbor Cache entry SHOULD be timed out
-   TENTATIVE_NCE_LIFETIME seconds after it was created in order to allow
-   for another host to attempt to register the IPv6 address.
-
 8.2.1.  Special Message Validation
 
    Due to the forwarding of the above special NS/NA between the 6LR and
    6LBR the hop limit check on receipt MUST be bypassed for such
    messages that contain a ARO with a Length field of 4.  The receipt of
    such messages MUST NOT modify any state on the router with the
    exception of the DAD table below.
@@ -1924,56 +1880,48 @@
    structure the DAD table.  It is indexed by the IPv6 address - the
    Registered Address in the ARO - and contains the EUI-64 of the host
    that is using that address.
 
 8.2.3.  6LR Sending a special Neighbor Solicitation
 
    When a 6LR that implements the optional multihop DAD receives an NS
-   from a host (the ARO has Length = 2) and subject to the above checks,
-   the 6LR forms and sends an NS to at least one 6LBR.  The NS contains
-   the following information:
+   from a host and subject to the above checks, the 6LR forms and sends
+   an NS to at least one 6LBR.  The NS contains the following information:
 
    o  In the IPv6 source address, a global address of the 6LR.
 
    o  In the IPv6 destination address, the address of the 6LBR.
 
    o  In the IPv6 hop limit, 255 or a smaller number.
 
    o  In the NS Target Address, the address of the 6LBR.
 
    o  In the ARO the Status field MUST be set to zero
 
-   o  In the ARO the EUI-64 and Registration lifetime are copied from
+   o  In the ARO the EUI-64, Registration lifetime, Registered Address,
+      LLALen, and Tenative Link-Layer Address are copied from
       the ARO received from the host.
 
-   o  In the ARO and the Registered Address set to the IPv6 address of
-      the host, that is, the sender of the triggering NS.
-
    When a 6LR receives an NS from a host with a zero Registration
    Lifetime then, in addition to removing the Neighbor Cache entry for
    the host as specified in section Section 6, an NS is sent to the
    6LBRs as above.
 
 
 
 
 Shelby, et al.          Expires February 4, 2011               [Page 35]
 
 Internet-Draft          ND Optimization for LLNs             August 2010
 
-
-   A router MUST NOT modify the Neighbor Cache as a result of receiving
-   a Neighbor Solicitation with an ARO of Length=4.
-
 8.2.4.  6LBR Receiving a special Neighbor Solicitation
 
    When a 6LBR that implements the optional multihop DAD receives an NS
-   from a 6LR, that is an NS that contains an ARO with Length = 4, then
-   it MUST NOT verify that the hop limit is 255 as specified above.
-   Then it proceeds to look for the Registration Address in the DAD
+   from a 6LR, then it MUST NOT verify that the hop limit is 255 as
+   specified above.  Then it proceeds to look for the Registration Address in the DAD
    Table.  If an entry is found and the recorded EUI-64 is different
    than the EUI-64 in the ARO, then it returns an NA with the ARO Status
    set to 1 ('Duplicate Address').  Otherwise it returns an NA with ARO
    Status set to zero.
 
    If no entry is found in the DAD Table and the Registration Lifetime
    is non-zero, then an entry is created and the EUI-64 and Registered
@@ -1986,35 +1934,18 @@
    In both of the above cases the ARO Status code is set to zero, and
    the 6LBR forms an NA with the ARO copied from the NS to the NA.  The
    NA is sent back to the 6LR i.e., back to the source of the NS.
 
 8.2.5.  Processing a special Neighbor Advertisement
 
    When a 6LR that implements the optional multihop DAD receives an NA
-   from a 6LBR, that is an NS that contains an ARO with Length = 4, then
-   it MUST NOT verify that the hop limit is 255 as specified above.  If
-   there is no Tentative Neighbor Cache entry matching the Registered
-   address and EUI-64, then NA is silently ignored.  Otherwise, the
-   information from the 6LBR is used to form an NA to send to the host.
-   The Status code is copied from the ARO received from the 6LBR to the
-   ARO that is sent to the host.
-
-   If the Status is non-zero indicating an error, then the Tentative
-   Neighbor Cache entry for the Registered Address is removed.
-   Otherwise it is made into a Registered Neighbor Cache entry.
-
-   A router MUST NOT modify the Neighbor Cache as a result of receiving
-   a Neighbor Advertisement with an ARO of Length=4, unless there is a
-   Tentative Neighbor Cache entry matching the IPv6 address and EUI-64.
-
-
-
-
-
-
+   from a 6LBR, then it MUST NOT verify that the hop limit is 255 as
+   specified above.  The information from the 6LBR is used to form an
+   NA to send to the host.  The ARO being sent to the host is copied
+   from the ARO received from the 6LBR.
 
 Shelby, et al.          Expires February 4, 2011               [Page 36]
 
 Internet-Draft          ND Optimization for LLNs             August 2010
 
 
 8.2.6.  Recovering from Failures
@@ -2154,16 +2085,20 @@
    address as per [RFC4944].  As the network is unmanaged (M flag not
    set in RA), the 6LN randomly chooses a 16-bit link-layer address and
    forms a tentative IPv6 address from it.
 
    4.  Next the 6LN registers that address with one or more of its
    default routers by sending a unicast NS message with an ARO
    containing its tentative global IPv6 address to register, the
-   registration lifetime and its EUI-64.  An SLLAO is also included with
-   the link-layer address corresponding to the address being registered.
+   registration lifetime, its EUI-64, and the link-layer address
+   corresponding to the address being registered. The SLLAO here corresponds
+   to the link-layer address associated with the IPv6 address from which
+   this unicast NS was sent. The unicast NS is sent from a link-local
+   address corresponding with the EUI-64 in the ARO, per section 7 of 
+   [RFC4944].
    If a successful (status 0) NA message is received the address can
    then be used and the 6LN assumes it has been successfully checked for
    duplicates.  If a duplicate address (status 1) NA message is
    received, the 6LN then removes the temporary IPv6 address and 16-bit
    link-layer address and goes back to step 3.  If a neighbor cache full
    (status 2) message is received, the 6LN attempts to register with
    another default router, or if none, goes back to step 2.
@@ -2338,14 +2273,22 @@
    context distribution and extensive contributions to earlier versions
    of the draft, Geoff Mulligan for suggesting the use of Address
    Registration as part of existing IPv6 Neighbor Discovery messages,
    and Mathilde Durvy for helping to clarify router interaction.
 
 
 14.  Changelog
+
+   Changes from -12 to -CO:
+   
+      o Temporary Neighbor Cache Entry removed
+	  
+	  o Addition of LLA to ARO
+	  
+	  o Always sent NS from IPv6 address based on EUI-64.
 
    Changes from -11 to -12:
 
 
 
 
 Shelby, et al.          Expires February 4, 2011               [Page 42]
