Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues
Note: This ballot was opened for revision 07 and is now closed.
(Jari Arkko) Yes
(Ron Bonica) No Objection
(Stewart Bryant) (was Discuss) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) (was Discuss) No Objection
(Lars Eggert) No Objection
(Adrian Farrel) No Objection
(Russ Housley) No Objection
Comment (2010-05-19 for -)
Please consider the comments from the Gen-ART Review by Enrico Marocco on 12 May 2010. The review can be found at: http://www.softarmor.com/rai/temp-gen-art/ draft-ietf-netlmm-mip-interactions-06-marocco.txt
(Tim Polk) (was Discuss) No Objection
(1) Section 3.2, list item 4 bullet 3 s/binging/binding/ (2) The final sentence in Section 5 (Security Considerations) is considerably weaker than the text in Section 3.2, list item 4 bullet 4. From section 3.2: Based on this consideration, the threat described in [RFC4832] is worse as it affects also hosts that are using the LMA/HA as MIPv6 HA and are not using PMIPv6. From section 5: Note that the compromised MAG threat described in [RFC4832] applies also here. I suggest that the text in the security considerations be strengthened...
(Dan Romascanu) No Objection
Comment (2010-10-28 for -)
The OPS-DIR review by Jouni Korhonen raised a number of non-blocking issues, most of them of editorial nature, which should be considered if a new revision of the document is spun out: The document mentions that there are system specific issues that need to be taken into account; see Sections 4.2.1 and 4.3. Those are merely bypassed stating being "out of scope". While this is true, from operational and management perspective it would be nice to see even references here for further reading if any of those "out of scope" things have been solved or discussed somewhere. For example Section 4.2.1 depends on LMA discovery to work properly within the same administrative domain. There are solutions for this documented in IETF in PMIPv6 context. Another related nit to point out is that the document could actually mention that the separate HA/LMA functions actually would benefit from a shared subscriber database (e.g. AAA server) to work properly. The text seems to hint that anyway. Few editorial comments: o Section 2 should also say that it uses acronyms from RFC5213 and RFC3775. o Section 3 add a reference to HMIPv6-MIPv6. o Sequence number based ordering is possible (optional) for PMIPv6 in RFC5213 unlike stated in Section 3.2, step 1) first bullet. Not that it would help to solve the issue described here, but using sequence numbers in PMIPv6 is possible in general as an option. o Section 3.2 step 4) last bullet I do not understand why it mentions "both host-based and network-based security associations are used to update the same binding cache entry at the HA/LMA" as earlier the scenario has been scoped so that HA & LMA binding caches are separate. o Section 3.2 -> s/(or binging cache)./(or binding cache). -> s/RFC4832, section 2.2/RFC4832, Section 2.2 -> add a reference to IKEv2 [RFC5996] o Section 3.3 says the ".. advertising the home link prefix to the MN in a unicast Router Advertisement message." While it makes sense and is typical behavior when a MAG receives a Router Solicitation, it is not necessarily the case always. The MAG can send multicast Router Advertisements when it so decides or send it before receiving a Router Solicitation. o Section 4.2.1 -> s/MN-HoA.For/MN-HoA. For o Section 4.2.2 -> s/MAG. the/MAG. The o Section 4.2.2 could reference to draft-ietf-netlmm-lma-discovery when it discusses about LMA discovery and it not being defined in RFC5213. o Section 5 reference [pmipv6-draft] should be [RFC5213]. o The document uses both (P)MIPv6 and (Proxy) Mobile IPv6 interchangeably. It should stick with one style. o The document uses both BCE and binding cache entry interchangeably. It should stick with one style. o The document uses both HA and Home Agent interchangeably. It should stick with one style. o The document uses both HA/LMA and LMA/HA interchangeably. It should stick with one style. o Most of the acronyms are not expanded on the first use.
(Peter Saint-Andre) No Objection
(Robert Sparks) No Objection
(Sean Turner) No Objection
Comment (2010-05-20 for -)
I support Tim's DISCUSS positions. Some nits: Section 3, second sentence: OLD This document does not ^^^^ only focus on scenarios where the two protocols are used by the same mobile node to manage local and global mobility, but it investigates ^^ also more complex scenarios where the protocols are more tightly ^^^^ NEW This document not only focuses on scenarios where the two protocols are used by the same mobile node to manage local and global mobility, but also investigates more complex scenarios where the protocols are more tightly Section 3, page 9, line 4: OLD depicted in the figure. However, the LMA and HA can be also ^^^^^^^ NEW depicted in the figure. However, the LMA and HA can also be