Subject: [MEXT] Home Link operation over p2p links

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 13 Feb 2008 14:19:44 -0800

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
[email-masked]
http://www.ietf.org/mailman/listinfo/mext

---

From: Julien Laganier <[email-masked]>
Date: Thu, 14 Feb 2008 17:24:46 +0100

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

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 14 Feb 2008 18:27:34 +0100

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

> > 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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Julien Laganier
> Sent: 14. veljaca 2008 17:25
> To: [email-masked]
> 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>
> 
> > 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:
> 
> 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
> >
> >    attached to the home link, it does not have to run 
> IKEv1/IKEv2 with 
> > the home agent to setup the necessary security associations.
> 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 
> 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. 
> 
> 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?
> 
> > 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.
> 
> > 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.
> 
> >    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 
> >    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.
> 
> >    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.
> >
> > 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
> 
> booting up 
> > on the home link over point-to-point links. It describes the issues 
> > and suggests a possible solution.
> >
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 14 Feb 2008 10:37:42 -0800

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.

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

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

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

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.

Vijay

---

From: Julien Laganier <[email-masked]>
Date: Tue, 19 Feb 2008 17:58:17 +0100

Hi Vijay,

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

> the architectures quoted in the draft are supposed to be

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

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

> a new flag in the Binding Update, that is fine with me.

Great.

> 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>
> >
> >>    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
> >> 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:
> >
> > 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
> >> 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.
> >
> > before hand, thus it can't conclude that it is home before it
> > acquire a home address via bootstrapping.
> >
> > 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?
> >
> >> required for mobile router operation, as described in [10], may
> >> also obtained using the Binding Update and Binding Acknowledgement
> >> 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.
> >
> >> 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.
> >
> >>    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.
> >>
> >>    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
> >
> >> http://www.ietf.org/internet-drafts/draft-devarapalli-mext-mipv6-h
> >>ome -link-00.txt
> >>

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 24 Feb 2008 11:33:19 -0800

Hi Julien,

Sorry for the delay in my response.

Julien Laganier wrote:
> the "external" address the node configured on the home link), 

The INTERNAL_IP6_ADDRESS configuration payload does not carry
the prefix length in it. Just the 128-bit address. An address
"fitting" in a prefix is not sufficient to conclude you are
at home.

Having said, the mobile node can use the IKEv2 exchange to
figure out if it is at home. RFC 5026 defines a new
configuration payload attribute called the MIP6_HOME_PREFIX
attribute. This can be used to obtain the home prefix.

> why would 

The draft tries to analyze all the issues, figuring out you
are attached to the home link, associating the address you
obtain via the p2p link mechanism with the MIPv6 virtual
interface, bootstrapping parameters that are obtained as part
of the BU/BAck transfer, etc...

> The mobile network prefix can come from DHCPv6 PD.

Yes, all these are possible.

> time constraints. 

Having a spec completed in the IETF is different from getting the
IPsec vendors to implement it any time soon.

> This can be debated of course :)

Yes, but over beer. :)

> router comes in place. 

Not if the mobile router is on the home link. Anyway, I don't
think a DHCPv6 relay (that is on the home agent) creates
forwarding entries for the mobile network prefix delegated to
the mobile router. You still need a BU for setting up
forwarding.

>>> implementation should behave with bootstrapping while on the home

Even if we conclude that we don't need to extend the Binding
Update with a flag, I would like us to work on a document that
describes how the mobile node boots up on a p2p link attached
to the home agent and concludes that it is on the home link.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 24 Feb 2008 12:24:49 -0800

Hello,

I updated the document to include a paragraph explaining that
the home agent treats the BU sent from the home link, when the
mobile node boots up, as a de-registration BU and responds with
status '133' in the binding ack.

http://www.ietf.org/internet-drafts/draft-devarapalli-mext-mipv6-home-link-01.txt

Vijay