Dual-Stack Mobile IPv4
Summary: Needs 9 more YES or NO OBJECTION positions to pass.
Note: This ballot was opened for revision 07 and is now closed.
Jari Arkko Yes
( Mark Townsley ) Yes
( Ron Bonica ) No Objection
( Ross Callon ) No Objection
( Lisa Dusseault ) No Objection
( Lars Eggert ) No Objection
( Pasi Eronen ) (was Discuss) No Objection
( Russ Housley ) No Objection
( Cullen Jennings ) No Objection
( Chris Newman ) No Objection
( Jon Peterson ) No Objection
( Tim Polk ) No Objection
Comment (2008-12-03 for -)
This is an updated comment: Issue #1 is the new issue; Issue #2 has been addressed in email for the authors already. Issue #1 The IPv6 Prefix Reply Extension is defined as a skippable extension. As I understand the protocol, this extension will only appear if the client included the IPv6 Prefix Request Extension in a previous message, so I would expect the client to always support this extension. In fact, if the client does not support the extension, it seems to be some kind of error condition. Is there an advantage to using a skippable extension for the prefix reply? Issue #2 The text in section 4.5, list item 2) apparently assumes that the code value in the registration reply header is set to an accept code, but this isn't stated. Perhaps it is obvious, given the text in 4.2, but it might bear repeating here. If the mobile node receives a registration reply header with a code value set to a reject code, would it also follow the procedures in list item 1)?
( Dan Romascanu ) No Objection
( David Ward ) No Objection
( Magnus Westerlund ) No Objection
Comment (2008-12-04 for -)
I don't have the time to wrap my head about this question so I am going to ask directly instead. I hope I can get an answer. Does this MIP4 extension deal with the case when there is a v4<->v6 address family translator between the MN and the FN or HA? Can this operate in such an environment without an application level gateway that support MIP4?