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

"Hemant Singh (shemant)" <> Thu, 10 July 2008 02:49 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 381153A67AD; Wed, 9 Jul 2008 19:49:34 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 497D13A67AD for <>; Wed, 9 Jul 2008 19:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.598
X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6DEx0a7MRypH for <>; Wed, 9 Jul 2008 19:49:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C0C7C3A6765 for <>; Wed, 9 Jul 2008 19:49:30 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.30,335,1212364800"; d="scan'208";a="13776359"
Received: from ([]) by with ESMTP; 10 Jul 2008 02:21:37 +0000
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id m6A2LbC7006830; Wed, 9 Jul 2008 22:21:37 -0400
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id m6A2LbM0028388; Thu, 10 Jul 2008 02:21:37 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 22:21:37 -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, 9 Jul 2008 22:21:36 -0400
Message-ID: <>
In-Reply-To: <>
Thread-Topic: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Thread-Index: AcjiLnFqkt4nKpFYTP6g2ZxqW55qyQABARgQ
References: <> <> <> <> <> <> <>
From: "Hemant Singh (shemant)" <>
To: "Thomas Narten" <>, "JINMEI Tatuya / ????" <>
X-OriginalArrivalTime: 10 Jul 2008 02:21:37.0517 (UTC) FILETIME=[AE4731D0:01C8E233]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5590; t=1215656497; x=1216520497; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; 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=22Thomas=20Narten=22=20<>,=0A=20=2 0=20=20=20=20=20=20=22JINMEI=20Tatuya=20/=20????=22=20<Jinme>; bh=tEL8iMoUJqyIpEOA5AqfLaP1Zmr79CxEEoailxboWRE=; b=OVcyFDP79J4jn3Hd7SPmMCnAkVLPXR6KrqSusk+EkjPbD8luc5sfhukC1Q h5Xoi6seF9z99tuoIXdOVeLC9tB9T4nhRkVOvK5O4Ws25RIIMPpokBc/Erzj 8UHLZTm2lD;
Authentication-Results: rtp-dkim-1;; dkim=pass ( sig from verified; );
Cc: Bob Hinden <>, Brian Haberman <>,
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit


You said: 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

Right. Remember, Erik said to v6ops on the issue that David Miles raised
that if a host received an NA from a src-addr that does not exist in the
host's PrefixList, then the receiving host has to drop the NS. I also
said the same to David Miles saying ND is a link-local scoped protocol,
so how can an NS arrive in the network from a prefix that doesn't exist
in the receiving host's PrefixList? 

Frankly David's issue was a deliberate src-addr selection screw up by
the sending host. Anyhow, as you say, the bogus NCE causes no harm.
Let's think issues in this area some more. That is why I and Wes decided
we are not going to touch this rule in our subnet-model draft. We need
more consensus and discussion.


-----Original Message-----
From: Thomas Narten [] 
Sent: Wednesday, July 09, 2008 9:43 PM
To: JINMEI Tatuya / ????
Cc: Hemant Singh (shemant);; Brian Haberman; Bob Hinden
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt


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

JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <>; 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

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
>    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
>    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,
>    node SHOULD create a new one and set its reachability state to
>    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
>    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
>    to FALSE.  This will be the case even if the Neighbor Solicitation
>    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

IETF IPv6 working group mailing list
Administrative Requests: