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

[Thomas Narten <[e-mail]>]

Jinmei,

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

JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <[e-mail]> 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
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------