Subject: [Mip6] MIP and Upper Layer Protocol interaction

From: Rajeev Koodli <[email-masked]>
Date: Tue, 06 Jun 2006 16:32:22 -0700

Hello folks,

we have problem dealing with change of HoA with a CN.

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.

Any thoughts on how to handle this MIP - ULP interaction?

-Rajeev

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 7 Jun 2006 02:43:44 +0300 (EEST)

Hi,

On Tue, 6 Jun 2006, Rajeev Koodli wrote:

> pseudo-hoa for privacy purposes), it has no _reliable_ way of
> knowing whether it has existing sessions with that CN.

=> Can you please elaborate more on this? Is there any particular
draft you're referring to? What type of pseudo-HoA you're considering?

Regards,

Wassim H.

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 06 Jun 2006 17:12:18 -0700

Hi Wassim,

>draft you're referring to? What type of pseudo-HoA you're considering?
No particular draft as such. The problem is if the MN wishes to change 
its HoA
for whatever reasons (3041 style privacy included), it has no reliable 
means of
determining whether there is an existing connection/session or not.

-Rajeev

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 06 Jun 2006 17:35:17 -0700

Hello Rajeev,

It could be that there isn't really a problem.

Suppose that the mobile node keeps track of whether or not
the correspondent node has a binding.  Then, it can notify
the correspondent if it changes home address, in addition
to sending notifications about each new care-of address.

If the correspondent node has no binding, then we can
imagine that there hasn't been any traffic recently and that
there are no TCP sessions.

In that case, if the correspondent node wants to send
data to the mobile node, it would have to re-resolve the
mobile's host name.  This could possibly require that
the old home address first would fail.  Presumably, this
isn't exactly a mobility problem.  I guess the motivation
is to allow a device to operate with a new home agent
in a new network but still maintain its existing "identity"
from the point of view of some correspondent nodes.

If I missed out on previous discussion about this point,
please excuse my lack of context!  Otherwise, can you
say what use scenarios you had in mind?

Regards,
Charlie P.

Rajeev Koodli wrote:

> Mobopts mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mobopts

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 06 Jun 2006 18:18:33 -0700

Hi Charlie,

> It could be that there isn't really a problem.
That would be good. :-)

> there are no TCP sessions.
The CN (and the MN) can have a binding and not have a TCP
connection. So, the emphasis here is on "reliably" in "being able to detect
an existing connection". The BCE lifetime is not correlated to the lifetime
of a TCP connection. (You _could_ have a CN teardown a binding
and have it later send a BRR for a new connection. But this won't
work easily with multiple connections).

> from the point of view of some correspondent nodes.
I tend to agree that this may not be strictly a mobility problem.
Typically, you need to resolve a user identifier to device identifier before
starting a connection, and you can construct the mapping in such
a way as to support dynamic HoAs.

> say what use scenarios you had in mind?
Well, a MN may use RFC 3041 style HoA or some other form to
thwart compromises in location privacy and profiling.

Regards,

-Rajeev

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 06 Jun 2006 18:23:21 -0700

> 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

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 06 Jun 2006 18:45:15 -0700

> a way as to support dynamic HoAs.

the bootstrapping specifications can handle updating
FQDN to HoA mapping. for identifiers other than FQDN
we would need additional work.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Wed, 7 Jun 2006 08:19:46 -0700

Charlie,

Let's see if I understand. Are you saying that if the mobile node wants to 
change home address, it should change existing sessions by treating the 
change as route optimization? That is, it would send a route optimization 
binding update (with appropriate security) with the new home address as a 
care of address? Presumably new sessions would be started with the new home 
address.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 07 Jun 2006 10:13:06 -0700

> the binding cache entry at the CN.
This is a way to do it. Nevertheless, keeping the privacy issue aside..

> to update the DNS entry if it wants its FQDN to
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.

-Rajeev

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 07 Jun 2006 11:51:32 -0700

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

3. the mobile node keeps track of all the sockets that
were opened with a particular home address.

4. etc....

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.

let me know if I am completely off track.

Vijay

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 07 Jun 2006 17:44:38 -0700

