Subject: Re: [MEXT] Home Link Detection

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 20 Mar 2008 08:30:36 -0700 (PDT)

Hi Julien,

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

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

[behcet] This protocol is OK but I am not sure if it would be used in ptp link by SDOs. SDOs would probably prefer to have stateful address configuration.
Also RA sending entity may not be the HA. In that case the use of prefix delegation which I believe is needed becomes tricky. 
How do we coordinate and make sure the same prefix is selected in the two parts of the protocol be different entities so that MN concludes that it is at home.

My thinking was that the issues like the above are the reason why mext is considering to work on the home link detection.

Regards,

Behcet

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

---

From: Julien Laganier <[email-masked]>
Date: Wed, 26 Mar 2008 11:52:48 +0100

Hi Behcet,

More below:

On Thursday 20 March 2008, Behcet Sarikaya 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.
>
> [behcet] This protocol is OK but I am not sure if it would be used in
> ptp link by SDOs. SDOs would probably prefer to have stateful address
> configuration. 

I don't know which SDOs you're referring about. Besides, the use of 
stateful address configuration doesn't dispense a node from sending RS 
and the on-link router to replies with RAs. In other words it is not 
because a node knows its address that it doesn't need to know which 
prefixes are on-link.

> Also RA sending entity may not be the HA. 

On a point-to-point home link there's only two ends, the HA and the MN. 
Since the RA has to be sent by an on-link router (NDP messages are 
never forwarded from one link to another), it has to be the HA.

> In that case the use of prefix delegation which I believe is needed
> becomes tricky. How do we coordinate and make sure the same prefix is
> selected in the two parts of the protocol be different entities so
> that MN concludes that it is at home.

> My thinking was that the issues like the above are the reason why
> mext is considering to work on the home link detection.

This is different problem than Home Link Detection, which is waht this 
thread is discussing. If you want to discuss a different problem please 
change the subject line. That would help the discussion on Home Link 
Detection to converge on its own.

What you're talking about seems to be more a matter of coordination 
between HA and DHCP server configurations. Not sure what  the problem 
really is, neither where such work would belong. In any case, let's not 
mix different problems in the discussion.

Thanks.

--julien

---

From: <[email-masked]>
Date: Wed, 26 Mar 2008 12:08:24 +0100

Hi Julien,

In the p2p case, the HA may be the end point or on the same link than the end point.

Kassi 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Julien Laganier
Envoyé : mercredi 26 mars 2008 11:53
À : Behcet Sarikaya
Cc : [email-masked]
Objet : Re: [MEXT] Home Link Detection

Hi Behcet,

More below:

On Thursday 20 March 2008, Behcet Sarikaya wrote:
> > then run IKEv2 with the home agent. Not run IKEv2 with the home 

I don't know which SDOs you're referring about. Besides, the use of stateful address configuration doesn't dispense a node from sending RS and the on-link router to replies with RAs. In other words it is not because a node knows its address that it doesn't need to know which prefixes are on-link.

On a point-to-point home link there's only two ends, the HA and the MN. 
Since the RA has to be sent by an on-link router (NDP messages are never forwarded from one link to another), it has to be the HA.

> My thinking was that the issues like the above are the reason why mext 
> is considering to work on the home link detection.

This is different problem than Home Link Detection, which is waht this thread is discussing. If you want to discuss a different problem please change the subject line. That would help the discussion on Home Link Detection to converge on its own.

What you're talking about seems to be more a matter of coordination between HA and DHCP server configurations. Not sure what  the problem really is, neither where such work would belong. In any case, let's not mix different problems in the discussion.

Thanks.

--julien

---

From: "Premec, Domagoj" <[email-masked]>
Date: Wed, 26 Mar 2008 12:32:30 +0100

Hi Julien,

> Since the RA has to be sent by an on-link router (NDP 
> messages are never forwarded from one link to another), it 
> has to be the HA.

