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

JINMEI Tatuya / 神明達哉 <Jinmei_Tatuya@isc.org> Wed, 09 July 2008 02:32 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 30B4F3A67FD; Tue, 8 Jul 2008 19:32:14 -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 671A83A67FD for <ipv6@core3.amsl.com>; Tue, 8 Jul 2008 19:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.6
X-Spam-Level:
X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001]
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 PEVAUzHfDa6G for <ipv6@core3.amsl.com>; Tue, 8 Jul 2008 19:32:11 -0700 (PDT)
Received: from mon.jinmei.org (mon.jinmei.org [IPv6:2001:4f8:3:36::162]) by core3.amsl.com (Postfix) with ESMTP id DF7023A6780 for <ipv6@ietf.org>; Tue, 8 Jul 2008 19:32:10 -0700 (PDT)
Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 0775433C2E; Tue, 8 Jul 2008 19:32:20 -0700 (PDT)
Date: Tue, 08 Jul 2008 19:32:20 -0700
Message-ID: <m2k5fv6b4b.wl%Jinmei_Tatuya@isc.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <Jinmei_Tatuya@isc.org>
To: "Hemant Singh (shemant)" <shemant@cisco.com>
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
In-Reply-To: <B00EDD615E3C5344B0FFCBA910CF7E1D04E41EB9@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>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

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