Re: Neighbor Discovery and on-link determination

[Thomas Narten <narten@us.ibm.com>]

David Miles <davidm@thetiger.com> writes:

> I have seen an unusual scenario which I was wanting to run past people to 
> comment on:

> I have routerA and routerB connected to each other via Ethernet.

> RouterA has the following addresses on the interface to RouterB:
> 2000:100::2/64
> 3000:100::2/64
> With a default route to 2000:100::1

> RouterB has the following addresses on the interface to RouterA:
> 2000:100::1/64
> With a route for 3000:100::/64 to 2000:100::2

> Per RFC4861, RouterA is sending ND as follows (assume it wants to 
> src traffic from 3000:100::2 to a off-link address):
>     3000:1::2 -> FF02::1:FF00:1
>     Type: Neighbor Solicitation (135)
>     Code: No Code (0)
>        Tgt Addr: 2000:100::1
>        Option  : Src Link Layer Addr 00:00:00:00:00:01

> As 7.2.2 says "if the source address of the packet prompting the 
> solicitation is the same as one of the addresses assigned to the outgoing 
> interface, that address SHOULD be placed in the IP Source Address of the 
> outgoing solicitation."

> When RouterB will receive the ND as it is sent to the solicited-node MC 
> address and will check the target address is valid (matches an addresss 
> assigned to the receiving interface).
> RouterB should then create a Neighbour Cache entry and set its state to 
> STALE using the link-layer address in the ND. It should then send a 
> solicited neighbor advertisement.

> This means that the RouterB will have a single address 3000:1::2 in its 
> Neighbour Cache, but the route will direct traffic to 2000:200::2. 
> Obviously the Neighbour Cache would now contain an entry for an address 
> that does not (appear) to be on-link from a route-table perspective.

Hmm. This would appear to be a bug.

I do not believe it was the intention to have any addresses that
appear as the source of an NS result in a recipient of the NS
concluding that the source address is on-link.

That said, if you follow the words in the spec (with the "conceptual
algorithms"), the result would appear to be a bogus entry in the
Neighbor Cache, but one that would not get used. I.e., when sending to
that destination, RouterB would first look in its Destination Cache,
find no entry and then do next-hop determination (i.e., by looking at
the on-link information. It would NOT look in the Neighbor Cache at
this point, it only does that after determining if the destination is
on-link.

In any case, I would have expected that before creating a Neighbor
Cache Entry for the source address mentioned above, the receiver
should first verify that the address would be considered on-link per
the standard checks.

> How should Neighbour Cache and route table interact on a routerB? I had 
> always assumed route table replaces Prefix List on a router, but that 
> would mean Neighbour Cache would always be consulted with the next-hop of 
> the static route (following the sending algorithm in RFC 4861).

That may be the common implementation, but that is not what the
conceptual sending alogrithm says should happen.

> This seems to directly relate to the definition of on-link as being:
> - an address covered by on of the link's prefixes, or
> - an address in the target of a rediect, or

yes

> - an address in the target of a neigbour advertisement, or

There is no definition that I know if that would allow you to draw
this conclusion. All one can conclude is that the sender of the NS
believes the target is on-link. They may be right, but they may also
be wrong.

> - an address in the source of a neighbour discovery message

No, per above.

> Should a router really consider an address on-link just because it 
> received a ND - I can see many potential security concerns if that is the 
> case.

I think not, with security concerns being one reason why not.

> Any clarifications or experiance appreciated.

Good catch!

Thomas