Skip to main content

8. Substitutable Feature Behavior

Normally, in a 6LoWPAN multihop network, the RA messages are used to disseminate prefixes and context information to all the 6LRs in a route-over topology. If all routers are configured to use a substitute mechanism for such information distribution, any remaining use of the 6LoWPAN-ND mechanisms is governed by the substitute specification.

There is also the option for a 6LR to perform multihop DAD (for IPv6 addresses not derived from an EUI-64) against a 6LBR in a route-over topology by using the DAR and DAC messages. This is substitutable because there might be other ways to either allocate a unique address, such as DHCPv6 [RFC3315], or use other future mechanisms for multihop DAD. Again, in this case, any remaining use of the 6LoWPAN-ND mechanisms is governed by the substitute specification.

To be clear: Implementations MUST support the features described in Sections 8.1 and 8.2, unless the implementation supports some alternative ("substitute") from some other specification.

8.1. Multihop Prefix and Context Distribution​

The multihop distribution relies on RS messages and RA messages sent between routers, and using the ABRO version number to control the propagation of the information (prefixes and context information) that is being sent in the RAs.

This multihop distribution mechanism can handle arbitrary information from an arbitrary number of 6LBRs. However, the semantics of the context information requires that all the 6LNs use the same information whether they send, forward, or receive compressed packets. Thus, the manager of the 6LBRs needs to somehow ensure that the context information is in synchrony across the 6LBRs. This can be handled in different ways. One possible way to ensure it is to treat the context and prefix information as originating from some logical or virtual source, which in essence means that it looks like the information is distributed from a single source.

If a set of 6LBRs behave as a single one (using mechanisms out of scope of this document) so that the prefixes and contexts and the ABRO version number will be the same from all the 6LBRs, then those 6LBRs can pick a single IP address to use in the ABRO.

8.1.1. 6LBRs Sending Router Advertisements​

6LBRs supporting multihop prefix and context distribution MUST include an ABRO in each of their RAs. The ABRO Version Number field is used to keep prefix and context information consistent throughout the LoWPAN, along with the guidelines in Section 7.2. Each time any information in the set of PIOs or 6COs changes, the ABRO version is increased by one.

This requires that the 6LBR maintain the PIO, 6CO, and ABRO Version Number in stable storage, since an old version number will be silently ignored by the 6LRs.

8.1.2. Routers Sending Router Solicitations​

In a 6LoWPAN, unless substituted, multihop distribution is done using RA messages. Thus, on interface initialization, a router (6LR) MUST send RS messages following the rules specified for hosts in [RFC4861]. This in turn will cause the routers to respond with RA messages that can then be used to initially seed the prefix and context information.

8.1.3. Routers Processing Router Advertisements​

If multihop distribution is not done using RA messages, then the routers follow [RFC4861], which states that they merely do some consistency checks; in this case, nothing in Section 8.1 applies. Otherwise, the routers will check and record the prefix and context information from the received RAs, and use that information as follows.

If a received RA does not contain an ABRO, then the RA MUST be silently ignored.

The router uses the 6LBR Address field in the ABRO to check if it has previously received information from the 6LBR. If it finds no such information, then it just records the 6LBR address, Version, Valid Lifetime, and the associated prefixes and context information. If the 6LBR is previously known, then the Version Number field MUST be compared against the recorded version number for that 6LBR. If the version number received in the packet is less than the stored version number, then the information in the RA is silently ignored. Otherwise, the recorded information and version number are updated.

8.1.4. Storing the Information​

The router keeps state for each 6LBR that it sees with an ABRO. This includes the version number, the Valid Lifetime, and the complete set of PIOs and 6COs. The prefixes are timed out based on the Valid Lifetime in the PIO. The Context Prefix is timed out based on the Valid Lifetime in the 6CO.

