Subject: RE: 2461bis update

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 25 May 2005 22:17:19 -0400

This section was changed based on comments from Pekka and yourself. Note that
I'm referring to the section as a whole and not only the first paragraph. I don't remember
the intent of changing every line since I changed the whole section in rev 2. But 
the main reason for the change was clarifications and no substantial change was made.

The current text, I believe (please correct me if I'm wrong) conveyed the same 
message as the previous section in 2461. It seems that one of the sources 
of the confusion is that you're assuming the "two things" text must refer to
the same thing in 2461bis as it did in 2461. That's not the case of course. 

So to avoid meddling with text unnecessarily, I would ask you to tell me 
if this section (in 2461bis) does anything differently to implementations from 
the same section in 2461. If that's the case, please let us know and I'll fix it. 
Or, if the text is not clear, I'm happy to fix it. But the only lack of clarity you 
point to below is a result of comparing ordering of text in the current revision with
the corresponding one in 2461. It doesn't need to be the same thing (as you point out below) as long as 
the result is the same for implementations. 

In any case, if there is anything to be done, I think we should add that to the IESG
comments. I'm sure they'll require changes to text. 

Hesham

 > But, in case I was not clear enough, the point is that the relevant
 > change from RFC2461 to rfc2461bis makes the text rather unreadable.
 > So, I'd first like to know the intent of the change.
 > 
 > One specific point at the moment: Section 7.2.5 of
 > draft-ietf-ipv6-2461bis-03.txt reads:
 > 
 >    If the target's Neighbor Cache entry is in the INCOMPLETE 
 > state when
 >    the advertisement is received, one of two things happen: If the
 >    advertisement were solicited, the state is changed to REACHABLE.
 >    Otherwise, the state is set to STALE. Note that the 
 > Override flag is
 >    ignored if the entry is in the
 >    INCOMPLETE state.
 > 
 > From this paragraph, the "two things" would be:
 > 
 >   1. If the advertisement were solicited, the state is changed to
 >      REACHABLE.
 >   2. Otherwise, the state is set to STALE.
 > 
 > On the other hand, the corresponding part of RFC2461 was:
 > 
 >    If the target's Neighbor Cache entry is in the INCOMPLETE 
 > state when
 >    the advertisement is received, one of two things happens.  If the
 >    link layer has addresses and no Target Link-Layer address 
 > option is
 >    included, the receiving node SHOULD silently discard the received
 >    advertisement.  Otherwise, the receiving node performs 
 > the following
 >    steps:
 >        (....)
 > 
 > From this paragraph, the "two things" would be:
 > 
 >   1. If the link layer has addresses and no Target Link-Layer address
 >      option is included, the receiving node SHOULD silently discard
 >      the received advertisement.
 >   2. Otherwise, the receiving node performs the following steps:
 >        (....)
 > 
 > So, while the beginning part is exactly the same, the "two things"
 > seem to refer to completely different things.
 > 
 > The difference itself is not necessarily a problem.  However,
 > rfc2461bis-03 then repeats its "two things":
 > 
 >     - If the advertisement's Solicited flag is set, the state of the
 >       entry is set to REACHABLE, otherwise it is set to STALE.
 > 
 > Now this make me really confused...
 > 
 > Additionally, the relationship between the two parts beginning with
 > "If the (target's) Neighbor Cache entry is in the INCOMPLETE 
 > state" is
 > not very clear to me:
 > 
 >    If the target's Neighbor Cache entry is in the INCOMPLETE 
 > state when
 >    the advertisement is received, one of two things happen: (...)
 > 
 >    If the Neighbor Cache entry is in INCOMPLETE state, the receiving
 >    node performs the following steps:
 >       (...)
 > 
 > Note that the second part was one of the "two things" in original
 > RFC2461.
 > 
 > All of these things just confused me about what this part wanted to
 > convey.
 > 
 > So, again, I'd first like to know the intent of the change, and then
 > I'm willing to suggest explicit text according to the intent.
 > 
 > I hope this time I'm clear enough.  Thanks,
 > 
 > 					JINMEI, Tatuya
 > 					Communication Platform Lab.
 > 					Corporate R&D Center, 
 > Toshiba Corp.
 > 					[email-masked]
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 26 May 2005 12:01:37 +0900

>>>>> On Wed, 25 May 2005 22:17:19 -0400, 
>>>>> "Soliman, Hesham" <[email-masked]> said:

> the main reason for the change was clarifications and no substantial change was made.

The only comments I made for this section (except the very recent one
we are now discussing) were the latter part of the section.  More
specifically, I agreed with Pekka that the latter part contained a
redundant condition, and also suggested to clarify the complex
conditions in the latter part.  On the other hand, I didn't even
expect a change (from RFC2461) to the first part.  Actually, I didn't
understand the points of the changes to the first part from RFC2461
and asked the intent, rather than suggested any changes from RFC2461.
That said, I'm even happy with the original text of RFC2461 about the
first part of this section.  (I actually said that before, see
http://www1.ietf.org/mail-archive/web/ipv6/current/msg04818.html)

As a meta-level comment, if we cannot remember the specific reason for
revising the text, I don't think it's a good idea to revise that
(since it can even introduce a new bug that was not in the original
document).

At least I don't see any problem in the first part of this section in
original RFC2461, so I'd now rather suggest to leave it (the first
part of 7.2.5) as was in original RFC2461.

Finally, I also noticed that Pekka's comment was not really applied in
draft-ietf-ipv6-2461bis-03.txt.  Specifically, the current text is
different from what I proposed in the following message:
  http://www1.ietf.org/mail-archive/web/ipv6/current/msg04819.html
(you seemed to agree with the change:
 http://www1.ietf.org/mail-archive/web/ipv6/current/msg04822.html)

That is, I proposed the following text:

   II. If the Override flag is set, or the supplied link-layer address
     is the same as that in the cache, or no Target Link-layer address
     option was supplied, the received advertisement MUST update the
     Neighbor Cache entry as follows:

but rfc2461bis-03 actually reads:

   II. If the Override flag is set, or the supplied Override flag is
       Clear, or the supplied link-layer address is the same as that in
       the cache, or no Target Link-layer address option was supplied,
       the received advertisement MUST update the Neighbor Cache entry
       as follows:

This is clearly incorrect (the condition is then always true, since it
says, "If A, or !A, or ..." (where A = the Override flag is set))

How I'd like to propose a complete suggestion.  The point is:

  - don't change the first of section 7.2.5 from RFC2461
  - address Pekka's point correctly

Then the entire section would then be as follows.  Is this okay for
you?

7.2.5.  Receipt of Neighbor Advertisements

   When a valid Neighbor Advertisement is received (either solicited or
   unsolicited), the Neighbor Cache is searched for the target's entry.
   If no entry exists, the advertisement SHOULD be silently discarded.
   There is no need to create an entry if none exists, since the
   recipient has apparently not initiated any communication with the
   target.

   Once the appropriate Neighbor Cache entry has been located, the
   specific actions taken depend on the state of the Neighbor Cache
   entry, the flags in the advertisement and the actual link-layer
   address supplied.

   If the target's Neighbor Cache entry is in the INCOMPLETE state when
   the advertisement is received, one of two things happens.  If the
   link layer has addresses and no Target Link-Layer address option is
   included, the receiving node SHOULD silently discard the received
   advertisement.  Otherwise, the receiving node performs the following
   steps:

    - It records the link-layer address in the Neighbor Cache entry.

    - It sets the IsRouter flag in the cache entry based on the Router
      flag in the received advertisement.

    - It sends any packets queued for the neighbor awaiting address
      resolution.

   Note that the Override flag is ignored if the entry is in the
   INCOMPLETE state.

   If the target's Neighbor Cache entry is in any state other than
   INCOMPLETE when the advertisement is received, the following actions
   take place:

   I. If the Override flag is clear and the supplied link-layer address
     differs from that in the cache, then one of two actions takes
     place:
     a. If the state of the entry is REACHABLE, set it to STALE, but
        do not update the entry in any other way.
     b. Otherwise, the received advertisement should be ignored and MUST
        NOT update the cache.
   II. If the Override flag is set, or the supplied link-layer address
     is the same as that in the cache, or no Target Link-layer address
     option was supplied, the received advertisement MUST update the
     Neighbor Cache entry as follows:

    - The link-layer address in the Target Link-Layer Address option
      MUST be inserted in the cache (if one is supplied and is different
      than the already recorded address).

    - If the Solicited flag is set, the state of the entry MUST be set
      to REACHABLE.  If the Solicited flag is zero and the link-layer
      address was updated with a different address the state MUST be set
      to STALE.  Otherwise, the entry's state remains unchanged.

      An advertisement's Solicited flag should only be set if the
      advertisement is a response to a Neighbor Solicitation.  Because
      Neighbor Unreachability Detection Solicitations are sent to the
      cached link-layer address, receipt of a solicited advertisement
      indicates that the forward path is working.  Receipt of an
      unsolicited advertisement, however, suggests that a neighbor has
      urgent information to announce (e.g., a changed link-layer
      address).  If the urgent information indicates a change from what
      a node is currently using, the node should verify the reachability
      of the (new) path when it sends the next packet.  There is no need
      to update the state for unsolicited advertisements that do not
      change the contents of the cache.

    - The IsRouter flag in the cache entry MUST be set based on the
      Router flag in the received advertisement.  In those cases where
      the IsRouter flag changes from TRUE to FALSE as a result of this
      update, the node MUST remove that router from the Default Router
      List and update the Destination Cache entries for all destinations
      using that neighbor as a router as specified in Section 7.3.3.
      This is needed to detect when a node that is used as a router
      stops forwarding packets due to being configured as a host.

   The above rules ensure that the cache is updated either when the
   Neighbor Advertisement takes precedence (i.e., the Override flag is
   set) or when the Neighbor Advertisement refers to the same link-layer
   address that is currently recorded in the cache.  If none of the
   above apply, the advertisement prompts future Neighbor Unreachability
   Detection (if it is not already in progress) by changing the state in
   the cache entry.