Re: [MEXT] Home Link operation over p2p links

["Premec, Domagoj" <domagoj.premec at siemens.com>]

Hi Julien, Vijay,

> In the case of bootstrapping the MN does not know its home 
> address before hand, thus it can't conclude that it is home 
> before it acquire a home address via bootstrapping. 
> 
> By default it will thus assume it is not at home and initiate 
> bootstrapping. Hence there is a need to send a BU to get the 
> Home Address. As you note "the IKEv2 exchange is triggered by 
> the need to send a binding update", thus I assume IKEv2 would 
> be triggered to acquire an home address.
> 
> Then the MN can conclude it is home (because HoA included in 
> RA's PIO) and drop the IKE and IPsec association.

Another way how a MN could detect it is on its home link is by using DHCP: if the Home network prefix in Home Network Information option matches the prefix in RA's PIO then the MN is at home link. This would avoid the overhead of setting up the IKE SA.

> >    The IKEv2 exchange is only used to bootstrap the MIPv6 home 
> > address. The DS-MIPv6 [11] IPv4 home address is obtained by 
> the mobile 
> > node using the exchange of Binding Update and Binding 
> Acknowledgement 
> > with the home agent.

IPv4 HoA could be obtained via IKEv2 exchange in the same way as IPv6 HoA.

domagoj



> -----Original Message-----
> From: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] On 
> Behalf Of Julien Laganier
> Sent: 14. veljaca 2008 17:25
> To: mext at ietf.org
> Subject: Re: [MEXT] Home Link operation over p2p links
> 
> Hello Vijay,
> 
> Thanks for submitting the draft in time! This is definitely 
> helpful to assess the rechartering work item you proposed.
> 
> <chair hat off>
> 
> I have couple of comments on your draft:
> 
> > 3.1.  Detecting Attachment to the Home Link
> >
> >    In Mobile IPv6, a mobile node detects that it has attached to the
> >    home link when it receives a router advertisement with the home
> >    prefix.  Some of the point-to-point links like IPsec tunnels and
> >    PMIPv6 tunnels do not support running neighbor discovery in the
> >    tunnels.  When the home link is created by concatenating a GTP 
> > tunnel with a PMIPv6 tunnel or an IPsec tunnel with PMIPv6 
> tunnels, it 
> > becomes difficult for a router advertisement to be sent over the 
> > concatenated tunnels.
> 
> When "concatenating a GTP tunnel with a PMIPv6 tunnel", the 
> RS can be sent through the GTP tunnel by the MN, up to the 
> MAG. Then the MAG replies with an RA containing the Home 
> Network Prefix, so there doesn't seem to be an issue. Am I 
> missing something?
> 
> When "concatenating an IPsec tunnel with a PMIPv6 tunnel", 
> the MN cannot send the RS through the IPsec tunnel, and 
> likewise, the MAG wouldn't be able to reply with an RA 
> containing the Home Network Prefix. However, isn't the main 
> issue at stake here the fact that IPsec "interfaces" are not 
> fully fledged IPv6 interface, i.e. they do not support 
> link-local addresses and multicast, etc. See Pasi's draft 
> describing the issues and possible solution:
> 
> 	draft-eronen-ipsec-ikev2-ipv6-config-02.txt
> 
> It seems to me that if what Pasi proposes was implemented in 
> the HA implementing IKEv2, then the issues your draft describe w.r.t. 
> detecting home link attachment would vanish. If that is the 
> case, wouldn't the right approach be to fix IPsec rather than 
> extending MIPv6 because IPsec has a deficiency?
> 
> > 3.2.  Bootstrapping
> >
> >    Mobile IPv6 bootstrapping [8] and [9] depends on the use of IKEv2
> >    between the mobile node and the home agent to bootstrap the MIPv6
> >    home address.  According to RFC 3775, when the mobile node is
> >    attached to the home link, it does not have to run 
> IKEv1/IKEv2 with 
> > the home agent to setup the necessary security associations.
> > Most often, the IKEv2 exchange is triggered by the need to send a 
> > binding update.  So if the mobile node boots up the home 
> link, it may 
> > not be able to use IKEv2 to bootstrap the MIPv6 home address.
> 
> Purely based on RFC3775 the MN does not have to run IKE to 
> setup SA's with HA when it is attached on its home link (But 
> note that here we're talking about bootstrapping and that 
> wasn't part of 3775 so we can't reason uniquely in terms of 
> what 3775 says). However, the only ways for a MN to figure 
> out that it is attached on its home link are either to 
> compare its home address with the prefix advertized on-link in RA's. 
> 
> In the case of bootstrapping the MN does not know its home 
> address before hand, thus it can't conclude that it is home 
> before it acquire a home address via bootstrapping. 
> 
> By default it will thus assume it is not at home and initiate 
> bootstrapping. Hence there is a need to send a BU to get the 
> Home Address. As you note "the IKEv2 exchange is triggered by 
> the need to send a binding update", thus I assume IKEv2 would 
> be triggered to acquire an home address.
> 
> Then the MN can conclude it is home (because HoA included in 
> RA's PIO) and drop the IKE and IPsec association.
> 
> It is true that it isn't written down but to me it looks 
> logical that an implementor would follow these steps. Do you 
> think such a procedure is inappropriate?
> 
> >    The IKEv2 exchange is only used to bootstrap the MIPv6 home 
> > address. The DS-MIPv6 [11] IPv4 home address is obtained by 
> the mobile 
> > node using the exchange of Binding Update and Binding 
> Acknowledgement 
> > with the home agent.  The Mobile Network Prefixes required 
> for mobile 
> > router operation, as described in [10], may also obtained using the 
> > Binding Update and Binding Acknowledgement exchange between 
> the mobile 
> > router and the home agent.  This is specified in [12]. According to 
> > the current specifications, the mobile node (or the mobile router) 
> > does not send a Binding Update to the home agent when it is 
> attached 
> > to the home link.
> 
> Regarding IPv4 home address allocation, the same reasoning 
> applies as with bootstrapping of the MIPv6 home address 
> above: there would be a need to send a BU (to get the IPv4 
> HoA) thus IKE would be triggered, and dropped down once the 
> v4 address is known.
> 
> Regarding Mobile Network Prefix Assignment, there's no 
> agreement yet whether this is done with extensions to BUs and 
> BAs, or using DHCP. If it was done using DHCP it could work 
> provided that DHCP requests can be sent thru the 
> point-to-point link. Francis has proposed a method where a 
> DHCP relay is collocated on the MR, and thus only unicast 
> DHCP messages have to be sent and received. Therefore it 
> would work well on a point-to-point link.
> 
> >    Since it is not typical for the mobile node to initiate an IKEv2
> >    exchange with its home agent and not possible to send a Binding
> >    Update from the home link, there is a need for other 
> bootstrapping
> >    mechanisms that would work across all point-to-point home links.
> >    However, this would result in the mobile node using different
> >    bootstrapping mechanisms depending on the point-to-point that 
> > appears as the home link.  The mobile node would also end 
> with using 
> > different bootstrapping mechanisms when attached to the 
> home link and 
> > when attached to the visited link.  To avoid this, it would be 
> > desirable to use the same bootstrapping mechanisms 
> irrespective of the 
> > point-to-point link that appears as the home link and/or 
> the visited 
> > link.
> 
> But it looks like the same IKEv2 based bootstrapping 
> mechanism is used in everycase, it is just that once the MN 
> figures out it is at home it can drop the IKE and IPsec SA's.
> 
> > 3.4.  Forwarding at the Home Agent
> >
> >    According to RFC 3775, when the mobile node is attached 
> to the home 
> > link, it behaves as a regular IPv6 host and is able to send/receive 
> > packets directly without going through the home agent.
> > In case the home agent needs to send any packet to the 
> mobile node, it 
> > has a valid neighbor cache entry for the mobile node which is then 
> > used to forward packets to the mobile node.
> >
> >    When point-to-point links are used a home links, then the packets
> >    meant for the mobile node always reach the home agent 
> first and are 
> > then forwarded to the mobile node.  However, the home agent cannot 
> > construct a neighbor cache entry for the mobile node, since most of 
> > the point-to-point links mentioned in Section 1 do not 
> support sending 
> > neighbor solicitation and receiving neighbor advertisement messages.
> 
> Again, if IPsec was fixed as in Pasi's proposal then it would 
> work just fine. Other point-to-point links happily carry 
> multicast traffic.
> 
> > 3.5.  Indicating Service Selection Option
> >
> >    A new extension, the Service Selection for Mobile IPv6, has been
> >    specified in [13] for the mobile node to indicate to the 
> home agent 
> > which service it wants to access.  The Service Selection option is 
> > sent in the Binding Update.  When the mobile node boots up 
> in the home 
> > link, it won't be able to indicate the service it wants to 
> access to 
> > the home agent, since the Binding Update message is not 
> sent from the 
> > home link.
> >
> >    It is possible to indicate the Service the mobile node wants to
> >    access in the IKEv2 exchange with the home agent.  The service
> >    information is encoded in the IDr payload in the IKEv2 exchange.
> >    However, this requires the mobile node to initiate an IKEv2 
> > exchange with the mobile node from the home link.  According to RFC 
> > 3775, the mobile node does not have to initiate an IKEv2 
> exchange when 
> > it boots up in the home link.
> 
> Same goes here than for bootstrapping. There's indeed a need 
> to send a BU, so does the MN, then IKEv2 kicks in, BU is sent 
> out, and no problem.
> 
> In conclusion I am not sure there's a clear case to extend 
> MIPv6. Maybe there's some room for a document clarifying how 
> implementation should behave with bootstrapping while on the 
> home link.
> 
> What do you think?
> 
> Best,
> 
> --julien
> 
> On Wednesday 13 February 2008, Vijay Devarapalli wrote:
> > Hello folks,
> >
> > Here is a draft that describes issues with the mobile node 
> booting up 
> > on the home link over point-to-point links. It describes the issues 
> > and suggests a possible solution.
> >
> > 
> http://www.ietf.org/internet-drafts/draft-devarapalli-mext-mipv6-home
> >-link-00.txt
> >
> > Comments/reviews are welcome.
> >
> > Vijay
> > _______________________________________________
> > MEXT mailing list
> > MEXT at ietf.org
> > http://www.ietf.org/mailman/listinfo/mext
> 
> 
> _______________________________________________
> MEXT mailing list
> MEXT at ietf.org
> http://www.ietf.org/mailman/listinfo/mext
> 
> 
_______________________________________________
MEXT mailing list
MEXT at ietf.org
http://www.ietf.org/mailman/listinfo/mext