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

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:narten@us.ibm.com] 
Sent: Thursday, July 10, 2008 9:52 AM
To: Hemant Singh (shemant)
Cc: Jinmei_Tatuya@isc.org; Bob Hinden; Brian Haberman; ipv6@ietf.org
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

"Hemant Singh (shemant)" <shemant@cisco.com> 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
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------