Re: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal

Hi Hesham,

After looking at your proposed text, I must say that I am not totally
convinced.

Stepping back from the specific issue raised by Pasi for a moment,
- Do we really need to have the capability to obtain the prefix from the HA
when the MN does not have IPv6 connectivity to the HA? While I recognize the
fact that this mechanism is specified in RFC3775 as a means by which the MN
can obtain the prefix from the HA to bootstrap, I don't believe it has much
value.
Since other bootstrapping mechanisms have been developed, I do not see the
need for obtaining the prefix from the HA by an MN using the prefix
solicitation mechanism, especially in the case where the MN is attached via
IPv4 only. Hence I would suggest removing this feature entirely from the
DSMIP6 I-D. I do not see any harm in not having the capability to do prefix
solicitation when attached via an IPv4 only network.

-Raj

On 2/18/09 9:30 PM, "ext Hesham Soliman" <hesham@elevatemobile.com> wrote:

> Folks,
>
> Please take a look the Pasi's comment below and my response and let me know
> if anyone has comments on this before I submit the draft. This should be the
> final comment on the doc. Does the text in section 3.2 make sense? If not,
> does the explanation below make sense? If not please suggest text.
>
>
>> Section 3.2:
>>>   Securing these messages requires the mobile node to have a
>>>   security association with the home agent, using IPsec (AH or ESP)
>>>   and based on the mobile node's IPv4 care-of address as described
>>>   in [RFC3775].  Since the mobile node needs to encapsulate all IPv6
>>>   traffic sent to the home agent into IPv4 while located in an
>>>   IPv4-only visited network, this SA would match all packets if the
>>>   selectors were based on the information in the outer header.
>>
>> This looks strange (when using tunnel mode IPsec, the selectors select
>> the packets to be protected before the outer header is added -- so the
>> last sentence is weird) -- what are the IPsec SPD entries, and what
>> does the resulting packet look like?
>>
>
> => I was confused by the snippet above and then went back to see why I added
> this a long time ago. Basically the scenario here is that a MN can send the
> prefix solicitation and receive advertisement from its HA, while located in
> a foreign link. These messages may be sent before a home address is
> allocated. So, if a MN is located in an IPv4 network, it would have to
> negotiate the SA using IPv4 and it's IPv4 address is one of the selectors.
> The inner IPv6 packet would probably contain a link local in the src address
> since there is no global IPv6 address available to the MN. In 3775/6, the
> (un-encapsulated message) is protected by a transport mode SA. In DSMIP, if
> we do a transport mode SA on the outer header, then this SA would apply to
> all traffic since everything is tunnelled back to the HA. And the outer
> header is identical for all packets.
>
> Does this make sense to you? If so, I can clarify the text according to this
> logic. If not, please let me know what I missed.
>
> Hesham
>
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext