Mobile IPv6 Fast Handovers
Note: This ballot was opened for revision 07 and is now closed.
(Jari Arkko) Yes
(Ross Callon) No Objection
(Lisa Dusseault) (was Discuss, Abstain) No Objection
(Lars Eggert) (was Discuss) No Objection
(Russ Housley) (was Discuss) No Objection
Based on Gen-ART Review from Ben Campbell... There are a large number of editorial errors that have clearly been introduced in this draft that were not in the RFC 4068, such as the 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. It is possible that the author started from the previously approved Internet-Draft text that became RFC 4068 instead of the output from the RFC Editor. If so, there may be substantive changes introduced to RFC 4068 during the editing or Auth48 that have been lost. The organization of this document difficult. The general operation of the protocol is described at least 3 times. Section 3.1 gives an overview, then section 3.2 gives the same description in more detail with some more normative language, and then section 4 describes it in even more detail with more normative language. It is common to have an overview section and a detailed section, but the presence of the half-way-between description is unsettling. The fact that normative language is spread across all of the sections increases the odds of implementation errors. In section 6, the reader learns that some of the messages are ICMPv6 extensions and that some of Mobile IPv6 extensions. This seems like very important information, and it should appear earlier. Section 3.1, paragraph 5, last sentence, says: > > Otherwise, it should send it immediately after > detecting attachment to NAR. > The use of "it" in two places causes confusion. Section 3.2, paragraph 1, says: > > The protocol begins when a MN sends RtSolPr to its access router... > Which access router? PAR or NAR? Please be specific. Section 3.2, paragraph 2, says: > > With the information provided in the PrRtAdv message, the MN > formulates a prospective NCoA and sends an FBU message." > To where? Please be specific. Section 4, paragraph 5, 1st list item, says: > > ... it responds indicating that the new access point is unknown. > How is this indicated? Section 4, paragraph 6, 2nd list item, says: > > PAR responds with a Code value indicating that the new access > point is connected to the current interface ... > What is the specific code value? Section 4, paragraph 7, 3rd list item, says: > > ... PAR responds indicating that the new access point is known ... > How is this indicated? Section 4, paragraph 16, 4th list item, says: > > ... provides the status of handover request in Handover Acknowledge > (HAck) message. > To where?
(Chris Newman) No Objection
Comment (2008-03-27 for -)
I support most of the discuss issues raised by other area directors, but did not notice any additional issues after a brief review.
(Jon Peterson) No Objection
(Tim Polk) (was Discuss) No Objection
The following editorial typos were identified in Alexey Melnikov's secdir review: In section 7: The protocol specified here, as a design principle, introduces no or minimal changes to related protocols. For example, no changes to the base Mobile IPv6 protocol are needed in order to implement this protocol. Similarly, no changes to the IPv6 stateless address autoconfiguration protocol [rfc4862] and DHCP [rfc3315] are introduced. The protocol specifies an optional extension to Neighbor Discovery [rfc4861] in which an access router may send a router advertisement as a response to the UNA message (see Section Section 6.4). Other than this extension, the specfication does not typo: specification modify Neighbor Discovery behavior (including the procedures performed when attached to the PAR and when attaching to the NAR). In Section 9: The following security vulnerabilities are identified, and suggested solutions mentioned. Insecure FBU: in this case, packets meant for one address could be stolen, or redirected to some unsuspecting node. This concern is the same as that in a MN and Home Agent relationship. Hence, the PAR MUST ensure that the FBU packet arrived from a node that legitimately owns the PCoA. The access router and its hosts may use any available mechanism to establish a security association which MUST be used to secure FBU. The current version of this protocol relies on a companion protocol [rfc-ho-send]. to An extra dot after "[rfc-ho-send]". establish such a security association.