headers
Vijay Devarapalli | 7 Jun 2006 03:23

Re: MIP and Upper Layer Protocol interaction

Rajeev Koodli wrote:

> If a MN wishes to change its HoA with a CN (e.g., use a different 
> pseudo-hoa for
> privacy purposes), it has no _reliable_ way of knowing whether it has
> existing sessions with that CN.

I read this paragraph three times, but couldn't get
the context.

if in the privacy context, I assume there is still
a *real* HoA. the pseudo HoA appears in the route
optimized traffic to the CN *instead* of the real
HoA. the CN knows the real HoA and the pseudo HoA.
the mapping from the real HoA to the pseudo HoA is
done using the binding update list at the MN and
the binding cache entry at the CN.

if not for privacy, perhaps the mobile node shouldn't
change its HoA abruptly, but let existing sessions
continue with the existing HoA and use the new HoA
for new sessions. the mobile node would also have
to update the DNS entry if it wants its FQDN to
resolve to the new HoA.

hope this helps.

Vijay
Permalink | Reply |
headers
Rajeev Koodli | 7 Jun 2006 19:13
Picon

Re: MIP and Upper Layer Protocol interaction

Vijay Devarapalli wrote:

> Rajeev Koodli wrote:
>
>> If a MN wishes to change its HoA with a CN (e.g., use a different 
>> pseudo-hoa for
>> privacy purposes), it has no _reliable_ way of knowing whether it has
>> existing sessions with that CN.
>
>
> I read this paragraph three times, but couldn't get
> the context.
>
> if in the privacy context, I assume there is still
> a *real* HoA. the pseudo HoA appears in the route
> optimized traffic to the CN *instead* of the real
> HoA. the CN knows the real HoA and the pseudo HoA.
> the mapping from the real HoA to the pseudo HoA is
> done using the binding update list at the MN and
> the binding cache entry at the CN.
>
This is a way to do it. Nevertheless, keeping the privacy issue aside..

> if not for privacy, perhaps the mobile node shouldn't
> change its HoA abruptly, but let existing sessions
> continue with the existing HoA and use the new HoA
> for new sessions. the mobile node would also have
> to update the DNS entry if it wants its FQDN to
> resolve to the new HoA.
>
(Continue reading)

Permalink | Reply |
headers
Shinta Sugimoto | 19 Jun 2006 09:38
Picon

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction

Hi Rajeev,

I am catching up on this thread. Please find my comments inline.

On Wed, 07 Jun 2006 10:13:06 -0700
Rajeev Koodli <rajeev <at> iprg.nokia.com> wrote:

> Vijay Devarapalli wrote:
> 
> > Rajeev Koodli wrote:
> >
> >> If a MN wishes to change its HoA with a CN (e.g., use a different 
> >> pseudo-hoa for
> >> privacy purposes), it has no _reliable_ way of knowing whether it has
> >> existing sessions with that CN.
> >
> >
> > I read this paragraph three times, but couldn't get
> > the context.
> >
> > if in the privacy context, I assume there is still
> > a *real* HoA. the pseudo HoA appears in the route
> > optimized traffic to the CN *instead* of the real
> > HoA. the CN knows the real HoA and the pseudo HoA.
> > the mapping from the real HoA to the pseudo HoA is
> > done using the binding update list at the MN and
> > the binding cache entry at the CN.
> >
> This is a way to do it. Nevertheless, keeping the privacy issue aside..
>
(Continue reading)

Permalink | Reply |
headers
Rajeev Koodli | 20 Jun 2006 03:12
Picon

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction


Hi,

the purpose here is to list the available options. Perhaps SHIM6 is
one option, but there are others to explore. I encourage you to
discuss them at the MobOpts meeting.

-Rajeev

ps: location privacy as such is being discussed in a problem statement
draft, and there is also a mobopts drfat on solutions. Please have a look
at them. Thanks.

Shinta Sugimoto wrote:

>Hi Rajeev,
>
>  
>
>If you need to maintain the sessions while changing the HoA
>from one to another, I think you need additional mechanism
>than plain MIPv6.  MIP (no matter IPv6 or IPv4) is designed
>to assure the reachability to a given HoA with the current
>location of the mobile node (CoA).  If the app wants
>to change HoAs for some reason (I assume that privacy is the
>main interest), there is a need to maintain the mapping of
>the identity and the locator of the mobile node.
>
>One option would be to run Shim6 over MIPv6.  Such usage has
>already been discussed in Shim6 WG.  By mobile node establishing
(Continue reading)

Permalink | Reply |
headers
Shinta Sugimoto | 20 Jun 2006 10:00
Picon

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction

Hi Rajeev,

