David Miles wrote:
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
So the routers are intentionally configured to have different on-link prefixes?
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:01As 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.
Correct. The same thing is true for a host receiving a redirect where the target is on-link.
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).
Since the neighbor cache is per-interface the routing table needs to be consulted first, and only what that results in knowing the interface on which to send the packet does the neighbor cache get consulted.
But I don't think there is anything in the RFC that explicitly spells that out.
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 - an address in the target of a neigbour advertisement, or - an address in the source of a neighbour discovery messageShould 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.
Given that the neighbor cache is per interface, can you give me an example of where this causes a security concern?
Erik