Re: [Gen-art] Gen-ART LC review of draft-ietf-mext-nemo-v4traversal-06.txt

Hi Hesham, see in line. Especially on the GRE point, I think
there's still an open issue.

On 2008-12-01 21:50, Hesham Soliman wrote:
> Hi Brian,
> 
> Thanks for the review and apologies for the late response. I'll only respond
> to comments that need further discussions or include your questions. I won't
> include comments that I'll address as you requested.
> 
>> 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?
> 
> => Perhaps it was my clumsy way of saying "just because there is no NAT
> between a MN and the HA, doesn't mean your address is globally unique",
> which is true of course. But I'm not sure it's a useful comment. So I can
> remove that. 

Yes, I think in this case deletion is the best clarification :-)

> 
>>    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.)
> 
> => If the MN is configured by a policy that requires it to always use UDP
> encapsulation, or if it tried normal IP in IP and it didn't work. Presumably
> the latter happened because the firewall didn't allow IP in IP.

OK. I think it would be clearer for the reader if you add this information.

> 
>>    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?
> 
> => This is the home address of the mobile node. It doesn't send to it. I
> think you must've thought it was the home agent's address?

I certainly wasn't thinking quite clearly. Of course, it's the correspondent
node that can never send directly to the private home address; the
correspondent node will only ever know the NATted 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?
> 
> => It was suggested by people to allow home agent's that are usually within
> the same admin domain to configure longer periods based on administrative
> configuration. This is for networks like 3GPP networks where the mobile node
> is usually within the same admin domain.

OK, as long as there is a reason for the extra complication.

> 
> 
>> 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.
> 
> => I know, it's the same GRE. People wanted to put GRE encapsulation in this
> specification.

Well in that case there needs to be a reference to RFC2784 and perhaps
RFC2890. I'm quite confused, because there is nothing in the text that
refers to GRE encapsulation - the only specific encapsulation mentioned
is RFC2473 and RFC4213, and neither of those use GRE as far as I know.
You can't use the same TLV to indicate both GRE and non-GRE encapsulations.

> 
>>    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)?
> 
> => Ok, but I'll use 4213, which obsoletes 2983.

Wrong! It obsoletes 2893. Very confusing...

> 
>> 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?
> 
> => Well, the mobile node is talking to a correspondent node. The address
> could come from anywhere. This is simply an illustration of how traffic is
> routed from a correspondent node to a mobile node and vice versa.

OK, but I believe this is almost the only place that the correspondent
node is mentioned, so it came as a bit of a surprise.

> 
>>    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.)
> 
> => Ok about the verb. The mobile node knows because it didn't receive any
> IPv6 information from the router, i.e. Router advertisements.

I think you should say a few words about that (i.e. that you assume that
the stack provides a status indicator of some kind for this, since this
is not a part of MIP6 itself).

    Brian
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art