Re: [MEXT] Home Link operation over p2p links

[Julien Laganier <julien.IETF at laposte.net>]

Hi Vijay,

On Thursday 14 February 2008, Vijay Devarapalli wrote:
> Hi Julien,
>
> Thanks for reviewing the document. A few high level comments
> first.
>
> - When the home agent receives a Binding Update from a mobile
> node on the home link, it is treated as a de-registration BU.
> This is according to RFC 3775 and has not been updated by any
> spec. When the home agent receives this BU from the mobile
> node, if it does not have a valid binding cache entry, it
> responds with the status 133 (Not home agent for this mobile
> node) in the binding ack. When the mobile node boots up in
> the point-to-point home link, the home agent does not have a
> valid binding cache entry for the mobile node. The DS-MIPv6
> IPv4 home address and Mobile Network prefixes will not be
> sent in the binding ack, since the Binding Update is seen as
> a failed one. This is one of the reasons why we introduced a
> new flag in the Binding Update.

You're right. I overlooked that fact. But anyway if you conclude you're 
home from the IKEv2 exchange (because the INTERNAL_IP6_ADDRESS either 
fits in the prefix advertized from RAs or is in the same prefix that 
the "external" address the node configured on the home link), why would 
you need to send a BU.

The IPv4 home address could be obtained from DCHPv4 (one could also 
think it comes thru an INTERNAL_IP4_ADDRESS in the IKEv2 exchange but 
let's not digress :)

The mobile network prefix can come from DHCPv6 PD.

> - I am aware of Pasi's draft on making IPsec tunnels look like
> regular IPv6 links. It might be a good idea, but the problem is
> that this draft has no "home" right now. Not sure if it will
> get standardized in the time frame we are looking at. Some of
> the architectures quoted in the draft are supposed to be
> finalized this year.

While I completely agree it is important to get specifications needed by 
SDOs relying on IETF protocols out in a timely fashion, as a general 
principle I do not think we should base protocol design decision on 
time constraints. This can be debated of course :)

> - Regarding the mobile router using DHCPv6 prefix delegation
> to acquire the mobile network prefixes when at home, there are
> some issues. Since the mobile router is reachable only over the
> p2p link, the home agent becomes the default router where all
> the packets meant for the mobile router's mobile network
> prefixes arrive. The home agent according to RFC 3963 does not
> create forwarding entries for the mobile router prefixes until
> it receives a Binding Update from the mobile router with the
> prefixes in the message. The home agent does not advertise
> reachability for the mobile network prefixes either until
> there is a valid binding cache entry for the mobile router.

When at home, why couldn't the mobile network prefix comes directly out 
of DHCPv6 PD, without BU. When a network prefix is delegated to a 
router, presumably forwarding entries for that prefix pointing to that 
router comes in place. If the router is a mobile router, when it leaves 
home it can send BUs to get that routed through a tunnel. What am I 
missing?

> - Regarding the solution proposed in the draft, if it turns out
> that we can resolve all the issues without having to introduce
> a new flag in the Binding Update, that is fine with me.

Great.

> I am not going to respond in detail to your comments below, yet.
> I want to check if you agree with the comments above first.

Ok.

--julien

> Julien Laganier wrote:
> > 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-h
> >>ome -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