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

Thomas Narten <narten@us.ibm.com> Thu, 10 July 2008 01:42 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 E2C1F3A684B; Wed, 9 Jul 2008 18:42:56 -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 CD3F13A6812 for <ipv6@core3.amsl.com>; Wed, 9 Jul 2008 18:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 uoqrkkfh9ToY for <ipv6@core3.amsl.com>; Wed, 9 Jul 2008 18:42:54 -0700 (PDT)
Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id 8A1533A6765 for <ipv6@ietf.org>; Wed, 9 Jul 2008 18:42:54 -0700 (PDT)
Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6A1h67k014249 for <ipv6@ietf.org>; Wed, 9 Jul 2008 21:43:06 -0400
Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6A1h5Tf178268 for <ipv6@ietf.org>; Wed, 9 Jul 2008 19:43:05 -0600
Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6A1h5Pl001357 for <ipv6@ietf.org>; Wed, 9 Jul 2008 19:43:05 -0600
Received: from cichlid.raleigh.ibm.com (sig-9-76-148-45.mts.ibm.com [9.76.148.45]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6A1h3M9001314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2008 19:43:05 -0600
Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m6A1h0sG026605; Wed, 9 Jul 2008 21:43:00 -0400
Message-Id: <200807100143.m6A1h0sG026605@cichlid.raleigh.ibm.com>
To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <Jinmei_Tatuya@isc.org>
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
In-reply-to: <m2k5fv6b4b.wl%Jinmei_Tatuya@isc.org>
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>
Comments: In-reply-to JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <Jinmei_Tatuya@isc.org> message dated "Tue, 08 Jul 2008 19:32:20 -0700."
Date: Wed, 09 Jul 2008 21:43:00 -0400
From: Thomas Narten <narten@us.ibm.com>
Cc: 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Jinmei,

Thanks for teasing this discussion apart further. You've tweaked an
old memory to the surface. :-)

JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <Jinmei_Tatuya@isc.org>; writes:

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

It was intentional. I'd just forgotten why. :-)

When NodeA issues a NS for NodeB, that usually means that NodeA has
traffic to send to NodeB, and NodeB will shortly thereafter send a
response packet back to/through NodeA. In IPv4, that requires both
sides issue ARPs independently. I.e., NodeA has to ARP for NodeB, and
NodeB then later has to ARP for NodeA. A total of 4 packets, 2 of them
broadcast.

With ND, we can short circuit the need for the second packet
exchange. When NodeA issues an NS for NodeB, NodeB (per the rule we
have been discussing) goes ahead and creates a Neighbor Cache Entry
for NodeA (i.e., from the source address of the NS). When NodeB then
generates a response packet, it doesn't need to do an additional NS/NA
exchange, because it already has an entry for the desired address.

See Section 7.2.3 of RFC 4861:

> 7.2.3.  Receipt of Neighbor Solicitations
> 
>    A valid Neighbor Solicitation that does not meet any of the following
>    requirements MUST be silently discarded:
> 
>     - The Target Address is a "valid" unicast or anycast address
>       assigned to the receiving interface [ADDRCONF],
> 
>     - The Target Address is a unicast or anycast address for which the
>       node is offering proxy service, or
> 
>     - The Target Address is a "tentative" address on which Duplicate
>       Address Detection is being performed [ADDRCONF].
> 
>    If the Target Address is tentative, the Neighbor Solicitation should
>    be processed as described in [ADDRCONF].  Otherwise, the following
>    description applies.  If the Source Address is not the unspecified
>    address and, on link layers that have addresses, the solicitation
>    includes a Source Link-Layer Address option, then the recipient
>    SHOULD create or update the Neighbor Cache entry for the IP Source
>    Address of the solicitation.  If an entry does not already exist, the
>    node SHOULD create a new one and set its reachability state to STALE
>    as specified in Section 7.3.3.  If an entry already exists, and the
>    cached link-layer address differs from the one in the received Source
>    Link-Layer option, the cached address should be replaced by the
>    received address, and the entry's reachability state MUST be set to
>    STALE.
> 
>    If a Neighbor Cache entry is created, the IsRouter flag SHOULD be set
>    to FALSE.  This will be the case even if the Neighbor Solicitation is
>    sent by a router since the Neighbor Solicitation messages do not
>    contain an indication of whether or not the sender is a router.  In
>    the event that the sender is a router, subsequent Neighbor
>    Advertisement or Router Advertisement messages will set the correct
>    IsRouter value.  If a Neighbor Cache entry already exists, its
>    IsRouter flag MUST NOT be modified.
> 
>    If the Source Address is the unspecified address, the node MUST NOT
>    create or update the Neighbor Cache entry.
> 
>    After any updates to the Neighbor Cache, the node sends a Neighbor
>    Advertisement response as described in the next section.

One could argue that the above should be tweaked to say "create an NCE
only if the source address of the NS is on-link per other
indications". But given that the NCE is not actually used, if that
address is not considered on-link, there is no harm in just leaving
things as they are. The specification as written does not seem to be
resulting in broken implementations.

Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------