Subject: [MEXT] Home Link Detection [Fwd: I-D Action:draft-krishnan-mext-hld-01.txt]

From: Suresh Krishnan <[email-masked]>
Date: Mon, 31 Mar 2008 11:41:28 -0400

Hi Folks,
   This draft talks about how to detect attachment to a home link when 
the split scenario is used for bootstrapping (RFC5026). Please take some 
time to review it.

Thanks
Suresh

-------- Original Message --------
Subject: I-D Action:draft-krishnan-mext-hld-01.txt
Date: Mon, 31 Mar 2008 08:00:01 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : MIPv6 Home Link Detection
	Author(s)       : S. Krishnan, G. Tsirtsis
	Filename        : draft-krishnan-mext-hld-01.txt
	Pages           : 6
	Date            : 2008-03-31

The MIPv6 bootstrapping procedure allows the mobile node to
dynamically discover its home prefix using an IKEv2 exchange.  Since
the home prefix is not statically configured on the mobile node,
there is a need to specify a mechanism for the mobile node to detect
if it is on its home link.  This document specifies one such
mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-krishnan-mext-hld-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

---

From: <[email-masked]>
Date: Mon, 31 Mar 2008 17:57:31 +0200

Hi,

This is what I have sent in when discussing Home link detection few days ago (see attached message). Then I will agree.
But I think it is necessary to check only if the MN prefix belongs to Home prefixes and not to compare all link prefixes to the home prefixes.

Regards

Kassi

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Suresh Krishnan
Envoyé : lundi 31 mars 2008 17:41
À : [email-masked]
Objet : [MEXT] Home Link Detection [Fwd: I-DAction:draft-krishnan-mext-hld-01.txt]

Hi Folks,
   This draft talks about how to detect attachment to a home link when the split scenario is used for bootstrapping (RFC5026). Please take some time to review it.

Thanks
Suresh

-------- Original Message --------
Subject: I-D Action:draft-krishnan-mext-hld-01.txt
Date: Mon, 31 Mar 2008 08:00:01 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

The MIPv6 bootstrapping procedure allows the mobile node to dynamically discover its home prefix using an IKEv2 exchange.  Since the home prefix is not statically configured on the mobile node, there is a need to specify a mechanism for the mobile node to detect if it is on its home link.  This document specifies one such mechanism.

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

Subject: Re: [MEXT] Home Link Detection
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Date: Wed, 26 Mar 2008 12:48:53 +0200

Hi all,
 
I think that we cannot speak about CoA or HoA before discovering if we are in a home network or in a foreign network. I think that it will be made as follows:

At bootstrap step (this means that the MN has neither HoA, nor HA-address...) the MN connects to a network, discovers a link-prefix and configures an address (MN-address). At this point it does not know if this address is a HoA or a CoA. The MN has to discover a HA and home-prefixes (prefixes for which the HA acts as Home Agent):

If the link-prefix (= MN-prefix) belongs to the home-prefixes then the MN is in a home network and the HoA = MN-address (MN-home-prefix = MN-prefix).

If the link-prefix does not belong to the home-prefixes then the MN is in a foreign network and the CoA = MN-address. In this case, the MN asks for a HoA from the HA in the first BU.

At a handover step (this means that the MN was connected to a network and moves to another network) the MN has already a HoA, a HA address, may be a CoA.... When the MN connects to a network and discovers a link-prefix it compares this prefix to the MN-home-prefix:

If the same then the MN is in its home network and sends a BU to HA (if necessary).

If not then the MN is in a foreign network. It will configure a CoA and send a BU to HA.

Kassi

________________________________

De : [email-masked] [mailto:[email-masked]] De la part de Behcet Sarikaya
Envoyé : mardi 25 mars 2008 22:42
À : Vijay Devarapalli; Julien Laganier
Cc : [email-masked]
Objet : Re: [MEXT] Home Link Detection

Julien, your scenario is not according to SDO links. I think that the home link operation work item should concentrate on p2t SDO  home link operation and should complement previous bootstrapping work.

Please see my comment inline below.

Behcet

----- Original Message ----
From: Vijay Devarapalli <[email-masked]>
To: Julien Laganier <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, March 19, 2008 7:41:24 PM
Subject: Re: [MEXT] Home Link Detection

Julien Laganier wrote:
> Vijay,
> 
> Still <chair hat off>:
> 
> Vijay Devarapalli wrote:
>> Julien Laganier wrote:
>>> Vijay Devarapalli wrote:
>>>> 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.
>>> 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.
> 
> 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

Ok.
[behcet] Not OK. According to http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.txt
IKEv2 happens with EAP in authentication phase which in SDOs happens when immediately MN enters the network.
So home prefix assignment occurs after CFG_REQUEST is received. http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.txt lacks any discussion on how the home prefix is assigned

>>> I don't see what requires additional specification.

[behcet] Sorry, I do think it 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.
> 
> 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 
> MIP6_HOME_PREFIX was "designed" for.

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

> 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: Suresh Krishnan <[email-masked]>
Date: Mon, 31 Mar 2008 13:24:42 -0400

Hi Mohammed,
   I agree with you mostly but where I differ is that I think there can 
be more than one "link-prefixes" while you assume there is going to be a 
single "link-prefix". I think to address the problem in a generic way, 
we need to address the case where there is more than one prefix 
available on the link to which the MN has attached.

Thanks
Suresh

[email-masked] wrote:
> ------------------------------------------------------------------------
> 
> Subject:
> To:
> <[email-masked]>, <[email-masked]>, 
> <[email-masked]>
> 
> To:
> <[email-masked]>, <[email-masked]>, 
> <[email-masked]>
> CC:
> <[email-masked]>
> 
> 
> Hi all,
>

---

From: "Benjamin Lim" <[email-masked]>
Date: Tue, 1 Apr 2008 10:54:31 +0800

Hi Suresh,

One question.

In section 4:- 
If I understand correctly, the operation in section 4 is used when MN
detects a new link (e.g. roaming). I can understand the steps in section 4
for initial boot-up, but once MN obtains the home prefix via bootstrap
procedure, does subsequent movement requires MN to re-do bootstrap to query
for home prefix? Or am I missing something?

Regards,
Benjamin Lim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Suresh Krishnan
> Sent: Monday, March 31, 2008 11:41 PM
> To: [email-masked]
> Subject: [MEXT] Home Link Detection [Fwd: 
> I-DAction:draft-krishnan-mext-hld-01.txt]
> 
> Hi Folks,
>    This draft talks about how to detect attachment to a home 
> link when the split scenario is used for bootstrapping 
> (RFC5026). Please take some time to review it.
> 
> Thanks
> Suresh
> 
> dynamically discover its home prefix using an IKEv2 exchange. 
>  Since the home prefix is not statically configured on the 
> mobile node, there is a need to specify a mechanism for the 
> mobile node to detect if it is on its home link.  This 
> document specifies one such mechanism.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: <[email-masked]>
Date: Tue, 1 Apr 2008 08:46:14 +0200

Hi Suresh,

I have never assumed that there will be only a single prefix. Even if there are multiple prefixes on the link, the MN has to compare only those whom it uses as its address prefix.

Other comments:

- Home prefixes may be discovered by other mechanisms (at the bootstrap configuration for example)

- At the handover step the MN does not need to discover the home prefixes because it already knows its.

Best regards,

Kassi

-----Message d'origine-----
De : Suresh Krishnan [mailto:[email-masked]] 
Envoyé : lundi 31 mars 2008 19:25
À : KASSI-LAHLOU Mohammed RD-CORE-CAE
Cc : [email-masked]
Objet : Re: [MEXT] Home Link Detection [Fwd: I-DAction:draft-krishnan-mext-hld-01.txt]

Hi Mohammed,
   I agree with you mostly but where I differ is that I think there can be more than one "link-prefixes" while you assume there is going to be a single "link-prefix". I think to address the problem in a generic way, we need to address the case where there is more than one prefix available on the link to which the MN has attached.

Thanks
Suresh

[email-masked] wrote:
> De : [email-masked] [mailto:[email-masked]] De la part 
> de Suresh Krishnan Envoyé : lundi 31 mars 2008 17:41 À : [email-masked] 
> Objet : [MEXT] Home Link Detection [Fwd: 
> De : [email-masked] [mailto:[email-masked]] De la part 
> de Behcet Sarikaya Envoyé : mardi 25 mars 2008 22:42 À : Vijay 
> Devarapalli; Julien Laganier Cc : [email-masked] Objet : Re: [MEXT] 
> Home Link Detection
> 
> 
>>> 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.
> [behcet] Not OK. According to 
> http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.txt
> So home prefix assignment occurs after CFG_REQUEST is received. 
> http://tools.ietf.org/id/draft-ietf-dime-mip6-split-07.txt lacks any 
> discussion on how the home prefix is assigned
> 
>>> obvious. The MIP6_HOME_PREFIX attribute was designed for home 
>>> address auto-configuration. Not for home link detection.

---

From: Julien Laganier <[email-masked]>
Date: Tue, 1 Apr 2008 11:51:48 +0200

Hi Suresh,

Two comments:

- The draft seems to assume that SLAAC is used by the MN. However that 
is not needed per se, DHCP could be used to configure the MN's address. 
The only requirement is that the MN obtain one or more PIOs, how the 
MN's address is configured is irrelevant. Thus, I think you should 
reword as:

4.  Mobile Node Operation

   When an MN arrives on a new link it performs the following steps to
   determine if it is on the home link.
   o  The MN sends out a Router Solicitation
   o  The MN receives a Router Advertisement in response with one or
      more Prefix Information Options as specified in [RFC4861].
   o  The MN configures one or more addresses, referred to as the
      Current MN Addresses (CMA), via DHCPv6 if the"Managed address
      configuration" (M) flag is set in the Router Solicitation, or via
      SLAAC if one or more of the received prefixes has the "autonomous
      address configuration" (A) flag set. 
   o  The MN stores all the prefix(es) received along with their prefix
      lengths in the RA in a conceptual list called the Current Link
      Prefix List (CLPL)
   o  The MN uses one of the addresses in the CMA to initiate the
      bootstrapping procedure described in [RFC5026].  The MN MUST
      include the MIP6_HOME_PREFIX attribute in the CFG_REQUEST message.
   o  The MN receives the home prefix and the corresponding prefix
      length from the HA contained in the MIP6_HOME_PREFIX attribute in
      the CFG_REPLY message.  The MN stores it in a conceptual variable

- The procedure could also be made generic to work with hiopt. The 
minimal specification could simply say that the "MN MUST obtain a home 
prefix as part of a bootstrapping procedure [RFC5026][hiopt], and 
compare it against prefixes in the list of PIOs"

What do you think?

--julien

On Monday 31 March 2008, Suresh Krishnan wrote:
> Hi Folks,
>    This draft talks about how to detect attachment to a home link
> when the split scenario is used for bootstrapping (RFC5026). Please
> take some time to review it.
>
> Thanks
> Suresh
>