While the prefixes and context information are stored in the router, their valid and preferred lifetimes are decremented as time passes. This ensures that when the router is in turn later advertising that information in the RAs it sends, the 'expiry time' doesn't accidentally move further into the future. For example, if a 6CO with a Valid Lifetime of 10 minutes is received at time T, and the router includes this in an RA it sends at time T+5 minutes, the Valid Lifetime in the 6CO it sends will be only 5 minutes.

8.1.5. Sending Router Advertisements​

When multihop distribution is performed using RA messages, the routers MUST ensure that the ABRO always stays together with the prefixes and context information received with that ABRO. Thus, if the router has received prefix P1 with an ABRO saying it is from one 6LBR, and prefix P2 from another 6LBR, then the router MUST NOT include the two prefixes in the same RA message. Prefix P1 MUST be in an RA that includes an ABRO from the first 6LBR, etc. Note that multiple 6LBRs might advertise the same prefix and context information, but they still need to be associated with the 6LBRs that advertised them.

The routers periodically send RAs as in [RFC4861]. This is for the benefit of the other routers receiving the prefixes and context information. The routers also respond to RSs by unicasting RA messages. In both cases, the above constraint of keeping the ABRO together with 'its' prefixes and context information applies.

When a router receives new information from a 6LBR, that is, either it hears from a new 6LBR (a new 6LBR address in the ABRO) or the ABRO version number of an existing 6LBR has increased, then it is useful to send out a few triggered updates. The recommendation is to behave the same as when an interface has become an advertising interface as described in [RFC4861], that is, send up to three RA messages. This ensures rapid propagation of new information to all the 6LRs.

8.2. Multihop Duplicate Address Detection​

The ARO can be used, in addition to registering an address in a 6LR, to have the 6LR verify that the address isn't used by some other host known to the 6LR. However, that isn't sufficient in a route-over topology (or in a LoWPAN with multiple 6LBRs), since some host attached to another 6LR could be using the same address. There might be different ways for the 6LRs to coordinate such duplicate address detection in the future, or addresses could be assigned using a DHCPv6 server that verifies uniqueness as part of the assignment.

This specification offers a substitutable simple technique for 6LRs and 6LBRs to perform DAD that reuses the information from the ARO in the DAR and DAC messages. This technique is not needed when the Interface ID in the address is based on an EUI-64, since those are assumed to be globally unique. The technique assumes that either the 6LRs register with all the 6LBRs or the network uses some out-of-scope mechanism to keep the DAD tables in the 6LBRs synchronized.

The multihop DAD mechanism is used synchronously the first time an address is registered with a particular 6LR. That is, the ARO is not returned to the host until multihop DAD has been completed against the 6LBRs. For existing registrations in the 6LR, 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. One method to achieve this is to track how much is left of the lifetime the 6LR registered with the 6LBRs and to re-register with the 6LBR when this lifetime is about to run out.

For synchronous multihop DAD, the 6LR performs some additional checks to ensure that it has an NCE 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) NCE 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 NCE exists, then the 6LR MUST create a Tentative NCE with the EUI-64 and the SLLAO. This entry will be used to send the response to the host when the 6LBR responds positively.

When a 6LR receives an NS containing an ARO with a non-zero Registration Lifetime and it has no existing Registered NCE, then with this mechanism the 6LR will invoke synchronous multihop DAD.

The 6LR will unicast a DAR message to one or more 6LBRs, where the DAR contains the host's address in the Registered Address field. The DAR will be forwarded by 6LRs until it reaches the 6LBR; hence, its IPv6 Hop Limit field will not be 255 when received by the 6LBR. The 6LBR will respond with a DAC message, which will have a hop limit less than 255 when it reaches the 6LR.

When the 6LR receives the DAC from the 6LBR, it will look for a matching (same IP address and EUI-64) (Tentative or Registered) NCE. If no such entry is found, then the DAC is silently ignored. If an entry is found and the DAC had Status=0, then the 6LR will mark the Tentative NCE as Registered. In all cases, when an entry is found, then the 6LR will respond to the host with an NA, copying the Status and EUI-64 fields from the DAC to an ARO in the NA. In case the status is an error, then the destination IP address of the NA is derived from the EUI-64 field of the DAC.

