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

> 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 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.

    - If the advertisement's Solicited flag is set, the state of the
      entry is set to REACHABLE, otherwise it is set to STALE.

    - 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.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to