please find my comments/questions inline.

On Mon, 19 Jun 2006 21:12:10 -0400
Rajeev Koodli <rajeev <at> iprg.nokia.com> wrote:

> 
> Hi,
> 
> the purpose here is to list the available options. Perhaps SHIM6 is
> one option, but there are others to explore.

Ok, I see.

> I encourage you to
> discuss them at the MobOpts meeting.

Yes.

> 
> -Rajeev
> 
> ps: location privacy as such is being discussed in a problem statement
> draft, and there is also a mobopts drfat on solutions. Please have a look
> at them. Thanks.

Thanks for the information. I've just read the ps and solution drafts.

Still I am not quite sure if I understand the exact issue being
(Continue reading)

Permalink | Reply |
headers
QIU Ying | 20 Jun 2006 12:44
Picon

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction


Hi, Shinta

My cents is also inline.

>> ps: location privacy as such is being discussed in a problem statement
>> draft, and there is also a mobopts drfat on solutions. Please have a look
>> at them. Thanks.
>
> Thanks for the information. I've just read the ps and solution drafts.

Thanks for your attention on the drafts.
>
> Still I am not quite sure if I understand the exact issue being
> discussed on this thread.  Is the issue 1) how to identify correspondent
> node with whom the mobile node already established a sessoin based on a
> given HoA,

In MIPv6, after receiving a BU message from MN, the CN check it BU cache. If 
no entry about the MN, CN create a new entry for the MN. In other word, if 
there is the MN entry in BU cache, it means the MN has already established a 
connection. Of course, the entry is not for a specifical session only, it is 
for the connection between two peers.

>or 2) how to provide HoA agility when the mobile node changes
> it's HoA from one to another (for privacy reason), or both ?

a pseudo HoA is used to replace the actual HoA.
pseudo home address = one of home network prefix || Enc(Kph_i, interface ID)
(Continue reading)

Permalink | Reply |
headers
Shinta Sugimoto | 20 Jun 2006 13:12
Picon

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction

Hi Ying,

please find my comments below.

On Tue, 20 Jun 2006 18:44:50 +0800
QIU Ying <qiuying <at> i2r.a-star.edu.sg> wrote:

> 
> Hi, Shinta
> 
> My cents is also inline.
> 
> >> ps: location privacy as such is being discussed in a problem statement
> >> draft, and there is also a mobopts drfat on solutions. Please have a look
> >> at them. Thanks.
> >
> > Thanks for the information. I've just read the ps and solution drafts.
> 
> Thanks for your attention on the drafts.
> >
> > Still I am not quite sure if I understand the exact issue being
> > discussed on this thread.  Is the issue 1) how to identify correspondent
> > node with whom the mobile node already established a sessoin based on a
> > given HoA,
> 
> In MIPv6, after receiving a BU message from MN, the CN check it BU cache. If 
> no entry about the MN, CN create a new entry for the MN. In other word, if 
> there is the MN entry in BU cache, it means the MN has already established a 
> connection.
(Continue reading)

Permalink | Reply |
headers
Vijay Devarapalli | 20 Jun 2006 02:12

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction

Shinta Sugimoto wrote:
>> The problem here is how does the MN know to "let the
>> existing sessions continue with the existing HoA"? If there is no CN's
>> address in BUL, surely the MN can choose a suitable HoA. For
>> a CN with which it has a binding, it has no reliable way of knowing
>> whether there are any ULP sessions.
> 
> If you need to maintain the sessions while changing the HoA
> from one to another, I think you need additional mechanism
> than plain MIPv6.  MIP (no matter IPv6 or IPv4) is designed
> to assure the reachability to a given HoA with the current
> location of the mobile node (CoA).  If the app wants
> to change HoAs for some reason (I assume that privacy is the
> main interest), there is a need to maintain the mapping of
> the identity and the locator of the mobile node.

Mobile IPv6 today allows you to use two home addresses
at the same time. it also allows you to bind both home
addresses to the same CoA.

> One option would be to run Shim6 over MIPv6.  Such usage has
> already been discussed in Shim6 WG.  By mobile node establishing
> Shim6 context with its HA/CN, it could utilize multiple HoAs
> without annoying upper layer protocols.  

yes, this can be done. but I would like to restrict
shim6 usage when mip6 is used to the case where the
home link is site multihomed and the mobile node already
has the multiple home addresses configured on it. not
when the mobile node decides to change its home address.
(Continue reading)

Permalink | Reply |
headers
Shinta Sugimoto | 20 Jun 2006 09:37
Picon

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction

Hi Vijay,

please find my comments inline.

