--- 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]