Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6)
Note: This ballot was opened for revision 07 and is now closed.
(Jari Arkko) Yes
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Pasi Eronen) (was Discuss) No Objection
First of all, I should say that after working on the DSMIPv6 document, I'm rather sympathetic to arguments that perhaps using IPsec for Mobile IPv6 wasn't such a great idea in hindsight, and the authentication option can be valuable in some deployments. However, much of the text in Sections 2/3/4 is written in way that makes it difficult to distinguish when it's describing the history (why RFC 4285 was originally done, before IKEv2 and RFC 4877 existed), and when it's describing why it's still a good idea today. It seems the energy needed to rewrite this text doesn't exist, however, and I'm grudgingly changing this from discuss to comment. Also, somewhat surprisingly for a document defending RFC 4285, the document also doesn't mention what's IMHO the *main* advantage of RFC 4285 over IPsec: implementation complexity. Especially with new MIPv6 features like DSMIPv6, the interface between IPsec stack and MIPv6 stack is getting complex, and the IPsec stack needs more MIPv6-specific functionality (so you can't necessarily use just any off-the-shelf IPsec stack). However, it seems not everyone agrees about this topic, so perhaps it can be omitted, too. I'd be happier if the text discussing overhead of IPsec/IKE reminded folks that IKE overhead is usually one time (e.g. once a day), not something that happens when doing handover -- currently it does give an impression that IPsec/IKE is a bandwidth hog, which isn't really that accurate.
(Russ Housley) (was Discuss) No Objection
(Cullen Jennings) No Objection
(Chris Newman) No Objection
(Tim Polk) No Objection
Comment (2008-08-28 for -** No value found for 'p.get_dochistory.rev' **)
I understand (more or less) the history of this document, and its goals, but I wish this document had evolved into a more even treatment of the applicability of RFC 4285 and RFC 4877. The document reads more as a defense of 3gpp than was necessary imho. Documenting the process more generically, then using 3gpp as an example would have made the document easier for future system architects to apply the information when architecting their own solutions. Addressing this comment directly would require major surgery that is probably innapropriate at this stage of the document lifecycle, but I think implementing Pasi's proposals or something similar would certainly be helpful.