Hi Hemant. It seems we have agreement on all but one point. Great!
See below. > >I'm also confused by the use of Neighbor Cache in section 2. AFAIK it > is > >the prefix list plus the *destination cache* (plus default router list) > >which corresponds to the forwarding table in a host. The neighbor cache > >is merely a generalization of the ARP cache in IPv4. The text uses > >"neighbor cache" in two places where I'd expect to see "destination > cache". > >Thus I think we need to change FROM > > The conceptual sending algorithm of [RFC4861] defines a Prefix > > List and Neighbor Cache. The combination of Prefix List and > > Neighbor Cache form what many implementations consider to be > the > > IP data forwarding table for a host. > >TO > > The conceptual sending algorithm of [RFC4861] defines a Prefix > > List and Destination Cache. The combination of Prefix List and > > Destination Cache form what many implementations consider to be > the > > IP data forwarding table for a host. > >--- > <hs> The reason we worded the text this way was to point out incorrect > implementations like BSD that had combined the ND-cache with the > Destination Cache and suffered from problems in on-link determination as > a result. We could change the text to include the Prefix List, the > Destination Cache, the Default Router List, and Neighbor Cache. You > see, once the next-hop determination is made, to forward a packet out, > the node has to look up the entry in the Neighbor Cache for the > link-layer address. However, if we wanted to talk just about Layer 3 > information, we could include just the Prefix List, the Destination > Cache, and the Default Router List.=20 > </hs> I prefer the latter option, i.e., just adding "default router list" to the first sentence. The reason is that (going back to Section 5.2 of RFC 4861), for the purposes of on-link determination, one doesn't use the Neighbor Cache. One need only perform next-hop determination (which leads to a Destination Cache Entry). At that point, if the next hop address in the selected entry matches the address in the packet, you know its on-link. > >This should be "Destination Cache" instead of "Neighbor Cache": > > determination can affect the state of ND: through updating the > > Prefix List or the Neighbor Cache. Through deprecating the > last > >--- > <hs> Good catch, this should read "Destination Cache", not "Neighbor > Cache". However, please note that the last sentence of this paragraph > should remain as "Neighbor Cache". Yes, I agree. > > The on-link definition in the Terminology section of [RFC4861], as > > modified by this document, defines the complete list of cases where > > an address is considered on-link. Individual address entries can > be > >Change sentence to: > > The on-link definition in the Terminology section of [RFC4861], as > > modified by this document, defines the complete list of cases > > where a node considers an address to be on-link. > <hs> Agree with new text provided "node" in new text is changed to > "host". > </hs> OK. > >--- > > 2. In the absence of other sources of on-link information, > including > > Redirects, if the RA advertises a prefix with the on-link(L) > bit > > set and later the Valid Lifetime expires, the host MUST then > > consider addresses of the prefix to be off-link, as specified > by > > the PIO paragraph of section 6.3.4 of [RFC4861]. > >Better (above is not quite right): > > 2. In the absence of other sources of on-link information, > > including Redirects, if the RA advertises a prefix with the > > on-link(L) bit set and later the Valid Lifetime expires, the > > host MUST then update its Prefix List w.r.t. to the entry. In > > most cases, this will result in the addresses covered by the > > prefix defaulting back to being considered off-link, as > > specified by the PIO paragraph of section 6.3.4 of > > [RFC4861]. However, there are cases where an address could be > > covered by multiple entries in the Prefix List, where > > expiration of one prefix would result in destinations then > > being covered by a different entry. > <hs> Agree with new text subject to changing "w.r.t. to" to "with > respect to". Prefix list entries can overlap as you pointed out. > </hs> Agreed. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
