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

Thomas Narten <narten@us.ibm.com> Thu, 10 July 2008 13:53 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 512703A690B; Thu, 10 Jul 2008 06:53:03 -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 560143A6849 for <ipv6@core3.amsl.com>; Thu, 10 Jul 2008 06:53:02 -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 QGvgXFQkbdhG for <ipv6@core3.amsl.com>; Thu, 10 Jul 2008 06:52:58 -0700 (PDT)
Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id 73B9E3A698B for <ipv6@ietf.org>; Thu, 10 Jul 2008 06:52:58 -0700 (PDT)
Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6ADr9oV004322 for <ipv6@ietf.org>; Thu, 10 Jul 2008 09:53:09 -0400
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6ADqtQe029028 for <ipv6@ietf.org>; Thu, 10 Jul 2008 07:52:55 -0600
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6ADqj41024163 for <ipv6@ietf.org>; Thu, 10 Jul 2008 07:52:46 -0600
Received: from cichlid.raleigh.ibm.com (sig-9-76-148-45.mts.ibm.com [9.76.148.45]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6ADqYHs023695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2008 07:52:41 -0600
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 m6ADqUEC026668; Thu, 10 Jul 2008 09:52:31 -0400
Message-Id: <200807101352.m6ADqUEC026668@cichlid.raleigh.ibm.com>
To: "Hemant Singh (shemant)" <shemant@cisco.com>
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
In-reply-to: <B00EDD615E3C5344B0FFCBA910CF7E1D04E41EFD@xmb-rtp-20e.amer.cisco.com>
References: <486388BD.2090801@innovationslab.net> <200807031925.m63JPRp7031611@cichlid.raleigh.ibm.com> <B00EDD615E3C5344B0FFCBA910CF7E1D04E41EB6@xmb-rtp-20e.amer.cisco.com> <200807032111.m63LBUCF014613@cichlid.raleigh.ibm.com> <B00EDD615E3C5344B0FFCBA910CF7E1D04E41EB9@xmb-rtp-20e.amer.cisco.com> <m2k5fv6b4b.wl%Jinmei_Tatuya@isc.org> <B00EDD615E3C5344B0FFCBA910CF7E1D04E41EFD@xmb-rtp-20e.amer.cisco.com>
Comments: In-reply-to "Hemant Singh (shemant)" <shemant@cisco.com> message dated "Wed, 09 Jul 2008 12:21:06 -0400."
Date: Thu, 10 Jul 2008 09:52:29 -0400
From: Thomas Narten <narten@us.ibm.com>
Cc: Brian Haberman <brian@innovationslab.net>, Bob Hinden <bob.hinden@nokia.com>, ipv6@ietf.org
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

"Hemant Singh (shemant)" <shemant@cisco.com>; writes:

> Tatuya,

> Erik suggested some new text to us related to bullets 3 and 4 of on-link
> definition in the Terminology section of RFC4861. He is busy this week -
> we are sending this on his behalf. As you know bullet 4 is being debated
> in 6man. Erik thinks even bullet 3 is suspect. We don't want such
> suspect information to be lost in archived emails of 6man. So we added
> the information to our draft. Please see the new paragraph from us:


>     The on-link definition in the Terminology section of [RFC4861]
>     defines the complete list of cases where an address is
>     considered on-link.  Note, in particular, that Redirect Messages
>     can also indicate an address is off-link.  As of the writing of
>     this document, bullets three and four of the on-link definition
>     are being debated and may need further clarification.
>     Individual address entries can be expired by the Neighbor
>     Unreachability Detection mechanism.

> Please let us know if the new text works for you?

It does not work for me.

Looking at the bullets 3 & 4:

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

IMO, bullets 3 & 4 MUST NOT be taken to indicate an address is
on-link. Nowhere in the ND specification does receipt of an NA or NS
result in the creation of a Destination Cache Entry that overrides the
first two bullets. The first 2 bullets are the only way (excluding
manual configuration) that an address is indicated to be on-link.

Yes, there are cases where and NS will create or update a  Neighbor
Cache Entry, but that is NOT the same thing as indicating that the
address is on-link.

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