On Mon, 19 Jun 2006 17:12:43 -0700
Vijay Devarapalli <vijay.devarapalli <at> azairenet.com> wrote:

> Shinta Sugimoto wrote:
> >> The problem here is how does the MN know to "let the
> >> existing sessions continue with the existing HoA"? If there is no CN's
> >> address in BUL, surely the MN can choose a suitable HoA. For
> >> a CN with which it has a binding, it has no reliable way of knowing
> >> whether there are any ULP sessions.
> > 
> > If you need to maintain the sessions while changing the HoA
> > from one to another, I think you need additional mechanism
> > than plain MIPv6.  MIP (no matter IPv6 or IPv4) is designed
> > to assure the reachability to a given HoA with the current
> > location of the mobile node (CoA).  If the app wants
> > to change HoAs for some reason (I assume that privacy is the
> > main interest), there is a need to maintain the mapping of
> > the identity and the locator of the mobile node.
> 
> Mobile IPv6 today allows you to use two home addresses
> at the same time. it also allows you to bind both home
> addresses to the same CoA.

Yes, that's true.  But then there is a problem to choose
which one for which communication.  When it comes to agility,
it's more problematic.
(Continue reading)

Permalink | Reply |
headers
Vijay Devarapalli | 20 Jun 2006 19:54

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction

Shinta Sugimoto wrote:

>>
>>>>The problem here is how does the MN know to "let the
>>>>existing sessions continue with the existing HoA"? If there is no CN's
>>>>address in BUL, surely the MN can choose a suitable HoA. For
>>>>a CN with which it has a binding, it has no reliable way of knowing
>>>>whether there are any ULP sessions.
>>>
>>>If you need to maintain the sessions while changing the HoA
>>>from one to another, I think you need additional mechanism
>>>than plain MIPv6.  MIP (no matter IPv6 or IPv4) is designed
>>>to assure the reachability to a given HoA with the current
>>>location of the mobile node (CoA).  If the app wants
>>>to change HoAs for some reason (I assume that privacy is the
>>>main interest), there is a need to maintain the mapping of
>>>the identity and the locator of the mobile node.
>>
>>Mobile IPv6 today allows you to use two home addresses
>>at the same time. it also allows you to bind both home
>>addresses to the same CoA.
> 
> 
> Yes, that's true.  But then there is a problem to choose
> which one for which communication.  When it comes to agility,
> it's more problematic.

actually we are not looking for address agility here. we want
the mobile node to change its home address and while changing
it allow existing sessions using the old home address to
(Continue reading)

Permalink | Reply |
headers
Shinta Sugimoto | 21 Jun 2006 12:13
Picon

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction

Hi Vijay,

please find my further comments inline.

On Tue, 20 Jun 2006 10:54:06 -0700
Vijay Devarapalli <vijay.devarapalli <at> azairenet.com> wrote:

> Shinta Sugimoto wrote:
> 
> >>
> >>>>The problem here is how does the MN know to "let the
> >>>>existing sessions continue with the existing HoA"? If there is no CN's
> >>>>address in BUL, surely the MN can choose a suitable HoA. For
> >>>>a CN with which it has a binding, it has no reliable way of knowing
> >>>>whether there are any ULP sessions.
> >>>
> >>>If you need to maintain the sessions while changing the HoA
> >>>from one to another, I think you need additional mechanism
> >>>than plain MIPv6.  MIP (no matter IPv6 or IPv4) is designed
> >>>to assure the reachability to a given HoA with the current
> >>>location of the mobile node (CoA).  If the app wants
> >>>to change HoAs for some reason (I assume that privacy is the
> >>>main interest), there is a need to maintain the mapping of
> >>>the identity and the locator of the mobile node.
> >>
> >>Mobile IPv6 today allows you to use two home addresses
> >>at the same time. it also allows you to bind both home
> >>addresses to the same CoA.
> > 
> >
(Continue reading)

Permalink | Reply |
headers
Vijay Devarapalli | 22 Jun 2006 00:01

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction

Shinta Sugimoto wrote:

>>>>>>The problem here is how does the MN know to "let the
>>>>>>existing sessions continue with the existing HoA"? If there is no CN's
>>>>>>address in BUL, surely the MN can choose a suitable HoA. For
>>>>>>a CN with which it has a binding, it has no reliable way of knowing
>>>>>>whether there are any ULP sessions.
>>>>>
>>>>>If you need to maintain the sessions while changing the HoA
>>>>
>>>>>from one to another, I think you need additional mechanism
>>>>
>>>>>than plain MIPv6.  MIP (no matter IPv6 or IPv4) is designed
>>>>>to assure the reachability to a given HoA with the current
>>>>>location of the mobile node (CoA).  If the app wants
>>>>>to change HoAs for some reason (I assume that privacy is the
>>>>>main interest), there is a need to maintain the mapping of
>>>>>the identity and the locator of the mobile node.
>>>>
>>>>Mobile IPv6 today allows you to use two home addresses
>>>>at the same time. it also allows you to bind both home
>>>>addresses to the same CoA.
>>>
>>>
>>>Yes, that's true.  But then there is a problem to choose
>>>which one for which communication.  When it comes to agility,
>>>it's more problematic.
>>
>>actually we are not looking for address agility here. we want
>>the mobile node to change its home address and while changing
(Continue reading)

Permalink | Reply |
headers
QIU Ying | 22 Jun 2006 13:31
Picon

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction


Hi, Shinta and Vijay

I skip some old quotation for easy read

>> Now I have another question.  Looking into the solution draft
>> (draft-irtf-mobopts-location-privacy-solutions-01) it seems to me
>> that a pseudo-HoA is derived from mobile node's home prefix
>> and it is actually a globally unique IPv6 address.  If I understand
>> the role of pseudo-HoA correctly, it aims to serve as a tag to
>> locate the real HoA for the MN.  If so, I am afraid that it may
>> not be necessary to generate a pseudo-HoA in form of IPv6 address.

RFC3775 requires that option/routing address must be a routable address. So 
a random number as the destination option is not acceptable.

>> In particular, there is no need to contain the home prefix which
>> could be of interest for an eavesdropper to identify the mobile
>> node.  Am I missing something ?

So we need multi home prefix to generate the psuedo HoA to delude the 
eavesdroppers. The reason of the psuedo HoA with home prefix is that the 
psuedo HoA in both HoTI/HoT and BU must be the same, while the HoT must be 
routed to the home agent.

> I would actually wait for version 02, which should be out next
> week before we discuss further. I wasn't very happy with
> version 01.

Hope the version 02 do not disappoint you :-)
(Continue reading)

Permalink | Reply |
headers
Shinta Sugimoto | 22 Jun 2006 14:36
Picon

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction

Hi Ying,

Thanks for your clarification. Please find my comments inline.

On Thu, 22 Jun 2006 19:31:50 +0800
QIU Ying <qiuying <at> i2r.a-star.edu.sg> wrote:

> 
> Hi, Shinta and Vijay
> 
> I skip some old quotation for easy read
> 
> >> Now I have another question.  Looking into the solution draft
> >> (draft-irtf-mobopts-location-privacy-solutions-01) it seems to me
> >> that a pseudo-HoA is derived from mobile node's home prefix
> >> and it is actually a globally unique IPv6 address.  If I understand
> >> the role of pseudo-HoA correctly, it aims to serve as a tag to
> >> locate the real HoA for the MN.  If so, I am afraid that it may
> >> not be necessary to generate a pseudo-HoA in form of IPv6 address.
> 
> RFC3775 requires that option/routing address must be a routable address. So 
> a random number as the destination option is not acceptable.

Correct.  And it's mainly for security reason.  RH2 and HAO DSTOPT
are MIPv6 specific, and they are processed only by the final destination.
So, in order to extend the MIPv6 protocol for privacy support, I think
exceptionional cases shall be made.  And I am afraid that the
version 01 actually suggests to include encrypted HoA E(Kbm, HoA)
in the HAO destination option, doesn't it ?
(Continue reading)

Permalink | Reply |
headers
Shinta Sugimoto | 22 Jun 2006 09:18
Picon

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction

On Wed, 21 Jun 2006 15:01:03 -0700
Vijay Devarapalli <vijay.devarapalli <at> azairenet.com> wrote:

> Shinta Sugimoto wrote:
> 
> >>>>>>The problem here is how does the MN know to "let the
> >>>>>>existing sessions continue with the existing HoA"? If there is no CN's
> >>>>>>address in BUL, surely the MN can choose a suitable HoA. For
> >>>>>>a CN with which it has a binding, it has no reliable way of knowing
> >>>>>>whether there are any ULP sessions.
> >>>>>
> >>>>>If you need to maintain the sessions while changing the HoA
> >>>>
> >>>>>from one to another, I think you need additional mechanism
> >>>>
> >>>>>than plain MIPv6.  MIP (no matter IPv6 or IPv4) is designed
> >>>>>to assure the reachability to a given HoA with the current
> >>>>>location of the mobile node (CoA).  If the app wants
> >>>>>to change HoAs for some reason (I assume that privacy is the
> >>>>>main interest), there is a need to maintain the mapping of
> >>>>>the identity and the locator of the mobile node.
> >>>>
> >>>>Mobile IPv6 today allows you to use two home addresses
> >>>>at the same time. it also allows you to bind both home
> >>>>addresses to the same CoA.
> >>>
> >>>
> >>>Yes, that's true.  But then there is a problem to choose
> >>>which one for which communication.  When it comes to agility,
> >>>it's more problematic.
(Continue reading)

