Subject: RE: [netlmm] MAC address as MN-ID

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 10 Oct 2007 22:32:32 -0400

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Thursday, October 11, 2007 9:01 AM
> To: Narayanan, Vidya
> Cc: Netlmm
> Subject: Re: [netlmm] MAC address as MN-ID
> 
> Narayanan, Vidya wrote:
> >> I had some questions on that. How do you generate a unique
> >> interface identifier and how do we transfer that across MAGs
> >> (so that all MAGs have the same interface identifier for a
> >> particular mobile node interface). Without that I don't think
> >> it makes sense reserving a new sub-type value for this.
> >>
> >
> > To a large extent, this needs to be solved outside the IETF scope.
> 
> Completely disagree. Without this, I don't think it makes sense
> identifying a mobile node based on the interface identifier and
> allocating a PMIPv6 home network prefix per interface identifier.
> Even basic PMIPv6 handover would break if the old MAG and the new
> MAGs don't use the same interface identifier.
> 
[KC>] I agree with Vijay here. The IIDs are not always MAC addresses. In
many 3G networks, IIDs are assigned or dynamically generated per
session. So, unless there is a reliable way to carry this IIDs across
MAG handovers, inclusion of this field in the PMIP6 signaling will cause
more problems.   

>  > Some
> > examples of how this may be solved:
> >
> > A) Use something like the MAC address of the MN - this is obviously
the
> > most straightforward and doesn't need any synchronization
> 
> This is solved by having subtype 2 in the MN-ID mobility option.
> 
> > B) Use of NAI and access technology type combination when you know
that
> > only one such interface is available on the hosts that connect -
this
> > would typically be the case for cellular interfaces of a given type,
for
> > e.g.
> 
> A combination of the MN identifier and the access technology type was
> in the proposal sent by Raj last Saturday.
> 
> > C) Use of NAI and some access technology groups when feasible - this
> > would be possible when a given system has sync between the hosts and
the
> > network to follow the same rules.  For e.g., a certain SDO may have
> > policies that two given access technologies can be grouped into the
same
> > type, given that their hosts and network elements know only one is
> > active at a given time.
> 
> I have pointed out numerous times, that you would need an equivalent
> of Linux port bonding to achieve something like this. I believe port
> bonding-type concept is needed only if you plan to use both interfaces
> at the same time to send/receive traffic. If you are only doing inter-
> access technology handovers using PMIPv6, you wouldn't need this kind
> of implementation.
> 
> > The point here was that we can't restrict how an interface (at the
IP
> > level) is uniquely identified in a given system.
> 
> There is no intention to restrict this. At the same time it should be
> unique enough to identify the mobile node and allocate the PMIPv6 home
> network prefix. This should remain unique in a particular PMIPv6
> domain. I don't think you can leave the generation of this identifier
> out of scope.
> 
> Vijay
> 
> For completely
> > unmodified IP hosts, A & B above would work.  At least among all the
> > technologies we have today, those that support shared links or
multiple
> > interfaces have some kind of Link ID (hence allowing the use of
> > something like A) and those that don't typically (not a guarantee)
don't
> > have more than one interface of the same access type.
> >
> > In systems where NETLMM is supported over multiple access
technologies
> > without virtual interfaces, something like C or other algorithms can
be
> > defined in scope of that specific deployment or SDO.
> >
> > Vidya
> 
> 
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 11 Oct 2007 15:44:53 -0700 (PDT)

Hi Kuntal,
  Have you seen this draft?
http://ietfreport.isoc.org/all-ids/draft-dupont-ipv6-imei-10.txt
It explains how to get 64-bit IIDs for 3GPP and 3GPP2. For WiMAX we already have MAC addresses.
  So it is possible in all technologies to get per-interface unique identifiers which are 64-bits long.
  Regards,

Behcet
----- Original Message ----
From: "Chowdhury, Kuntal" <[email-masked]>
To: Vijay Devarapalli <[email-masked]>; "Narayanan, Vidya" <[email-masked]>
Cc: Netlmm <[email-masked]>
Sent: Wednesday, October 10, 2007 9:32:32 PM
Subject: RE: [netlmm] MAC address as MN-ID

the
that
this
for
the
same
IP
multiple
don't
technologies
be

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 11 Oct 2007 20:31:29 -0400

Hi Behcet,

IMEI is not used as IID in any of the networks that I know of (3GPP2, 3GPP, WiMAX, WiFi). Moreover, in case of 3GPP2, MEID was only recently introduced. There are other formats of the hardware ID in use in 3GPP2 e.g. ESN.

Nevertheless, we cannot mandate use of IMEI as a prerequisite for PMIP6. This won't simply happen. 

BTW, this is an expired I-D.

-Kuntal

________________________________________
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Friday, October 12, 2007 7:45 AM
To: Chowdhury, Kuntal
Cc: Netlmm
Subject: Re: [netlmm] MAC address as MN-ID

Hi Kuntal,

Behcet
----- Original Message ----
From: "Chowdhury, Kuntal" <[email-masked]>
To: Vijay Devarapalli <[email-masked]>; "Narayanan, Vidya" <[email-masked]>
Cc: Netlmm <[email-masked]>
Sent: Wednesday, October 10, 2007 9:32:32 PM
Subject: RE: [netlmm] MAC address as MN-ID

>  > Some
the
that
this
for
the
same
IP
multiple
don't
technologies
be