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 --------------------------------------------------------------------
- FW: Neighbor Discovery and on-link determination MILES DAVID