Permalink | Reply |
headers
Keiichi SHIMA | 22 Jun 2006 06:39

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction

Hi all,

On 2006/06/22, at 7:01, Vijay Devarapalli wrote:

> Shinta Sugimoto wrote:
>
>>>>>>> The problem here is how does the MN know to "let the
>>>>>>> existing sessions continue with the existing HoA"? If there  
>>>>>>> is no CN's
>>>>>>> address in BUL, surely the MN can choose a suitable HoA. For
>>>>>>> a CN with which it has a binding, it has no reliable way of  
>>>>>>> knowing
>>>>>>> whether there are any ULP sessions.
>>>>>>
>>>>>> If you need to maintain the sessions while changing the HoA
>>>>>
>>>>>> from one to another, I think you need additional mechanism
>>>>>
>>>>>> than plain MIPv6.  MIP (no matter IPv6 or IPv4) is designed
>>>>>> to assure the reachability to a given HoA with the current
>>>>>> location of the mobile node (CoA).  If the app wants
>>>>>> to change HoAs for some reason (I assume that privacy is the
>>>>>> main interest), there is a need to maintain the mapping of
>>>>>> the identity and the locator of the mobile node.
>>>>>
>>>>> Mobile IPv6 today allows you to use two home addresses
>>>>> at the same time. it also allows you to bind both home
>>>>> addresses to the same CoA.
>>>>
>>>>
(Continue reading)

Permalink | Reply |
headers
Vijay Devarapalli | 22 Jun 2006 19:22

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction

Keiichi SHIMA wrote:

>> its not even about privacy. its about the mobile node deciding
>> to change home addresses, while minimizing impact on existing
>> sessions. new sessions would be started with the new HoA. for
>> a short period there will be two home addresses with some
>> sessions based on the old HoA and some on the new HoA.
> 
> 
> What does 'minimizing impact on sessions'?  Does it mean session  
> continuity?

just let the sessions on the old HoA continue for a while
(not forever though).

> Then, I have a simple question that why do we need to provide session  
> continuity when home address changes?  A home address is the  identifier 
> of the end node.  If it changed, then the sessions related  to the 
> identifier should be terminated.  

thats one option. another option is to let the use of old
HoA and the new HoA for a while.

> If we can change from one  home 
> address to another home address, then why do we need Mobile IP?
> 
> Or does the discussion is for a new mobility mechanism other than MIP  
> based?
> 
> # or I am misunderstanding...?
(Continue reading)

Permalink | Reply |
headers
Rajeev Koodli | 22 Jun 2006 23:27
Picon

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction

Vijay Devarapalli wrote:

>
>> Then, I have a simple question that why do we need to provide 
>> session  continuity when home address changes?  A home address is 
>> the  identifier of the end node.  If it changed, then the sessions 
>> related  to the identifier should be terminated.  
>
>
> thats one option. another option is to let the use of old
> HoA and the new HoA for a while.
>
yes, how to allow a previous HoA to be used while using a different HoA 
for new sessions.

>> If we can change from one  home address to another home address, then 
>> why do we need Mobile IP?
>>
>> Or does the discussion is for a new mobility mechanism other than 
>> MIP  based?
>>
>> # or I am misunderstanding...?
>
>
> we need to go back to the original mail from Rajeev and
> figure out what problem we are trying to solve. this thread
> has been too long. :)
>

I guess we never really ran into this issue within the realm of MIP..
(Continue reading)

Permalink | Reply |
headers
QIU Ying | 22 Jun 2006 13:09
Picon

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction


Hi, all,

My comments is at the bottom. a long quotation.

----- Original Message ----- 
From: "Keiichi SHIMA" <keiichi <at> iijlab.net>
To: "Vijay Devarapalli" <vijay.devarapalli <at> azairenet.com>
Cc: <mip6 <at> ietf.org>; "Rajeev Koodli" <rajeev <at> iprg.nokia.com>; 
<mobopts <at> irtf.org>
Sent: Thursday, June 22, 2006 12:39 PM
Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction

> Hi all,
>
> On 2006/06/22, at 7:01, Vijay Devarapalli wrote:
>
>> Shinta Sugimoto wrote:
>>
>>>>>>>> The problem here is how does the MN know to "let the
>>>>>>>> existing sessions continue with the existing HoA"? If there  is no 
>>>>>>>> CN's
>>>>>>>> address in BUL, surely the MN can choose a suitable HoA. For
>>>>>>>> a CN with which it has a binding, it has no reliable way of 
>>>>>>>> knowing
>>>>>>>> whether there are any ULP sessions.
>>>>>>>
>>>>>>> If you need to maintain the sessions while changing the HoA
>>>>>>
>>>>>>> from one to another, I think you need additional mechanism
(Continue reading)

Permalink | Reply |
headers
Vijay Devarapalli | 21 Jun 2006 19:36

RE: [Mobopts] Re: MIP and Upper Layer Protocol interaction

>  > > => There is no difference between the two scenarios. 
>  > 
>  > your reply is too cryptic.
>  > 
>  > when shim6 is used, one cannot start using another address
>  > without first adding that address to the list of addresses
>  > that the HA/CN need to be aware of (basically add to the
>  > shim6 state).
> 
> => Of course, which is doable in both scenarios.
> 
>  > 
>  > also, if both home addresses are from the same prefix,
>  > shim6 shouldn't be used. 
>          ^^^^^^^^^
> => that's your opinion, but the point is it can be used just as easily
> whether it's the same prefix or a different one. It actually 
> makes sense
> to use on solution for both cases.
> 
> 
>   if the home link is multihomed
>  > and the mobile node has multiple home addresses from the
>  > different prefixes, then shim6 is applicable.
> 
> => It's applicable in both cases, you want to use it in one case. 

yes. in my first reply to Shinta, I had said, I 
_would like_ to restrict the use of shim6 when MIP6
is used to the scenario when the home link is
(Continue reading)

Permalink | Reply |
headers
Soliman, Hesham | 20 Jun 2006 05:49

RE: [Mobopts] Re: MIP and Upper Layer Protocol interaction


 > > One option would be to run Shim6 over MIPv6.  Such usage has
 > > already been discussed in Shim6 WG.  By mobile node establishing
 > > Shim6 context with its HA/CN, it could utilize multiple HoAs
 > > without annoying upper layer protocols.  
 > 
 > yes, this can be done. but I would like to restrict
 > shim6 usage when mip6 is used to the case where the
 > home link is site multihomed and the mobile node already
 > has the multiple home addresses configured on it. not
 > when the mobile node decides to change its home address.

=> There is no difference between the two scenarios. 

Hesham
Permalink | Reply |
headers
Vijay Devarapalli | 20 Jun 2006 19:45

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction

Soliman, Hesham wrote:
>  > > One option would be to run Shim6 over MIPv6.  Such usage has
>  > > already been discussed in Shim6 WG.  By mobile node establishing
>  > > Shim6 context with its HA/CN, it could utilize multiple HoAs
>  > > without annoying upper layer protocols.  
>  > 
>  > yes, this can be done. but I would like to restrict
>  > shim6 usage when mip6 is used to the case where the
>  > home link is site multihomed and the mobile node already
>  > has the multiple home addresses configured on it. not
>  > when the mobile node decides to change its home address.
> 
> => There is no difference between the two scenarios. 

your reply is too cryptic.

when shim6 is used, one cannot start using another address
without first adding that address to the list of addresses
that the HA/CN need to be aware of (basically add to the
shim6 state).

also, if both home addresses are from the same prefix,
shim6 shouldn't be used. if the home link is multihomed
and the mobile node has multiple home addresses from the
different prefixes, then shim6 is applicable.

ofcourse, one can do all this with shim6, but then quoting
you "shim6 is trying to solve world hunger". ;) (hope you
don't mind it).
(Continue reading)

Permalink | Reply |
headers
Soliman, Hesham | 21 Jun 2006 12:58

RE: [Mobopts] Re: MIP and Upper Layer Protocol interaction


 > > => There is no difference between the two scenarios. 
 > 
 > your reply is too cryptic.
 > 
 > when shim6 is used, one cannot start using another address
 > without first adding that address to the list of addresses
 > that the HA/CN need to be aware of (basically add to the
 > shim6 state).

=> Of course, which is doable in both scenarios.

 > 
 > also, if both home addresses are from the same prefix,
 > shim6 shouldn't be used. 
         ^^^^^^^^^
=> that's your opinion, but the point is it can be used just as easily
whether it's the same prefix or a different one. It actually makes sense
to use on solution for both cases.

  if the home link is multihomed
 > and the mobile node has multiple home addresses from the
 > different prefixes, then shim6 is applicable.

=> It's applicable in both cases, you want to use it in one case. 

Hesham
Permalink | Reply |
headers
Vijay Devarapalli | 7 Jun 2006 20:51

Re: MIP and Upper Layer Protocol interaction

Rajeev Koodli wrote:

>> if not for privacy, perhaps the mobile node shouldn't
>> change its HoA abruptly, but let existing sessions
>> continue with the existing HoA and use the new HoA
>> for new sessions. the mobile node would also have
>> to update the DNS entry if it wants its FQDN to
>> resolve to the new HoA.
>>
> The problem here is how does the MN know to "let the
> existing sessions continue with the existing HoA"? If there is no CN's
> address in BUL, surely the MN can choose a suitable HoA. For
> a CN with which it has a binding, it has no reliable way of knowing
> whether there are any ULP sessions.

we could easily say its implementation specific since its
internal to the mobile node. :)

