Erik and Thomas, Thanks for the review and the text - humble apologies for the delay. I and Wes discussed your reply. Please see in line below between <hs> and </hs>. We will post a -07 soon taking care of these comments from you.
Hemant & Wes -----Original Message----- >From: Erik Nordmark [mailto:[email protected]] >Sent: Tuesday, December 08, 2009 1:43 PM >To: IPv6 Maintenance WG; Wes Beebee (wbeebee); Hemant Singh (shemant) >Cc: Thomas Narten >Subject: Editorial comments on draft-ietf-6man-subnet-model-06 >I had some editorial questions and comments on >draft-ietf-6man-ipv6-subnet-model-06 and I asked Thomas about that >(since he contributed some new text in this area). Based on Thomas and I >discussion this, here are some suggested edits. >Throughout the document the term "on-link" is still not used precisely >in all cases. It is important to note that "on-link" is a relative >statement, referring to one node's perspective. Other nodes on the >same link may not have the same understanding that a particular >destination is "on-link". >--- >This doesn't look quite right: > 1. The original Neighbor Discovery (ND) specification [RFC4861] was > unclear in its usage of the term on-link in a few places. In > IPv6, an address is considered to be on-link (with respect to a > specific link), if the address has been assigned to an interface > attached to that link. >I read this as if the admin on node A configures some random IPv6 >address on an interface, then magically other nodes on the link will >consider it to be on-link. It is clear that the address *is* on-link >once it is configured, but it can't be *considered to be* on-link by >others unless there is some protocol to convey that. >The text would make sense if we just dropped "considered to be" above. >But a better rewrite would be to say: > 1. The original Neighbor Discovery (ND) specification [RFC4861] > was unclear in its usage of the term on-link in a few places. > In IPv6, an address is on-link (with respect to a specific > link), if the address has been assigned to an interface > attached to that link. Any node attached to the link can send > a datagram directly to an on-link address without forwarding > the datagram through a router. However, in order for a node to > to know that a destination is on-link, it must obtain > configuration information to that effect. In IPv6, there are > two main ways of maintaining information about on-link > destinations. First, a host maintains a Prefix List that > identifies ranges of addresses that are to be considered > on-link. Second, Redirects can identify individual > destinations that are on-link; such Redirects update the > Destination Cache. <hs> Agree with new text. </hs> >--- >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. </hs> >Later we have an extra '-' appear that doesn't existing in the quoted >text in RFC 4861. The draft contains > If the Source Address is not the unspecified address and, on- > link layers that have addresses, the solicitation includes a >But the text in RFC 4861 says > description applies. If the Source Address is not the unspecified > address and, on link layers that have addresses, the solicitation > includes a Source Link-Layer Address option, then the recipient >The distinction between "on link layer" (one could also say "for link >layers") and "on-link layers" might be important, hence I think the >misquote should be fixed. <hs> Good catch - will remove the extra hyphen. </hs> >--- >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". </hs> >Old: > IPv4 implementations typically associate a netmask with an address > when an IPv4 address is assigned to an interface. That netmask > together with the IPv4 address designates an on-link prefix. > Addresses that are covered by this prefix are viewed as on-link i.e., > traffic to these addresses is not sent to a router. See section > 3.3.1 in [RFC1122]. Prior to the deployment of Classless Inter- > Domain Routing (CIDR), an address's netmask could be derived directly > from the address. In the absence of specifying a specific netmask > when assigning an address, some implementations would fall back to > deriving the netmask from the class of the address. >New: > IPv4 implementations typically associate a netmask with an address > when an IPv4 address is assigned to an interface. That netmask > together with the IPv4 address designates an on-link prefix. Nodes > consider addresses covered by an on-link prefix to be directly > attached to the same link as the sending node, i.e., they send > traffic for such addresses directly rather than to a router. See > section 3.3.1 in [RFC1122]. Prior to the development of subnetting > [RFC950] and Classless Inter-Domain Routing (CIDR) [RFC1519], an > address's netmask could be derived directly from the address simply > by determining whether it was a Class A, B or C address. Today, > assigning an address to an interface also requires specifying a > netmask to use. In the absence of specifying a specific netmask > when assigning an address, some implementations would fall back to > deriving the netmask from the class of the address. <hs> New text is fine by us. </hs> >--- > The reception of a Prefix Information Option (PIO) with the L-bit set > [RFC4861] and a non-zero valid lifetime creates (or updates) an entry > in the Prefix List. All the prefixes that are on the Prefix List, > i.e., have not yet timed out, are considered to be on-link. >change last sentence to: > All prefixes on a host's Prefix List, i.e., have not yet timed out, > are considered to be on-link by that host. <hs> New text is fine by us. </hs> >--- > 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> >--- > IPv6 packets sent using the Conceptual Sending Algorithm as described > in [RFC4861] only trigger address resolution for IPv6 addresses that > are on-link. Packets to any other address are sent to a default >New: > > IPv6 packets sent using the Conceptual Sending Algorithm as described > in [RFC4861] only trigger address resolution for IPv6 addresses > that the sender considers to be on-link. <hs> New text is fine by us. </hs> >--- > 2. Note that Redirect Messages do not contain sufficient information > to signal that an address is off-link. Rather, they indicate a > preferred next-hop that is a more appropriate choice to use than > the originator of the Redirect. >new: Add new paragraph and tweak the above for better transition. > 2. It should be noted that ND does not have a way to indicate a > destination is "off-link". Rather, a destination is assumed > to be off-link, unless there is explicit information > indicating that it is on-link. Such information may later > expire or be changed, in which case a destination may revert > back to being considered off-link, but that is different than > there being an explicit mechanism for signaling that a > destination is off-link. > Redirect Messages do not contain sufficient information to > signal that an address is off-link. Instead, Redirect > Messages indicate a preferred next-hop that is a more > appropriate choice to use than the originator of the > Redirect. ... <hs> New text looks great. </hs> >--- > 3. IPv6 also defines the term "neighbor" and "link" to refer to >s/and "link"// >It reads incorrectly in the current sentence. Changing it to "on-link" >(was that the original intention?) is also not quite right since >"on-link" is a property of an IP address and not a property of a node. <hs> Agree - removing "and link". </hs> >--- > 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> >--- > 3. Newer implementations, which are compliant with [RFC4861] MUST > adhere to the following rules. Older implementations, which are > compliant with [RFC2461] but not [RFC4861] may remain as is. If > the Default Router List is empty and there is no other source of > on-link information about any address or prefix: >Better: > 3. Implementations compliant with [RFC4861] MUST adhere to the > following rules. If the Default Router List is empty and there > is no other source of on-link information about any address or > prefix: <hs> Agree to new text. </hs> >--- > This document addresses a security concern present in [RFC4861]. As > a result, the last bullet of the on-link definition in [RFC4861] has > been retracted. US-CERT Vulnerability Note VU#472363 lists the > implementations affected. >s/last/last two/ <hs> Agree to change. </hs> -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
