Subject: [MEXT] Home Link Detection

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Mar 2008 07:13:29 -0700

Folks,

In RFC 3775 and 3963, it is assumed that the mobile node is
pre-configure with the home prefix. So when it sees a router
advertisement with the same prefix, it knows it is on the home
link.

This was before we developed the Mobile IPv6 bootstrapping
mechanisms. In the bootstrapping work, the mobile node does not
have to be configured with a home prefix. All the mobile node
needs to be configured with is an identity that it can present
to the home agent, and the home agent FQDN. See RFC 5026 and
the bootstrapping problem statement. So when the mobile node
boots up on the home link, there is no pre-configured prefix
for it to compare with the prefix received in the router
advertisement.

One possible mechanism is to configure an address/prefix from
the link layer set up (link-specific mechanism) and then obtain
the home prefix from the home agent. The mobile node would then
compare the two prefixes to figure out if it is attached to the
home link. To configure a prefix from the home agent using
IKEv2, the mobile node MUST use the MIP6_HOME_PREFIX attribute
defined in RFC 5026. Note that the MIP6_HOME_PREFIX attribute
was originally defined for home address auto-configuration, not
for home link detection. We need to specify this somewhere, and
I would prefer the IETF specifying it.

Note that this was mentioned on slide 8 in the slides Jouni
presented.

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 12 Mar 2008 15:22:35 +0100

IMHO you take the problem by the bad side, i.e., in place of trying
to decide if the link is a home link, just define the link to be a
home link.

Thanks

[email-masked]

PS: this idea is based on my understanding of the architecture, perhaps
not correct: depending on the access technology either real IPv6 mobility
is used or the access link is merged at the layer two in the home link
(so the currently used access technology guides the choice).
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Mar 2008 07:25:49 -0700

> to decide if the link is a home link, just define the link to be a

This can be done, but it is better to avoid configuration on
the mobile node which tells it which link is the home link.
A dynamic home link detection mechanism is always preferable.

Vijay

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 12 Mar 2008 07:49:18 -0700

Hello Vijay,

That depends on the price of the mechanism for
doing the dynamic link detection.

Regards,
Charlie P.

---

From: "Davis, Terry L" <[email-masked]>
Date: Wed, 12 Mar 2008 08:11:03 -0700

Charlie

I tend to agree with Vijay at least whenever I envision trying to use it
at an airport.  That implies several hundred aircraft at a time (maybe a
couple thousand different aircraft over a week) owned by 20 or 30
different airlines using multiple communication link types (wired,
wireless, satcom, etc) through maybe up to ten different service
providers simultaneously.  In that scenario, dynamic is probably cheap.

Wish I could have made back there for the meeting!

Take care
Terry

PS: And those several hundred aircraft, will each use probably 20 or 30
other airports scattered around the globe weekly.

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Wednesday, March 12, 2008 7:49 AM
> To: Vijay Devarapalli
> Cc: [email-masked]
> Subject: Re: [MEXT] Home Link Detection
> 
> 
> Hello Vijay,
>

---

From: <[email-masked]>
Date: Wed, 12 Mar 2008 16:19:58 +0100

Hello Francis,

I agree, but a HA  for this link must be detected if not the link must be considered as a visited link.

Regards,

Kassi

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Francis Dupont
Envoyé : mercredi 12 mars 2008 15:23
À : Vijay Devarapalli
Cc : Julien Laganier; [email-masked]
Objet : Re: [MEXT] Home Link Detection

IMHO you take the problem by the bad side, i.e., in place of trying to decide if the link is a home link, just define the link to be a home link.

Thanks

PS: this idea is based on my understanding of the architecture, perhaps not correct: depending on the access technology either real IPv6 mobility is used or the access link is merged at the layer two in the home link (so the currently used access technology guides the choice).
_______________________________________________
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: <[email-masked]>
Date: Wed, 12 Mar 2008 17:22:02 +0200

