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 resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-mext-nemo-v4traversal-06.txt
Reviewer: Brian Carpenter
Review Date: 2008-11-17
IETF LC End Date: 2008-11-18
IESG Telechat date: (if known)

Summary: This draft is on the right track but some clarifications are needed.

Comments: 

The first one is cosmetic; all the others are technical issues.

> 2.  Introduction
> 
>                                        ...However, since IPv6 is not
>    widely deployed, it is unlikely that mobile nodes will use IPv6
>    addresses only for their connections.


This will look rather strange ten years from now (we hope). How about

   However, since IPv6 is not yet widely deployed, it is unlikely that
   mobile nodes will initially use IPv6 addresses only for their connections.


>    Scenario 3: Home Agent behind a NAT

>    In this scenario, the communication between the mobile node and the
>    home agent is further complicated by the fact that the home agent is
>    located within a private IPv4 network.  However, in this scenario, we
>    assume that the home agent is allocated a globally unique IPv4
>    address.  

Does that mean a *shared* address, so that the home agent only has a share
of the port numbers (i.e. the NAT is a NAPT)?  Any non-NAPT NAT scenario
is pretty unrealistic. In any case, I don't recall any detailed discussion of
this scenario in the main part of the draft.

> 3.3.2.  Foreign Network Supports IPv4 Only
> 
>    If the mobile node is in a foreign network that only supports IPv4,
>    it needs to detect whether a NAT is in its communication path to the
>    home agent.  This is done while exchanging the binding update and
>    acknowledgement messages as shown later in this document.  NAT
>    detection is needed for the purposes of the signaling presented in
>    this specification.  A mobile node SHOULD NOT assume that its IPv4
>    address is globally unique if a NAT device was not detected.

Don't understand the last sentence. How, then, does the node choose to
enter the "3.3.2.1.  Foreign Network Supports IPv4 Only (Public Addresses)"
logic?


> 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.


> 4.1.3.  The Binding Update Message Extensions
...
>    F
> 
>       When set, this flag indicates a request for forcing UDP
>       encapsulation regardless of whether a NAT is present on the path
>       between the mobile node and the home agent.

In what circumstances is this set? (Same question for 4.2.2.)

> 4.2.1.  IPv4 Address Acknowledgement Option
...
>    IPv4 Home Address
> 
>       The IPv4 home address that the home agent will use in the binding
>       cache entry.  This could be a public or private address. 

But if it's private, it's of no value to the mobile, which cannot send
to it. Surely the mobile (and possibly its correspondent node) needs to 
know the public address of the NAT that hides the private home address?

> 4.2.2.  The NAT Detection Option
> 
>    This option is sent from the home agent to the mobile node to
>    indicate whether a NAT was in the path.  This option MAY also include
>    a suggested NAT binding refresh time for the mobile node.  

The home agent has even less chance than the mobile of guessing the NAT's 
timeout. So why is this refresh time a useful addition to the protocol,
rather than just defining the mobile node's default refresh as NATKATIMEOUT?


> 5.1.  Tunelling Formats
...
>    The following value is assigned to the Type field, other values may
>    be assigned in the future:
> 
>       1 GRE

I'm puzzled by the choice of acronym. GRE refers to RFC2784 which has its own
encapsulation header format.

> 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.  It is recommended that the mobile node use PLMTUD
>    as specified in [RFC4459].

Is that not a normative reference to an Informational RFC? The fact
that "recommended" is lower case doesn't change its meaning in English.

"PLMTUD" does not exist in RFC4459.

The most recent recommendations are different - see RFC4821, which is
a Proposed Standard.

>    To accommodate traffic that uses Explicit Congestion Notification
>    (ECN), it is RECOMMENDED that the ECN information is copied between
>    the inner and outer header as defined in [RFC3168].

OK, but why not also suggest that the DSCP be copied, as defined in
RFC2983 (which is Informational)?

> 5.2.  NAT Detection
...
>    Upon receiving the binding acknowledgement with the NAT detection
>    option, the mobile node sets the tunnel to the home agent to UDP
>    encapsulation.  Hence, all future packets to the home agent are
>    tunneled in UDP and IPv4.  For all tunneled IPv6 packets, the source
>    address in the IPv6 header is the mobile node's IPv6 home address and
>    the destination address is the correspondent node's IPv6 address.
>    All tunneled IPv4 packets will contain the mobile node's IPv4 home
>    address in the source address field of the inner IPv4 packet and the
>    correspondent node's IPv4 address in the destination address field.

Where did the correspondent node's IPv4 address come from?

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

How does the mobile know that it's in an IPv4-only network? (Also, there's
a missing verb in that sentence.)

> 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:

>    [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.

>    [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.


Warnings from idnits:

  == It looks like you're using RFC 3978 boilerplate.  You should update
     this, as the boilerplate described in the IETF Trust License Policy
     document (see http://trustee.ietf.org/license-info) is accepted from 10
     November 2008, and will be required from 16 December 2008, 01:00 UTC. 
     Version 1.34 of xml2rfc can be used to produce documents with boilerplate
     according to the mentioned Trust License Policy document.

 == Unused Reference: 'RFC4306' is defined on line 1844, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC4877' is defined on line 1854, but no explicit
     reference was found in the text

  -- Obsolete informational reference (is this intentional?): RFC 3978