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

On 23/02/09 9:35 PM, "Christian.Kaas-Petersen@tieto.com"
<Christian.Kaas-Petersen@tieto.com> wrote:

> It is not clear to me, that RFC 3775 allows the exchange
> of Mobile Prefix Solicitations and Mobile Prefix Advertisements
> during bootstrapping.

=> It doesn't. It only allows it after the MN gets a HoA.

If a mobile node is booting in a foreign network,
> and has no home address, it has not yet made any registration with
> a home agent, then certainly the home agent has no way to send
> unsolicited MPA to a mobile node (RFC 3775 sec 6.8).  Should the
> mobile node attempt to send a MPS to the home agent, it is a
> requirement the Home Address destination option is included in an
> ESP protected packet (RFC 3775 sec 6.7), which means it must have
> a home address.  That's why I fail to understand how MPS/MPA can
> be used for bootstrapping, because the home address is required.
> 
> In my view, this does not change with DSMIP, except that the home
> address is no longer stored in a destination option but in the
> (inner) IPv6 source address.  Because the mobile node already knows
> its IPv6 home address, I should think it a valid functionality
> to ask the home agent of any updates in the IPv6 home prefixes.

=> DSMIP will not change the use of the HAO for MPS and MPA. The HAO will
still be used.

Hesham

> 
> Christian
>  
> 
>> -----Original Message-----
>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On
>> Behalf Of Basavaraj.Patil@nokia.com
>> Sent: 20. februar 2009 22:28
>> To: hesham@elevatemobile.com; mext@ietf.org
>> Subject: 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
>> 
>> _______________________________________________
>> MEXT mailing list
>> MEXT@ietf.org
>> https://www.ietf.org/mailman/listinfo/mext
>> 