Hi Vijay,

> internal to the mobile node. :)
that's okay. I am trying to see what we can use..

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

> to stop using a particular IPv6 address and start using
Yes, but you don't expect session persistence in that case.

-Rajeev

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 08 Jun 2006 11:08:06 -0700

> I am referring to such interaction. How do we formalize it

not sure.

draft-ietf-mip6-mipext-advapi-07.txt is one option, but it
is already in the RFC Editor queue. another option is to
write an Informational document that describes how a
Mobile IPv6 host could deal with home address changes.

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

Vijay

---

From: "Syam Madanapalli" <[email-masked]>
Date: Fri, 9 Jun 2006 09:29:17 +0530

Hi Vijay,

[cut]
> 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

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 9 Jun 2006 11:53:31 +0200

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

-- 
Thierry ERNST, PhD
INRIA Rocquencourt Project-Team IMARA
+33 1 39 63 59 30 (office)

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 09 Jun 2006 09:47:19 -0700

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

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 09 Jun 2006 09:55:43 -0700

> 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

---

From: Christian Vogt <[email-masked]>
Date: Fri, 16 Jun 2006 08:46:02 +0200

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
this in our case.  But the document linked above might still be of
interest to you.  Check section 4.2 in particular.

Kind regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

---

From: Keiichi SHIMA <[email-masked]>
Date: Fri, 16 Jun 2006 18:05:08 +0200

Hi,

> address, it would have to notify that CN about the change of its home

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 <[email-masked]>
WIDE Project <[email-masked]>

---

From: Shinta Sugimoto <[email-masked]>
Date: Mon, 19 Jun 2006 10:38:19 +0300

Hi Rajeev,

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

On Wed, 07 Jun 2006 10:13:06 -0700

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

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.  However, I am not sure
if it fulfills your requirement especially in terms of privacy
(hiding the identity, which is MN's HoA in this case).
Would you see any problem with this approach ?  I see that
signaling overhead may also be a concern (to run both Shim6
and MIPv6).

I have some additional questions:

- If privacy is the main concern, would you think 
http://www.ietf.org/internet-drafts/draft-dupont-mip6-privacyext-03.txt
would help to solve your initial requirement ? If not, could
you please tell me why ?
- Do you assume that different HoAs that mobile node may
request are derived from different home prefixes ? Or are you
considering that the node generates HoAs from a single prefix
with privacy extension ?

Regards,
Shinta

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 19 Jun 2006 17:12:43 -0700

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

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

> would help to solve your initial requirement ? If not, could

I think its orthogonal. the use of pseudo-HoA instead
of the actual HoA is also being worked on in mobopts.

> considering that the node generates HoAs from a single prefix

I think its the same prefix, but I guess its better if
Rajeev clarifies.

Vijay

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 19 Jun 2006 21:12:10 -0400

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.

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 19 Jun 2006 20:49:15 -0700

> when the mobile node decides to change its home address.

=> There is no difference between the two scenarios. 

Hesham

---

From: Shinta Sugimoto <[email-masked]>
Date: Tue, 20 Jun 2006 10:37:53 +0300

Hi Vijay,

please find my comments inline.

On Mon, 19 Jun 2006 17:12:43 -0700

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

> when the mobile node decides to change its home address.

I think it depends on motivation whether it makes sense
to apply Shim6 here.  Utilizing Shim6 would allow HoA agility
(from ULP point of view).  OTOH, Shim6 (in the current form)
does not take privacy into consideration very much, actually.
So if the motivation is to achieve location privacy (not
allowing third party to learn the binding), I think that
we may probably need something else.

> of the actual HoA is also being worked on in mobopts.

I've read the solution draft from the mobopts
<draft-irtf-mobopts-location-privacy-solutions-01.txt>
and it seems to me that both draft try to achieve the same goal.

> I think its the same prefix, but I guess its better if

Ok, it seems so (HoAs are derived from same prefix).

Regards,
Shinta

---

From: Shinta Sugimoto <[email-masked]>
Date: Tue, 20 Jun 2006 11:00:01 +0300

Hi Rajeev,

please find my comments/questions inline.

On Mon, 19 Jun 2006 21:12:10 -0400
Rajeev Koodli <[email-masked]> wrote:

> one option, but there are others to explore.

Ok, I see.

> I encourage you to

Yes.

> draft, and there is also a mobopts drfat on solutions. Please have a look

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
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, or 2) how to provide HoA agility when the mobile node changes
it's HoA from one to another (for privacy reason), or both ?

