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

From: Hesham Soliman <[email-masked]>
Date: Thu, 19 Feb 2009 14:30:25 +1100

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

---

From: <[email-masked]>
Date: Fri, 20 Feb 2009 22:27:41 +0100

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" <[email-masked]> wrote:

> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: <[email-masked]>
Date: Mon, 23 Feb 2009 11:35:56 +0100

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

Christian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: 20. februar 2009 22:28
> To: [email-masked]; [email-masked]
> 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.
> 
> - 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
> 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
> 
> 
> > 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:
> >> 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
> >
> >

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Feb 2009 11:48:23 +0100

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

[email-masked] 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

> 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: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of 
>> [email-masked] Sent: 20. februar 2009 22:28 To: 
>> [email-masked]; [email-masked] Subject: Re: [MEXT] FW: 
>> DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal
>> 
>> 
>> Hi Hesham,
>> 
>>  - 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
>> 
>> 
>>> 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
>>>>> and based on the mobile node's IPv4 care-of address as 
>>>>> described in [RFC3775].  Since the mobile node needs to
>> encapsulate all IPv6
>>> can send the prefix solicitation and receive advertisement from 
>>> its HA, while located in a foreign link. These messages may be
>> sent before
>>> _______________________________________________ MEXT mailing list
>>>  [email-masked] https://www.ietf.org/mailman/listinfo/mext
>> _______________________________________________ MEXT mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/mext
>> 
> _______________________________________________ MEXT mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/mext
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Feb 2009 11:50:12 +0100

> solicitation when attached via an IPv4 only network.

Inconvenient: losing the ability to deal with renumbering of the home 
network.

Alex

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 23 Feb 2009 22:17:00 +1100

On 23/02/09 9:35 PM, "[email-masked]"
<[email-masked]> wrote:

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

---

From: <[email-masked]>
Date: Mon, 23 Feb 2009 15:46:20 +0100

> Inconvenient: losing the ability to deal with renumbering of the home

This is based on the assumption that an HoA that is assigned to an MN will
essentially be static. I don't see this as being practical since MNs will
tend to obtain an HoA dynamically every time they boot or other intervals.
So renumbering of the home network is a non-issue.

-Raj