Dual-Stack Mobile IPv4
RFC 5454

Note: This ballot was opened for revision 10 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 -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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 -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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?