Note: This ballot was opened for revision 07 and is now closed.
Summary: Needs 9 more YES or NO OBJECTION positions to pass.
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?
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.
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?
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)?