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
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
