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

Erik Nordmark <> Mon, 14 July 2008 10:22 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 891BA28C250; Mon, 14 Jul 2008 03:22:57 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD6FC28C250 for <>; Mon, 14 Jul 2008 03:22:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rCXOqhYxyNpG for <>; Mon, 14 Jul 2008 03:22:56 -0700 (PDT)
Received: from (brmea-mail-4.Sun.COM []) by (Postfix) with ESMTP id 035583A6896 for <>; Mon, 14 Jul 2008 03:22:55 -0700 (PDT)
Received: from ([]) by (8.13.6+Sun/8.12.9) with ESMTP id m6EANG5T010504; Mon, 14 Jul 2008 10:23:16 GMT
Received: from [] (punchin-nordmark.SFBay.Sun.COM []) by (8.13.8+Sun/8.13.8) with ESMTP id m6EAMmKJ747276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 03:22:50 -0700 (PDT)
Message-ID: <>
Date: Mon, 14 Jul 2008 03:22:44 -0700
From: Erik Nordmark <>
User-Agent: Thunderbird (X11/20070723)
MIME-Version: 1.0
To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= <>
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
References: <> <> <> <> <> <>
In-Reply-To: <>
Cc: Thomas Narten <>,, Brian Haberman <>, Bob Hinden <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"

JINMEI Tatuya / 神明達哉 wrote:

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

Yes, I think both bullet three and bullet four where there for some 
(incomplete) thoughts about NBMA. But I can't see a case when they would 
be needed. The redirect to an on-link target seems to be sufficient.

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

Did you verify that it in fact treats the source of the NS as on-link as 
a result?

I don't have an issue with creating a neighbor cache entry; that has no 
security implications because it does impact anything but the neighbor 
cache on the interface where the NS was received. The question is about 
on-link determination.
Thus will the source of the NS be treated as on-link? Is the behavior of 
the implementations different if the source of the NS falls in a prefix 
which is already considered on-link on some other interface?

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

Unfortunately, RFC 4861 doesn't specific enough about on-link 
determination to say whether that is a global activity, or whether it is 
done per interface.
Appendix A focuses on default router selection on multihomed nodes.

How do different multihomed implementation handle on-link determination?


IETF IPv6 working group mailing list
Administrative Requests: