11. Security Considerations

The security considerations of IPv6 ND [RFC4861] and address autoconfiguration [RFC4862] apply. Additional considerations can be found in [RFC3756].

There is a slight modification to those considerations, due to the fact that in this specification the M flag in the RAs disables the use of stateless address autoconfiguration for addresses not derived from EUI-64. Thus, a rogue router on the link can force the use of only DHCP for short addresses, whereas in [RFC4861] and [RFC4862] the rogue router could only cause the addition of DHCP and not disable stateless address autoconfiguration for short addresses.

This specification assumes that the link layer is sufficiently protected -- for instance, by using MAC-sublayer cryptography. Thus, its threat model is no different from that of IPv6 ND [RFC4861]. The first trust model listed in Section 3 of [RFC3756] applies here. However, any future 6LoWPAN security protocol that applies to ND for the 6LoWPAN protocol is out of scope of this document.

The multihop DAD mechanisms rely on DAR and DAC messages that are forwarded by 6LRs, and as a result the hop_limit=255 check on the receiver does not apply to those messages. This implies that any node on the Internet could successfully send such messages. We avoid any additional security issues due to this by requiring that the routers never modify the NCE due to such messages, and that they discard them unless they are received on an interface that has been explicitly configured to use these optimizations.

In some future deployments, one might want to use SEcure Neighbor Discovery (SEND) [RFC3971] [RFC3972]. This is possible with the ARO as sent between hosts and routers, since the address that is being registered is the IPv6 source address of the NS and SEND verifies the IPv6 source address of the packet. Applying SEND to the router-to-router communication in this document is out of scope.