Regards,
Shinta

---

From: QIU Ying <[email-masked]>
Date: Tue, 20 Jun 2006 18:44:50 +0800

Hi, Shinta

My cents is also inline.

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

Thanks for your attention on the drafts.
> 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

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

More detail please refer to our new version that should be online by the 
weekend.

Regards and Thanks
Qiu Ying

------------ Institute For Infocomm Research - Disclaimer -------------
This email is confidential and may be privileged.  If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you.
--------------------------------------------------------

---

From: Shinta Sugimoto <[email-masked]>
Date: Tue, 20 Jun 2006 14:12:27 +0300

Hi Ying,

please find my comments below.

On Tue, 20 Jun 2006 18:44:50 +0800
QIU Ying <[email-masked]> wrote:

> connection.

I assume, you are referring to a binding association between the MN and CN
by the "connection" in above sentence.

> Of course, the entry is not for a specifical session only, it is 

Yes.

From MN's perspective (also from CN's perspective), it's quite obvious if
there has already been a binding association established with a given CN
or not, from its BUL (in case of CN, it can be found in BC as you said).

What I meant by 1) is how can the MN identify with which CN, it has
one or more TCP session which is based on its HoA.  Note that I am
*not* asking if it's possible or not (I think it's possible, BTW),
but I am clarifying if it's the issue being discussed on this
thread or not.

> pseudo home address = one of home network prefix || Enc(Kph_i, interface ID)

Ok.

> More detail please refer to our new version that should be online by the 

Ok, thanks. Will check that.

Regards,
Shinta

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 20 Jun 2006 10:45:17 -0700

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

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 20 Jun 2006 10:54:06 -0700

> which one for which communication.  When it comes to agility,

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 and start using the new home address for new sessions.
not sure if shim6 addresses this.

> (from ULP point of view).  

see above.

> and it seems to me that both draft try to achieve the same goal.

there were a bunch of solution drafts on mip6 privacy (I
think four of them). draft-irtf-mobopts-location-privacy-solutions-01.txt,
is trying to come up with one solution.

> Ok, it seems so (HoAs are derived from same prefix).

see my reply to Hesham.

Vijay

---

From: Shinta Sugimoto <[email-masked]>
Date: Wed, 21 Jun 2006 13:13:34 +0300

Hi Vijay,

please find my further comments inline.

On Tue, 20 Jun 2006 10:54:06 -0700

> continue and start using the new home address for new sessions.

I see.  Now I understand that address agility is not the main
issue here.  If I understand the above correctly, the issue
is more about how to handle pseudo-HoA especially for correspondents
of the mobile node, and how to minimize the impact to the
existing communication.

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

> not sure if shim6 addresses this.

AFAICT, Shim6 does not provide any exact solution for this
particular issue.

