Draft: draft-ietf-ipv6-2461bis-09.txt Reviewer: Scott W Brim [swb@employees.org] Review Date: Wednesday 11/8/2006 9:52 AM IETF LC Date: 11/10/2006 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. I have one question on the protocol, and several on documentation. Since this is a significant protocol, documentation is very important. For the sake of new implementors I have a number of suggestions for clarity. Many of them have to do with the use of "SHOULD", since we have been polishing up its use and advice to implementors. I'll start with my protocol question: 7.2.7 Anycast neighbor announcements - "Second, the Override flag in Neighbor Advertisements SHOULD be set to 0, so that when multiple advertisements are received, the first received advertisement is used rather than the most recently received advertisement." How does the Override flag work when you advertise an included prefix? In this case, I'm advertising a single route to you with the Override flag off. What if you already have a route to a larger prefix that includes it? Do I punch a hole? Am I discarded? Is this documented? OK, onward to non-protocol issues. 3.0 protocol overview - Duplicate address detection "Duplicate Address Detection: How a node determines that an address it wishes to use is not already in use by another node." should be "Duplicate Address Detection: How a node determines whether or not an address it wishes to use is already in use by another node." - Router advertisement: the phrase "on-link determination" has not appeared before. It should be explained. 4.1 router solicitation message - Source link-layer address "The link-layer address of the sender, if known. MUST NOT be included if the Source Address is the unspecified address. Otherwise it SHOULD be included on link layers that have addresses." We've been tightening up "SHOULD"s recently. RFC2119 says: SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. In this draft, "otherwise ... SHOULD" implies that there are situations in which the link layer address is known, and the source address is included, but the link layer address may be omitted. RFC2119 says that deserves explanation. As guidance to implementors, who are supposed to understand the full implications and carefully weigh them, when would this be appropriate? For load balancing? If so just say so. For example down below in Router Advertisement Message, you say "A router MAY omit this option in order to enable inbound load sharing across multiple link-layer addresses." Something like that would work here -- if nothing else add a pointer to text elsewhere. There are more issues with SHOULDs not being thoroughly explained below. I'm only listing the ones where I believe naive implementors might benefit from explanation. 4.2 router advertisement - "Note: If neither M nor O flags are set this indicates that no information is available via DHCPv6." This means that the responding router always knows if DHCPv6 is definitely available or definitely not available. Is there any possibility that the responding router might not know? If so, how about changing the text to "is known to be available"? - "SHOULD be sent on links that have a variable MTU (as specified in the document that describes how to run IP over the particular link type). MAY be sent on other links." Same comment on undocumented SHOULD. How about changing it to "MUST be sent ... (where specified ...)"? 4.3 neighbor solicitation - "Source link-layer address The link-layer address for the sender. MUST NOT be included when the source IP address is the unspecified address. Otherwise, on link layers that have addresses this option MUST be included in multicast solicitations and SHOULD be included in unicast solicitations." Same thing about SHOULD. If it SHOULD be included, under what conditions is it expected that it would not be? 4.4 Neighbor advertisement - Override Flag: "It SHOULD NOT be set in solicited advertisements for anycast addresses and in solicited proxy advertisements. It SHOULD be set in other solicited advertisements and in unsolicited advertisements. SHOULD and SHOULD NOT without explanation. Should these be MUSTs? - Target link-layer address: "When responding to a unicast Neighbor Solicitation this option SHOULD be included." SHOULD. When would you not? 4.5 Redirect - "It SHOULD be included (if known). SHOULD. When would you not? 6.2.1 router config variables - AdvCurHopLimit "The value should be set to that current diameter of the Intern iset." s/that/the/ 6.2.6 processing router solicitations - "If the router already has a Neighbor Cache entry for the solicitation's sender, the solicitation contains a Source Link-Layer Address option, and the received link-layer address differs from that already in the cache, the link-layer address SHOULD be updated in the appropriate Neighbor Cache entry, and its reachability state MUST also be set to STALE." Unelaborated SHOULD? 6.3.4 processing received router advertisements - In a paragraph that begins "After extracting information" ... "If the advertisement contains a Source Link-Layer Address option the link-layer address SHOULD be recorded in the Neighbor Cache entry for the router ..." This seems to be another unexplained SHOULD. Setting the solicited flag ... - In 7.2.5, "An advertisement's Solicited flag should only be set if the advertisement is a response to a Neighbor Solicitation." However, in 7.2.6, "The Solicited flag MUST be set to zero, in order to avoid confusing the Neighbor Unreachability Detection algorithm." Is there a consistency problem here? 7.3.3 - "When a node needs to perform address resolution on a neighboring address, it creates an entry in the INCOMPLETE state and initiates address resolution as specified in Section 7.2. If address resolution fails, the entry SHOULD be deleted, so that subsequent traffic to that neighbor invokes the next-hop determination procedure again." "SHOULD" again. When would you not delete the entry? - "In the Target Address field: the address to which subsequent packets for the destination SHOULD be sent." That's talking about the recipient of the redirect. It's not about the sender's behavior, so this SHOULD should not be capitalized. 8.3 - "A host receiving a valid redirect SHOULD update its Destination Cache accordingly so that subsequent traffic goes to the specified target. If no Destination Cache entry exists for the destination, an implementation SHOULD create such an entry." Another set of unsupported SHOULDs. What if it doesn't? 9 Options - "Receivers MUST silently ignore any options they do not recognize and continue processing the message." I would add, as has been done in other WGs, that if a new option is so ignored by the receiver, protocol behavior MUST still continue as if the option had not been sent. That is, processing of options is always backward compatible unless the option is declared as required. (Did not check state machine)