[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Neighbor Discovery and on-link determination



Thanks Thomas,

I'll move this into v6man if that is the case (and to ensure everyone is across it).

So in summary, the definition of on-link is where the uncertainty arose, because the current definition is: on-link - an address that is assigned to an interface on a specified link. A node considers an address to be on- link if: - it is covered by one of the link's prefixes (e.g., as indicated by the on-link flag in the Prefix Information option), or - a neighboring router specifies the address as the target of a Redirect message, or - a Neighbor Advertisement message is received for the (target) address, or
- any Neighbor Discovery message is received from the address.


It sounds as though we should remove the last two conditions?

I'd also suggest that in the Message Validation section we include the checks you mention (is the source of the ND or target of the NA an on- link prefix per Prefix List)

Best Regards,

-David

On 25/06/2008, at 1:36 AM, Thomas Narten wrote:

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