I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The document defines a way to support IPv4 home addresses in mobile
IPv6 and a way to tunnel mobile IPv6 messages over IPv4.

Pre-amble: I know next to nothing about this set of protocols though
it seems that this specification mixes so many things that its security
properties must be highly complex, certainly beyond what I can analyse
in the time available.

#1 I guess the main concern would be that a node could hijack another
node's IPv4 home address. If an MN is able to (securely) do mobile IPv6,
I'm not clear on how that node is prevented from claiming someone else's
IPv4 address as its IPv4 home address. If that is covered, adding a
paragraph to the security considerations section that makes it clear
would be useful. (At least to me.)

#2 - p10, last para: this refers to the mobile node's "policy profile"
but that's not defined (here) so its not possible to know what security
considerations apply. Same paragraph says that "the network will
ensure..." but doesn't say how.

#3 - 3.1.2.2, 2nd bullet says that the mobility anchor MUST check the
authorization of the node to use the address claimed but doesn't say
how that authorization can be done. (I *think* this may be the same
point as #1 above.)

#4 - 3.1.2.4 Does this create a new way to cause another node to lose
its address(es) by sending bogus lifetime extension requests?

#5 - (not really security but...) 3.2.1 I couldn't follow what'd
happen if a lot of nodes with static IPv4 home addresses that belong to
the same subnet roamed to different mobile gateways.

Nits/Typos etc.

1. The draft could do with some more work on the language, e.g.  "both
the protocols" in the 1st sentence should be "both of the protocols."
There are many similar cases, however, none that I've seen make the
document less clear to me, other than as a distraction though that might
not be the same for all readers (e.g. non native English speakers).
OTOH, this kind of language might be clearer for non-native English
speakers:-)

2. If section 1 is intended to be a useful overview for the
non-initiated, then I have to say it failed in that for me (one of the
non-initiated). However, it may actually be intended more to position
this for people familiar with the technology.

#3 3.1.2.7 says: "when there is not a single Home Network Prefix
option with NON_ZERO value present in the request..." That's very
hard to interpret and possibly badly ambiguous. "Not a single" could
mean zero or >1.

#4 3.1.3 says that the mobility anchor MUST advertise a connected
route but doesn't say how.

#5 section 7: s/news/new/