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

"Hemant Singh (shemant)" <shemant@cisco.com> Thu, 10 July 2008 14:05 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 8AB513A6918; Thu, 10 Jul 2008 07:05:28 -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 C43473A68B7 for <ipv6@core3.amsl.com>; Thu, 10 Jul 2008 07:05:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.923
X-Spam-Level:
X-Spam-Status: No, score=-5.923 tagged_above=-999 required=5 tests=[AWL=0.676, 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 j9HcXg5TFQu2 for <ipv6@core3.amsl.com>; Thu, 10 Jul 2008 07:05:22 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8B8193A6918 for <ipv6@ietf.org>; Thu, 10 Jul 2008 07:05:22 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.30,338,1212364800"; d="scan'208";a="13827766"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Jul 2008 14:05:37 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6AE5bb3027305; Thu, 10 Jul 2008 10:05:37 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6AE5ZgT026507; Thu, 10 Jul 2008 14:05:37 GMT
Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 10:05:35 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Date: Thu, 10 Jul 2008 10:05:35 -0400
Message-ID: <B00EDD615E3C5344B0FFCBA910CF7E1D04E41F0F@xmb-rtp-20e.amer.cisco.com>
In-Reply-To: <200807101352.m6ADqUEC026668@cichlid.raleigh.ibm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Thread-Index: AcjilO8fIkrLHUXIT+G6555LqioHWQAADY+g
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> <200807101352.m6ADqUEC026668@cichlid.raleigh.ibm.com>
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: "Thomas Narten" <narten@us.ibm.com>
X-OriginalArrivalTime: 10 Jul 2008 14:05:35.0766 (UTC) FILETIME=[063C8360:01C8E296]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3939; t=1215698737; x=1216562737; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20<shemant@cisco. com> |Subject:=20RE=3A=206MAN=20WG=20Last=20Call=3Adraft-ietf-6m an-ipv6-subnet-model-00.txt |Sender:=20 |To:=20=22Thomas=20Narten=22=20<narten@us.ibm.com>; bh=ptQS+x/yGiBDym9/JQAVHJmZ+SpNoGpW3tz4vh/hPKA=; b=X/5H//2m/Ua1Q4wYF+sJ5hcAvIcNuSA1dzSjMw/spEll1ErKeMT6uaiWQ5 kGW3r+cd3QZuVS8efuodG+gptgRzrJkHMcGv0m/Ysg5lDhqq51tAKkziAZCv iESXvkukif;
Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Thomas,

You say: " bullets 3 & 4 MUST NOT be taken to indicate an address is
on-link."

But the Terminology section and the on-link definition clearly say
either of bullets 3 and 4 signify that the address is on-link. I have
snipped the text of the definition below.

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.

So are you saying bullets 3 and 4 need to change? Anyway, Tatuya is not
letting any change to RFC4861 in our draft. So why is our text not
acceptable when we say these bullets need discussion?

Hemant

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com] 
Sent: Thursday, July 10, 2008 9:52 AM
To: Hemant Singh (shemant)
Cc: Jinmei_Tatuya@isc.org; Bob Hinden; Brian Haberman; ipv6@ietf.org
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

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