After discussion with authors (see attachments), I am
now convinced that there is no issue with the text as
it stands and am withdrawing the comment. If anyone
feels differently, please follow-up on the list.
Thanks - Fred
[EMAIL PROTECTED]
-----Original Message-----
From: Templin, Fred L
Sent: Thursday, October 26, 2006 4:10 PM
To: ipv6@ietf.org
Subject: Question about "on-link" in RFC2461(bis)
I have a question about on-link determination for IPv6 ND.
(RFC2461(bis), Section 2.1) has the following definition
for on-link:
"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, 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."
Clauses 1 and 2 seem to be the same considerations as for IPv4,
but clauses 3 and 4 seem to imply that IPv6 ND implementations
"snoop" on ND messages and "remember" the addresses of neighbors
heard from on the link, e.g., even for multicast ND messages that
are unsolicited or in response to a third party's solicitations.
This is independent of any prefixes assigned on an interface and
also seems to be independent of any neighbor cache entries, since
receipt of ND messages does not necessarily result in neighbor
cache entries being created.
So my question is, for how long will an implementation remember
the addresses of on-link neighbors discovered from snooping on
ND messages - forever? (The spec doesn't seem to provide guidance
on this?) And, what happens when a neighbor that was previously
on-link departs? Will the node try indefinitely to reach the
now-departed neighbor on the local link even if more up-to-date
information is received, e.g., from a routing protocol? The spec
seems to be ambiguous on these points - am I missing something?
Fred
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--- Begin Message ---
Hi Fred,
I have a question below.
> - a Neighbor Advertisement message is received for
> the (target) address, or
>
> - any Neighbor Discovery message is received from
> the address."
>
> Clauses 1 and 2 seem to be the same considerations as for IPv4,
> but clauses 3 and 4 seem to imply that IPv6 ND implementations
> "snoop" on ND messages and "remember" the addresses of neighbors
> heard from on the link, e.g.,
=> The "remember" part makes sense, however, I don't know why you say
that implementations need to "snoop" on ND messages. The two billets
above (3, 4) talk about messages _received_.
even for multicast ND messages that
> are unsolicited or in response to a third party's solicitations.
=> Why do you conclude that from those bullets?
> This is independent of any prefixes assigned on an interface and
> also seems to be independent of any neighbor cache entries, since
> receipt of ND messages does not necessarily result in neighbor
> cache entries being created.
>
> So my question is, for how long will an implementation remember
> the addresses of on-link neighbors discovered from snooping on
> ND messages - forever? (The spec doesn't seem to provide guidance
> on this?)
=> It seems reasonable to remember this for the duration of the cache
entry corresponding to such neighbour.
And, what happens when a neighbor that was previously
> on-link departs?
=> If the cache entry is still there then all information related to
such entry will still be valid. Does that make sense ?
Hesham
--- End Message ---
--- Begin Message ---
Hesham,
Thanks for the reply; see below for follow-up:
> I have a question below.
>
>> - a Neighbor Advertisement message is received for
>> the (target) address, or
>>
>> - any Neighbor Discovery message is received from
>> the address."
>>
>> Clauses 1 and 2 seem to be the same considerations as for IPv4,
>> but clauses 3 and 4 seem to imply that IPv6 ND implementations
>> "snoop" on ND messages and "remember" the addresses of neighbors
>> heard from on the link, e.g.,
>
> => The "remember" part makes sense, however, I don't know why you say
> that implementations need to "snoop" on ND messages. The two billets
> above (3, 4) talk about messages _received_.
Right; I am only talking about ND messages received. By "snoop"
I was only meaning that an implementation examines received ND
messages for their IPv6 source address and/or target address
and remembers that address as being on-link.
>> even for multicast ND messages that
>> are unsolicited or in response to a third party's solicitations.
>
> => Why do you conclude that from those bullets?
Example is an NA(DAD) sent to 'All Nodes' multicast in response
to an NS(DAD). All nodes on the link will receive it, so clauses
3 and 4 seem to imply that receiving nodes should remember the
source address as belonging to an onlink neighbor.
>> This is independent of any prefixes assigned on an interface and
>> also seems to be independent of any neighbor cache entries, since
>> receipt of ND messages does not necessarily result in neighbor
>> cache entries being created.
>>
>> So my question is, for how long will an implementation remember
>> the addresses of on-link neighbors discovered from snooping on
>> ND messages - forever? (The spec doesn't seem to provide guidance
>> on this?)
>
> => It seems reasonable to remember this for the duration of the cache
> entry corresponding to such neighbour.
But, there may not be any cache entry before or after the
ND message was received since receipt of an NA(DAD) or even
an unsolicited NA does not necessarily result in a cache
entry being created/updated. So, should the receiving node
remember the source and/or target address as belonging to
an on-link neighbor even if no cache entry exists? Clauses
3 and 4 seem to say that it should.
>> And, what happens when a neighbor that was previously
>> on-link departs?
>
> => If the cache entry is still there then all information related to
> such entry will still be valid. Does that make sense ?
Yes, but clauses 3 and 4 seem to imply that an address
heard from in any received ND message should be remembered
as *onlink for all time independent of any neighbor cache
entries*, and I don't think that is right?
A simple reword of clauses 3 and 4 for the definition for
onlink might satisfy my concerns; here is a suggested reword:
"- a Neighbor Advertisement message that updates the
neighbor cache is received for the (target) address, or
- any Neighbor Discovery message that updates the
neighbor cache is received from the address."
Where it also needs to be made clear for clauses 3 and 4 that
the "onlink" property of the address shares fate with the
neighbor cache entry - but, I'm not sure how to add something
like that to the definition?
Fred
[EMAIL PROTECTED]
Hesham
--- End Message ---
--- Begin Message ---
> > => The "remember" part makes sense, however, I don't know
> why you say
> > that implementations need to "snoop" on ND messages. The
> two billets
> > above (3, 4) talk about messages _received_.
>
> Right; I am only talking about ND messages received. By "snoop"
> I was only meaning that an implementation examines received ND
> messages for their IPv6 source address and/or target address
> and remembers that address as being on-link.
=> Ok, that's not what I think of the meaning of snoop, but anyway, we
agree on the final meaning.
> > => Why do you conclude that from those bullets?
>
> Example is an NA(DAD) sent to 'All Nodes' multicast in response
> to an NS(DAD). All nodes on the link will receive it, so clauses
> 3 and 4 seem to imply that receiving nodes should remember the
> source address as belonging to an onlink neighbor.
=> Right, I see what you mean.
> >> So my question is, for how long will an implementation remember
> >> the addresses of on-link neighbors discovered from snooping on
> >> ND messages - forever? (The spec doesn't seem to provide guidance
> >> on this?)
> >
> > => It seems reasonable to remember this for the duration
> of the cache
> > entry corresponding to such neighbour.
>
> But, there may not be any cache entry before or after the
> ND message was received since receipt of an NA(DAD) or even
> an unsolicited NA does not necessarily result in a cache
> entry being created/updated. So, should the receiving node
> remember the source and/or target address as belonging to
> an on-link neighbor even if no cache entry exists? Clauses
> 3 and 4 seem to say that it should.
=> They're definitely silent on the presence of an entry.
> > => If the cache entry is still there then all information
> related to
> > such entry will still be valid. Does that make sense ?
>
> Yes, but clauses 3 and 4 seem to imply that an address
> heard from in any received ND message should be remembered
> as *onlink for all time independent of any neighbor cache
> entries*, and I don't think that is right?
=> Yes I agree with you on the need to make those clauses relevant to
existing NC entries.
>
> A simple reword of clauses 3 and 4 for the definition for
> onlink might satisfy my concerns; here is a suggested reword:
>
> "- a Neighbor Advertisement message that updates the
> neighbor cache is received for the (target) address, or
>
> - any Neighbor Discovery message that updates the
> neighbor cache is received from the address."
>
> Where it also needs to be made clear for clauses 3 and 4 that
> the "onlink" property of the address shares fate with the
> neighbor cache entry - but, I'm not sure how to add something
> like that to the definition?
=> I think the above rewording is fine. It is common sense that any
information in a particular entry is lost once that entry is removed. So
simply tying the behaviour above with the presence of an entry should be
sufficient IMO.
Hesham
--- End Message ---
--- Begin Message ---
> > I have a question below.
> >
> >> - a Neighbor Advertisement message is received for
> >> the (target) address, or
> >>
> >> - any Neighbor Discovery message is received from
> >> the address."
> >>
> >> Clauses 1 and 2 seem to be the same considerations as for IPv4,
> >> but clauses 3 and 4 seem to imply that IPv6 ND implementations
> >> "snoop" on ND messages and "remember" the addresses of neighbors
> >> heard from on the link, e.g.,
> >
> > => The "remember" part makes sense, however, I don't know why you say
> > that implementations need to "snoop" on ND messages. The two billets
> > above (3, 4) talk about messages _received_.
I agree. I don't know why you think snoop is implied here. It is not,
AFAIAC.
Also, I don't know why you say "remember". If you recieve a NA or ND
message as described above, that means that the address at issue is
on-link. Whether or not you rememeber that for some period of time is
a separate issue, and is (presumably) covered in specific sections of
the spec that talk about updating cache entries. (Remember, the above
is just a definition.)
> >> even for multicast ND messages that
> >> are unsolicited or in response to a third party's solicitations.
> >
> > => Why do you conclude that from those bullets?
> Example is an NA(DAD) sent to 'All Nodes' multicast in response
> to an NS(DAD). All nodes on the link will receive it, so clauses
> 3 and 4 seem to imply that receiving nodes should remember the
> source address as belonging to an onlink neighbor.
No, you are reading too much. You only "remember" if it makes sense to
save that information for some period of time. The text you quote is a
definition. It is not describing protocol behavior (i.e., _when_ you
cache info and when you don't)
> >> This is independent of any prefixes assigned on an interface and
> >> also seems to be independent of any neighbor cache entries, since
> >> receipt of ND messages does not necessarily result in neighbor
> >> cache entries being created.
> >>
> >> So my question is, for how long will an implementation remember
> >> the addresses of on-link neighbors discovered from snooping on
> >> ND messages - forever? (The spec doesn't seem to provide guidance
> >> on this?)
> >
> > => It seems reasonable to remember this for the duration of the cache
> > entry corresponding to such neighbour.
Right. But I don't think anything needs to be said about this in the
definition section.
Is there another part of the spec that does not cover this sufficiently?
> But, there may not be any cache entry before or after the
> ND message was received since receipt of an NA(DAD) or even
> an unsolicited NA does not necessarily result in a cache
> entry being created/updated. So, should the receiving node
> remember the source and/or target address as belonging to
> an on-link neighbor even if no cache entry exists? Clauses
> 3 and 4 seem to say that it should.
No. See above.
> >> And, what happens when a neighbor that was previously
> >> on-link departs?
NUD handles this. As long as the cached info still "works", we
continue using it. If something goes wrong, we time out the entry and
restart the address next-hop resolution process.
> A simple reword of clauses 3 and 4 for the definition for
> onlink might satisfy my concerns; here is a suggested reword:
Per above, I don't think any changes are needed for clauses 3&4.
> Where it also needs to be made clear for clauses 3 and 4 that
> the "onlink" property of the address shares fate with the
> neighbor cache entry - but, I'm not sure how to add something
> like that to the definition?
Don't understand this.
Thomas
--- End Message ---
--- Begin Message ---
Hello Thomas - please see below for follow-up:
>> > => The "remember" part makes sense, however, I don't know why you
say
>> > that implementations need to "snoop" on ND messages. The two
billets
>> > above (3, 4) talk about messages _received_.
>
> I agree. I don't know why you think snoop is implied here. It is not,
> AFAIAC.
In my reply to Hesham, I clarified what I meant by "snoop":
"Right; I am only talking about ND messages received. By "snoop"
I was only meaning that an implementation examines received ND
messages for their IPv6 source address and/or target address
and remembers that address as being on-link."
I agree that the term "snoop" was poorly chosen and if I
had it to do over again I wouldn't have used the term. But,
it isn't important to the rest of the discussion below so
maybe just forget it.
> Also, I don't know why you say "remember". If you recieve a NA or ND
> message as described above, that means that the address at issue is
> on-link. Whether or not you rememeber that for some period of time is
> a separate issue, and is (presumably) covered in specific sections of
> the spec that talk about updating cache entries. (Remember, the above
> is just a definition.)
The term "on-link" is cited 65 times throughout the document
so IMO the definition needs to be as precise as possible. When
you say: "If you receive a NA or ND message as described above,
that means that the address at issue is on-link." that goes to
my very point. The point is that the on-link property of an
address needs to be maintained in conjunction with a neighbor
cache entry for the address and not seperately. The definition
is ambiguous on that point and could lead to harmful on-link
determinations.
>>> Example is an NA(DAD) sent to 'All Nodes' multicast in response
>>> to an NS(DAD). All nodes on the link will receive it, so clauses
>>> 3 and 4 seem to imply that receiving nodes should remember the
>>> source address as belonging to an onlink neighbor.
>
> No, you are reading too much. You only "remember" if it makes sense to
> save that information for some period of time. The text you quote is a
> definition. It is not describing protocol behavior (i.e., _when_ you
> cache info and when you don't)
I am seeing an ambiguous definition that could lead to harmful
on-link determinations. I disagree that I am "reading too much";
to the contray by the current definition I am reading too little.
As evidence to the point, the issue of on-link determination is
seeing critical scrutiny in the NETLMM wg right now, and there is
also a v6ops document in the RFC editor queue on "IPv6 Neighbor
Discover On-link Assumption Considered Harmful".
>> >> So my question is, for how long will an implementation remember
>> >> the addresses of on-link neighbors discovered from snooping on
>> >> ND messages - forever? (The spec doesn't seem to provide guidance
>> >> on this?)
>> >
>> > => It seems reasonable to remember this for the duration of the
cache
>> > entry corresponding to such neighbour.
>
> Right. But I don't think anything needs to be said about this in the
> definition section.
The definition is currently ambiguous on this point and
easily fixed.
> Is there another part of the spec that does not cover this
sufficiently?
In places where the term "on-link" is cited in which on-link
determination is other than due to an on-link prefix, there is
opportunity for harmful on-link determination due to the ambiguous
definition. Probably the best example is Section 6.3.4, the sentence:
"The reasons for an address being treated as on-link is specified in
the definition of "on-link" in Section 2.1." A second example is in
Section 5.2, the sentence: "If the destination is on-link, the
next-hop address is the same as the packet's destination address."
A third example is Section 7.2, the sentence: "Address resolution
is performed only on addresses that are determined to be on-link and
for which the sender does not know the corresponding link-layer
address (see section 5.2)."
>> But, there may not be any cache entry before or after the
>> ND message was received since receipt of an NA(DAD) or even
>> an unsolicited NA does not necessarily result in a cache
>> entry being created/updated. So, should the receiving node
>> remember the source and/or target address as belonging to
>> an on-link neighbor even if no cache entry exists? Clauses
>> 3 and 4 seem to say that it should.
>
> No. See above.
IMO, the definition is ambiguous and could lead to harmful
on-link determinations.
>> >> And, what happens when a neighbor that was previously
>> >> on-link departs?
>
> NUD handles this. As long as the cached info still "works", we
> continue using it. If something goes wrong, we time out the entry and
> restart the address next-hop resolution process.
I agree - as long as the on-link property of an address is
maintained *in conjunction with* a neighbor cache entry for
the address. But, if an implementation maintains the on-link
property of the address *independently of* the neighbor cache,
it could try forever to reach a node that was formerly on the
link as an on-link neighbor, even though the node has long
since departed.
>> A simple reword of clauses 3 and 4 for the definition for
>> onlink might satisfy my concerns; here is a suggested reword:
>
> Per above, I don't think any changes are needed for clauses 3&4.
Disagree; the definition is key to the entire spec and
ambiguous as it currently stands. It is also easily fixed.
>> Where it also needs to be made clear for clauses 3 and 4 that
>> the "onlink" property of the address shares fate with the
>> neighbor cache entry - but, I'm not sure how to add something
>> like that to the definition?
>
> Don't understand this.
Maybe just forget it then; it's not important to the
discussion above.
Thanks - Fred
[EMAIL PROTECTED]
--- End Message ---
--- Begin Message ---
"Templin, Fred L" <[EMAIL PROTECTED]> writes:
> I agree that the term "snoop" was poorly chosen and if I
> had it to do over again I wouldn't have used the term. But,
> it isn't important to the rest of the discussion below so
> maybe just forget it.
Agree.
> > Also, I don't know why you say "remember". If you recieve a NA or ND
> > message as described above, that means that the address at issue is
> > on-link. Whether or not you rememeber that for some period of time is
> > a separate issue, and is (presumably) covered in specific sections of
> > the spec that talk about updating cache entries. (Remember, the above
> > is just a definition.)
> The term "on-link" is cited 65 times throughout the document
> so IMO the definition needs to be as precise as possible. When
> you say: "If you receive a NA or ND message as described above,
> that means that the address at issue is on-link." that goes to
> my very point. The point is that the on-link property of an
> address needs to be maintained in conjunction with a neighbor
> cache entry for the address and not seperately. The definition
> is ambiguous on that point and could lead to harmful on-link
> determinations.
I don't see this.
> >>> Example is an NA(DAD) sent to 'All Nodes' multicast in response
> >>> to an NS(DAD). All nodes on the link will receive it, so clauses
> >>> 3 and 4 seem to imply that receiving nodes should remember the
> >>> source address as belonging to an onlink neighbor.
> >
> > No, you are reading too much. You only "remember" if it makes sense to
> > save that information for some period of time. The text you quote is a
> > definition. It is not describing protocol behavior (i.e., _when_ you
> > cache info and when you don't)
> I am seeing an ambiguous definition that could lead to harmful
> on-link determinations.
At one level, I have to note that this document/definition has existed
for 10 years. Can you point to any one example where the definition
has caused confusion or ambiguity in practice? I can't think of any
one case.
I think you are making this way more complicated than is justified.
> I disagree that I am "reading too much"; to the contray by the
> current definition I am reading too little. As evidence to the
> point, the issue of on-link determination is seeing critical
> scrutiny in the NETLMM wg right now, and there is also a v6ops
> document in the RFC editor queue on "IPv6 Neighbor Discover On-link
> Assumption Considered Harmful".
I don't see how the above are any evidence that that definition is
unclear. Are people arguing about a problem with the definition? Would
a change in definition make the above issues go away or change in any
way?
> In places where the term "on-link" is cited in which on-link
> determination is other than due to an on-link prefix, there is
> opportunity for harmful on-link determination due to the ambiguous
> definition. Probably the best example is Section 6.3.4, the sentence:
> "The reasons for an address being treated as on-link is specified in
> the definition of "on-link" in Section 2.1." A second example is in
> Section 5.2, the sentence: "If the destination is on-link, the
> next-hop address is the same as the packet's destination address."
> A third example is Section 7.2, the sentence: "Address resolution
> is performed only on addresses that are determined to be on-link and
> for which the sender does not know the corresponding link-layer
> address (see section 5.2)."
Sorry, I just don't get what the problem is.
> IMO, the definition is ambiguous and could lead to harmful
> on-link determinations.
Please take this to the list then and see if you can get any
support. I don't see the problem, and I don't see your suggested
changes as making any difference. In fact, I think they are incorrect,
as explained below.
> >> >> And, what happens when a neighbor that was previously
> >> >> on-link departs?
> >
> > NUD handles this. As long as the cached info still "works", we
> > continue using it. If something goes wrong, we time out the entry and
> > restart the address next-hop resolution process.
> I agree - as long as the on-link property of an address is
> maintained *in conjunction with* a neighbor cache entry for
> the address. But, if an implementation maintains the on-link
> property of the address *independently of* the neighbor cache,
> it could try forever to reach a node that was formerly on the
> link as an on-link neighbor, even though the node has long
> since departed.
Why on earth would an implementation do the above as you suggest?
Again, this hasn't seemed to be a problem in practice. What am I
missing?
> A simple reword of clauses 3 and 4 for the definition for
> onlink might satisfy my concerns; here is a suggested reword:
> "- a Neighbor Advertisement message that updates the
> neighbor cache is received for the (target) address, or
No. By definition, an address is on-link if a router is sending out an
RA with the prefix information option covering that prefix and if the
lifetime for the option hasn't expired. Whether any of this
information is stored in a cache or not doesn't change the definition.
Note: a prefix may be on-link, but an implementation may not know that
(e.g., cache is not maintained, RA was not received, etc.) You're
definition above tries to make the definition of on-link be related to
what is cached. I think that is technically incorrect.
> - any Neighbor Discovery message that updates the
> neighbor cache is received from the address."
same here.
> Where it also needs to be made clear for clauses 3 and 4 that
> the "onlink" property of the address shares fate with the
> neighbor cache entry - but, I'm not sure how to add something
> like that to the definition?
You are tying to much to implementation here, IMO.
Re-reading all this, I do think one change might be appropriate for
clause one:
OLD:
- it is covered by one of the link's prefixes, or
NEW:
- it is covered by one of the link's on-link prefixes, or
That said, no one has seemed to have had a problem with the clause as
previously written.
Thomas
--- End Message ---
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
