<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 21, 2016 at 1:01 AM, Mike Jones <span dir="ltr">&lt;<a href="mailto:mike@mikejones.in" target="_blank">mike@mikejones.in</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Under that interpretation I believe a ND packet sourced from an<br>
address which has not been configured as on-link should be rejected.<br></blockquote><div><br></div><div>Actually, I think the IOS behaviour is wrong because it violates RFC 4861 section 7.2.3:</div><div><br></div><div><div>   If the Source Address is not the unspecified</div><div>   address and, on link layers that have addresses, the solicitation</div><div>   includes a Source Link-Layer Address option, then the recipient</div><div>   SHOULD create or update the Neighbor Cache entry for the IP Source</div><div>   Address of the solicitation.</div></div><div>[...]</div><div><div>   After any updates to the Neighbor Cache, the node sends a Neighbor</div><div>   Advertisement response as described in the next section.</div></div><div><br></div><div>RFC 5942 takes care to clarify the behaviour after the change to the IPv6 subnet model:</div><div><br></div><div>       Note that the Neighbor Cache is a<br></div><div><div>       separate data structure referenced by the Destination Cache, but</div><div>       entries in the Neighbor Cache are not necessarily in the</div><div>       Destination Cache.  It is quite possible (and intentional) that</div><div>       entries be added to the Neighbor Cache for addresses that would</div><div>       not be considered on-link as defined above.  For example, upon</div><div>       receipt of a valid NS, Section 7.2.3 of [RFC4861] states:</div><div><br></div><div>          If an entry does not already exist, the node SHOULD create a</div><div>          new one and set its reachability state to STALE as specified</div><div>          in Section 7.3.3.  If an entry already exists, and the cached</div><div>          link-layer address differs from the one in the received Source</div><div>          Link-Layer option, the cached address should be replaced by</div><div>          the received address, and the entry&#39;s reachability state MUST</div><div>          be set to STALE.</div><div><br></div><div>       The intention of the above feature is to add an address to the<br></div><div>       Neighbor Cache, even though it might not be considered on-link</div><div>       per the Prefix List. [...]  This causes no problems in practice, so long as the</div><div>       entry only exists in the Neighbor Cache and the address is not</div><div>       considered to be on-link by the IP forwarding code (i.e., the</div><div>       address is not added to the Prefix List and is not marked as</div><div>       on-link in the Destination Cache).</div></div><div><br></div><div>So what should happen in this case is:<br></div><div><ol><li>Router sends NS for host&#39;s global address from its global address.</li><li>Host creates or updates neighbour cache entry for router&#39;s global address.</li><li>Host replies to NS.</li><li>The neighbour cache entry for the router&#39;s global IPv6 address remains in the host&#39;s neighbour cache, but *is not used* for traffic because the entry is not marked in the destination cache as being on-link. (Only a redirect can do that.)</li></ol></div></div></div></div>