Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Thomas Narten <narten@us.ibm.com> Thu, 03 July 2008 15:33 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 9754B3A6820; Thu, 3 Jul 2008 08:33:33 -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 5C3CF3A6820 for <ipv6@core3.amsl.com>; Thu, 3 Jul 2008 08:33:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 7YtHONrhzie3 for <ipv6@core3.amsl.com>; Thu, 3 Jul 2008 08:33:31 -0700 (PDT)
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 3A8043A6809 for <ipv6@ietf.org>; Thu, 3 Jul 2008 08:33:31 -0700 (PDT)
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m63FXd48027061 for <ipv6@ietf.org>; Thu, 3 Jul 2008 11:33:39 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m63FXdTY217228 for <ipv6@ietf.org>; Thu, 3 Jul 2008 11:33:39 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m63FXcxr006777 for <ipv6@ietf.org>; Thu, 3 Jul 2008 11:33:39 -0400
Received: from cichlid.raleigh.ibm.com (sig-9-76-130-61.mts.ibm.com [9.76.130.61]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m63FXblU006743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2008 11:33:38 -0400
Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m63FXZdM030742; Thu, 3 Jul 2008 11:33:36 -0400
Message-Id: <200807031533.m63FXZdM030742@cichlid.raleigh.ibm.com>
To: "MILES DAVID" <David.Miles@alcatel-lucent.com.au>
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
In-reply-to: <986DCE2E44129444B6435ABE8C9E424D01762C38@SGSINSMBS02.ad4.ad.alcatel.com>
References: <D9872168DBD43A41BD71FFC4713274D405429068@xmb-ams-33b.emea.cisco .com><BB56240F3A190F469C52A57138047A03A2C459@xmb-rtp-211.amer.cisco.com> <986DCE2E44129444B6435ABE8C9E424D0170C2BD@SGSINSMBS02.ad4.ad.alcatel.com> <B00EDD615E3C5344B0FFCBA910CF7E1D04E41E2B@xmb-rtp-20e.amer.cisco.com> <986DCE2E44129444B6435ABE8C9E424D01762084@SGSINSMBS02.ad4.ad.alcatel.com> <B00EDD615E3C5344B0FFCBA910CF7E1D04E41E52@xmb-rtp-20e.amer.cisco.com> <986DCE2E44129444B6435ABE8C9E424D01762C38@SGSINSMBS02.ad4.ad.alcatel.com>
Comments: In-reply-to "MILES DAVID" <David.Miles@alcatel-lucent.com.au> message dated "Thu, 03 Jul 2008 08:22:55 +0800."
Date: Thu, 03 Jul 2008 11:33:35 -0400
From: Thomas Narten <narten@us.ibm.com>
Cc: ipv6@ietf.org, erik.nordmark@sun.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

"MILES DAVID" <David.Miles@alcatel-lucent.com.au>; writes:

> Hemant,

> Thanks for your patience.

> Given we are now very clear that a receiver should drop any ND message
> from a source that it is not in its prefix list,

No, I would not go that far. There is no harm in responding to an NS
for a target address that is assigned to your interface. Indeed, it is
necessary to make communication work in some situtations. What should
not happen, however, is to use reciept of an ND message as an
indication that the sender of that message is on-link. (i.e.,
overriding or supplementing information learned from other means).

Likewise, receipt of an NA should not be taken as an indication that
the sender of that NA is on-link (i.e, anyone could just send out a
broadcast NA with bogus info in it). One should NOT create a Neighbor
Cache Entry upon receipt of a random (unsolicited) NA. (Luckily, the
spec already says you shouldn't do this, though for different
reasons.)

But if one has issued an NS for a particular address (because one
already believes the target is on-link), receipt of an NA should (of
course) update the neighbor cache for that entry.

> might I suggest the
> paragraph in question be amended to say:
> In addition to the Prefix List, individual addresses are on-link if
>    they are the target of a Redirect Message indicating on-link.

> Removing the text: 
> or the
>    source of a valid Neighbor Solicitation or Neighbor Advertisement
>    message.

> The clarification would be a step in the right direction.

IMO, removing that line is the right thing to do.

It is clear to me that bullet four in RFC 4861:

>    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.

Is wrong and needs tweaking. We should fix that on the next update of
the ND spec. :-)

That said, we are clearly talking about an edge case situation here
that hasn't come up in practice very often. So the urgency of fixing
this is not terribly great, IMO. But going forward (i.e, in any new
documents), we should do the right thing.

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