(B > The only comments I made for this section (except the very recent one
(B > we are now discussing) were the latter part of the section. More
(B > specifically, I agreed with Pekka that the latter part contained a
(B > redundant condition, and also suggested to clarify the complex
(B > conditions in the latter part. On the other hand, I didn't even
(B > expect a change (from RFC2461) to the first part. Actually, I didn't
(B > understand the points of the changes to the first part from RFC2461
(B > and asked the intent, rather than suggested any changes from RFC2461.
(B > That said, I'm even happy with the original text of RFC2461 about the
(B > first part of this section. (I actually said that before, see
(B > http://www1.ietf.org/mail-archive/web/ipv6/current/msg04818.html)
(B >
(B > As a meta-level comment, if we cannot remember the specific
(B > reason for
(B > revising the text, I don't think it's a good idea to revise that
(B > (since it can even introduce a new bug that was not in the original
(B > document).
(B >
(B > At least I don't see any problem in the first part of this section in
(B > original RFC2461, so I'd now rather suggest to leave it (the first
(B > part of 7.2.5) as was in original RFC2461.
(B >
(B > Finally, I also noticed that Pekka's comment was not really
(B > applied in
(B > draft-ietf-ipv6-2461bis-03.txt. Specifically, the current text is
(B > different from what I proposed in the following message:
(B > http://www1.ietf.org/mail-archive/web/ipv6/current/msg04819.html
(B > (you seemed to agree with the change:
(B > http://www1.ietf.org/mail-archive/web/ipv6/current/msg04822.html)
(B >
(B > That is, I proposed the following text:
(B >
(B > II. If the Override flag is set, or the supplied
(B > link-layer address
(B > e is the same as that in the cache, or no Target
(B > Link-layer address
(B > option was supplied, the received advertisement MUST update the
(B > Neighbor Cache entry as follows:
(B >
(B > but rfc2461bis-03 actually reads:
(B >
(B > II. If the Override flag is set, or the supplied Override flag is
(B > Clear, or the supplied link-layer address is the same
(B > as that in
(B > the cache, or no Target Link-layer address option was
(B > supplied,
(B > the received advertisement MUST update the Neighbor
(B > Cache entry
(B > as follows:
(B
(B=> Yes this is clearly wrong. I'll update this. As for the rest, you still
(Bdon't say
(Bwhat's wrong with it, you just ask for it to be changed back. I don't agree
(Bwith your suggestion because there is no basis for it, but to save cycles I'll
(Bchange it back...
(B
(BHesham
(B
(B
(B >
(B > This is clearly incorrect (the condition is then always
(B > true, since it
(B > says, "If A, or !A, or ..." (where A = the Override flag is set))
(B >
(B > How I'd like to propose a complete suggestion. The point is:
(B >
(B > - don't change the first of section 7.2.5 from RFC2461
(B > - address Pekka's point correctly
(B >
(B > Then the entire section would then be as follows. Is this okay for
(B > you?
(B >
(B > 7.2.5. Receipt of Neighbor Advertisements
(B >
(B > When a valid Neighbor Advertisement is received (either
(B > solicited or
(B > unsolicited), the Neighbor Cache is searched for the
(B > target's entry.
(B > If no entry exists, the advertisement SHOULD be silently
(B > discarded.
(B > There is no need to create an entry if none exists, since the
(B > recipient has apparently not initiated any communication with the
(B > target.
(B >
(B > Once the appropriate Neighbor Cache entry has been located, the
(B > specific actions taken depend on the state of the Neighbor Cache
(B > entry, the flags in the advertisement and the actual link-layer
(B > address supplied.
(B >
(B > If the target's Neighbor Cache entry is in the INCOMPLETE
(B > state when
(B > the advertisement is received, one of two things happens. If the
(B > link layer has addresses and no Target Link-Layer address
(B > option is
(B > included, the receiving node SHOULD silently discard the received
(B > advertisement. Otherwise, the receiving node performs
(B > the following
(B > steps:
(B >
(B > - It records the link-layer address in the Neighbor Cache entry.
(B >
(B > - If the advertisement's Solicited flag is set, the state of the
(B > entry is set to REACHABLE, otherwise it is set to STALE.
(B >
(B > - It sets the IsRouter flag in the cache entry based on
(B > the Router
(B > flag in the received advertisement.
(B >
(B > - It sends any packets queued for the neighbor awaiting address
(B > resolution.
(B >
(B > Note that the Override flag is ignored if the entry is in the
(B > INCOMPLETE state.
(B >
(B > If the target's Neighbor Cache entry is in any state other than
(B > INCOMPLETE when the advertisement is received, the
(B > following actions
(B > take place:
(B >
(B > I. If the Override flag is clear and the supplied
(B > link-layer address
(B > differs from that in the cache, then one of two actions takes
(B > place:
(B > a. If the state of the entry is REACHABLE, set it to STALE, but
(B > do not update the entry in any other way.
(B > b. Otherwise, the received advertisement should be
(B > ignored and MUST
(B > NOT update the cache.
(B > II. If the Override flag is set, or the supplied
(B > link-layer address
(B > is the same as that in the cache, or no Target
(B > Link-layer address
(B > option was supplied, the received advertisement MUST update the
(B > Neighbor Cache entry as follows:
(B >
(B > - The link-layer address in the Target Link-Layer Address option
(B > MUST be inserted in the cache (if one is supplied and
(B > is different
(B > than the already recorded address).
(B >
(B > - If the Solicited flag is set, the state of the entry
(B > MUST be set
(B > to REACHABLE. If the Solicited flag is zero and the link-layer
(B > address was updated with a different address the state
(B > MUST be set
(B > to STALE. Otherwise, the entry's state remains unchanged.
(B >
(B > An advertisement's Solicited flag should only be set if the
(B > advertisement is a response to a Neighbor
(B > Solicitation. Because
(B > Neighbor Unreachability Detection Solicitations are sent to the
(B > cached link-layer address, receipt of a solicited advertisement
(B > indicates that the forward path is working. Receipt of an
(B > unsolicited advertisement, however, suggests that a
(B > neighbor has
(B > urgent information to announce (e.g., a changed link-layer
(B > address). If the urgent information indicates a
(B > change from what
(B > a node is currently using, the node should verify the
(B > reachability
(B > of the (new) path when it sends the next packet.
(B > There is no need
(B > to update the state for unsolicited advertisements that do not
(B > change the contents of the cache.
(B >
(B > - The IsRouter flag in the cache entry MUST be set based on the
(B > Router flag in the received advertisement. In those
(B > cases where
(B > the IsRouter flag changes from TRUE to FALSE as a
(B > result of this
(B > update, the node MUST remove that router from the
(B > Default Router
(B > List and update the Destination Cache entries for all
(B > destinations
(B > using that neighbor as a router as specified in Section 7.3.3.
(B > This is needed to detect when a node that is used as a router
(B > stops forwarding packets due to being configured as a host.
(B >
(B > The above rules ensure that the cache is updated either when the
(B > Neighbor Advertisement takes precedence (i.e., the
(B > Override flag is
(B > set) or when the Neighbor Advertisement refers to the
(B > same link-layer
(B > address that is currently recorded in the cache. If none of the
(B > above apply, the advertisement prompts future Neighbor
(B > Unreachability
(B > Detection (if it is not already in progress) by changing
(B > the state in
(B > the cache entry.
(B >
(B > --------------------------------------------------------------------
(B > IETF IPv6 working group mailing list
(B > ipv6@ietf.org
(B > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
(B > --------------------------------------------------------------------
(B >
(B
(B===========================================================
(BThis email may contain confidential and privileged material for the sole use
(B of the intended recipient. Any review or distribution by others is strictly
(B prohibited. If you are not the intended recipient please contact the sender
(B and delete all copies.
(B===========================================================
(B
(B
(B--------------------------------------------------------------------
(BIETF IPv6 working group mailing list
(Bipv6@ietf.org
(BAdministrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
(B--------------------------------------------------------------------