[this probably belongs to PMIP-MIP interactions discussion]
It gets tricky when PMIP6 is used to emulate the home link. MAG terminates the p2p link and sends RA with HNP, but the actual HA/LMA is somewhere behind the MAG. So even if the MN is at its home link, it can not safely assume that the other end of the p2p link (or the node sending the RAs with the HNP) is the HA. In other words, the HA is not located on the home link :-)

domagoj

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Julien Laganier
> Sent: 26. ozujak 2008 11:53
> To: Behcet Sarikaya
> Cc: [email-masked]
> I don't know which SDOs you're referring about. Besides, the 
> use of stateful address configuration doesn't dispense a node 
> from sending RS and the on-link router to replies with RAs. 
> In other words it is not because a node knows its address 
> that it doesn't need to know which prefixes are on-link.
> 
> Since the RA has to be sent by an on-link router (NDP 
> messages are never forwarded from one link to another), it 
> has to be the HA.
> 
> This is different problem than Home Link Detection, which is 
> waht this thread is discussing. If you want to discuss a 
> different problem please change the subject line. That would 
> help the discussion on Home Link Detection to converge on its own.
> 
> What you're talking about seems to be more a matter of 
> coordination between HA and DHCP server configurations. Not 
> sure what  the problem really is, neither where such work 
> would belong. In any case, let's not mix different problems 
> in the discussion.
> 
> Thanks.
> 
> --julien
> 
> 
> 
>

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 27 Mar 2008 10:55:09 +1100

> It gets tricky when PMIP6 is used to emulate the home link. MAG  
> terminates the p2p link and sends RA with HNP, but the actual HA/LMA  
> is somewhere behind the MAG. So even if the MN is at its home link,  
> it can not safely assume that the other end of the p2p link (or the  
> node sending the RAs with the HNP) is the HA. In other words, the HA  
> is not located on the home link :-)
>
=> Can we please use the correct MIP terminology in this discussion?  
If the MN shares an IP-enabled link with the HA then it is home  
according to our specs. If it does not share it then it is not home.  
Now, if someone wants to emulate the home link remotely using PMIP or  
any other protocol in a way that makes the MN think it is home, then  
the MN is home. We don't care how this emulation happened.

Hesham

---

From: Julien Laganier <[email-masked]>
Date: Thu, 27 Mar 2008 10:45:51 +0100

Folks,

This is a consensus call on whether we should include a deliverable for 
Home Link Detection in our updated charter. I have reviewed the 
discussion on Home Link Detection that happened so far and you can find 
below my interpretation of the WG consensus. Please reply to the list 
stating whether you agree (YES) or not (NO) with that interpretation of 
the WG consensus. Please DO NOT engage in additional discussion within 
this discussion thread.

Thanks for your support.

-- julien & marcelo, MEXT chairs

-----------------------------------------------------------------------
There's a consensus that an RFC5026-enabled MN detects it is at home by 
comparing the prefixes in RA's PIOs received via Router Discovery and 
in IKEv2's MIP6_HOME_PREFIX received via RFC5026 Bootstrapping.

There's also a consensus that it is useful to document in an 
INFORMATIONAL document the above since it seems it is not that obvious 
to anyone by reading RFC5026.
-----------------------------------------------------------------------
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 27 Mar 2008 11:39:07 +0100

Yes, I support this work. 

Additionaly, as I mentioned before, there is another option for detecting home link: looking at the home network prefix received in the Home Network Information option (draft-hiopt). I think this should be included in the Home Link Detection document.

domagoj

> Sent: 27. ozujak 2008 10:46
> To: [email-masked]
> Subject: [MEXT] Consensus call on Home Link Detection
> 
> Folks,
> 
> This is a consensus call on whether we should include a 
> deliverable for Home Link Detection in our updated charter. I 
> have reviewed the discussion on Home Link Detection that 
> happened so far and you can find below my interpretation of 
> the WG consensus. Please reply to the list stating whether 
> you agree (YES) or not (NO) with that interpretation of the 
> WG consensus. Please DO NOT engage in additional discussion 
> within this discussion thread.
> 
> Thanks for your support.
> 
> There's a consensus that an RFC5026-enabled MN detects it is 
> at home by comparing the prefixes in RA's PIOs received via 
> Router Discovery and in IKEv2's MIP6_HOME_PREFIX received via 
> RFC5026 Bootstrapping.
> 
> INFORMATIONAL document the above since it seems it is not 
> that obvious to anyone by reading RFC5026.

---

From: Julien Laganier <[email-masked]>
Date: Thu, 27 Mar 2008 12:06:29 +0100

On Thursday 27 March 2008, Premec, Domagoj wrote:
> Additionaly, as I mentioned before, there is another option for
> detecting home link: looking at the home network prefix received in
> the Home Network Information option (draft-hiopt). I think this
> should be included in the Home Link Detection document.

Agree (but another solution would be to document home link detection 
with hiopt straight in draft-ietf-mip6-hiopt which is still in IESG).

--julien

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 27 Mar 2008 23:31:30 +1100

Hi Julien,  opposed to it. Neutral.

Hesham

I'm not

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 27 Mar 2008 08:34:40 -0500

YES.

Regards,
Ahmad

> Sent: Thursday, March 27, 2008 4:46 AM
> To: [email-masked]

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 27 Mar 2008 15:06:53 +0100

Julien,

> Agree (but another solution would be to document home link 
> detection with hiopt straight in draft-ietf-mip6-hiopt which 
> is still in IESG).

I think it would be better to cover all home link detection alternatives at one place. But I have no strong opinion on this, I'm fine either way as long as it is documented somewhere.

domagoj

> From: julien laganier [mailto:[email-masked]] On 
> Sent: 27. ožujak 2008 12:06
> To: Premec, Domagoj
> Cc: [email-masked]
> Subject: Re: [MEXT] Consensus call on Home Link Detection
> 
> > the Home Network Information option (draft-hiopt). I think 
> this should 
> > be included in the Home Link Detection document.
> 
> Agree (but another solution would be to document home link 
> detection with hiopt straight in draft-ietf-mip6-hiopt which 
> is still in IESG).
> 
> --julien
> 
> > > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > > Of Julien Laganier
> deliverable 
> > > for Home Link Detection in our updated charter. I have 
> reviewed the 
> > > discussion on Home Link Detection that happened so far 
> and you can 
> > > find below my interpretation of the WG consensus. Please reply to 
> > > the list stating whether you agree (YES) or not (NO) with that 
> > > interpretation of the WG consensus. Please DO NOT engage in 
> > > additional discussion within this discussion thread.
> > >
> > > Thanks for your support.
> > >
> > > There's a consensus that an RFC5026-enabled MN detects it 
> is at home 
> > > by comparing the prefixes in RA's PIOs received via 
> Router Discovery 
> > > and in IKEv2's MIP6_HOME_PREFIX received via
> > > RFC5026 Bootstrapping.
> > >
> > > INFORMATIONAL document the above since it seems it is not that 
> > > obvious to anyone by reading RFC5026.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 27 Mar 2008 07:08:08 -0700

Yes, of course.

But don't treat this issue in isolation. We also need to address
a few other thinks like configuring the IPv4 home address, setting
up forwarding for mobile network prefixes, conveying flow filters
to the home agent, etc.. when booting up on the home link.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 27 Mar 2008 10:24:35 -0500

No. 

You are better off adding a section in 3775bis that covers home link
detection given various other means that have been developed in the last
couple of years.

-Raj

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 28 Mar 2008 16:26:36 -0400

Hi Chairs,
   YES. I think this is a fair description of the consensus in the room.

Cheers
Suresh

---

From: <[email-masked]>
Date: Sun, 30 Mar 2008 09:53:40 +0200

YES-ish.

/Jouni

ps: How would this relate to the earlier task on
    home link operation in various SDOs?

> Sent: 27. maaliskuuta 2008 11:46
> To: [email-masked]
> deliverable for 
> at home by