Subject: RE: [Seamoby] Issue 12: Inclusion of MN's nCoA in CTAR or CTD

From: Soliman Hesham <[email-masked]>
Date: Mon, 30 Jun 2003 05:25:48 -0400

John, 

The MN's identifier should not be tied to its
IP address or, as you correctly point out, its
MAC address. If the MN needs to be identified, 
then a more abstract identifier should be used.
For example, a NAI, IMSI, TMSI, FQDN (?) ...etc.

Neither the IP address nor the MAC address are 
useful as generic identifiers.

Hesham

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]]
 > Sent: Monday, June 30, 2003 5:03 AM
 > To: [email-masked]; [email-masked]
 > Subject: RE: [Seamoby] Issue 12: Inclusion of MN's nCoA in 
 > CTAR or CTD
 > 
 > 
 > Hi James,
 > 
 > > Issue 12 questions including the MN's nCoA in CTAR or CTD. 
 > If MN has not yet
 > > completed DAD, then the address is not confirmed and it 
 > may not be if there
 > > is a conflict (note however that exactly how to quickly 
 > confirm a nCoA is
 > > currently a topic of heavy discussion on the MIP list, RFC 
 > 2462 DAD may not
 > > be done). There seems to be an assumption built in that 
 > predictive handover
 > > is occuring, and the MN will know its CoA prior to moving 
 > to the new link
 > > or, if not predictive, then immediately on coming on link.
 > > 
 > > Was this intended as an identifier for the MN on the new 
 > link? If so,
 > > wouldn't a more stable identifier be the MN's link layer address?
 > > 
 > > And what is the purpoe of old CoA?
 > 
 > Thinking about this a bit more - this is a tricky issue.  
 > link layer address
 > may not be good, in the case of vertical handovers.  Also, 
 > what to do with
 > IPv4 & possibly NATed addresses?
 > 
 > Do we need to have a stable Session ID of some sort that is used?
 > 
 > John
 > 
 > _______________________________________________
 > Seamoby mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/seamoby
 > 

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 30 Jun 2003 08:40:13 -0700

Hello Hesham and John,

> For example, a NAI, IMSI, TMSI, FQDN (?) ...etc.

I don't think this is true.  I think that the means
by which the identification is carried out, should
be the same as the means used for the original
purpose of the particular protocol.  For instance,
if a security association is based on IP address,
then the identification ought to be by IP address.
If PAR knows the mobile node by its MAC address,
then that would be useful.  I think since we're in
the IETF, the IP address will be very handy.

> useful as generic identifiers.

All we have to do is identify the mobile node for
the purpose of context transfer, not for generic
purposes.  In fact, the word "identify" is tricky
enough.  Surely you won't suggest that every context
tranfer requires an identity verification with some
certificate authority...?

> Do we need to have a stable Session ID of some sort that is used?

I sincerely hope this approach is not taken.  It amounts
to excess baggage and almost a license for bloat (if not
a mandate for bloat).

Also, please remember that contexts come and go, but the
mobile node stays "the same".  Would you need a session
ID per context?  Yecch!  What, exactly, is the session?

Regards,
Charlie P.