6. Router Behavior for 6LRs and 6LBRs

Both 6LRs and 6LBRs maintain the Neighbor Cache [RFC4861] based on the AROs they receive in NA messages from hosts, ND packets from other nodes, and, potentially, a routing protocol used in the 6LoWPAN as outlined in Section 3.5.

The routers SHOULD NOT garbage-collect Registered NCEs (see Section 3.4), since they need to retain them until the Registration Lifetime expires. Similarly, if NUD on the router determines that the host is UNREACHABLE (based on the logic in [RFC4861]), the NCE SHOULD NOT be deleted but rather retained until the Registration Lifetime expires. A renewed ARO should mark the cache entry as STALE. Thus, for 6LoWPAN routers, the Neighbor Cache doesn't behave like a cache. Instead, it behaves as a registry of all the host addresses that are attached to the router.

Routers MAY implement the Default Router Preference (Prf) extension [RFC4191] and use that to indicate to the host whether the router is a 6LBR or a 6LR. If this is implemented, then 6LRs with no route to a border router MUST set Prf to (11) for low preference, other 6LRs MUST set Prf to (00) for normal preference, and 6LBRs MUST set Prf to (01) for high preference.

6.1. Forbidden Actions

Even if a router in a route-over topology can reach both a host and another target, because of radio propagation it generally cannot know whether the host can directly reach the other target. Therefore, it cannot assume that Redirect will actually work from one host to another. Therefore, it SHOULD NOT send Redirect messages. The only potential exception to this "SHOULD NOT" is when the deployment/implementation has a way to know how the host can reach the intended target. Hence, it is RECOMMENDED that the implementation by default does not send Redirect messages but can be configurable when the deployment calls for this. In contrast, for mesh-under topologies, the same considerations about Redirects apply as in [RFC4861].

A router MUST NOT set the L (on-link) flag in the PIOs, since that might trigger hosts to send multicast NSs.

6.2. Interface Initialization

The 6LBR router interface initialization behavior is the same as in [RFC4861]. However, in a dynamic configuration scenario (see Section 8.1), a 6LR comes up as a non-router and waits to receive the advertisement for configuring its own interface address first, before setting its interfaces to be advertising interfaces and turning into a router.

6.3. Processing a Router Solicitation

A router processes RS messages as specified in [RFC4861]. The differences relate to the inclusion of ABROs in the RA messages and the exclusive use of unicast RAs. If a 6LR has received an ABRO from a 6LBR, then it will include that option unmodified in the RA messages it sends. And, if the 6LR has received RAs -- whether with the same prefixes and context information or different -- from a different 6LBR, then it will need to keep those prefixes and that 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.

When the ABRO Valid Lifetime associated with a 6LBR times out, all information related to that 6LBR MUST be removed. As an implementation note, it is recommended that RAs are sent sufficiently more frequently than the ABRO Valid Lifetime so that missing an RA does not result in removing all information related to a 6LBR.

An RS might be received from a host that has not yet registered its address with the router. Thus, the router MUST NOT modify an existing NCE based on the SLLAO from the RS. However, a router MAY create a Tentative NCE based on the SLLAO. Such a Tentative NCE SHOULD be timed out in TENTATIVE_NCE_LIFETIME seconds, unless a registration converts it into a Registered NCE.

A 6LR or 6LBR MUST include an SLLAO in the RAs it sends; this 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 (approximately 18 hours).

Unlike [RFC4861], which suggests multicast RAs, this specification improves the exchange by always unicasting RAs in response to RSs. This is possible, since the RS always includes an SLLAO, which is used by the router to unicast the RA.

6.4. Periodic Router Advertisements

A router does not need to send any periodic RA messages, since the hosts will solicit updated information by sending RSs before the lifetimes expire.

However, if the routers use RAs to distribute prefix and/or context information across a route-over topology, that might require periodic RA messages. Such RAs are sent using the configurable MinRtrAdvInterval and MaxRtrAdvInterval as per [RFC4861].

6.5. Processing a Neighbor Solicitation

A router handles NS messages as specified in [RFC4861], with added logic described in this section for handling the ARO.

In addition to the normal validation of an NS and its options, the ARO is verified as follows (if present). If the Length field is not two, or if the Status field is not zero, then the NS is silently ignored.

If the source address of the NS is the unspecified address, or if no SLLAO 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. It isn't a duplicate if (1) there is no NCE for the IPv6 source address of the NS or (2) there is such an NCE and the EUI-64 is the same. 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 NCEs. In the case where it is a duplicate address, then the router responds with a unicast NA message with the ARO Status field set to one (to indicate that the address is a duplicate) as described in Section 6.5.2. In this case, there is no modification to the Neighbor Cache.

6.5.2. Returning Address Registration Errors

Address registration errors are not sent back to the source address of the NS due to a possible risk of L2 address collision. Instead, the NA is sent to the link-local IPv6 address with the Interface ID part derived from the EUI-64 field of the ARO as per [RFC4944]. In particular, this means that the universal/local bit needs to be inverted. The NA is formatted with a copy of the ARO from the NS, but with the Status field set to indicate the appropriate error.

The error is sent to the link-local address with the Interface ID derived from the EUI-64. Thus, if the ARO was from and for a short address, the L2 destination address for the NA with the ARO error will be the 64-bit unique address.

6.5.3. Updating the Neighbor Cache

If the 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) an NCE 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 unicast NA with the ARO Status field set to two (to indicate that the router's Neighbor Cache is full) as described in Section 6.5.2.

The Registration Lifetime and the EUI-64 are recorded in the NCE. A unicast NA is then sent in response to the NS. This NA SHOULD include a copy of the ARO, with the Status field set to zero. A TLLAO (Target Link-Layer Address Option) [RFC4861] is not required in the NA, since the host already knows the router's link-layer address from RAs.

If the ARO contains a zero Registration Lifetime, then any existing NCE for the IPv6 source address of the NS MUST be deleted and an NA sent as above.

Should the Registration Lifetime in an NCE expire, then the router MUST delete the cache entry.

The addition and removal of Registered NCEs would result in notifying the routing protocol.

Note: If the substitutable multihop DAD (Section 8.2) is used, then the updating of the Neighbor Cache is slightly different due to Tentative NCEs.

6.5.4. Next-Hop Determination

In order to deliver a packet destined for a 6LN registered with a router, next-hop determination is slightly different for routers than for hosts (see Section 5.6). The routing table is checked to determine the next-hop IP address. A Registered NCE determines if the next-hop IP address is on-link. It is the responsibility of the routing protocol of the router to maintain on-link information about its registered neighbors. Tentative NCEs MUST NOT be used to determine on-link status of the registered nodes.

6.5.5. 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 ARO between each other. Otherwise, the routers SHOULD use the ARO. When routers use the ARO to register with each other and multihop DAD (Section 8.2) is in use, then care must be taken to ensure that there isn't a flood of ARO-carrying messages sent to the 6LBR as each router hears an ARO from their neighboring routers. The details for this scenario are out of scope of this document.

Routers MAY also use multicast NSs as in [RFC4861] to resolve each others link-layer addresses. Thus, routers MAY multicast NSs for other routers, for example, as a result of receiving some routing protocol update. Routers MUST respond to multicast NSs. This implies that routers MUST join the solicited-node multicast addresses as specified in [RFC4861].