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

"Wes Beebee (wbeebee)" <wbeebee@cisco.com> Fri, 11 July 2008 13:22 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 5047A3A69D6; Fri, 11 Jul 2008 06:22:47 -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 A23EE3A6B21 for <ipv6@core3.amsl.com>; Fri, 11 Jul 2008 06:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level:
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=0.623, 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 rPzZeq3uCvJi for <ipv6@core3.amsl.com>; Fri, 11 Jul 2008 06:22:42 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2CD5D3A69D6 for <ipv6@ietf.org>; Fri, 11 Jul 2008 06:22:42 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.30,345,1212364800"; d="scan'208";a="51827639"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 11 Jul 2008 13:22:56 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6BDMu1v032651; Fri, 11 Jul 2008 06:22:56 -0700
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6BDMtpf007484; Fri, 11 Jul 2008 13:22:55 GMT
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jul 2008 09:22:55 -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: Fri, 11 Jul 2008 09:23:14 -0400
Message-ID: <BB56240F3A190F469C52A57138047A03B26477@xmb-rtp-211.amer.cisco.com>
In-Reply-To: <B00EDD615E3C5344B0FFCBA910CF7E1D04E41F27@xmb-rtp-20e.amer.cisco.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+G6555LqioHWQAJYdHAAAV4S+AAIa+RgA==
From: "Wes Beebee (wbeebee)" <wbeebee@cisco.com>
To: "Hemant Singh (shemant)" <shemant@cisco.com>, "Erik Nordmark" <erik.nordmark@sun.com>
X-OriginalArrivalTime: 11 Jul 2008 13:22:55.0015 (UTC) FILETIME=[3A52AB70:01C8E359]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5637; t=1215782576; x=1216646576; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20<wbeebee@cisco.co m> |Subject:=20RE=3A=206MAN=20WG=20Last=20Call=3Adraft-ietf-6m an-ipv6-subnet-model-00.txt |Sender:=20; bh=tYNq24xNYlynWAH4bPCpUjyxqjJhmUepmxhP6mhgFX8=; b=Ps8zmKi1E+cbhcJUyQwVssCOR3+7tTs5+PSEA1rYz6DA6YxvPWuIhYtx2q OiixTK5Q3w50WMXqy/wm4NT7W7rQz9Zvjyb1EeZV8DvuR9zzS+2iAqAceQpY dURgnmU+8kRErHpgfNXk1B5ZfICw6sgmV99AbluGe8aJT8tSpl1DM=;
Authentication-Results: sj-dkim-1; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
Cc: Thomas Narten <narten@us.ibm.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

Sorry to reopen this, but do you think that the following clarification
could be added to the IPv6 Subnet Models draft to address bullets three
and four of the on-link definition in the Terminology section of RFC
4861:

"Since only the Neighbor Cache is updated with the source address of a
received ND packet or the target of an NA packet, and the Destination
Cache and Prefix List are not updated, an ND packet cannot indicate that
a destination is on-link in the absence of corresponding on-link prefix
information."

What does the WG think?

- Wes

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
Hemant Singh (shemant)
Sent: Thursday, July 10, 2008 5:12 PM
To: Hemant Singh (shemant); Thomas Narten
Cc: ipv6@ietf.org; Brian Haberman; Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Thomas,

2nd ping. If you could please reply, that'd be great. I don't think the
ship will return back to port to discuss anything related to on-link
definition bullets three and four in our draft - that ship has sailed.
So now that we have agreed to removing the line mentioned in the email
chain below I hope you don't have anything objection to this para (from
Introduction section of our draft), do you?

   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.  Individual address entries can be expired by
   the Neighbor Unreachability Detection mechanism.

Thanks.

Hemant 

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
Hemant Singh (shemant)
Sent: Thursday, July 10, 2008 2:28 PM
To: Thomas Narten
Cc: Brian Haberman; Bob Hinden; ipv6@ietf.org
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Thomas,

Are you ok with the new paragraph if we removed this sentence from it:

"As of the writing of this document, bullets three and four of the
on-link definition are being debated and may need further
clarification." 

Further, since Tatuya will not let us add any text that suggests new
rules over RFC4861, we cannot accommodate any discussion related to
bullet 3 and 4 of on-link definition in our draft.

Please reply ASAP.

Thanks.

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
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------