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

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Nov 2008 14:56:11 +1300

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 01 Dec 2008 19:50:51 +1100

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. 

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

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

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

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

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

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

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

Hesham

On 17/11/08 12:56 PM, "Brian E Carpenter" <[email-masked]>
wrote: