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

Thomas,

BTW, Erik sent this email to v6ops on June 25th, 2006 that the receiver
should drop such an ND Message - it's snipped between quotes below.

"David Miles wrote:

I'd also suggest that in the Message Validation section we include the
checks you mention (is the source of the ND or target of the NA an
on-link prefix per Prefix List) 

If you do that, how would communication work in your example?

The NS would be dropped since its source isn't covered by an on-link
prefix on the receiver, right? 

   Erik"

Anyhow, we already sent an email to Erik suggesting the following
changes to our subnet-model draft. The gist of our changes are indeed to
say that the 4th bullet of on-link definition is not a valid means to
determine on-link. 

For reference, here is the URL to our draft.

http://www.ietf.org/internet-drafts/draft-ietf-6man-ipv6-subnet-model-00
.txt

Here are the two changes we have proposed to our draft.

1. In Introduction section, here is new text:

[In addition to the Prefix List, individual addresses are on-link if
they are the target of a Redirect Message indicating on-link.]

2. In section 2, we reworded bullet 2 as follows:

                  The configuration of an IPv6 address, whether through
                  IPv6 stateless address autoconfiguration [RFC4862],
                  DHCPv6[RFC3315], or manual configuration MUST NOT
imply 
                  that any prefix is on-link. A host is explicitly told
that prefixes or addresses 
                  are on-link through the means specified in the
definition of on-link in the 
                  Terminology section of [RFC4861].  The source of an ND
message 
                  is no longer used for on-link determination, which is
a change from [RFC4861].  
                  Note that the requirement for manually configured
addresses is not explicitly mentioned 
                  in [RFC4861]. 

Do the changes look OK to you and everyone else?

Thanks.

Hemant 

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com] 
Sent: Thursday, July 03, 2008 11:34 AM
To: MILES DAVID
Cc: Hemant Singh (shemant); Wes Beebee (wbeebee); ipv6@ietf.org;
erik.nordmark@sun.com
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

"MILES DAVID" <David.Miles@alcatel-lucent.com.au> 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
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------