FW: Neighbor Discovery and on-link determination

"MILES DAVID" <David.Miles@alcatel-lucent.com.au> Wed, 25 June 2008 00:07 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipv6-archive@megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AAEE3A6896; Tue, 24 Jun 2008 17:07:35 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 374733A6896 for <ipv6@core3.amsl.com>; Tue, 24 Jun 2008 17:07:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.697
X-Spam-Level:
X-Spam-Status: No, score=0.697 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, ROUND_THE_WORLD_LOCAL=2.696]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQIY9PUSBU2O for <ipv6@core3.amsl.com>; Tue, 24 Jun 2008 17:07:33 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 1F7253A6820 for <ipv6@ietf.org>; Tue, 24 Jun 2008 17:07:32 -0700 (PDT)
Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m5P07TE7002548; Tue, 24 Jun 2008 19:07:30 -0500 (CDT)
Received: from mail.net.alcatel.com.hk (h202-65-2-130.alcatel.com [202.65.2.130]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id m5P07S4U013909; Tue, 24 Jun 2008 19:07:29 -0500 (CDT)
Received: from sgsinsbhs01.ad4.ad.alcatel.com (localhost [127.0.0.1]) by mail.net.alcatel.com.hk (8.13.7/8.13.7/Alcanet1.0) with ESMTP id m5ONti0F013213; Wed, 25 Jun 2008 07:55:46 +0800
Received: from SGSINSMBS02.ad4.ad.alcatel.com ([135.254.109.30]) by sgsinsbhs01.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 08:07:25 +0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: FW: Neighbor Discovery and on-link determination
Date: Wed, 25 Jun 2008 08:07:22 +0800
Message-ID: <986DCE2E44129444B6435ABE8C9E424D016BDF7E@SGSINSMBS02.ad4.ad.alcatel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Neighbor Discovery and on-link determination
Thread-Index: AcjWVxhlFOMlTyEITomz8KL4n/9fPgAABRdA
From: "MILES DAVID" <David.Miles@alcatel-lucent.com.au>
To: <ipv6@ietf.org>
X-OriginalArrivalTime: 25 Jun 2008 00:07:25.0291 (UTC) FILETIME=[7294C3B0:01C8D657]
X-imss-version: 2.046
X-imss-result: Passed
X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5
X-imss-settings: Baseline:2 C:2 M:2 S:2 R:2 (0.1500 0.1500)
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Cc: Thomas Narten <narten@us.ibm.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

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

Copied here to continue discussion.


> From: David Miles <davidm@thetiger.com>;
> Date: 25 June 2008 10:04:25 AM
> To: Thomas Narten <narten@us.ibm.com>;, IETF V6OPS WG
<v6ops@ops.ietf.org 
> >
> 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 <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
>>
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------