Hi

Well, I also agree with what Vijay suggest in terms of DHAAD. But
perhaps networks resources are used more due to anycast traffic as DHAAA
req. use HA anycast address of its own home subnet prefix. Perhaps this
is the price??

regds
Preeti

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Davis, Terry L
>Sent: 12 March, 2008 17:11
>To: [email-masked]; Vijay Devarapalli
>Cc: [email-masked]
>I tend to agree with Vijay at least whenever I envision trying 
>to use it at an airport.  That implies several hundred 
>aircraft at a time (maybe a couple thousand different aircraft 
>over a week) owned by 20 or 30 different airlines using 
>multiple communication link types (wired, wireless, satcom, 
>etc) through maybe up to ten different service providers 
>simultaneously.  In that scenario, dynamic is probably cheap.
>
>PS: And those several hundred aircraft, will each use probably 
>20 or 30 other airports scattered around the globe weekly.
>
>
>> That depends on the price of the mechanism for doing the 
>dynamic link 
>> detection.
>> 
>> Regards,
>> Charlie P.
>> 
>> 
>> Vijay Devarapalli wrote:
>> > Francis Dupont wrote:
>> >
>> > This can be done, but it is better to avoid configuration on the 
>> > mobile node which tells it which link is the home link.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 12 Mar 2008 16:24:37 +0100

And please note the I-D is not about what one should do but about
the prefix delegation for NEMO documents should specify (so incompatible
solutions are not an issue as they should not be specified together :-).

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Wed, 12 Mar 2008 16:26:51 +0100

In your previous mail you wrote:

   I agree, but a HA for this link must be detected if not the link
   must be considered as a visited link.
   
=> on a point-to-point link I am fine with the assumption the other
end is the HA.

Thanks

---

From: "Premec, Domagoj" <[email-masked]>
Date: Wed, 12 Mar 2008 18:01:33 +0100

Vijay,

Another alternative for detecting the home link is to make use of the home network information option defined in draft-hiopt. If the home network prefix in the home network information option matches the prefix configured on the p2p interface, then the MN is at home. This would work without establishing a security association with the HA.

domagoj

> Behalf Of Vijay Devarapalli
> Sent: 12. ozujak 2008 15:13
> To: [email-masked]
> Cc: Julien Laganier
> Subject: [MEXT] Home Link Detection
> 
> Folks,
> 
> advertisement with the same prefix, it knows it is on the home link.
> 
> mechanisms. In the bootstrapping work, the mobile node does 
> not have to be configured with a home prefix. All the mobile 
> node needs to be configured with is an identity that it can 
> present to the home agent, and the home agent FQDN. See RFC 
> 5026 and the bootstrapping problem statement. So when the 
> mobile node boots up on the home link, there is no 
> pre-configured prefix for it to compare with the prefix 
> received in the router advertisement.
> 
> the link layer set up (link-specific mechanism) and then 
> obtain the home prefix from the home agent. The mobile node 
> would then compare the two prefixes to figure out if it is 
> attached to the home link. To configure a prefix from the 
> home agent using IKEv2, the mobile node MUST use the 
> MIP6_HOME_PREFIX attribute defined in RFC 5026. Note that the 
> MIP6_HOME_PREFIX attribute was originally defined for home 
> address auto-configuration, not for home link detection. We 
> need to specify this somewhere, and I would prefer the IETF 
> specifying it.
> 
> Note that this was mentioned on slide 8 in the slides Jouni presented.
> 
> Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Mar 2008 10:07:06 -0700

> Another alternative for detecting the home link is to make use of the home network information option defined in draft-hiopt. If the home network prefix in the home network information option match…

Could work. Though this requires the use of DHCPv6 on the p2p
link. DHCPv6 may not be available.

Vijay

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 12 Mar 2008 10:34:05 -0700

Hi Vijay,

During the meeting there was good consensus among people that the way of
doing this is to compare the prefix received in RA with the prefix
received in the MIP6_HOME_PREFIX attribute of the configuration payload.

The intention is to scope better the problem in the mailing list to
understand if there is interest in working on an Informational document,
i.e. writing a paragraph which should eventually go into the charter.

Gerardo

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Vijay Devarapalli
> Sent: Wednesday, March 12, 2008 10:07 AM
> To: Premec, Domagoj
> Cc: Julien Laganier; [email-masked]
> > Another alternative for detecting the home link is to make use of
the
> home network information option defined in draft-hiopt. If the home
> network prefix in the home network information option matches the
prefix
> configured on the p2p interface, then the MN is at home. This would
work
> without establishing a security association with the HA.
> 
link.
presented.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 12 Mar 2008 21:13:08 +0100

Vijay Devarapalli wrote:
> have to be configured with a home prefix.

Well I'm not sure why you mentioning this... ?

Is the bootstrapping work a mandatory implementation?  In my 
understanding I can go ahead and bootstrap MRs without using the 
bootstrapping work.  I can just use DHAAD and MPD and pre-configure the 
home prefix on MNs.

Apparently that bootstrapping method _can_ support ptp links?

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Mar 2008 14:31:00 -0700

> bootstrapping work.  I can just use DHAAD and MPD and pre-configure the 

 From what I have seen, SDOs that are planning to use Mobile IPv6
do not configure the mobile node with a home prefix. The home
agent (and the home prefix) are assigned dynamically most of the
time. In fact, the same mobile node might be assigned different
home agents (and home prefixes) depending on what service it is
trying to access.

Using DHAAD (dynamic home agent address discovery) requires that
the mobile node is configured with the home prefix. The mobile
node needs the prefix to construct the DHAAD anycast address.

Bootstrapping is not mandatory, of course. You can always deploy
a system where the mobile node is configured with a permanent
(or a long lived) home prefix.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 12 Mar 2008 23:08:57 +0100

Vijay Devarapalli wrote:
>> bootstrapping work.  I can just use DHAAD and MPD and pre-configure
>>  the home prefix on MNs.
> 
> From what I have seen, SDOs that are planning to use Mobile IPv6 do
> not configure the mobile node with a home prefix. The home agent (and
> the home prefix) are assigned dynamically most of the time. In fact,
> the same mobile node might be assigned different home agents (and
> home prefixes) depending on what service it is trying to access.

This may be language but I don't understand what you mean.

The SDO phones I've used are always pre-configured with some fixed
strings, always the APN name or IP address of it, never change.  I don't
know how future SDO phones will be pre-configured though.  You seem to
know.   You may be right.

> Using DHAAD (dynamic home agent address discovery) requires that the
> mobile node is configured with the home prefix. The mobile node needs
> the prefix to construct the DHAAD anycast address.

Right.

> Bootstrapping is not mandatory, of course. You can always deploy a
> system where the mobile node is configured with a permanent (or a
> long lived) home prefix.

Ok,

Alex

>>  This email has been scanned by the MessageLabs Email Security
>> System. For more information please visit
>> http://www.messagelabs.com/email

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 13 Mar 2008 14:16:54 +0100

Vijay,

> link. DHCPv6 may not be available.

At least one SDO relies on the draft-hiopt for MIP6 bootstraping, so it would be worth mentioning this option as one way of doing home link detection. I agree that DHCPv6 may not be always available, even though only stateless DHCPv6 is needed in this context.

domagoj

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: 12. ozujak 2008 18:07
> To: Premec, Domagoj
> Cc: [email-masked]; Julien Laganier
> > Another alternative for detecting the home link is to make 
> use of the home network information option defined in 
> draft-hiopt. If the home network prefix in the home network 
> information option matches the prefix configured on the p2p 
> interface, then the MN is at home. This would work without 
> establishing a security association with the HA.
> 
> >> Of Vijay Devarapalli
> >> mechanisms. In the bootstrapping work, the mobile node 
> does not have 
> >> to be configured with a home prefix. All the mobile node 
> needs to be 
> >> configured with is an identity that it can present to the 
> home agent, 
> >> and the home agent FQDN. See RFC
> mobile node 
> >> boots up on the home link, there is no pre-configured 
> prefix for it 
> >> to compare with the prefix received in the router advertisement.
> >>
> >> One possible mechanism is to configure an address/prefix from the 
> >> link layer set up (link-specific mechanism) and then 
> obtain the home 
> >> prefix from the home agent. The mobile node would then compare the 
> >> two prefixes to figure out if it is attached to the home link. To 
> >> configure a prefix from the home agent using IKEv2, the 
> mobile node 
> >> MUST use the MIP6_HOME_PREFIX attribute defined in RFC 5026. Note 
> >> that the MIP6_HOME_PREFIX attribute was originally defined 
> for home 
> >> address auto-configuration, not for home link detection. 
> We need to 
> >> specify this somewhere, and I would prefer the IETF specifying it.
> >>

---

From: Julien Laganier <[email-masked]>
Date: Tue, 18 Mar 2008 11:20:51 +0100

Hi Vijay,

<chair hat off>

One comment below:

> advertisement with the same prefix, it knows it is on the home

When RFC 5026 is used, the MN has no pre-configured home prefix but get 
it dynamically in the MIP6_HOME_PREFIX attribute obtained via the IKEv2 
exchange of the bootstrapping mechanism. Then it simply behave as 
usual, i.e., quoting you "when it sees a router advertisement with the 
same prefix, it knows it is on the home link."

I don't see what requires additional specification.

--julien

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Mar 2008 16:04:23 -0700

> same prefix, it knows it is on the home link."

The sequence of steps when the MN boots up on the home link would be
the other way around. The MN would first boot up, setup the link and
then run IKEv2 with the home agent. Not run IKEv2 with the home agent
and then send a router solicitation on the home link to trigger a
router advertisement.

> I don't see what requires additional specification.

There is nothing that specifies that the mobile node should first
setup a the p2p link that connects it to the home agent, then run
IKEv2 from the home link and obtain the home prefix, then compare
the prefix obtained from IKEv2 with the prefix obtained from the p2p
link setup and finally conclude it is on the home link. This is not
obvious. The MIP6_HOME_PREFIX attribute was designed for home address
auto-configuration. Not for home link detection.

At the last IETF meeting (I wasn't at the meeting, but was listening
to the audio stream), we had some folks go up to the microphone and
say RFC 3775 already specifies how to detect the home link and
nothing new is needed. :)

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 19 Mar 2008 10:46:42 -0500

Hi Julien/Vijay,

If I recall the discussion from the meeting correctly, this was supposed
to be an informational document. Also, my understanding that the
document will capture the details in a generic way for how MN could
recognize its home link. Of course, it can give examples on how it can
be done using, for example IKEv2, etc., but it should be generic enough
that we do not need to update the draft again in case a new mechanism is
used.

If that what is proposed and we have in mind, I would like to support
this work item.

Regards,
Ahmad

> Sent: Tuesday, March 18, 2008 6:04 PM
> To: Julien Laganier
> Cc: [email-masked]
> > When RFC 5026 is used, the MN has no pre-configured home prefix but 
> > get it dynamically in the MIP6_HOME_PREFIX attribute 
> obtained via the 
> > IKEv2 exchange of the bootstrapping mechanism. Then it 
> simply behave 
> > as usual, i.e., quoting you "when it sees a router 
> advertisement with 
> > the same prefix, it knows it is on the home link."
> 
> The sequence of steps when the MN boots up on the home link 
> would be the other way around. The MN would first boot up, 
> setup the link and then run IKEv2 with the home agent. Not 
> run IKEv2 with the home agent and then send a router 
> solicitation on the home link to trigger a router advertisement.
> 
> There is nothing that specifies that the mobile node should 
> first setup a the p2p link that connects it to the home 
> agent, then run
> IKEv2 from the home link and obtain the home prefix, then 
> compare the prefix obtained from IKEv2 with the prefix 
> obtained from the p2p link setup and finally conclude it is 
> on the home link. This is not obvious. The MIP6_HOME_PREFIX 
> attribute was designed for home address auto-configuration. 
> Not for home link detection.
> 
> At the last IETF meeting (I wasn't at the meeting, but was 
> listening to the audio stream), we had some folks go up to 
> the microphone and say RFC 3775 already specifies how to 
> detect the home link and nothing new is needed. :)
> 
> Vijay

---

From: Julien Laganier <[email-masked]>
Date: Wed, 19 Mar 2008 19:03:55 +0100

Vijay,

Still <chair hat off>:

Vijay Devarapalli wrote:
> > get it dynamically in the MIP6_HOME_PREFIX attribute obtained via
> > the IKEv2 exchange of the bootstrapping mechanism. Then it simply
> > behave as usual, i.e., quoting you "when it sees a router
> > link."

This isn't what I had in mind. What I had in mind is:

1) MN would boot up
2) Setup the link:
	-  send an RS on the link
	-  receives an RA with PIO from the link
	-  configures a CoA for the link
3) Run IKEv2:
	- receives MIP6_HOME_PREFIX
4) Compare MIP6_HOME_PREFIX and PIO
	- same: conclude it's at home
	- different: conclude it's not at home

> auto-configuration. Not for home link detection.

I don't see what isn't obvious, and it doesn't matter what the 
MIP6_HOME_PREFIX was "designed" for.

The prefix received in the RA's PIO is an on-link prefix. If the 
MIP6_HOME_PREFIX from which the MN configures a home address is the 
same as the RA's PIO, then the home address belongs to the RA's PIO, 
therefore the home address is on-link, therefore the MN is at home.

--julien

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Mar 2008 17:41:24 -0700

> 	- different: conclude it's not at home

Ok.

> I don't see what isn't obvious, 

:) Well, if it is obvious for everyone, we are done.

> and it doesn't matter what the 

It does. Implementing the MIP6_HOME_PREFIX attribute is optional,
since it is supposed to be used for home address auto-configuration.
If you are not supporting home address auto-configuration in your
system (for various reasons), then you don't even have to implement
this attribute.

Vijay

---

From: Julien Laganier <[email-masked]>
Date: Thu, 20 Mar 2008 11:22:03 +0100

Vijay,

Still <chair hat off>:

Vijay Devarapalli wrote:
> >>> When RFC 5026 is used, the MN has no pre-configured home prefix
> >>> but get it dynamically in the MIP6_HOME_PREFIX attribute obtained
> >>> via the IKEv2 exchange of the bootstrapping mechanism. Then it
> >>> simply behave as usual, i.e., quoting you "when it sees a router
> >> The sequence of steps when the MN boots up on the home link would
> >> be the other way around. The MN would first boot up, setup the
> >> link and then run IKEv2 with the home agent. Not run IKEv2 with
> >> the home agent and then send a router solicitation on the home
> >> link to trigger a router advertisement.
> >
> >> the prefix obtained from IKEv2 with the prefix obtained from the
> >> p2p link setup and finally conclude it is on the home link. This
> >> is not obvious. The MIP6_HOME_PREFIX attribute was designed for
> >> home address auto-configuration. Not for home link detection.
> >

Are we? :)

> > and it doesn't matter what the MIP6_HOME_PREFIX was "designed" for.
>

With RFC5026 there's no other way for a MN to detect it's at home except  
asking for the MIP6_HOME_PREFIX and comparing it with on-link prefixes.

Thus it is implicit in RFC5026 that a MN has to ask for the 
MIP6_HOME_PREFIX to do home link detection. Is that too theological?

--julien