I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-mext-nemo-v4traversal-07.txt
Reviewer: Brian Carpenter
Review Date:  2008-12-14
IESG Telechat date: 18 December 2008

Summary: Almost ready

Normative reference issues:

> 10.2.  Informative

The following appear to me to be used normatively; the absence of an
upper case keyword doesn't prove the absence of a normative reference:

>    [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
>               Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
>               March 2000.

>    [RFC2983]  Black, D., "Differentiated Services and Tunnels",
>               RFC 2983, October 2000.

(Sorry about this, it was added at my suggestion and is a downref.)

>    [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
>               of Explicit Congestion Notification (ECN) to IP",
>               RFC 3168, September 2001.

>    [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
>               for IPv6 Hosts and Routers", RFC 4213, October 2005.

>    [RFC4459]  Savola, P., "MTU and Fragmentation Issues with In-the-
>               Network Tunneling", RFC 4459, April 2006.

(downref, if I'm right)

>    [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
>               (MOBIKE)", RFC 4555, June 2006.

>    [RFC5026]  Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
>               Bootstrapping in Split Scenario", RFC 5026, October 2007.



Editorial comments: 

> 3.3.2.2.  Foreign Network Supports IPv4 Only (Private Addresses)
...
>    After accepting the binding update, the home agent MUST create a new
>    binding cache entry for the mobile node's IPv6 home address.  If an
>    IPv4 home address option were included, the home agent MUST create
>    another entry for that address.  All entries MUST point to the mobile
>    node's IPv4 care-of address included in the source address of the
>    IPv4 header that encapsulated the binding update message.

I think there should be a note here that this care-of address was
*translated* i.e. not the private care-of address known to the mobile
node. This is clarified in section 5.2 but that is many pages ahead.

> 5.1.1.  tunnelling Impacts on Transport and MTU
>
>    Changing the tunnel format may occur due to movement of the mobile
>    node from one network to another.  This can have impacts on the link
>    and path MTU, which may affect the amount of bandwidth available to
>    the applications.  The mobile node may use PMTUD as specified in
>   [RFC4459].

The most recent recommendations are different - see RFC4821. Maybe mention
that too?

> 5.2.  NAT Detection
...
>    A mobile node MUST always tunnel binding updates in UDP when located
>    in an IPv4-only network.  

I think this should indicate how the mobile knows that it's in an IPv4-only network,
or maybe it should say 'A mobile node that has not been assigned an IPv6 address
by the foreign network...'. Also, there's a missing verb in that sentence.

> 9.  IANA Considerations
...
>                    Note also that documents published as "RFC Editor
>       contributions" [RFC4844] are not considered to be IETF documents.

I don't understand why this is mentioned, since it's obvious.