Thomas,
You say: " bullets 3 & 4 MUST NOT be taken to indicate an address is
on-link."
But the Terminology section and the on-link definition clearly say
either of bullets 3 and 4 signify that the address is on-link. I have
snipped the text of the definition below.
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.
So are you saying bullets 3 and 4 need to change? Anyway, Tatuya is not
letting any change to RFC4861 in our draft. So why is our text not
acceptable when we say these bullets need discussion?
Hemant
-----Original Message-----
From: Thomas Narten [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 10, 2008 9:52 AM
To: Hemant Singh (shemant)
Cc: [EMAIL PROTECTED]; Bob Hinden; Brian Haberman; [email protected]
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
"Hemant Singh (shemant)" <[EMAIL PROTECTED]> writes:
> Tatuya,
> Erik suggested some new text to us related to bullets 3 and 4 of
> on-link definition in the Terminology section of RFC4861. He is busy
> this week - we are sending this on his behalf. As you know bullet 4 is
> being debated in 6man. Erik thinks even bullet 3 is suspect. We don't
> want such suspect information to be lost in archived emails of 6man.
> So we added the information to our draft. Please see the new paragraph
from us:
> The on-link definition in the Terminology section of [RFC4861]
> defines the complete list of cases where an address is
> considered on-link. Note, in particular, that Redirect Messages
> can also indicate an address is off-link. As of the writing of
> this document, bullets three and four of the on-link definition
> are being debated and may need further clarification.
> Individual address entries can be expired by the Neighbor
> Unreachability Detection mechanism.
> Please let us know if the new text works for you?
It does not work for me.
Looking at the bullets 3 & 4:
> 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.
IMO, bullets 3 & 4 MUST NOT be taken to indicate an address is on-link.
Nowhere in the ND specification does receipt of an NA or NS result in
the creation of a Destination Cache Entry that overrides the first two
bullets. The first 2 bullets are the only way (excluding manual
configuration) that an address is indicated to be on-link.
Yes, there are cases where and NS will create or update a Neighbor
Cache Entry, but that is NOT the same thing as indicating that the
address is on-link.
Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
