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

[Thomas Narten <[e-mail]>]

"MILES DAVID" <[e-mail]> writes:

> Hemant,

> Thanks for your patience.

> Given we are now very clear that a receiver should drop any ND message
> from a source that it is not in its prefix list,

No, I would not go that far. There is no harm in responding to an NS
for a target address that is assigned to your interface. Indeed, it is
necessary to make communication work in some situtations. What should
not happen, however, is to use reciept of an ND message as an
indication that the sender of that message is on-link. (i.e.,
overriding or supplementing information learned from other means).

Likewise, receipt of an NA should not be taken as an indication that
the sender of that NA is on-link (i.e, anyone could just send out a
broadcast NA with bogus info in it). One should NOT create a Neighbor
Cache Entry upon receipt of a random (unsolicited) NA. (Luckily, the
spec already says you shouldn't do this, though for different
reasons.)

But if one has issued an NS for a particular address (because one
already believes the target is on-link), receipt of an NA should (of
course) update the neighbor cache for that entry.

> might I suggest the
> paragraph in question be amended to say:
> In addition to the Prefix List, individual addresses are on-link if
>    they are the target of a Redirect Message indicating on-link.

> Removing the text: 
> or the
>    source of a valid Neighbor Solicitation or Neighbor Advertisement
>    message.

> The clarification would be a step in the right direction.

IMO, removing that line is the right thing to do.

It is clear to me that bullet four in RFC 4861:

>    on-link     - an address that is assigned to an interface on a
>                  specified link.  A node considers an address to be on-
>                  link if:
> 
>                     - it is covered by one of the link's prefixes (e.g.,
>                       as indicated by the on-link flag in the Prefix
>                       Information option), or
> 
>                     - a neighboring router specifies the address as the
>                       target of a Redirect message, or
> 
>                     - a Neighbor Advertisement message is received for
>                       the (target) address, or
> 
>                     - any Neighbor Discovery message is received from
>                       the address.

Is wrong and needs tweaking. We should fix that on the next update of
the ND spec. :-)

That said, we are clearly talking about an edge case situation here
that hasn't come up in practice very often. So the urgency of fixing
this is not terribly great, IMO. But going forward (i.e, in any new
documents), we should do the right thing.

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