RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
"Hemant Singh (shemant)" <shemant@cisco.com> Wed, 09 July 2008 15:49 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 BBF1028C10F; Wed, 9 Jul 2008 08:49:58 -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 CCB4A28C10F for <ipv6@core3.amsl.com>; Wed, 9 Jul 2008 08:49:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.547
X-Spam-Level:
X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 hT4LMTZP0drO for <ipv6@core3.amsl.com>; Wed, 9 Jul 2008 08:49:45 -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 7185A28C123 for <ipv6@ietf.org>; Wed, 9 Jul 2008 08:49:44 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.30,332,1212364800"; d="scan'208,217"; a="13677926"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 Jul 2008 15:49:56 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m69Fnu83017924; Wed, 9 Jul 2008 11:49:56 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m69FnoOn014504; Wed, 9 Jul 2008 15:49:56 GMT
Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 11:49:53 -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: Wed, 09 Jul 2008 11:49:53 -0400
Message-ID: <B00EDD615E3C5344B0FFCBA910CF7E1D04E41EFB@xmb-rtp-20e.amer.cisco.com>
In-Reply-To: <m2k5fv6b4b.wl%Jinmei_Tatuya@isc.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Thread-Index: AcjhbCdxVUeq6/dLTfmyyLZQmFvWSAAbxXcg
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>
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: Jinmei_Tatuya@isc.org
X-OriginalArrivalTime: 09 Jul 2008 15:49:53.0664 (UTC) FILETIME=[6DD23800:01C8E1DB]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=22300; t=1215618596; x=1216482596; 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<Jinmei_Tatuya@isc.org>; bh=XLofIXaAL8FYmaBrVO8BEn8vikmpwwbyjumPjhk+mO4=; b=NeCLkAMnpXxEhJtoVaDSMXa46SDbqiOakxWo2XZns2eutsTp/q+spAYiO+ frNTY/eLaBAPGkOfKHxrdhxCrq3EuY043VrsV5GVKrx5JQCpA0HTQk1K4NMs NH4XdjQ9K6;
Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Cc: Thomas Narten <narten@us.ibm.com>, Bob Hinden <bob.hinden@nokia.com>, Brian Haberman <brian@innovationslab.net>, 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: multipart/mixed; boundary="===============1920730978=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Tatuya, This suggestion by you: From: In addition to the Prefix List, individual addresses are on-link if they are the target of a Redirect Message indicating on-link, or the source of a valid Neighbor Solicitation or Neighbor Advertisement message. Note that Redirect Messages can also indicate an address is off-link. Individual address entries can be expired by the Neighbor Unreachability Detection mechanism. To: Section 2 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. makes sense to us - we will take text from you - thanks. Further, it's better continuing discussion related to the 4th bullet of on-link definition from the Terminology section of RFC4861. We can totally not touch it in our draft - that is what we will do. We will also remove any mention of the source-address rule in bullet 2 of section 2 of our draft. That's closure on our draft for the last call. However, we can start that 4th bullet discussion right now where I and Wes will justify why we wanted the 4th bullet deprecated. Thomas has been saying that as well. We will explain why we do. You see, the data forwarding table on a host takes precedence over ND-cache. The data forwarding table consults the Destination Cache. If an IPv6 node is a router then the data forwarding table is called the routing table. We router folks do not like the 4th bullet because we do not want our routing table cache to be touched merely based on source address of packets received by the router interface. You see, the 4th bullet seems to only apply to a router-less network but if one starts applying the rule to routers, that is wrong! There are other reasons too that we do not like the 4th bullet - the reasons have been given in emails to this mailer. Hemant & Wes -----Original Message----- From: Jinmei_Tatuya@isc.org [mailto:Jinmei_Tatuya@isc.org] Sent: Tuesday, July 08, 2008 10:32 PM To: Hemant Singh (shemant) Cc: Thomas Narten; ipv6@ietf.org; Brian Haberman; Bob Hinden Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt At Thu, 3 Jul 2008 17:35:56 -0400, "Hemant Singh (shemant)" <shemant@cisco.com> wrote: > Will something like this work for you - we have replaced "change" with > "clarification". > > [The source of an ND message is no longer used for on-link > determination, which is a clarification of bullet four of on-link > definition in Terminology section of [RFC4861].] > > or > > [The source of an ND message is no longer used for on-link > determination, which is a clarification of on-link definition in > Terminology section of [RFC4861].] I object to this type of change (I have an alternate proposal. See the end of this message). > I agree with you, no implementations have actually interpreted this > source address rule, but when folks like David notice the bug, folks > quote the definition of on-link in Terminology section of RFC4861. > That is why we thought of adding this line to our doc. First off, I believe we should be more careful before "deprecating" this rule: - any Neighbor Discovery message is received from the address. As an implementor, I've been aware of the non-trivial flavor of this on-link condition, and have noticed it creates tricky corner cases. But I've always thought it's intentional, rather than a "bug". Although I was not 100% sure in which case this rule is expected to be used, I've imagined it might be useful in a router-less network (as we briefly discussed in a different thread) or some NBMA network. BSD variants have in fact supported this behavior for years: I've just tested this with a FreeBSD 7.0 box and confirmed it (that is, if that host receives an NS from an address that is not covered by "on-link" prefixes advertised by RAs, it will create a specific neighbor cache entry for that address). I've also quickly checked that Linux (seemingly) supports this behavior, too. I also suspect there may even be a TAHI test item that requires this behavior (since it's tricky, and TAHI tests check tricky behaviors "by definition":-). If my guess is correct, there will be other implementations that support this behavior to qualify for an "IPv6 ready logo" or something. Now that I've seen the "inventors" of the neighbor discovery protocol say it's a mistake and that I've also been wondering for what purpose this rule is expected to be useful, I'd not necessarily be objecting to the idea of deprecating this rule. But since this will affect (potentially many) existing implementations, this should be more carefully and explicitly discussed with the implementors who have already supported the behavior. Perhaps we could have this discussion when we want to revise RFC4861 to the full STD, but it should not be done in part of a branch thread on a derivative "clarification" document. (BTW, I've seen a "security" concern on this behavior in a different thread. I was not sure about whether it's a mere FUD or it has a really serious new security implication, due to the lack of details, but in any event I'd not buy that argument in this context. Since ND is a link-local protocol, any attack including this one must be performed within the same link as the victim. And once we consider such a hostile environment, we already know the neighbor discovery as a whole is just vulnerable to many serious attacks. If we want to counter this situation, we must deploy SEND; simply deprecating one minor corner case doesn't help). Now, going back to the wording of the "subnet model" document, I suggest the following change to reflect this discussion: From: In addition to the Prefix List, individual addresses are on-link if they are the target of a Redirect Message indicating on-link, or the source of a valid Neighbor Solicitation or Neighbor Advertisement message. Note that Redirect Messages can also indicate an address is off-link. Individual address entries can be expired by the Neighbor Unreachability Detection mechanism. To: Section 2 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. The key intent of the proposed change is to avoid the explicit duplicate of the conditions. So, even if we eventually make a consensus on whether to deprecate any "on-link" conditions described in RFC4861, probably in a context of revising the RFC, it will be less likely that some implementors naively implement the would-be-obsolete rule by simply referring to the "subnet model" document. I also believe this approach is generally desirable because this document just tries to clarify some subtle points of RFC4861, rather than making a substantial change to it. --- JINMEI, Tatuya Internet Systems Consortium, Inc.
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-mod… Brian Haberman
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wojciech Dec (wdec)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wes Beebee (wbeebee)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wojciech Dec (wdec)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… MILES DAVID
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… MILES DAVID
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… MILES DAVID
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Thomas Narten
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Thomas Narten
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wes Beebee (wbeebee)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Thomas Narten
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wes Beebee (wbeebee)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wes Beebee (wbeebee)
- FW: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: FW: 6MAN WG Last Call:draft-ietf-6man-ipv6-su… JINMEI Tatuya / 神明達哉
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Thomas Narten
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… MILES DAVID
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Thomas Narten
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Thomas Narten
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Suresh Krishnan
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Suresh Krishnan
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wes Beebee (wbeebee)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wes Beebee (wbeebee)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Erik Nordmark
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Erik Nordmark
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Erik Nordmark
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Erik Nordmark
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Erik Nordmark
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wes Beebee (wbeebee)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Azinger, Marla
- 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-mod… Brian Haberman
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Brian Haberman
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Brian E Carpenter
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wes Beebee (wbeebee)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wes Beebee (wbeebee)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)