Document: draft-ietf-mipshop-fmipv6-rfc4068bis-06 Reviewer: Ben Campbell Review Date: 2008-3-15 IETF LC End Date: 2008-3-15 Summary: This document is on the right track, but needs work. Comments: Disclaimer: I do not have much background in Mobile IPv6. I assume others have reviewed this for technical correctness. --General Comments This is a difficult review, as the document is an update to a previous RFC. It is almost certain that some of my comments apply to the original RFC, and I realize that the goal of this revision is probably not to fix _every_ issue in that RFC. Therefore, a response to the effect of "That issue was in the original RFC, and was beyond the scope of our changes" is perfectly reasonable for most of my comments. That being said, there are a large number of editorial nits that have clearly been introduced in this draft that were not in the original RFC. The omission of articles and incorrect use of "an" vs "a" occur throughout. A diff shows that there are several paragraphs where the introduction of such errors are the _only_ changes from the RFC, which I suspect they may be the result of regression errors. Is it possible that the author started from the original test for RFC 4068 _before_ the RFC editor edits? If so, I am concerned that if there were any substantive changes introduced to RFC 4068 during the RFC Editor or author's 48 process, they may have been lost. Checking for such losses would, unfortunately, require more time than I can commit to this review. I find the general organization of this document hard to follow. The general operation of the protocol is described no less than 3 times. Section 3.1 gives a high level overview. 3.2 gives the same description in more detail with some more normative language. Section 4 describes it in even more detail with more normative language. It is common to have an overview section and a detailed operation section, but I am confused by the presence of the "middle" description. Normative language is spread across the sections, which increases the odds of implementation errors. I read through all three descriptions, and still found myself wondering about basic questions such as "what transport do these messages use?" It wasn't until section 6 that I learned that some of the messages are ICMPv6 extensions, and that some of Mobile IPv6 extensions. Finally, there is a great deal of imprecise language that I think could impact interoperability. There are a number of statements of the form "an XXX message is sent" or "XXX/YYY messages are exchanged" that left me digging to figure out what device sends the message and what device consumes it. I will address some of these in the detailed comments, but I'm sure there are a number that I missed. -- Detailed Comments: Section 2, RFC 2119 boilerplate: IDNITS does not like the 2119 boilerplate. I don't think 2119 defines "silently ignore". Section 2, Figure 1: Do you intend Figure 1 to be part of the terminology section? It might make more sense to put it nearer the first reference. 3.1, paragraph 4: "The information provided in the PrRtAdv message can be used even when DHCP [rfc3315] is used to configure an NCoA on the NAR's link. In this case, the protocol supports forwarding using PCoA, and the MN performs DHCP once it attaches to the NAR's link. The MN still formulates an NCoA for FBU processing; however, it MUST NOT send packets using this NCoA." The "this NCoA" in the last sentence is assumed to be different than the one received via DHCP, right? paragraph 5. last sentence: "Otherwise, it should send it immediately after detecting attachment to NAR." I found the multiple use of "it" to cause pronoun confusion. "And, PAR SHOULD forward the inner packet in the tunnel to its destination (i.e., to the MN's correspondent)." Is SHOULD strong enough for this requirement? What happens if the PAR does not forward the inner packet? paragraph 7: "In addition, buffering for handover traffic may be desirable." Buffering by which device? (NAR or PAR?) last paragraph" "The access routers MUST have necessary security association established by means outside the scope of this document." The document should at least describe the security characteristics expected for such security associations, if it is not going to specify the mechanisms. (Does this conflict with statements about IPSec in the security considerations section?) 3.2, paragraph 1" "The protocol begins when a MN sends RtSolPr to its access router..." Which access router? PAR or NAR? Please be specific. paragraph 2: " With the information provided in the PrRtAdv message, the MN formulates a prospective NCoA and sends an FBU message." To where? Please be specific. paragraph 3: " Depending on whether an FBack is received or not on the previous link, which clearly depends on whether FBU was sent in the first place, there are two modes of operation." I found this confusing, as there are clearly other reasons for not receiving an FBack than having simply not sent an FBU. numbered item 1: "...PAR can determine whether NCoA is acceptable to NAR through the exchange of HI and HAck messages. When assigned addressing (i.e., addresses are assigned by the router) is used, the proposed NCoA in FBU is carried in HI, and NAR MAY assign the proposed NCoA.Z" Please be specific about which devices sends the and receives the HI. Same for the HAck. I can infer the answers, but don't just assume the answers are obvious. numbered item 2: 'Hence, the MN (re)sends FBU immediately after sending the UNA message." Does the MN resend to the PAR or to the NAR? paragraph 8: Can you move figures 2 and 3 closer to the first reference? (At least in the same section?) Section 3.3, Figure 2: Does the PAR really send the FBack to both the MN and the NAR? Figure 3: Combining the HI and HAck on same line obfuscates which device is the sender and recipient for each message. Section 4, paragraph 2: "...the MN sends RtSolPr in order to resolve access point identifiers to subnet router information." Sends it where? Yes, the figure shows this--but it's clearer if the text says it too. "Implementations SHOULD make use of such triggers whenever available." Is SHOULD strong enough here? If the MN does not have some mechanism to detect access point changes, how could it use this protocol at all? paragraph 5 (list item 1) "...it responds indicating that the new access point is unknown." How is this indicated? That is, what code, option, etc? paragraph 6 (list item 2) "PAR responds with a Code value indicating that the new access point is connected to the current interface..." What is the specific code value? Paragraph 7 (list item 3) "...then PAR responds indicating that the new access point is known..." How is this indicated? paragraph 15 (list item 3) "MAY create a host route entry for PCoA..." Is MAY strong enough? Are there negative consequences of not doing it? paragraph 16 (list item 4) "provides the status of handover request in Handover Acknowledge (HAck) message." To where does it send the HAck? "However, it SHOULD be prepared to process any other options which may be defined in the future." What does that mean? How can it process an option that has not yet been defined? The wording seems to imply more than simply ignoring unknown options. paragraph 25 (list item 1): "updates the state to STALE" This is the first mention of a formal state--can you reference where it is defined? Paragraph 26 (list item 2) Same as previous comment for "INCOMPLETE" state. Paragraph 29 (list item 1) Numbered list with just one item. Section 5.4, last paragraph "... it SHOULD also provide its own support for buffering." Can you provide guidance on how much buffering is needed? Section 5.5, first paragraph: I'm confused. You seem to say that this protocol (I assume "this" means the protocol being defined) SHOULD only be deployed when there is little chance of collision--but it also must use DAD to try to avoid collisions, unless there is little chance of collision in which case it may turn DAD off. That seems self-contradictory. Section 6, first paragraph: This is the first mention of ICMP I find in the document. It would be helpful to mention that the messages defined in this document are ICMP extensions early in the draft. (Same comment for Mobility Header messages in section 6.3) 6.1.2, 3rd paragraph from the end of page 23: "If a New CoA option is present following the New Router Prefix Information option, the MN SHOULD use the supplied NCoA and send FBU immediately or else stand to lose service." Why is this not a MUST? Loosing service is a drastic result for ignoring a SHOULD. 6.5, paragraphs 1-2: You state that all options are of the form described in Figure 10, but that's not necessarily true for Mobility Header LLA. I suggest treating ICMPv6 and Mobility Header options separately. 9, paragraph 2: What security properties are required of the security mechanism? section 9, 2nd to last paragraph: "IPsec ESP [rfc4303] in transport mode with mandatory integrity protection SHOULD be used for protecting the signaling messages. " Why is this a SHOULD and not a MUST? Appendix B: Do you expect the change log to be published in the final RFC? A list of changes from RFC4068, rather than a list of changes for each draft revision, would be more helpful for implementors.