Dual-Stack Mobile IPv4
RFC 5454

Note: This ballot was opened for revision 10 and is now closed.

Lars Eggert No Objection

(Jari Arkko; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Mark Townsley; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Chris Newman; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Cullen Jennings; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Dan Romascanu; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(David Ward; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Jon Peterson; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Lisa Dusseault; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection (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?

(Pasi Eronen; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ross Callon; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Tim Polk; former steering group member) No Objection

No Objection (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)?