FW: Neighbor Discovery and on-link determination

["MILES DAVID" <[e-mail]>]

This issue was raised in v6ops, that on comments from Thomas seem better
suited for v6man.

Copied here to continue discussion.


> From: David Miles <[e-mail]>
> Date: 25 June 2008 10:04:25 AM
> To: Thomas Narten <[e-mail]>, IETF V6OPS WG
<[e-mail] 
> >
> Subject: 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 <[e-mail]> 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
>>
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------