Subject: [netlmm] MAC address as MN-ID

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Oct 2007 10:53:08 -0700

Hello folks,

This is not related to the multi-homing discussion. :)

Erik's email pointed out something that we don't explicitly support
in the base PMIPv6 spec today. I think we should allow for using
PMIPv6 in scenarios where there is nothing more than a MAC address
for the mobile node to present and acquire an address in a PMIPv6
domain. PMIPv6 today allows such a deployment, but we need some
extensions to support it.

We need to extend RFC 4283 to define a new subtype in the Mobile
Node Identifier Option. RFC 4283 only defines one subtype to indicate
an NAI. We need subtype '2' to indicate a "L2 identifier" or more
explicitly "802.3/802.11 MAC address".

We can either work on a 4283bis to define a new subtype or include
this in the base PMIPv6 spec itself. Comments?

Vijay

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 09 Oct 2007 21:44:50 +0300

> This is not related to the multi-homing discussion. :)

Its a welcome change :-) ...

> this in the base PMIPv6 spec itself. Comments?

... but I think this may be somewhat related. Basically, the
question is what does MNID stand for. I suspect that you'll
need an abstract link-layer specific unique value plus an
optional NAI.

Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Oct 2007 00:16:47 +0200

> this in the base PMIPv6 spec itself. Comments?

I thought about this line too.

This sounds very much as all the identifiers DHCPv6 has already defined 
(MAC address, Subscriber-ID, Circuit-ID - to name a few).

I'm not sure whether I prefer to extend RFC4283, PMIPv6 or simply use 
and adapt where necessary DHCPv6.

If only could we formulate the problem ok.  Momentarily I think the 
multi-homing discussion is only around an effect, not the problem itself.

Alex

> Vijay

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Oct 2007 15:27:49 -0700

> need an abstract link-layer specific unique value plus an

I believe the "MNID" or the MN identifier is something the mobile
node presents to the MAG as part of attaching to the MAG. This
uniquely identifies the mobile node. It could be the NAI or a L2 
identifier.

The "abstract layer-link specific unique value" is something I don't
understand. I also don't believe it should be generated by the MAG.
Moreover, it needs a bit of work to specify this. I don't think it
is as simple as saying use an abstract link identifier.

Vijay

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Wed, 10 Oct 2007 08:38:16 +0200

> this in the base PMIPv6 spec itself. Comments?
Agree.
I would prefer it is added to 4283bis.
PMIPv6 might mention it too and refers to 4283bis.

Bruno.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 10 Oct 2007 00:15:22 -0700

Vijay,
Thanks for bringing this up.  Sometime back, I had checked with Jari on
relaxing the requirement of Standards Action for IANA assignment of
sub-types to RFC4283.  Sub-types such as MAC address or any other L2
address type that a different SDO may want to register can be used as
MN-ID.  It seems too stringent to require standards action to register
all sub-types.  Jari seems okay with the idea of relaxing that
requirement.  We need someone to write a document that effectively
achieves that.  Any volunteers?  I am not sure if that needs to be
RFC4283bis; I think it can be an update to RFC4283.

Somewhat orthogonal to that, I think what we may need for PMIP6 is an L2
ID or Interface ID option, without being specific about what it is, as
Jari has suggested in response to your email here.  That would be useful
to carry an interface specific ID to the LMA - the requirement there is
just that the ID uniquely identify an interface and it doesn't matter
exactly what it is.  Potentially, this option could be an RFC4283
sub-type too and can be defined in the PMIP6 base spec itself. Of
course, the NAI option may also be present along with this option. 

Vidya

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Tuesday, October 09, 2007 10:53 AM
> To: Netlmm
> Subject: [netlmm] MAC address as MN-ID
> 
> Hello folks,
> 
> Erik's email pointed out something that we don't explicitly 
> support in the base PMIPv6 spec today. I think we should 
> allow for using
> PMIPv6 in scenarios where there is nothing more than a MAC 
> address for the mobile node to present and acquire an address 
> in a PMIPv6 domain. PMIPv6 today allows such a deployment, 
> but we need some extensions to support it.
> 
> We need to extend RFC 4283 to define a new subtype in the 
> Mobile Node Identifier Option. RFC 4283 only defines one 
> subtype to indicate an NAI. We need subtype '2' to indicate a 
> "L2 identifier" or more explicitly "802.3/802.11 MAC address".
> 
> We can either work on a 4283bis to define a new subtype or 
> include this in the base PMIPv6 spec itself. Comments?
> 
> Vijay
> 
>

---

From: Julien Laganier <[email-masked]>
Date: Wed, 10 Oct 2007 11:45:10 +0200

> this in the base PMIPv6 spec itself. Comments?

We could also use SEND public keys as MN Identifier. That would allow to 
secure MN movement detection by the MAG via use of SEND (see the MN-AR 
interface draft).

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Oct 2007 12:08:31 +0200

> secure MN movement detection by the MAG via use of SEND (see the MN-AR 

I agree.

I think we have until now: IEEE 48bit address, SeND public key, USB 
48bit MAC address, ppp-negotiated interface identifier.

(the 48bit MAC addresses used on USB aren't managed by IEEE - no
  uniqueness guaranteed)

Alex

This "other" 48bit MAC addresses is what is used by USB for example, a 
48bit identifier that doesn't conform to IEEE's

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Oct 2007 09:05:31 -0700

> RFC4283bis; I think it can be an update to RFC4283.

hmm... I think we should just revise 4283bis by adding a couple of
subtypes in addition to the one that is already there. While revising
it we can add some text saying, the allocation of new values for the
subtype field can done with IESG approval or expert review. No need
for standards action.

> Jari has suggested in response to your email here.  

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.

Vijay

That would be useful

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 10 Oct 2007 09:18:10 -0700 (PDT)

> subtype field can done with IESG approval or expert review. No need

Why should this belong to 4283. What 4283 defines is a mobility
option for carrying some identifier. The identifier formats  are
specified in 4282.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Oct 2007 10:50:30 -0700

Sri,

> option for carrying some identifier. The identifier formats  are

4282 only defines the NAI. No other identifier.

4283 defines a container as well as a subtype field. We need to set
aside new values for the subtype field or make it easy to reserve
new values for the subtype field without having to approve a new
RFC for each subtype value. So we need to revise 4283 for this
purpose.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 10 Oct 2007 16:44:41 -0700

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

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.

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. 

The point here was that we can't restrict how an interface (at the IP
level) is uniquely identified in a given system.  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

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Oct 2007 17:00:32 -0700

Narayanan, Vidya wrote:
> 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.

 > Some

This is solved by having subtype 2 in the MN-ID mobility option.

> would typically be the case for cellular interfaces of a given type, for

A combination of the MN identifier and the access technology type was
in the proposal sent by Raj last Saturday.

> type, given that their hosts and network elements know only one is

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.

> 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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 11 Oct 2007 17:41:36 -0700

I don't see how a procedure for creation of unique link IDs can be
defined at the IETF, when the links and the systems that manage it are
outside the scope of the IETF.  IP, for instance, requires unique
addresses on each interface to function, but, doesn't mandate a means of
arriving at that.  It provides hooks for it - e.g., you may use the
EUI-64 means of arriving at the IID in IPv6, you may use different
client IDs/DUID in DHCPv4/DHCPv6 to get unique addresses and so on.
Ultimately, either one of these methods is used or a particular link
layer encapsulation of IP needs to specify some behavior, when none of
these apply.  

Similarly, here, we can provide hints on how to arrive at unique ids for
the interface, but, it may not work for all systems.  It seems perfectly
reasonable to provide some non-normative means by which you can do this
and leave it up to a specific SDO to say exactly how an interface is
identified in that system.  

Vidya 

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Wednesday, October 10, 2007 5:01 PM
> To: Narayanan, Vidya
> Cc: Netlmm
> Subject: Re: [netlmm] MAC address as MN-ID
> 
> Narayanan, Vidya wrote:
> interface 
> 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.
> 
>  > Some
> > A) Use something like the MAC address of the MN - this is obviously 
> > the most straightforward and doesn't need any synchronization
> 
> > 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.
> 
> > 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.
> 
> 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
> > 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.
> > 
> > without virtual interfaces, something like C or other 
> algorithms can 
> > be defined in scope of that specific deployment or SDO.
> > 
> > Vidya
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 11 Oct 2007 21:05:07 -0500

Hi Vidya,
Please see comments inline.

Regards,
Ahmad

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Friday, October 12, 2007 2:42 AM
> To: Vijay Devarapalli
> Cc: Netlmm
> Subject: RE: [netlmm] MAC address as MN-ID
> 
> 
> I don't see how a procedure for creation of unique link IDs 
> can be defined at the IETF, when the links and the systems 
> that manage it are outside the scope of the IETF.  

[Ahmad]
I agree with you, makes a lot of sense. On the other hand, how mandating
a logical interface on the IPv6 host to handle inter-access technology
all of a sudden becomes an IETF business?

> IP, for 
> instance, requires unique addresses on each interface to 
> function, but, doesn't mandate a means of arriving at that. 

[Ahmad]
It also does not mandate a means to hide these IP addresses nor the
interfaces. Right?
 