there are many ways this can be achieved inside a mobile
node.

1. the mobile node keeps track of number of packets sent
using a particular binding update list entry. it can
record this information in the binding update list entry
itself.

2. the mobile node records the timestamp of the last packet
sent using a particular binding update list entry in the
binding update list entry itself.
(Continue reading)

Permalink | Reply |
headers
Thierry Ernst | 9 Jun 2006 11:53
Picon
Picon
Favicon

Re: MIP and Upper Layer Protocol interaction


Several comments:
- doesn't this thread initiated Rajeev belong to Shim6 ?

- if it doesn't, it would be more appropriate to discuss it on the
Monami6 ML, although we excluded to produce an output on the matter
where the MN (i.e. either a host or a router)  has multiple HoAs. But,
still, Monami6 see is the right ML to discuss it when node multihoming
comes to mobility.

Thierry.

On Wed, 07 Jun 2006 11:51:32 -0700
Vijay Devarapalli <vijay.devarapalli <at> azairenet.com> wrote:

> Rajeev Koodli wrote:
> 
> >> if not for privacy, perhaps the mobile node shouldn't
> >> change its HoA abruptly, but let existing sessions
> >> continue with the existing HoA and use the new HoA
> >> for new sessions. the mobile node would also have
> >> to update the DNS entry if it wants its FQDN to
> >> resolve to the new HoA.
> >>
> > The problem here is how does the MN know to "let the
> > existing sessions continue with the existing HoA"? If there is no CN's
> > address in BUL, surely the MN can choose a suitable HoA. For
> > a CN with which it has a binding, it has no reliable way of knowing
> > whether there are any ULP sessions.
>
(Continue reading)

Permalink | Reply |
headers
Vijay Devarapalli | 9 Jun 2006 18:47

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction

Thierry,

I think this belongs in mobopts (or MIP6 if the problem is
sufficiently well understood). its more about stopping the
use of one HoA and starting the use of another HoA rather
than using multiple home addresses.

Vijay

Thierry Ernst wrote:
> Several comments:
> - doesn't this thread initiated Rajeev belong to Shim6 ?
> 
> - if it doesn't, it would be more appropriate to discuss it on the
> Monami6 ML, although we excluded to produce an output on the matter
> where the MN (i.e. either a host or a router)  has multiple HoAs. But,
> still, Monami6 see is the right ML to discuss it when node multihoming
> comes to mobility.
> 
> Thierry.
> 
> 
> 
> 
> 
> On Wed, 07 Jun 2006 11:51:32 -0700
> Vijay Devarapalli <vijay.devarapalli <at> azairenet.com> wrote:
> 
>> Rajeev Koodli wrote:
>>
(Continue reading)

Permalink | Reply |
headers
Rajeev Koodli | 8 Jun 2006 02:44
Picon

Re: MIP and Upper Layer Protocol interaction


Hi Vijay,

Vijay Devarapalli wrote:

> we could easily say its implementation specific since its
> internal to the mobile node. :)
>
that's okay. I am trying to see what we can use..

> there are many ways this can be achieved inside a mobile
> node.
>
> 1. the mobile node keeps track of number of packets sent
> using a particular binding update list entry. it can
> record this information in the binding update list entry
> itself.
>
> 2. the mobile node records the timestamp of the last packet
> sent using a particular binding update list entry in the
> binding update list entry itself.
>
> 3. the mobile node keeps track of all the sockets that
> were opened with a particular home address.
>
This might work. (1 and 2 above don't really relate to
whether a session/connection is alive or not).

I am referring to such interaction. How do we formalize it
(if not standardize it)?
(Continue reading)

Permalink | Reply |
headers
Christian Vogt | 16 Jun 2006 08:46
Picon
Favicon

Re: MIP and Upper Layer Protocol interaction

Hi Rajeev and Vijay,

you could also look at existing Internet protocol control blocks.

