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

[Alexandru Petrescu <[e-mail]>]

Side note about Mobile IPv6 bootstrapping... not sure about the DSMIPv6
aspect.

[e-mail] a écrit :
> It is not clear to me, that RFC 3775 allows the exchange of Mobile 
> Prefix Solicitations and Mobile Prefix Advertisements during 
> bootstrapping.  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).

I agree.

I think MN would discover the HA (DHAAD to anycast address, derived from
the home prefix) before sending the MPS (Mobile Prefix Sol'n) to a
specific HA address.  Once the MN has the HA address, and receives the
MPA (Mobile Prefix Adv't) it can derive its Home Address from the prefix
in MPA; probably this prefix is the same as the prefix initially used to
form the HA anycast address, except MN is now sure to have the latest info.

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

WEll, if the HA and MN don't have an SA, then they could run a dynamic
key formation (IKE?) right after the DHAAD phase.  I think this would
permit to protect the MPS/MPA exchange, without necessarily MN to have a
HoA.

Alex

> 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.
> 
> Christian
> 
> 
>> -----Original Message----- From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of 
>> [e-mail] Sent: 20. februar 2009 22:28 To: 
>> [e-mail]; [e-mail] 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" <[e-mail]>
>>  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
>>>  [e-mail] https://www.ietf.org/mailman/listinfo/mext
>> _______________________________________________ MEXT mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/mext
>> 
> _______________________________________________ MEXT mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/mext
>