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

[<[e-mail]>]

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: [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
>