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

Thomas,

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

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.

Hemant 

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

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