A Tentative NCE 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. Message Validation for DAR and DAC​

A node MUST silently discard any received DAR and DAC messages for which at least one of the following validity checks is not satisfied:

  • If the message includes an IP Authentication Header, the message authenticates correctly.
  • ICMP Checksum is valid.
  • ICMP Code is 0.
  • ICMP Length (derived from the IP length) is 32 or more bytes.
  • The Registered Address is not a multicast address.
  • All included options have a length that is greater than zero.
  • The IP source address is not the unspecified address, nor is it a multicast address.

The contents of the Reserved field and of any unrecognized options MUST be ignored. Future backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values.

Note that due to the forwarding of the DAR and DAC messages between the 6LR and 6LBR, there is no hop-limit check on receipt for these ICMPv6 message types.

8.2.2. Conceptual Data Structures​

A 6LBR implementing multihop DAD needs to maintain some state separate from the Neighbor Cache. We call this conceptual data structure the DAD table. It is indexed by the IPv6 address -- the Registered Address in the DAR -- and contains the EUI-64 and the Registration Lifetime of the host that is using that address.

8.2.3. 6LR Sending a Duplicate Address Request​

When a 6LR that implements multihop DAD receives an NS from a host, and subject to the above checks, the 6LR forms and sends a DAR to at least one 6LBR. The DAR contains the following information:

  • In the IPv6 source address, a global address of the 6LR.
  • In the IPv6 destination address, the address of the 6LBR.
  • In the IPv6 hop limit, MULTIHOP_HOPLIMIT.
  • The Status field MUST be set to zero.
  • The EUI-64 and Registration Lifetime are copied from the ARO received from the host.
  • 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 NCE for the host as specified in Section 6, a DAR is sent to the 6LBRs as above.

A router MUST NOT modify the Neighbor Cache as a result of receiving a DAR.

8.2.4. 6LBR Receiving a Duplicate Address Request​

When a 6LBR that implements the substitutable multihop DAD receives a DAR from a 6LR, it performs the message validation specified in Section 8.2.1. If the DAR is valid, the 6LBR 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 DAR, then it returns a DAC NA with the Status set to 1 ('Duplicate Address'). Otherwise, it returns a DAC with Status set to zero and updates the lifetime.

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 Address from the DAR are stored in that entry.

If an entry is found in the DAD table, the EUI-64 matches, and the Registration Lifetime is zero, then the entry is deleted from the table.

In both of the above cases, the 6LBR forms a DAC with the information copied from the DAR and the Status field is set to zero. The DAC is sent back to the 6LR, i.e., back to the source of the DAR. The IPv6 hop limit is set to MULTIHOP_HOPLIMIT.

8.2.5. Processing a Duplicate Address Confirmation​

When a 6LR implementing multihop DAD receives a DAC message, then it first validates the message per Section 8.2.1. For a valid DAC, if there is no Tentative NCE matching the Registered Address and EUI-64, then the DAC is silently ignored. Otherwise, the information in the DAC and in the Tentative NCE is used to form an NA to send to the host. The Status code is copied from the DAC to the ARO that is sent to the host. In the case where the DAC indicates an error (the Status is non-zero), the NA is returned to the host as described in Section 6.5.2, and the Tentative NCE for the Registered Address is removed. Otherwise, it is made into a Registered NCE.

A router MUST NOT modify the Neighbor Cache as a result of receiving a DAC, unless there is a Tentative NCE matching the IPv6 address and EUI-64.

8.2.6. Recovering from Failures​

If there is no response from a 6LBR after RETRANS_TIMER [RFC4861], then the 6LR would retransmit the DAR to the 6LBR up to MAX_UNICAST_SOLICIT [RFC4861] times. After this, the 6LR SHOULD respond to the host with an ARO Status of zero.

Last updated on