All connections, regardless of the transport protocol they use, are
represented by an Internet PCB.  That Internet PCB may link to a
separate transport-protocol-specific PCB, but that's less important for
your needs.  You can iterate through a list of all Internet PCBs and
look for the "foreign addresses" (i.e., CNs' addresses) recorded.  If
the MN has an entry in its binding update list for a given foreign
address, it would have to notify that CN about the change of its home
address.

In a related project, we wanted to find out about the establishment of
new and the tear-down of old upper-layer connections.  Our goal was to
create a Mobile IPv6 binding even when the mobile node is at home, in
order to facilitate proactive Mobile IPv6 signaling on the home link,
which some optimizations require.

The project was a diploma thesis of one of my students, Daniel
Jungbluth, which I supervised.  The following is a link to the
documentation of this work:

http://doc.tm.uka.de/2006/jungbluth-2006-homebindings.pdf

Daniel's diploma thesis is not exactly what /you/ are having in
mind---you need to check for existing upper-layer connections, while we
wanted to recognize the establishment of new or tear-down of old
connections.  Specifically, /we/ could not easily use Internet PCBs for
our needs; keeping an eye on the sockets turned out the best way to do
(Continue reading)

Permalink | Reply |
headers
Keiichi SHIMA | 16 Jun 2006 18:05

Re: [Mobopts] Re: MIP and Upper Layer Protocol interaction

Hi,

On 2006/06/16, at 8:46, Christian Vogt wrote:

> you could also look at existing Internet protocol control blocks.
>
> All connections, regardless of the transport protocol they use, are
> represented by an Internet PCB.  That Internet PCB may link to a
> separate transport-protocol-specific PCB, but that's less important  
> for
> your needs.  You can iterate through a list of all Internet PCBs and
> look for the "foreign addresses" (i.e., CNs' addresses) recorded.  If
> the MN has an entry in its binding update list for a given foreign
> address, it would have to notify that CN about the change of its home
> address.

In the BSD style PCB archtecture, we can check all connections using  
TCP, but it is difficult to check UDP connection(?)s.  Because one  
UDP socket (= one PCB) may be used for multiple destination.

I think, if we need more accurate mechanism to bind upper layers and  
MIP layer, maybe we need a new mechanism.

---
Keiichi SHIMA
IIJ Research Laboratory <keiichi <at> iijlab.net>
WIDE Project <shima <at> wide.ad.jp>
Permalink | Reply |
headers
Vijay Devarapalli | 8 Jun 2006 20:08

Re: MIP and Upper Layer Protocol interaction

Rajeev Koodli wrote:

> Vijay Devarapalli wrote:
> 
>> we could easily say its implementation specific since its
>> internal to the mobile node. :)
>>
> that's okay. I am trying to see what we can use..
> 
>> there are many ways this can be achieved inside a mobile
>> node.
>>
>> 1. the mobile node keeps track of number of packets sent
>> using a particular binding update list entry. it can
>> record this information in the binding update list entry
>> itself.
>>
>> 2. the mobile node records the timestamp of the last packet
>> sent using a particular binding update list entry in the
>> binding update list entry itself.
>>
>> 3. the mobile node keeps track of all the sockets that
>> were opened with a particular home address.
>>
> This might work. (1 and 2 above don't really relate to
> whether a session/connection is alive or not).
> 
> I am referring to such interaction. How do we formalize it
> (if not standardize it)?
(Continue reading)

Permalink | Reply |
headers
Rajeev Koodli | 9 Jun 2006 18:55
Picon

Re: MIP and Upper Layer Protocol interaction

Vijay Devarapalli wrote:

>>> Yes, but you don't expect session persistence in that case.
>>
>
> hmmm.... you still need the sessions using the old IPv6
> address to continue right?
>
I meant for non-MIP case.. If you are not using MIP, you don't expect
the session to survive if you change the address.

-Rajeev

> Vijay
Permalink | Reply |
headers
Syam Madanapalli | 9 Jun 2006 05:59
Picon

Re: MIP and Upper Layer Protocol interaction

Hi Vijay,

[cut]
> >> you would see this issue in a non-Mobile IPv6 host too
> >> when you have multiple IPv6 addresses and the host wants
> >> to stop using a particular IPv6 address and start using
> >> another IPv6 address.
> >>
> > Yes, but you don't expect session persistence in that case.
>
> hmmm.... you still need the sessions using the old IPv6
> address to continue right?

As we are changing the HoA, isn't it natural for Layer 3 session to break?
For session continuity in such cases, we may need to take applications help.
For example, SIP may re-invite using new address.

Thanks,
Syam

>
> Vijay
>
> _______________________________________________
> Mip6 mailing list
> Mip6 <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mip6
>
Permalink | Reply |

Gmane