However, there has been privacy analysis made for Shim6
(see Marcelo's draft for detail).
http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-privacy-00.txt
But in general, I think the requirements and prerequisite for
the privacy are a bit different in MIPv6 and Shim6.

> is trying to come up with one solution.

Ok. Thanks for the clarification.

Ok.

Regards,
Shinta

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 21 Jun 2006 03:58:13 -0700

> that the HA/CN need to be aware of (basically add to the

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

 > 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
 > different prefixes, then shim6 is applicable.

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

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 21 Jun 2006 15:01:03 -0700

> of the mobile node, and how to minimize the impact to the

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.

> node.  Am I missing something ?

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.

regarding the pseudo-HoA, it can be any 128 bit value. does
not have to have the home prefix.

Vijay

---

From: Keiichi SHIMA <[email-masked]>
Date: Thu, 22 Jun 2006 13:39:44 +0900

Hi all,

> sessions based on the old HoA and some on the new HoA.

What does 'minimizing impact on sessions'?  Does it mean session  
continuity?

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

---
Keiichi SHIMA

---

From: Shinta Sugimoto <[email-masked]>
Date: Thu, 22 Jun 2006 10:18:59 +0300

On Wed, 21 Jun 2006 15:01:03 -0700

> sessions based on the old HoA and some on the new HoA.

If I understand it correctly, upper layer protocol continue to
use *same* HoA even if the pseudo-HoA is changed, right ?
Pseudo-HoA that appears in RH2/HAO is expected to be updated
accordingly.  So, I am afraid that "changing HoA" is a bit
misleading explanation in this case.

> week before we discuss further. I wasn't very happy with

Ok, let's wait for the next version of the solution draft
then resume discussion.

Ok.

Regards,
Shinta

---

From: QIU Ying <[email-masked]>
Date: Thu, 22 Jun 2006 19:09:13 +0800

Hi, all,

My comments is at the bottom. a long quotation.

----- Original Message ----- 
From: "Keiichi SHIMA" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>
Cc: <[email-masked]>; "Rajeev Koodli" <[email-masked]>; 
<[email-masked]>
Sent: Thursday, June 22, 2006 12:39 PM
Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction

Yes.

> continuity when home address changes?  A home address is the  identifier 
> of the end node.

Yes, it is the key point. In normal MIP6, the identity HoA is always bound 
with CoA. However, for the privacy reason, we must break the relationship 
CoA and HoA in an eavesdropper perspective. It is why we need change the 
HoA. In fact, to change the HoA does means to change the owner, it just 
change the ones mask.

> If it changed, then the sessions related  to the identifier should be 
> terminated.  If we can change from one  home address to another home 
> address, then why do we need Mobile IP?

Home address indicate the owner of the CoA. MN is not able to get a packet 
with HoA as the destination address. Mobile IP ensure the direct connection 
between MN and CN.

> Or does the discussion is for a new mobility mechanism other than MIP 

It follows the mechanism of RFC3775 and 3776.

Regards
Qiu Ying

---

From: QIU Ying <[email-masked]>
Date: Thu, 22 Jun 2006 19:31:50 +0800

Hi, Shinta and Vijay

I skip some old quotation for easy read

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

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

> week before we discuss further. I wasn't very happy with

Hope the version 02 do not disappoint you :-)

Regards
Qiu Ying

---

From: Shinta Sugimoto <[email-masked]>
Date: Thu, 22 Jun 2006 15:36:20 +0300

Hi Ying,

Thanks for your clarification. Please find my comments inline.

On Thu, 22 Jun 2006 19:31:50 +0800

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

> eavesdroppers.

I am sorry, but I failed to understand why multiple home prefix
is needed to achieve the goal (privacy).  Could you please elaborate ?

> The reason of the psuedo HoA with home prefix is that the 

Could you please explain why does the draft suggest to modify the
way of CN trasmitting HoT to the MN ?  In plain MIPv6, HoT is sent
by the CN to the MN's HoA (to be set as the destination address).
Then we can expect that the HoT message is protected by the IPsec
tunnel established between the MN and HA.  Is there any problem
with that ?

> Hope the version 02 do not disappoint you :-)

No, I am not disappointed at all, it's an interesting draft.

Regards,
Shinta

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 22 Jun 2006 10:22:04 -0700

> What does 'minimizing impact on sessions'?  Does it mean session  

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

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

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

Vijay

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 22 Jun 2006 17:27:31 -0400

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

I guess we never really ran into this issue within the realm of MIP.. 
However, there is no
reason why you cannot use a different HoA. If you have dynamic HoA 
assignment which
happens to take place when the MN is using a previous (dynamically 
assigned) HoA, you
have this problem. We can argue that you can make the HoA effectively 
the same across the
assignments, but that is not the only solution we should have.

Anyway, this has been a good discussion so far. We should summarize and 
continue
at Mobopts meeting in Montreal.

Regards,

-Rajeev