> It provides hooks for it - e.g., you may use the
> ETUI-64 means of arriving at the IID in IPv6, you may use 
> different client IDs/DUID in DHCPv4/DHCPv6 to get unique 
> addresses and so on.

[Ahmad]
I do not like to call these hooks, I think we should call it a forward
compatible design. 
However, until we have a good understanding of the scenario about
multiple interfaces over the same access technology for a generic
multi-homed IPv6 host which will use its access type/radio to access the
same PMIPv6 domain and land on the same LMA over two different MAGs one
in Dallas and the other in Chicago; unless we have a reasonable
understanding of that deployment reality, I consider these hooks as BUGS
and absolutely not needed:-(

> Ultimately, either one of these methods is used or a 
> particular link layer encapsulation of IP needs to specify 
> some behavior, when none of these apply.  
> 
> Similarly, here, we can provide hints on how to arrive at 
> unique ids for the interface, but, it may not work for all 
> systems.  It seems perfectly reasonable to provide some 
> non-normative means by which you can do this and leave it up 
> to a specific SDO to say exactly how an interface is 

[Ahmad]
That is right. I also proposed that MAG includes a handoff indication
with the access type for whatever access technology that provide such an
indication to the MAG. Do not you think that is a good idea to optimize
the LMA decision in the case of multi-homing?

> > Even basic PMIPv6 handover would break if the old MAG and 
> the new MAGs 
> > don't use the same interface identifier.
> > 
> >  > Some
> equivalent 
> should be

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 11 Oct 2007 19:05:37 -0700

Vidya,

Basic PMIPv6 handover for a mobile node with just one interface
would break if we don't guarantee that all the MAGs can generate
the same interface identifier. Forget SDOs for the moment. So I
don't see how that can be out of scope.

> client IDs/DUID in DHCPv4/DHCPv6 to get unique addresses and so on.

Come on, in these cases, it is the mobile node that is generating
the IID. For PMIPv6, you are requiring the MAG to generate the IID.

> identified in that system.  

As long as the Mobile Node provides the interface identifier to
acquire a PMIPv6 home network prefix, there is no issue. The issue
comes when the MAG generates it and there is no standard way of
generating it. If there is some sort of context transfer between
MAGs, then it might work.

For using a MAC address as the mobile node identifier, you can always
using RFC 4283 with the subtype set to "2" (yet to be standardized)
and get a PMIPv6 home network prefix in a PMIPv6 domain.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 12 Oct 2007 00:35:26 -0700

Hi Ahmad,

<snip>
 
> [Ahmad]
> I agree with you, makes a lot of sense. On the other hand, 
> how mandating a logical interface on the IPv6 host to handle 
> inter-access technology all of a sudden becomes an IETF business?
> 

It is absolutely not IETF's business and nobody is suggesting that it
be.  From the IETF NETLMM charter perspective, the protocol is not
expected to handle inter-technology handoffs.  Keeping the other SDO
deployment models in mind, we are going beyond our charter here to
ensure that a solution we come up with doesn't prevent that.  And, it
was an example that was given to say how one could still do
inter-technology handoffs with a per-interface prefix model; other
examples were also given.  It is entirely upto another SDO that chooses
to use this protocol for inter-technology handoffs to choose how to do
it. 

> 
> > IP, for
> > instance, requires unique addresses on each interface to function, 
> > but, doesn't mandate a means of arriving at that.
> 
> [Ahmad]
> It also does not mandate a means to hide these IP addresses 
> nor the interfaces. Right?
>  

Right.  And, neither is anyone here suggesting that. 

> > ETUI-64 means of arriving at the IID in IPv6, you may use different 
> I do not like to call these hooks, I think we should call it 
> a forward compatible design. 
> However, until we have a good understanding of the scenario 
> about multiple interfaces over the same access technology for 
> a generic multi-homed IPv6 host which will use its access 
> type/radio to access the same PMIPv6 domain and land on the 
> same LMA over two different MAGs one in Dallas and the other 
> in Chicago; unless we have a reasonable understanding of that 
> deployment reality, I consider these hooks as BUGS and 
> absolutely not needed:-(
> 

Please see my email on the validity of multihoming for a clarification
on the above. 

> particular link 
> unique ids 
> > for the interface, but, it may not work for all systems.  It seems 
> > perfectly reasonable to provide some non-normative means by 
> which you 
> > can do this and leave it up to a specific SDO to say exactly how an 
> > interface is identified in that system.
> 
> [Ahmad]
> That is right. I also proposed that MAG includes a handoff 
> indication with the access type for whatever access 
> technology that provide such an indication to the MAG. Do not 
> you think that is a good idea to optimize the LMA decision in 
> the case of multi-homing?
>