Subject: [netlmm] Issue: Prefix allocation and multihomed MNs

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 25 Sep 2007 18:50:13 -0700

Just taking this one up on a separate thread.  Here is the discussion
from me and Vijay: 

"Vidya: 

> - Prefix allocation and multihomed MNs: 
> 
> The first bullet on page 18 states that the LMA "MUST ensure the 
> allocated prefix is not in use by any other mobile node".  In the 
> context of regular IP nodes that are multihomed, we discussed how it 
> is problematic when the same prefix/address is allocated to multiple 
> interfaces of the same node.  To prevent that problem, are we assuming

> that every distinct interface of an MN attached to the PMIP domain has

> a different unique identity?  If so, that needs to be stated. IMO, 
> that may not be practical, especially, if an NAI is used as the MN ID.

> So, in those cases, we really need to ensure that the LMA is not 
> allocating the same prefix to multiple interfaces of a multihomed MN.

> I think an appropriate rewording of this sentence may be something 
> like "the LMA MUST ensure the allocated prefix is not already in use, 
> i.e., there is no existing BCE for that prefix on the LMA".
> 
> I also recall that the document is supposed to state that the protocol

> does not support multihomed MNs more generically, but, I couldn't find

> such text.  Did I miss it?

Vijay: 

The conclusion from that thread was the multi-homing is out of scope for
the base PMIPv6 spec and not supported in the base PMIPv6 document. I
had proposed some text at that time. We never concluded on that."

We need to conclude this issue.  The tracker somehow shows this issue as
"closed" (issue #166 on the tracker) and I'm not sure why.  Other than
stating that multihoming is out of scope, we need to state one of the
following two things: 

- that PMIP is only intended for networks that have control over the
types of IP devices attaching to their networks and the burden is on the
administrators/network designers to ensure that multihomed IP devices
are not attaching using more than one interface to the same PMIP6 domain
(this is not the option I recommend)

(OR)

- define LMA behavior such that regular multihomed IP devices don't run
into issues of connectivity or shutting down interfaces.  This is much
more logical in my view and it is not a big change in the document. 

Thanks,
Vidya 

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

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 26 Sep 2007 00:02:04 -0500

Hi Vidya,

Multihomed MNs and how PMIP6 deals with them are out of scope in the context
of this document. If this is really important, then it should be specified
in a separate I-D.

I realize the problem that you are stating and this is the same that was
discussed some time back. At least my recollection was that we would not
deal with multihoming or how to avoid assigning the same address to multiple
interfaces on an MN.

I am just wondering if the LMA would really assign the same prefix to
multiple interfaces of an MN and in what scenario this would happen.
Basically when the LMA has assigned a prefix to an MN (to a specific
interface), that prefix is marked as assigned in the pool of prefixes. So I
don't see the LMA assigning the same prefix to another interface of that MN.
So I do not believe there is a need to do anything in the current I-D on
this issue other to clarify that multi-homing and issues associated with
multi-homing are out of scope for this document.

-Raj

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 26 Sep 2007 10:57:11 +0200

Hi Vidya,

I agree that we need some text about this issue.

> more logical in my view and it is not a big change in the document. 

Can you elaborate how this would work? How does the LMA differentiate
between PBUs that were triggered by the same vs different MN interfaces?

I guess the MAG would need to include some kind of MN physical network
interface ID in the PBU, but what kind of ID would that be and how does
the MAG learn that ID? Note that the MN's link-local address may not
work as an ID in general, since the MN may implement a kind of virtual
network interface which hides multiple physical network interfaces and
only exposes a single (virtual) network interface to the IP stack. This
may result in the same link-local address for multiple physical
interfaces. 

So do we need to mandate something on the MN side to solve this issue in
the general case?

Kilian

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 26 Sep 2007 11:47:20 +0200

Basavaraj Patil wrote:
> interface), that prefix is marked as assigned in the pool of prefixes.

Sorry Raj, but what method of assigning prefixes are you describing?

You are using the word 'pool' of prefixes, and this makes me think you 
mean DHCP.  (draft-06 uses 'pool' in the DHCP Section, and DHCP software 
has some 'pool' clauses).

But DHCP for PMIP6 is very unclear at this point, I think it can't work 
as the text suggests.

Alex

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

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 26 Sep 2007 06:49:55 -0500

Kilian,

> So do we need to mandate something on the MN side to solve this issue in

One of the tenets of Netlmm protocol has been to not require any changes or
requirements on the MN. So it is not an option.

Issues that arise from multi-homing and how to deal with them should be
dealt separately and not in the scope of this I-D.

-Raj

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 26 Sep 2007 15:10:47 +0200

Hi Raj,

I think we should differentiate between two cases:
1. supporting multi-homing requested by the host to achieve features
like load balancing, failover etc.
2. preventing that PMIP protocol breaks if an unmodified host activates
more than one network interface.

For case 1, I agree with you that this is out of scope of the base draft
and should be handled in a separate multi-homing document.

But I think Vidya was talking about case 2 and I agree that this issue
should be addressed in the base draft. 

Currently, I see the following potential issues if an unmodified host
activates more than one network interface and happens to attach to more
than one MAG of a given PMIP domain simultaneously:
- multiple MN interfaces get the same prefix assigned, which may break
something (e.g., routing) in the host and may result in loss of
connectivity
- BCE at LMA constantly and randomly changes since multiple MAGs send
PBUs to the LMA for the same MN. This may result in packet loss both in
downlink and uplink.
- the MAGs may discover and use different LMA addresses for the same
host etc.

However, I'm not sure how we can solve this issue without modifying the
host or mandating not to use multiple interfaces. Any ideas?

BR,

Kilian

> -----Original Message-----
> From: Basavaraj Patil [mailto:[email-masked]] 
> Sent: Mittwoch, 26. September 2007 13:50
> To: ext Kilian Weniger; Narayanan, Vidya
> Cc: [email-masked]
> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs
> 
> 
> Kilian,
> 
> 
> 
>

---

From: "Hui Deng" <[email-masked]>
Date: Wed, 26 Sep 2007 21:47:39 +0800

Sorry for my jumping in,

> something (e.g., routing) in the host and may result in loss of
could it be possible that the same prefix, but different address?
thanks,

-Hui

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 26 Sep 2007 09:14:42 -0500

Kilian,

While it is possible that a multi-interface MN can attach to different MAGs
which cause the MAGs to send a PBU to the same LMA, I personally think that
dealing with this is more of an academic exercise at the present time.

I do not believe we have the possibility of making any changes to the MN. So
that route is closed... At least for now.

So here is how I view the current scenario which IMO is academic at this
time and hence not something that we should be spending a lot of time on :

- If an MN attaches to multiple MAGs via different interfaces this would
trigger the MAGs to send PBUs to the LMA
- If the LMA receives them almost simultaneously (as an example), and a
PBAck has not been sent, then the LMA can choose to create an entry in the
BC for the last received PBU and ACK only the last received PBU (the LMA
would believe that the MN which attached to MAG1 moved to MAG2 resulting in
the transmission of PBUs from MAG1 and MAG2 near simulatenously)
- If the MN receives a PBU from another MAG for an MN which has an entry in
the BC as a result of a second interface attaching to a MAG, the LMA would
view this as the MN having moved to MAG2 and hence would delete the BCE for
MAG1 and insert MAG2 for the MN

But if we merely state (or mandate) that the LMA will only have only one MAG
entry in the BC at any given time, we would not have a problem with the
multi-homing scenario, right?

-Raj

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 26 Sep 2007 16:56:55 +0200

Raj,

can you explain why you think this an academic exercise? Do you think
that a host activating multiple network interfaces is an unrealistic
scenario?

At least it should be prevented that an unmodified host ends up with the
same address configured on multiple interfaces. I think this can
currently happen (e.g., with DHCP), right?

Mandating that the LMA will have only one MAG entry in the BC at any
given time doesn't solve the issues that I listed in my previous mail,
since they are independent of the number of entries in the BC.

BR,

Kilian

> Sent: Mittwoch, 26. September 2007 16:15
> To: ext Kilian Weniger
> Cc: [email-masked]

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 26 Sep 2007 08:16:58 -0700

Hi Kilian,

The scenario is realistic. Agreed. But, multi-homing is not
in scope for the base document. We can always publish new
document for supporting multi-homing.

PMIP6 deployments are going to be done in a managed way. 
Operators have control on what they are supporting. They
will have policy control systems in place, that can pretty
much eliminate simultaneous access of the device in a
PMIP6 domain. We dont have to define protocol extensions for
supporting that in the base document.

These discussions on Multi-homing, terminology, MAG compromise
dont converge that easily. It requires the WG time. I dont
think, we should decide to add this work to the document,
just before sending it to the IESG. 

Bottom line, this should be done as a new I-D.

Sri

> From: Kilian Weniger [mailto:[email-masked]] 
> Sent: Wednesday, September 26, 2007 7:57 AM
> To: Basavaraj Patil
> Cc: [email-masked]
> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs
> 
> Raj,
>

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 26 Sep 2007 11:06:15 -0500

Kilian,

Activating multiple interfaces is something that most devices and hosts do
already. However having the multiple interfaces attach to MAGs which are
served by a common LMA is. This is what I was saying as being academic.

If the MAGs that the MN attaches to are associated with different LMAs then
it is not a problem. The issue is only when both the MAGs are associated
with the same LMA and this may not be something that we want to focus on at
the present time or at least not in the context of this I-D.

Regarding your second point, do you believe that host implementations will
assign the same address to multiple interfaces that they may receive via
DHCP?

-Raj

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 26 Sep 2007 11:15:59 -0700

Raj, Sri,
The points you have raised are confusing to me.  I don't understand how
stating that multihoming is out of scope and that operators can ensure
multiple interfaces of the MN don't end up under the same LMA is
sufficient or even realistic.  

First, the most stringent thing that an operator can do is ensure that
an LMA only serves MAGs that are attached to a specific access
technology.  That *may* ensure that the multiple interface problem
doesn't occur in many cases (even this would require a serious warning
to that effect in the document), but, I don't see how that is also
fool-proof.  For instance, if the MN had multiple WLAN cards it wants to
simultaneously use, it could end up in problems.  

Especially with the way some of these systems may acquire the MN-ID, it
may be the AAA CUI or NAI, in which case, the same ID may be acquired by
the MAGs for all the interfaces of the MN. We then end up with a
situation where the LMA keeps overwriting the binding (since it only
keeps one entry per MN), while the MN sees the same address on its new
interface and decides to shut the interface down, effectively ending up
with no service.  This was described by Christian in one of his emails
and is a very realistic scenario.  

I don't believe we can hand wave on this issue and get somewhere with
the document.  I understand the importance of getting this document to
the IESG in a timely fashion, but, it is necessary to ensure that the
protocol works with normal, unmodified IP nodes.  

Regards,
Vidya

> Sent: Wednesday, September 26, 2007 9:06 AM
> To: ext Kilian Weniger
> Cc: [email-masked]
> Activating multiple interfaces is something that most devices 
> and hosts do already. However having the multiple interfaces 
> attach to MAGs which are served by a common LMA is. This is 
> what I was saying as being academic.
> 
> If the MAGs that the MN attaches to are associated with 
> different LMAs then it is not a problem. The issue is only 
> when both the MAGs are associated with the same LMA and this 
> may not be something that we want to focus on at the present 
> time or at least not in the context of this I-D.
> 
> Regarding your second point, do you believe that host 
> implementations will assign the same address to multiple 
> interfaces that they may receive via DHCP?
> 
> -Raj
> 
> 
> > At least it should be prevented that an unmodified host 
> ends up with 
> > the same address configured on multiple interfaces. I think 
> this can 
> >> While it is possible that a multi-interface MN can attach to 
> >> different MAGs which cause the MAGs to send a PBU to the 
> same LMA, I 
> >> personally think that dealing with this is more of an academic 
> >> exercise at the present time.
> >> 
> >> I do not believe we have the possibility of making any 
> changes to the 
> >> MN. So that route is closed... At least for now.
> >> 
> >> So here is how I view the current scenario which IMO is 
> academic at 
> >> this time and hence not something that we should be 
> spending a lot of 
> >> time on :
> >> 
> >> - If an MN attaches to multiple MAGs via different interfaces this 
> >> would trigger the MAGs to send PBUs to the LMA
> >> - If the LMA receives them almost simultaneously (as an 
> example), and 
> >> a PBAck has not been sent, then the LMA can choose to 
> create an entry 
> >> in the BC for the last received PBU and ACK only the last received 
> >> PBU (the LMA would believe that the MN which attached to 
> MAG1 moved 
> >> to
> >> MAG2 resulting in
> >> - If the MN receives a PBU from another MAG for an MN which has an 
> >> entry in the BC as a result of a second interface 
> attaching to a MAG, 
> >> the LMA would view this as the MN having moved to MAG2 and hence 
> >> would delete the BCE for
> >> But if we merely state (or mandate) that the LMA will only 
> have only 
> >> one MAG entry in the BC at any given time, we would not have a 
> >> problem with the multi-homing scenario, right?
> >> 
> >> -Raj
> >> 
> >> 
> >> 
> >> 
> >>>>>> - define LMA behavior such that regular multihomed IP devices 
> >>>>>> don't run into issues of connectivity or shutting down 
> >>>>>> interfaces.
> >>>> This is much
> >>>> One of the tenets of Netlmm protocol has been to not require any 
> >>>> changes or requirements on the MN. So it is not an option.
> >>>> 
> >>>> Issues that arise from multi-homing and how to deal with them 
> >>>> should be dealt separately and not in the scope of this I-D.
> >>>> 
> >>>> -Raj
> >>>> 
> >>>>> 
> >>>>> Kilian
> >>>>> 
> >>>>> 
> >>>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas 
> >>>>> Micke
> >>>>> 
> >>>>> 
> >>>>> 
> >>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: 
> Thomas Micke
> >>> 
> >>> 
> >> 
> >> 
> >> 
> > 
> >

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 26 Sep 2007 11:37:40 -0700 (PDT)

We dont have to add support for every feature in the base spec.
We split the IPv4 support just for the same reason. Why should
this be in the base spec ?

We can certainly add some text as Kilian was suggesting. But, we
cant get into the solution space.

If you can state what outcome you are expecting, that would be
good. If its some simple text, we can do that. That we already
agreed.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 26 Sep 2007 11:46:33 -0700

> multi-homing are out of scope for this document.

The LMA does not look at the interface, it only assigns home network 
prefixes based on the mobile node identifier. And the mobile node 
identifier might be the same irrespective of which interface the mobile 
node might be using.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 26 Sep 2007 11:50:00 -0700

The LMA has only one binding cache entry per mobile node at any time. So 
we never have a case where the MN with two interfaces is attached to two 
different MAGs, and both MAGs successfully create binding cache entries 
for the MN at the LMA. The LMA would only have one binding cache entry 
pointing to the MAG that sent the last proxy BU.

Vijay

Basavaraj Patil wrote:
>>>>> don't run
>>> should be

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 26 Sep 2007 11:57:32 -0700

Sri, 

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Wednesday, September 26, 2007 11:38 AM
> To: Narayanan, Vidya
> Cc: Basavaraj Patil; ext Kilian Weniger; [email-masked]

It is critical differentiate between a "feature" and a behavior in the
current spec that may break something on existing IP nodes.  Kilian
clearly articulated the differences here in the multihoming case.  We
are discussing the latter and that needs to be fixed.  

> We split the IPv4 support just for the same reason. Why 
> should this be in the base spec ?
> 
> We can certainly add some text as Kilian was suggesting. But, 
> we cant get into the solution space.
> 
> If you can state what outcome you are expecting, that would 
> be good. If its some simple text, we can do that. That we 
> already agreed.
> 

It is not a question of how simple the text is - it is a question of
what fixes the issue at hand.  I'll think about this a bit further and
send some suggestion later today. 

Thanks,
Vidya

> > The points you have raised are confusing to me.  I don't understand 
> > how stating that multihoming is out of scope and that operators can 
> > ensure multiple interfaces of the MN don't end up under the 
> same LMA 
> > is sufficient or even realistic.
> >
> > fool-proof.  For instance, if the MN had multiple WLAN 
> cards it wants 
> > to simultaneously use, it could end up in problems.
> >
> > Especially with the way some of these systems may acquire 
> the MN-ID, 
> > it may be the AAA CUI or NAI, in which case, the same ID may be 
> > acquired by the MAGs for all the interfaces of the MN. We 
> then end up 
> > with a situation where the LMA keeps overwriting the 
> binding (since it 
> > only keeps one entry per MN), while the MN sees the same address on 
> > its new interface and decides to shut the interface down, 
> effectively 
> > ending up with no service.  This was described by Christian 
> in one of 
> > his emails and is a very realistic scenario.
> >
> >> Activating multiple interfaces is something that most devices and 
> >> hosts do already. However having the multiple interfaces attach to 
> >> MAGs which are served by a common LMA is. This is what I 
> was saying 
> >> as being academic.
> >>
> >> If the MAGs that the MN attaches to are associated with different 
> >> LMAs then it is not a problem. The issue is only when both 
> the MAGs 
> >> are associated with the same LMA and this may not be 
> something that 
> >> we want to focus on at the present time or at least not in the 
> >> context of this I-D.
> >>
> implementations 
> >> will assign the same address to multiple interfaces that they may 
> >> receive via DHCP?
> >>
> >> -Raj
> >>
> >>

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 26 Sep 2007 14:15:33 -0700 (PDT)

Vidya,

> are discussing the latter and that needs to be fixed.

I think, we are just looking at this as an engineering problem.
A deployment has many aspects, we cannot just say, some operator
may plugin the device and the protocol will break. The base
spec does not support IPv4 addressing or IPv4 transport, if
some one drops in a device with IPv4 only stack, the base
protocol does not work. Same thing for multi-homing.

I'm not saying we should not support this scenario. I do not
think, we should try to do a hotch-potch solution in the base
spec and in the last minute. An extension doc is the way to
go. Lets add some reasonable warnings in this document and
leave it for other specs.

We also need to look at timelines. When draft-sgundave as
adopted as the WG doc, we did send the work items to the
chair and the AD to define the document scope. Number of
things including Auth Option, shared links ..were all listed.
This topic was never in scope. The same thing for Auth option,
we are stuck on this MN-Id, because Auth Option cant fit.
If some one wants to support Auth Option, sure, lets do it
as a new work item. Why bring these arguments on the need for
mobile node's Id. In a proxy model when a mobile is given
an address in a dynamic fashion, how else will the network
entities identify the mobile ? It must be there in signaling
messages.

Its logical to do these work items as seperate drafts and
not try to make them work magically in the current spec
and by opening new issues in the last minute. We can add
all these features, if we dont need to follow any timelines.

Sri

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Thu, 27 Sep 2007 07:24:25 +0900

Hi Vijay and Raj

When two MAGs sends PBU for multihomed-MN to the same LMA, one of MAG  
cannot detect the BCE change.
This is also problem for multihomed scenario, too.
Even if LMA keeps only one binding for MN,  MN may get the same home  
prefix from both MAGs at the same time.
MN, then, is no idea which interface should be selected for sending  
packet using HoA.

For example, while the binding of MN is registered,  LMA receives a  
PBU for the MN's second interface from new MAG and accepts it.
In this case, the old MAG cannot know the binding change triggered by  
the new MAG and continue serving the MN.
Because both MN's interfaces are active, both MAGs keep sending PBU  
and LMA overwrites the MN's binding between two MAGs.
As Kilian said in another thread, we may need notification message  
from LMA to MAG about BCE change (ex. revocation).

I think this is not academic issue.

ryuji@academia:-)

On 2007/09/27, at 3:50, Vijay Devarapalli wrote:

> The LMA has only one binding cache entry per mobile node at any  
> time. So we never have a case where the MN with two interfaces is  
> attached to two different MAGs, and both MAGs successfully create  
> binding cache entries for the MN at the LMA. The LMA would only  
> have one binding cache entry pointing to the MAG that sent the last  
> proxy BU.
>
> Vijay
>
> Basavaraj Patil wrote:
>> Kilian,
>> different MAGs
>> entry in

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 26 Sep 2007 16:42:59 -0700

Folks,
<Chair Hat On> 
It is our responsibility to ensure that the protocol does not break the
operation of regular IP nodes.  This is not a negotiable point and it is
not debatable.  This is not a feature, but, a primary part of ensuring
that the protocol is designed right.  

So, I don't believe we can forward this document to the IESG with issues
that will break regular IP connectivity of devices.  In no way or form
is it comparable to other "features" like IPv4 support that was left out
of the base document.  

Let's focus on fixing the problem. 

Vidya

> Sent: Wednesday, September 26, 2007 2:16 PM
> To: Narayanan, Vidya
> A deployment has many aspects, we cannot just say, some 
> operator may plugin the device and the protocol will break. 
> The base spec does not support IPv4 addressing or IPv4 
> transport, if some one drops in a device with IPv4 only 
> stack, the base protocol does not work. Same thing for multi-homing.
> 
> This topic was never in scope. The same thing for Auth 
> option, we are stuck on this MN-Id, because Auth Option cant fit.
> If some one wants to support Auth Option, sure, lets do it as 
> a new work item. Why bring these arguments on the need for 
> mobile node's Id. In a proxy model when a mobile is given an 
> address in a dynamic fashion, how else will the network 
> entities identify the mobile ? It must be there in signaling messages.
> 
> Its logical to do these work items as seperate drafts and not 
> try to make them work magically in the current spec and by 
> opening new issues in the last minute. We can add all these 
> features, if we dont need to follow any timelines.
> 
> Sri
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 26 Sep 2007 18:58:41 -0700

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Wednesday, September 26, 2007 4:43 PM
> To: Sri Gundavelli

I agree and realize your good intent. That is fine. Please
also note that it is also your responsibility to ensure the
protocol gets standardized in timely fashion. We are not
expecting some partially completed work to push it to the next
level. We have put lot of efforts and we believe the work is
complete. We responded to the review comments sent by many in
the WG, and we are more than happy to fix all the issues that
we agreed.

However, we are not delighted to deal with these new issues in
the last minute. This should been discussed in the WG prior
and a consensus should have been noted. Any case, lets wrap
this quickly. But, please avoid unwanted delays. There are many
SDO bodies that are watching this work. Please be sensitive to
that. We will greatly appreciate.

Additionally, the comments on MN-Id and the indirect goal of
supporting Auth Option, is not giving a clear clarity to an
innocent observer. If we want to support Auth Option, lets do
it the right way. 

There are also comments that are intended as hooks for enabling
some future work, in the form of creating a reference in this
document. This should be noted and clearly the comments from
people with such intent, should be discounted. Please make sure,
all of this is happening.

Lastly, I repeat, I do not see a reason why this feature for
supporting mobile nodes with multiple interface and for 
*Simultaneous* network access cannot be dealt in a separate
document.

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 26 Sep 2007 22:59:04 -0700

All,
Here is a description of the issue (I'm picking a simple scenario to
describe the issue; there are other scenarios as well; also, this has
been described on the list earlier): 

* MN has two interfaces attached to MAG1 and MAG2 under the same LMA
* Let's say MAG1 first created the binding at the LMA and acquired a
prefix/address for the MN, using MN-ID1
* MN obtains the prefix/address on Interface1
* MAG2 now sends a PBU with MN-ID1 also (very possible when the ID is
something like an NAI)
* LMA thinks the MN moved, updates the binding and returns the same
prefix for the MN to MAG2
* MN ends up with the same prefix/address on Interface2

At this point, if it is an IPv6 prefix, the MN may configure a different
address on Interface 2, but, we would have lost the point-to-point
nature and the associated properties of the MN-MAG link; if it is an
IPv6 or IPv4 address, the MN detects a duplicate address and shuts down
the interface from an IP point of view.  The MN thinks only Interface1
is active, while the LMA has a binding to MAG2 (corresponding to
Interface2 of the MN).  

Result: MN does not have any IP access via either of its interfaces.
Even if the MN has different addresses on the same prefix on its two
interfaces, Interface 1 cannot be used given LMA's state, but, the MN is
unaware of that. 

Some thoughts on avoiding this problem: 

It seems to me that this is an unavoidable problem if the same MN-ID is
sent for multiple interfaces of the MN to the LMA.  It seems like an
interface-specific ID (link layer address or equivalent) needs to be
included in the PBU, so that the LMA can ensure that the same
prefix/address is not assigned to multiple IP interfaces of an MN.  This
may not be too difficult, given that the MN-MAG link is point-to-point.

Thoughts? 

Thanks,
Vidya

---

From: "Genadi Velev" <[email-masked]>
Date: Thu, 27 Sep 2007 14:30:33 +0200

Hi Vidya,

I agree that there is an issue with multihomed MN attached to different
MAGs under the same LMA. First we need to differentiate between
scenarios where the multiple interfaces are of the same or different
access technologies. Scenario 1: if a MN has multiple interfaces of the
same technology (e.g. multiple WLAN cards), most probably the interfaces
would attempt to connect to the same access point which means to the
*same MAG*. Scenario 2: if the interfaces are of different access
technologies and the MAGs are serving a specific access technology, then
the interfaces are attached to *different MAGs*. I'm not exactly sure
what are the impacts in scenario 1, or if this scenario can be avoided
in managed networks (e.g. the network operator may not authorize the
attachment of the second interface). Any thoughts on scenario 1?

The following rows are considering merely scenario 2. 

> may not be too difficult, given that the MN-MAG link is 

If we look at the available options in PBU/PBA, we can see that next to
"NAI Option" (or "MN-ID option") we have a "Link-local Address Option".
Supposed that the link-local addresses of the multiple interfaces are
different, an LMA can differentiate among PBUs having the same MN-ID
option looking at the Link-local Address Option. IMHO, what we need to
specify in the PMIPv6 protocol is a behaviour in the LMA that the HNP is
not solely bound to a MN-ID but also to the link-local address. In this
way different HNPs would be assigned to PBUs (coming from different
MAGs) containing same MN-ID option but different link-local address
options.

thanks,
Genadi

> Sent: Thursday, September 27, 2007 7:59 AM
> To: Sri Gundavelli
> Cc: ext Kilian Weniger; [email-masked]

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 27 Sep 2007 07:03:09 -0700

> may not be too difficult, given that the MN-MAG link is 

This adds a limitation. A mobile node in a single access mode that
does a handoff between intefaces (access-1 to access-2), would loose
seamless roaming. It will loose the prefix.

There is no easy solution to this problem. It is impossible to
handle this scenario. Either, it requires some hooks on the MN side
or some complex handshake between LMA's and MAG's for MN presence
detection and also requires the L-2 technology on the MN-AR link to
provide some hooks for the MAG to page the node.

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 27 Sep 2007 07:07:47 -0700

Hi Genadi,
 
> MAGs) containing same MN-ID option but different link-local address

But, we need to allow handoff between two different interfaces (of
different access technologies), if we keep a relation to the LLA,
we cant do handoff. This scenario is more important than the scenario
of simultaneous multi-access.

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 27 Sep 2007 10:07:43 -0700

Hi Genadi,

> From: Genadi Velev [mailto:[email-masked]] 
> Sent: Thursday, September 27, 2007 5:31 AM
> To: Narayanan, Vidya
> Cc: ext Kilian Weniger; [email-masked]; Sri Gundavelli
> I agree that there is an issue with multihomed MN attached to 
> different MAGs under the same LMA. First we need to 
> differentiate between scenarios where the multiple interfaces 
> are of the same or different access technologies. Scenario 1: 
> if a MN has multiple interfaces of the same technology (e.g. 
> multiple WLAN cards), most probably the interfaces would 
> attempt to connect to the same access point which means to 
> the *same MAG*. Scenario 2: if the interfaces are of 
> different access technologies and the MAGs are serving a 
> specific access technology, then the interfaces are attached 
> to *different MAGs*. I'm not exactly sure what are the 
> impacts in scenario 1, or if this scenario can be avoided in 
> managed networks (e.g. the network operator may not authorize 
> the attachment of the second interface). Any thoughts on scenario 1?
> 

Actually, I don't think we can guarantee that two interfaces of the same
access technology are attached to the same MAG.  The RF characteristics
(including, say, types of antennas on each one, which may well differ
between two interfaces of the same technology) could end up with the MN
attaching to say, two different base stations or access points going to
different MAGs.  It also gets into how do we define a particular
technology - for instance, is WLAN an access technology or are
802.11a/b/g/n all different access technologies?  So, this is too tricky
to be making that assumption here. 

> > It seems to me that this is an unavoidable problem if the 
> same MN-ID 
> > is sent for multiple interfaces of the MN to the LMA.  It 
> seems like 
> > an interface-specific ID (link layer address or equivalent) 
> needs to 
> > be included in the PBU, so that the LMA can ensure that the same 
> > prefix/address is not assigned to multiple IP interfaces of an MN.  
> > This may not be too difficult, given that the MN-MAG link is 
> > point-to-point.
> 
> If we look at the available options in PBU/PBA, we can see 
> that next to "NAI Option" (or "MN-ID option") we have a 
> "Link-local Address Option".
> Supposed that the link-local addresses of the multiple 
> interfaces are different, an LMA can differentiate among PBUs 
> having the same MN-ID option looking at the Link-local 
> Address Option. IMHO, what we need to specify in the PMIPv6 
> protocol is a behaviour in the LMA that the HNP is not solely 
> bound to a MN-ID but also to the link-local address. In this 
> MAGs) containing same MN-ID option but different link-local 
> address options.
> 

Hmmm.. Can the LLA ever be the same over both interfaces?  Given that
the MN-MAG link is a point-to-point link, I would think it may be the
same.. If we can guarantee uniqueness of the LLA, that may work. But,
I'm not sure. 

Regards,
Vidya

> > At this point, if it is an IPv6 prefix, the MN may configure a 
> > different address on Interface 2, but, we would have lost the 
> > point-to-point nature and the associated properties of the MN-MAG 
> > link; if it is an
> > IPv6 or IPv4 address, the MN detects a duplicate address and shuts 
> > down the interface from an IP point of view.  The MN thinks only 
> > Interface1 is active, while the LMA has a binding to MAG2 
> > (corresponding to
> > Interface2 of the MN).  
> > 
> > interfaces, Interface 1 cannot be used given LMA's state, 
> but, the MN 
> > is unaware of that.
> > 
> > It seems to me that this is an unavoidable problem if the 
> same MN-ID 
> > is sent for multiple interfaces of the MN to the LMA.  It 
> seems like 
> > an interface-specific ID (link layer address or equivalent) 
> needs to 
> > be included in the PBU, so that the LMA can ensure that the same 
> > prefix/address is not assigned to multiple IP interfaces of an MN.  
> > This may not be too difficult, given that the MN-MAG link is 
> > point-to-point.
> > 
> > 
> > Thoughts? 
> > 
> > Thanks,
> > Vidya
> >

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 27 Sep 2007 10:10:01 -0700

Hi Sri,
I hope this is not news to anyone, but, we are not chartered to solve
inter-interface handoffs in the WG at the moment.  This is what our
charter states:

"The protocol will not attempt to hide handover
between two separate interfaces on the mobile node. " 

Inter-technology handoffs being a tricky problem to handle with NETLMM
was identified in the early stages of charter creation.  So, that is not
a limitation for considering some interface-specific identity to be
included in the PBU.  

Hope that helps. 

Regards,
Vidya 

> Sent: Thursday, September 27, 2007 7:08 AM
> To: 'Genadi Velev'; Narayanan, Vidya
> Cc: 'ext Kilian Weniger'; [email-masked]
> that next 
> > to "NAI Option" (or "MN-ID option") we have a "Link-local Address 
> > Option".
> interfaces are 
> > specify in the PMIPv6 protocol is a behaviour in the LMA 
> that the HNP 
> > is not solely bound to a MN-ID but also to the link-local 
> address. In 
> > this way different HNPs would be assigned to PBUs (coming from 
> > different
> But, we need to allow handoff between two different 
> interfaces (of different access technologies), if we keep a 
> relation to the LLA, we cant do handoff. This scenario is 
> more important than the scenario of simultaneous multi-access.
> 
> Sri
> 
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 27 Sep 2007 10:26:19 -0700

Hi Vidya,

That's interesting. We dont allow inter-interface handoff,
but we want to deal with multi-interface support issues ?
We dont have to do any thing for supporting the former and
the later requires some work.

The charter also does not talk about multi-homing and I
wonder if our decision to deal with this issue, is the
right one. We may need some clarification from Jari on
this.
	
IMO, if we really think, this breaks the protocol,
operator has the tools to deal with this. If a deployment
has to support multi-homing, there are number of things
that have to be place, including accounting system and
other things. The operator has the knobs to control this
aspect, it can be avoided in many different ways.

Not sure, what other solution we have.

Sri

> Sent: Thursday, September 27, 2007 10:10 AM
> To: Sri Gundavelli; Genadi Velev

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 27 Sep 2007 10:31:53 -0700

Sri,
You seem to be missing the point.  We are not dealing with
multi-interface support issues in this thread.  What we are dealing with
is the fact that an MN may not be able to use *any* interface simply
because it happens to have two interfaces.  Unless the MN knows that the
network is using PMIP and hence, it can only use one interface at a
time, you are going to have regular IP nodes that run into this problem.

In a nutshell, the problem is about an MN ending up with no IP service
using even one of its interfaces.  

I hope you can see that the problem doesn't relate to providing
multihoming to the MN; rather it relates to something far more
fundamental that this protocol is supposed to ensure - IP connectivity
to the MN. 

Vidya 

> Sent: Thursday, September 27, 2007 10:26 AM
> To: Narayanan, Vidya; 'Genadi Velev'
> wonder if our decision to deal with this issue, is the right 
> one. We may need some clarification from Jari on this.
> 	
> IMO, if we really think, this breaks the protocol, operator 
> has the tools to deal with this. If a deployment has to 
> support multi-homing, there are number of things that have to 
> be place, including accounting system and other things. The 
> operator has the knobs to control this aspect, it can be 
> avoided in many different ways.
> 
> > "The protocol will not attempt to hide handover between two 
> separate 
> > interfaces on the mobile node. "
> > 
> > was identified in the early stages of charter creation.  
> So, that is 
> > not a limitation for considering some interface-specific 
> identity to 
> > be included in the PBU.
> > 
> > Hope that helps. 
> > 
> > Regards,
> > Vidya
> > 
> interfaces (of 
> > > different access technologies), if we keep a relation to 
> the LLA, we 
> > > cant do handoff. This scenario is more important than the 
> scenario

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 27 Sep 2007 12:37:48 -0500

Vidya,

Just for my education, can you please explain why the MN would shutdown both
interfaces if it were to receive the same prefix on another interface on a
multi-interface host?
I guess I could dig up the archives... But if you can explain the issue
behind such behavior, I would appreciate it.

-Raj

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 27 Sep 2007 10:52:31 -0700

Vidya,

We are not dealing with
> because it happens to have two interfaces. 

If we are not dealing with multi-interface support, we dont
need to talk about the scenario where the MN has multiple active
interfaces. This is not the right interpretation of the charter,
IMHO.

If operators want to deal with this, let them configure a unique
NAI for each interface and even when multiple interfaces are
active, each interface will endup with a unique prefix.

Sri

> Sent: Thursday, September 27, 2007 10:32 AM

---

From: "Mohamed Khalil" <[email-masked]>
Date: Thu, 27 Sep 2007 13:51:47 -0500

Hi Raj,

I think an IPv6 node with unmodified IPv6 stack, should not be allowing
more than one interface to configure the same address configuration or
share the same onlink prefix. So the interface who tries to claim the
ownership of a prefix who is assigned to another interface will shut
down but not the original owner.
-----Original Message-----
From: Basavaraj Patil [mailto:[email-masked]] 
Sent: Thursday, September 27, 2007 12:38 PM
To: ext Narayanan, Vidya; Sri Gundavelli; Genadi Velev
Cc: ext Kilian Weniger; [email-masked]
Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs

Vidya,

Just for my education, can you please explain why the MN would shutdown
both interfaces if it were to receive the same prefix on another
interface on a multi-interface host? I guess I could dig up the
archives... But if you can explain the issue behind such behavior, I
would appreciate it.

-Raj

On 9/27/07 12:31 PM, "ext Narayanan, Vidya" <[email-masked]> wrote:

> multi-interface support issues in this thread.  What we are dealing 
> with is the fact that an MN may not be able to use *any* interface 
> simply because it happens to have two interfaces.  Unless the MN knows

> that the network is using PMIP and hence, it can only use one 
> interface at a time, you are going to have regular IP nodes that run 
> into this problem.
> 
>

---

From: "Mohamed Khalil" <[email-masked]>
Date: Thu, 27 Sep 2007 14:16:51 -0500

Raj, Q to u, how MIP6 handle the issue of multihoming? 

-----Original Message-----
From: Khalil, Mohamed (RICH2:2S20) 
Sent: Thursday, September 27, 2007 1:52 PM
To: Basavaraj Patil; ext Narayanan, Vidya; Sri Gundavelli; Genadi Velev
Cc: ext Kilian Weniger; [email-masked]
Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs

Hi Raj,

down but not the original owner. -----Original Message-----

Vidya,

-Raj

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 27 Sep 2007 13:10:58 -0700

Hi Raj,
In the example I wrote, the MN doesn't shut down both its interfaces.
It thinks Interface 1 is operational and has shutdown Interface 2 due to
a duplicate address.  However, the LMA only has a binding corresponding
to Interface 2 - so, the fact that the MN thinks it can use Interface 1
is not useful, since it really cannot send/receive any packets through
it.  As a result, the MN has no IP connectivity. 

Hope that clarifies. 

Vidya 

> Sent: Thursday, September 27, 2007 10:38 AM
> To: Narayanan, Vidya; Sri Gundavelli; Genadi Velev
> Just for my education, can you please explain why the MN 
> would shutdown both interfaces if it were to receive the same 
> prefix on another interface on a multi-interface host?
> I guess I could dig up the archives... But if you can explain 
> the issue behind such behavior, I would appreciate it.
> 
> -Raj
> 
> 
> > interface at a time, you are going to have regular IP nodes 
> that run into this problem.
> > 
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 27 Sep 2007 20:07:46 -0700

> it.  As a result, the MN has no IP connectivity. 

The above situation is recoverable. MAG2 would detect that the MN is no 
longer attached to it and send a de-registration proxy BU. LMA deletes 
the binding cache entry. Eventually MAG1 re-transmits the proxy BU and 
creates a new binding update at the LMA. The MN can now send/receive 
packets on interface 1.

Having a binding revocation mechanism will help in recovering sooner. 
The LMA would have sent a revocation mechanism to MAG1 when MAG2 sent a 
proxy BU. MAG1 would check if the MN is still attached, if yes would 
send a proxy BU again. MAG2 won't try to send a proxy BU once the mobile 
node's interface 2 goes down.

Vijay

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Fri, 28 Sep 2007 13:18:42 +0200

Hi Sri,

Sri> This adds a limitation. A mobile node in a single access mode that does a handoff between intefaces (access-1 to access-2), would loose seamless roaming. It will loose the prefix.

[FDJ] Not necessarily.
I can understand Vidya's proposal by making an analogy with DHCPv4.
In DHCPv4 the client adds "chaddr" in the DHCP messages, and the DHCP Server can use this information to allocate different IP@.

In PMIP6, the MAG (analogy to DHCP cleint) should add a link-indentifier of the MN, so that the LMA (analogy with DHCP Server) may allocate a different IP@.
Different interfaces would have different link identifiers (somehow required to be able to perform access authentication).
Note that such link identifier would be permanent for the same interface (i.e. it's not the LLA).

At first look, the proposed solution seems fine to me.
In .16 such link identifier would be a IEEE 802 MAC@, I presume there's a valid identifier in other link technologies.

On a side note and as FMI, Vidya's problem statement includes that a host with multiple interfaces will shutdown one of them when it sees a duplicated IP@.
May I ask where such behavior is defined?
It is rather constraining when thinking of multiple technologies and make-before-break.

Regards

federico

-----Message d'origine-----
De : Sri Gundavelli [mailto:[email-masked]] 
Envoyé : jeudi 27 septembre 2007 16:03
À : 'Narayanan, Vidya'
Cc : 'ext Kilian Weniger'; [email-masked]
Objet : RE: [netlmm] Issue: Prefix allocation and multihomed MNs

> It seems to me that this is an unavoidable problem if the same MN-ID 
> is sent for multiple interfaces of the MN to the LMA.  It seems like 
> an interface-specific ID (link layer address or equivalent) needs to 

Sri

---

From: "Genadi Velev" <[email-masked]>
Date: Fri, 28 Sep 2007 13:19:40 +0200

Hi Sri,
 
I see your point: handover between two different interfaces shall not be
supported in the base spec. This was also my understanding until Vidya,
Kilian and others raised the problem. Hence, I suggested the modified
behaviour in the LMA. After the recent discussions on this thread I tend
to think that we need to prevent a handoff between two different
interfaces in the base spec (rather than allowing/supporting this
handover). Supporting this handover and multihoming  can be done later
in a separate doc. 

I can think about several approaches to overcome this issue:
1) we can specify that the network operator shall take care of
preventing that a MN attaches with 2 interfaces to a PMIP domain (at
least to the same LMA). For example, the operator doesn't allow
attachment (i.e. authorization) of interface 2, since interface 1 is
still attached.
2) we can write a short text in the draft that the network operator
shall take care about assignment of different MN-ID (NAI) to different
interfaces during attachment procedure. 
3) we can describe how the current protocol behaves when a MN attempts
to attach with two interfaces. Similar to what is explained in Vijay's
email:
http://www1.ietf.org/mail-archive/web/netlmm/current/msg03483.html
4) we can go further and specify a procedure in the LMA: LMA doesn't
accept PBU from a new MAG, if the PBU contains same MN-ID option but
different LLA option which were received by old MAG.

Maybe somebody can think of another approaches?

Anyway, I think that we have to include some text in the base spec
covering this issue.

Genadi

> Sent: Thursday, September 27, 2007 4:08 PM
> To: 'Genadi Velev'; 'Narayanan, Vidya'
> > that next to

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Fri, 28 Sep 2007 13:41:01 +0200

Hi Sri,

I have seen several times now statements that the LMA would only have one binding per MN.
I'm a bit puzzled by this.

In MIP6 AFAIK the HA may have multiple bindings per MN (multiple CoA) but only one of them is primary.
The statement that there's only one single binding per MN makes me think that this feature is not supported by PMIP6.
Has this been discussed earlier? If yes I'll dig up the archives to catch up.

Thanks

federico

-----Message d'origine-----
De : Basavaraj Patil [mailto:[email-masked]] 
Envoyé : mercredi 26 septembre 2007 16:15
À : ext Kilian Weniger
Cc : [email-masked]
Objet : Re: [netlmm] Issue: Prefix allocation and multihomed MNs

Kilian,

While it is possible that a multi-interface MN can attach to different MAGs which cause the MAGs to send a PBU to the same LMA, I personally think that dealing with this is more of an academic exercise at the present time.

I do not believe we have the possibility of making any changes to the MN. So that route is closed... At least for now.

So here is how I view the current scenario which IMO is academic at this time and hence not something that we should be spending a lot of time on :

- If an MN attaches to multiple MAGs via different interfaces this would trigger the MAGs to send PBUs to the LMA
- If the LMA receives them almost simultaneously (as an example), and a PBAck has not been sent, then the LMA can choose to create an entry in the BC for the last received PBU and ACK only the last received PBU (the LMA would believe that the MN which attached to MAG1 moved to MAG2 resulting in the transmission of PBUs from MAG1 and MAG2 near simulatenously)
- If the MN receives a PBU from another MAG for an MN which has an entry in the BC as a result of a second interface attaching to a MAG, the LMA would view this as the MN having moved to MAG2 and hence would delete the BCE for
MAG1 and insert MAG2 for the MN

But if we merely state (or mandate) that the LMA will only have only one MAG entry in the BC at any given time, we would not have a problem with the multi-homing scenario, right?

-Raj

On 9/26/07 8:10 AM, "ext Kilian Weniger" <[email-masked]>
wrote:

> 2. preventing that PMIP protocol breaks if an unmodified host 
> activates more than one network interface.
> 
> For case 1, I agree with you that this is out of scope of the base 
> draft and should be handled in a separate multi-homing document.
> 
> activates more than one network interface and happens to attach to 
> more than one MAG of a given PMIP domain simultaneously:
> PBUs to the LMA for the same MN. This may result in packet loss both 
> in downlink and uplink.
> However, I'm not sure how we can solve this issue without modifying 
> the host or mandating not to use multiple interfaces. Any ideas?
> 
> BR,
> 
> Kilian
> 
> 
>>>> - define LMA behavior such that regular multihomed IP devices don't 
>>>> run into issues of connectivity or shutting down interfaces.
>> This is much
>> Issues that arise from multi-homing and how to deal with them should 
>> be dealt separately and not in the scope of this I-D.
>> 
>> -Raj
>> 
>>> 
>>> Kilian
>>> 
>>> 
>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke
>>> 
>>> 
>>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 28 Sep 2007 04:48:54 -0700

> Has this been discussed earlier? If yes I'll dig up the archives to catch up.

Multiple CoA support is only possible through monami6. Currently we 
don't support that with PMIPv6. The base PMIPv6 document assumes there 
is only MAG registered with the LMA at a time for a particular mobile node.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Sep 2007 14:06:27 +0200

Vijay Devarapalli wrote:
>> I have seen several times now statements that the LMA would only
>> have one binding per MN. I'm a bit puzzled by this.
>> 
>> In MIP6 AFAIK the HA may have multiple bindings per MN (multiple
>> CoA) but only one of them is primary. The statement that there's
>> only one single binding per MN makes me think that this feature is
>> not supported by PMIP6. Has this been discussed earlier? If yes
>> I'll dig up the archives to catch up.
> 
> don't support that with PMIPv6. The base PMIPv6 document assumes
> there is only MAG registered with the LMA at a time for a particular
> mobile node.

That is a problem.

MIP6 allows the MN to use two different interfaces, each with a
different HoA.  Monami6 is not needed for that MIP6 to work.

One can't require Monami6 for PMIP6 in order for a MN to use two interfaces.

PMIP6 relying its identifications on a unique 'MN-Id' for the mobile is
not good.  If the MN could have several such MN-Ids, each attached to an
interface then PMIP6 relying on MN-Id concept could work.  In this
sense, the easiest way for MN-Id is to actually be an address.

Alex

> 
> Vijay
> 
>> 
>> Thanks
>> 
>> federico
>> 
>> 
>> 
>> -----Message d'origine----- De : Basavaraj Patil
>> [mailto:[email-masked]] Envoyé : mercredi 26 septembre
>> 2007 16:15 À : ext Kilian Weniger Cc : [email-masked] Objet : Re:
>> [netlmm] Issue: Prefix allocation and multihomed MNs
>> 
>> 
>> Kilian,
>> 
>> different MAGs which cause the MAGs to send a PBU to the same LMA,
>> I personally think that dealing with this is more of an academic
>> I do not believe we have the possibility of making any changes to
>> the MN. So that route is closed... At least for now.
>> 
>> So here is how I view the current scenario which IMO is academic at
>>  this time and hence not something that we should be spending a lot
>> of time on :
>> 
>>  would trigger the MAGs to send PBUs to the LMA - If the LMA
>> receives them almost simultaneously (as an example), and a PBAck
>> has not been sent, then the LMA can choose to create an entry in
>> the BC for the last received PBU and ACK only the last received PBU
>>  (the LMA would believe that the MN which attached to MAG1 moved to
>>  MAG2 resulting in the transmission of PBUs from MAG1 and MAG2 near
>>  simulatenously) - If the MN receives a PBU from another MAG for an
>> MN which has an entry in the BC as a result of a second interface
>> attaching to a MAG, the LMA would view this as the MN having moved
>> to MAG2 and hence would delete the BCE for MAG1 and insert MAG2 for
>> the MN
>> 
>> But if we merely state (or mandate) that the LMA will only have
>> only one MAG entry in the BC at any given time, we would not have a
>> On 9/26/07 8:10 AM, "ext Kilian Weniger" 
>> <[email-masked]> wrote:
>> 
>>> Hi Raj,
>>> 
>>> I think we should differentiate between two cases: 1. supporting
>>> multi-homing requested by the host to achieve features like load
>>> balancing, failover etc. 2. preventing that PMIP protocol breaks
>>> if an unmodified host activates more than one network interface.
>>> 
>>> For case 1, I agree with you that this is out of scope of the
>>> base draft and should be handled in a separate multi-homing
>>> document.
>>> 
>>> But I think Vidya was talking about case 2 and I agree that this
>>>  issue should be addressed in the base draft.
>>> 
>>> Currently, I see the following potential issues if an unmodified
>>> host activates more than one network interface and happens to
>>> attach to more than one MAG of a given PMIP domain
>>> simultaneously: - multiple MN interfaces get the same prefix
>>> assigned, which may break something (e.g., routing) in the host
>>> and may result in loss of connectivity - BCE at LMA constantly
>>> and randomly changes since multiple MAGs send PBUs to the LMA for
>>> the same MN. This may result in packet loss both in downlink and
>>> uplink. - the MAGs may discover and use different LMA addresses
>>> for the same host etc.
>>> 
>>> However, I'm not sure how we can solve this issue without
>>> modifying the host or mandating not to use multiple interfaces.
>>> Any ideas?
>>> 
>>> BR,
>>> 
>>> Kilian
>>> 
>>> 
>>>> -----Original Message----- From: Basavaraj Patil
>>>> [mailto:[email-masked]] Sent: Mittwoch, 26. September
>>>> 2007 13:50 To: ext Kilian Weniger; Narayanan, Vidya Cc:
>>>> [email-masked] Subject: Re: [netlmm] Issue: Prefix allocation
>>>> and multihomed MNs
>>>> 
>>>> 
>>>> Kilian,
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 9/26/07 3:57 AM, "ext Kilian Weniger" 
>>>> <[email-masked]> wrote:
>>>> 
>>>>> Hi Vidya,
>>>>> 
>>>>>> - define LMA behavior such that regular multihomed IP
>>>>>> devices don't run into issues of connectivity or shutting
>>>>>> down interfaces.
>>>> This is much
>>>>> the MAG learn that ID? Note that the MN's link-local address
>>>>> may not work as an ID in general, since the MN may implement
>>>>> a kind
>>>> of virtual
>>>>> may result in the same link-local address for multiple
>>>>> physical interfaces.
>>>>> 
>>>> One of the tenets of Netlmm protocol has been to not require
>>>> any changes or requirements on the MN. So it is not an option.
>>>> 
>>>>> Panasonic R&D Center Germany GmbH 63225 Langen, Hessen,
>>>>> Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing
>>>>> Director: Thomas Micke
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________ netlmm
>>>>> mailing list [email-masked] 
>>> Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany 
>> _______________________________________________ netlmm mailing list
>>  [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
>> 
>> 
>> _______________________________________________ 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: "Kilian Weniger" <[email-masked]>
Date: Fri, 28 Sep 2007 14:11:05 +0200

Hi Vijay,

> node's interface 2 goes down.

I couldn't find any text in draft-muhanna-mip6-binding-revocation-01.txt
that says that a MAG should send a new PBU after receiving Binding
Revocation Indication (BRI) msg. 

According to current text, MAG1 would clean up ressources and unicast RA
message to the MN local link IP address with the home network prefix
lifetime is set to zero.

"3.2.2.  Use Case No. 2: LMA to MAG

   In this case, LMA MAY send a BRI message to the MAG, hosting a
   specific MN mobile IPv6 session, to indicate that the mobile IPv6
   binding of a specific MN session, which is registered and anchored at
   the LMA, has been revoked and MAG can clean up the associated
   resources.  If the MAG processes the BRI message, the MAG MUST send a
   BRA message in response to the LMA if the A bit in the BRI message is
   set.  In this case, the MAG SHOULD send a unicast RA message to the
   MN local link IP address with the home network prefix lifetime is set
   to zero."

I guess what you proposed requires changes to the revocation message
format (e.g., a new flag in the BRI) and processing of revocation
messages, right? 

BR,

Kilian

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 28 Sep 2007 05:31:49 -0700

> Revocation Indication (BRI) msg. 

When the MAG gets a revocation, it obviously checks if the MN is still 
attached. It is true that draft-muhanna-mip6-binding-revocation-01, but 
then the revocation draft is a "work in progress". :)

Vijay

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 28 Sep 2007 22:04:17 +0900

On 2007/09/28, at 20:48, Vijay Devarapalli wrote:

>> CoA) but only one of them is primary.
>> The statement that there's only one single binding per MN makes me  
>> think that this feature is not supported by PMIP6.
> there is only MAG registered with the LMA at a time for a  
> particular mobile node.

Right. and MCoA is out of scope in netlmm.
Even if PMIP work with MCoA, MN cannot utilize the same HoA to two  
interfaces...
I am not sure it is useful to consider MCoA here.

ryuji

>> De : Basavaraj Patil [mailto:[email-masked]] Envoyé :  
>> mercredi 26 septembre 2007 16:15
>> À : ext Kilian Weniger
>> Cc : [email-masked]
>> So here is how I view the current scenario which IMO is academic  
>> at this time and hence not something that we should be spending a  
>> lot of time on :
>> - If the LMA receives them almost simultaneously (as an example),  
>> and a PBAck has not been sent, then the LMA can choose to create  
>> an entry in the BC for the last received PBU and ACK only the last  
>> received PBU (the LMA would believe that the MN which attached to  
>> MAG1 moved to MAG2 resulting in the transmission of PBUs from MAG1  
>> and MAG2 near simulatenously)
>> entry in the BC as a result of a second interface attaching to a  
>> MAG, the LMA would view this as the MN having moved to MAG2 and  
>> hence would delete the BCE for
>> only one MAG entry in the BC at any given time, we would not have  
>> a problem with the multi-homing scenario, right?
>> -Raj
>>> 1. supporting multi-homing requested by the host to achieve  
>>> features like load balancing, failover etc.
>>> attach to more than one MAG of a given PMIP domain simultaneously:
>>> - multiple MN interfaces get the same prefix assigned, which may  
>>> break something (e.g., routing) in the host and may result in  
>>> loss of connectivity
>>> - BCE at LMA constantly and randomly changes since multiple MAGs  
>>> send PBUs to the LMA for the same MN. This may result in packet  
>>> loss both in downlink and uplink.
>>> - the MAGs may discover and use different LMA addresses for the  
>>> same host etc.
>>>
>>>>> may not work as an ID in general, since the MN may implement a  
>>>>> kind
>>>> of virtual

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 28 Sep 2007 22:08:16 +0900

Hi Sri

> active, each interface will endup with a unique prefix.

I think this is one way to avoid this multi-interface issue.
You can mention in the doc that MN should have different NAI per  
interfaces
if it has multiple interfaces attached to the PMIP domain.

regards,
ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Sep 2007 15:17:51 +0200

RYUJI WAKIKAWA wrote:
>>> multi-interface support issues in this thread.  What we are 
>>> dealing with is the fact that an MN may not be able to use *any*
>>> interface simply because it happens to have two interfaces.
>> 
>> If we are not dealing with multi-interface support, we dont need to
>> talk about the scenario where the MN has multiple active 
> I think this is one way to avoid this multi-interface issue. You can
> mention in the doc that MN should have different NAI per interfaces 

I think this can be made to work.  But it sounds unnatural.  An 
interface is identified by an address, or sometimes a number, and a user 
is identified by a NAI.

Alex

PS: especially this is an issue because HA tries to assign the HNP to
     the MN, at MAG.  This is a problem too.  The HA shouldn't try to
     assign addresses or HNPs in the PMIP6 signalling, for MN.  And it
     should continue keeping BCE entries as usual in MIP6.

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 28 Sep 2007 07:03:40 -0700 (PDT)

Hi Federico,

That is correct. We do not support simultaneous bindings. This
was discussed in the ML before.

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 28 Sep 2007 07:15:20 -0700 (PDT)

Hi Genadi,

Please see inline.

> http://www1.ietf.org/mail-archive/web/netlmm/current/msg03483.html

I'm ok with any of the above three options. We can certainly document
the scenario and close the issue. I do no think, we should try to
solve this problem here or use this issue to explicitly add text to
block the inter-access handoff, we did not do any thing to support that
scenario. When the charter says, its out of scope, we dont need to solve
all the issues, when the scenario is enabled. Operators can solve this
issue, these are managed deployments. Its not a like a consumer buying a
device and turning it on at home. So, I agree with your above three
suggested options.

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 28 Sep 2007 07:16:57 -0700 (PDT)

Hi Ryuji,

>> > dealing with
> You can mention in the doc that MN should have different NAI per interfaces

Sure. We can probably document this, as Genadi suggested.

Regards
Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 28 Sep 2007 07:57:09 -0700

> On a side note and as FMI, Vidya's problem statement includes 
> that a host with multiple interfaces will shutdown one of 
> them when it sees a duplicated IP@.

No where, as far as I know. It is perfectly valid to configure
two interfaces on the same subnet/prefix. Each interface will
obtain a different address, when using SLAAC or using DHCPv6.
But, it is invalid to enable ip.forwarding in such scenario.
In other words, a host can do this, but not a router. 

You can try that out using your Linux or Windows machine.

I do not agree we should discuss about multi-homing and so
I'm ok to add some text and move on.  

Sri

---

From: "Genadi Velev" <[email-masked]>
Date: Fri, 28 Sep 2007 17:59:24 +0200

Hi Sri,

it seems that we converge on this issue :-)

I was also agnostic on any of the initial options 1-4.  Of course the
simplest way to go forward is to describe options 1 and 2. The operator
can choose between not allowing multiple interfaces to be simultaneously
attached (option 1) or to support multiple interfaces to be attached but
assuring that different MN-ID is assigned to each interface.  

Option 3 still needs to be worked out in
draft-muhanna-mip6-binding-revocation-01, as discussed by Kilian and
Vijay. So, we can leave it out for the base PMIP specification. 

Genadi

> Sent: Friday, September 28, 2007 4:15 PM
> To: Genadi Velev
> Cc: Narayanan, Vidya; ext Kilian Weniger; [email-masked]

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 28 Sep 2007 11:39:06 -0500

I don't know if we have really converged ;)

Two questions: 
1. How can you prevent a device from attaching via multiple interfaces
simultaneously? Are you suggesting that within the scope of a PMIP6 domain,
you could potentially verify (at AAA level or some such thing) if an MN is
already attached via another interface and hence prevent it from attaching
via the second interface?

2. How do you ensure that variable MN-IDs are used depending on the
interface used by the host to attach to a network?

An MN which attaches via different interfaces simultaneously to a PMIP6
domain will result in the LMA having a BCE for the last received PBU. Host
behavior when multiple interfaces have the same address is unspecified and
we can just leave it at that. In the context of this document, we do not
need to solve it.

-Raj

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 28 Sep 2007 14:14:12 -0700

> if it has multiple interfaces attached to the PMIP domain.

In a practical deployment there is typically just one identity for the 
user with all the subscription information stored against this identity.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 28 Sep 2007 14:16:47 -0700

Thanks, Raj, for capturing the questions :) Just catching up with all
the emails, these are exactly the questions I arrived at as well.  These
are important questions to answer.  Some thoughts inline.  

> Sent: Friday, September 28, 2007 9:39 AM
> To: ext Genadi Velev; Sri Gundavelli
> 1. How can you prevent a device from attaching via multiple 
> interfaces simultaneously? Are you suggesting that within the 
> scope of a PMIP6 domain, you could potentially verify (at AAA 
> level or some such thing) if an MN is already attached via 
> another interface and hence prevent it from attaching via the 
> second interface?
> 

I think the above is very tricky and it is also quite difficult to
detect the difference between movement and a second interface in
practical scenarios.  For instance, not all systems go back to the AAA
upon every attachment (even assuming a AAA-enabled system, which itself
is not a constraint for PMIPv6).  So, the state that a AAA has may only
be as broad as which administrative domain the MN is presently at, not
exactly at which MAG.  Going down that path seems difficult to me.
Several AAA functions, including accounting, may be aggregated at some
middle point in the network, which further makes this detection
difficult. 

> 2. How do you ensure that variable MN-IDs are used depending 
> on the interface used by the host to attach to a network?
> 

If we left the MN-ID to be anything (e.g., an NAI), I don't believe we
can ensure this.  This is exactly identical to the DHCP analogy made
earlier in this thread by Federico.  When a DHCP client wishes to
acquire a routable IP address on multiple interfaces, it uses a
different client ID for each interface.  This situation is not
different, except that the network is trying to automatically obtain an
address for the MN.  So, I think we are back to having an
interface-specific ID as the MN-ID.  

> An MN which attaches via different interfaces simultaneously 
> to a PMIP6 domain will result in the LMA having a BCE for the 
> last received PBU. Host behavior when multiple interfaces 
> have the same address is unspecified and we can just leave it 
> at that. In the context of this document, we do not need to solve it.
> 

I don't get this part though.  Given that there isn't a practical way
for the network to determine if the MN is attaching to multiple MAGs or
just one (I can imagine somewhat more complicated ways of figuring that
out with additional help from the lower layers, but, we can't rely on
that), if we left it unsolved, that just means that an MN which happens
to have multiple interfaces may suffer lack of IP connectivity or
toggling/intermittent connectivity.  So, I think we do need to state
that the MN-ID used must be interface-specific.  How a system ensures
that the ID used is interface-specific doesn't need to be mandated. 

Vidya

> > simplest way to go forward is to describe options 1 and 2. The 
> > operator can choose between not allowing multiple interfaces to be 
> > simultaneously attached (option 1) or to support multiple 
> interfaces 
> > to be attached but assuring that different MN-ID is 
> assigned to each interface.
> > 
> >> block the inter-access handoff, we did not do any thing to support 
> >> that scenario. When the charter says, its out of scope, we 
> dont need 
> >> to solve all the issues, when the scenario is enabled. 
> Operators can 
> >> solve this issue, these are managed deployments. Its not a like a 
> >> consumer buying a device and turning it on at home. So, I 
> agree with 
> >> your above three suggested options.
> >> 
> >> Regards
> >> Sri
> >> 
> >> 
> >> 
> >> 
> > 
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 28 Sep 2007 14:17:58 -0700

Using two different identifiers on two different interfaces is a 
non-starter. The MN might just not have two different identifiers to use.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 28 Sep 2007 15:21:16 -0700

We are just talking about equivalents of link-layer IDs here.  The MN
will have a different link ID on each of its interfaces.  Actually, the
MN here has to do nothing.  The MAG needs to pick up an interface
specific identity for the MN - e.g., use its MAC address or something
equivalent. 

Vidya 

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Friday, September 28, 2007 2:18 PM
> To: Basavaraj Patil
> Cc: ext Kilian Weniger; [email-masked]; ext Genadi Velev
> Using two different identifiers on two different interfaces 
> is a non-starter. The MN might just not have two different 
> identifiers to use.
> 
> Vijay
> 
> Basavaraj Patil wrote:
> > simultaneously? Are you suggesting that within the scope of a PMIP6 
> > domain, you could potentially verify (at AAA level or some 
> such thing) 
> > if an MN is already attached via another interface and 
> hence prevent 
> > it from attaching via the second interface?
> > 
> > An MN which attaches via different interfaces simultaneously to a 
> > PMIP6 domain will result in the LMA having a BCE for the 
> last received 
> > PBU. Host behavior when multiple interfaces have the same 
> address is 
> > unspecified and we can just leave it at that. In the 
> context of this 
> > document, we do not need to solve it.
> > 
> > -Raj
> > 
> > 
> >>>> preventing that a MN attaches with 2 interfaces to a PMIP domain 
> >>>> (at least to the same LMA). For example, the operator 
> doesn't allow 
> >>>> attachment (i.e. authorization) of interface 2, since 
> interface 1 
> >>>> is still attached.
> >>>
> >>> I'm ok with any of the above three options. We can certainly 
> >>> document the scenario and close the issue. I do no think, 
> we should 
> >>> try to solve this problem here or use this issue to 
> explicitly add 
> >>> text to block the inter-access handoff, we did not do any 
> thing to 
> >>> support that scenario. When the charter says, its out of 
> scope, we 
> >>> dont need to solve all the issues, when the scenario is enabled. 
> >>> Operators can solve this issue, these are managed 
> deployments. Its 
> >>> not a like a consumer buying a device and turning it on 
> at home. So, 
> >>> I agree with your above three suggested options.
> >>>
> >>> Regards
> >>> Sri
> >>>
> >>>
> >>>
> >>>
> >>

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 28 Sep 2007 20:17:30 -0700

> specific identity for the MN - e.g., use its MAC address or something

How do you ensure it is unique? What if there is no no equivalent to the 
MAC address?

Sorry, the MN-ID must remain unique across the PMIPv6 domain.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 28 Sep 2007 22:43:46 -0500

Hi Vidya,

I believe the behavior of a host in the case where the interfaces are
configured with the same address (duplication of addresses assigned to the
interfaces) is implementation specific.
A host does not necessarily switch off an interface as a result of duplicate
addresses on the interfaces. I discussed this offline with Ryuji and he is
of the opinion that duplicate addresses on the interfaces do not cause the
IF to be shut down. So I don't think we can conclude that an interface is
shut down or unusable and causes disruption of IP connectivity to the MN. It
is behavior that is variable.

Quoting Ryuji here:
"
RFC2462 says in '5.4.5.  When Duplicate Address Detection Fails"
     A tentative address that is determined to be a duplicate as
Described above, MUST NOT be assigned to an interface and the node SHOULD
log a system management error.  If the address is a link-local address
formed from an interface identifier, the interface SHOULD be disabled.
'
So, according to the RFC, a node only shutdown when link-local
address is duplicated.. Not for the global.
"

The route table entry and interface used for sending/receiving is again
implementation specific.

Basically the point is that the issue of duplicate addresses being assigned
to  multi-homed hosts needs to be addressed in the IPv6 maintenance WG or
elsewhere. Solving this problem is not in the scope of PMIP6 or the Netlmm
WG. The problem of course arises in the PMI6 protocol scenario. But it is a
generic IPv6 issue that needs to be dealt with elsewhere.

Rgds,
-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 28 Sep 2007 22:58:20 -0500

On 9/28/07 4:16 PM, "ext Narayanan, Vidya" <[email-masked]> wrote:

Snip.. Snip..

> that the ID used is interface-specific doesn't need to be mandated.

I agree that the LMA does not have a way of realizing if the PBU from MAG2
is a result of the MN doing a HO vs the MN attaching to MAG2 via an
alternate interface. And as you state there can be out-of-band means to
detect it but cannot be relied on being available in all networks.

I think that in the context of the base PMIP6 protocol it is acceptable to
state that an MN may suffer IP connectivity loss in multi-homing cases. I
think we are trying to solve a corner case here. Because the behavior of an
MN which has duplicate addresses configured on its interfaces is
implementation specific, we cannot really conclude that there is IP
connectivity loss. Analyzing this further we (authors) concluded that the
address configured on the interfaces will be a duplicate only in the case
when RFC3041 type of addresses are generated based on the prefix in the RA.
If EUI64 or DHCP is used for address config, the addresses for the
interfaces will be unique although the prefix in the RAs from both MAGs are
identical. The LMA will however have only a single MAG in the BCE and this
will be the one from which the most recent PBU was received.
There will be oscillation of the MAG address in the BCE (betwee MAG1 and
MAG2) as a result of the MAGs periodically sending PBUs to the LMA. However
I do not think this is a problem that can be completely scoped or solved in
the context of the base PMIP6 protocol. It is best to acknowledge the issues
and move forward. After all, there are many things that need to be specified
in addition to the basic operation of PMIP6 to make this really work. This
issue would be one of those topics.

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 28 Sep 2007 23:05:02 -0500

Snip.. Snip..

> that the ID used is interface-specific doesn't need to be mandated.

Forgot one more thing....
I don't think we want to take the route of making the MN-ID being interface
specific. We can consider adding other hints to the LMA that can be used as
a means to interpret that it is the same MN attaching via an alternate
interface... But not change MN-ID to be interface specific.

-Raj

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 28 Sep 2007 23:05:29 -0700

Hi Raj,
I was using the interface being shut down as one example.  Whether the
interface is shut down or not, IP forwarding cannot be enabled on it
with a duplicate address.  So, from an IP point of view, that interface
is not useful to the MN.  So, the problem still exists, unless I'm
missing something fundamental.  

Thanks,
Vidya

> Sent: Friday, September 28, 2007 8:44 PM
> I believe the behavior of a host in the case where the 
> interfaces are configured with the same address (duplication 
> of addresses assigned to the
> A host does not necessarily switch off an interface as a 
> result of duplicate addresses on the interfaces. I discussed 
> this offline with Ryuji and he is of the opinion that 
> duplicate addresses on the interfaces do not cause the IF to 
> be shut down. So I don't think we can conclude that an 
> interface is shut down or unusable and causes disruption of 
> IP connectivity to the MN. It is behavior that is variable.
> 
> Quoting Ryuji here:
> "
>      A tentative address that is determined to be a duplicate 
> as Described above, MUST NOT be assigned to an interface and 
> the node SHOULD log a system management error.  If the 
> address is a link-local address formed from an interface 
> identifier, the interface SHOULD be disabled.
> '
> So, according to the RFC, a node only shutdown when 
> link-local address is duplicated.. Not for the global.
> "
> 
> The route table entry and interface used for 
> sending/receiving is again implementation specific.
> 
> Basically the point is that the issue of duplicate addresses 
> being assigned to  multi-homed hosts needs to be addressed in 
> the IPv6 maintenance WG or elsewhere. Solving this problem is 
> not in the scope of PMIP6 or the Netlmm WG. The problem of 
> course arises in the PMI6 protocol scenario. But it is a 
> > It thinks Interface 1 is operational and has shutdown 
> Interface 2 due 
> > to a duplicate address.  However, the LMA only has a binding 
> > corresponding to Interface 2 - so, the fact that the MN 
> thinks it can 
> > use Interface 1 is not useful, since it really cannot 
> send/receive any 
> > packets through it.  As a result, the MN has no IP connectivity.
> > 
> > Hope that clarifies.
> > 
> > Vidya
> > 
> >> Just for my education, can you please explain why the MN would 
> >> shutdown both interfaces if it were to receive the same prefix on 
> >> another interface on a multi-interface host?
> >> I guess I could dig up the archives... But if you can explain the 
> >> issue behind such behavior, I would appreciate it.
> >> 
> >> -Raj
> >> 
> >>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 28 Sep 2007 23:10:28 -0700

Just to further clarify - as you quote below from RFC2462, the duplicate
address is not assigned to the interface.  So, the interface that the
LMA is going to forward the packets to is not assigned the address in
the example scenario I was quoting and hence, the MN will not accept
packets on that link.  The interface that is valid from MN's perspective
is not acceptable to the LMA.  The "shutdown" example I was using seems
to have created a lot of confusion - essentially, I'm getting at the
fact that IP connectivity to the MN is messed up in this case. 

Vidya

> From: Narayanan, Vidya 
> Sent: Friday, September 28, 2007 11:05 PM
> To: 'Basavaraj Patil'; Sri Gundavelli; Genadi Velev
> I was using the interface being shut down as one example.  
> Whether the interface is shut down or not, IP forwarding 
> cannot be enabled on it with a duplicate address.  So, from 
> an IP point of view, that interface is not useful to the MN.  
> So, the problem still exists, unless I'm missing something 
> fundamental.  
> 
> Thanks,
> Vidya
> 
> > configured with the same address (duplication of addresses 
> assigned to 
> > the
> > A host does not necessarily switch off an interface as a result of 
> > duplicate addresses on the interfaces. I discussed this 
> offline with 
> > Ryuji and he is of the opinion that duplicate addresses on the 
> > interfaces do not cause the IF to be shut down. So I don't think we 
> > can conclude that an interface is shut down or unusable and causes 
> > disruption of IP connectivity to the MN. It is behavior that is 
> > variable.
> > 
> > Quoting Ryuji here:
> > "
> > Described above, MUST NOT be assigned to an interface and the node 
> > SHOULD log a system management error.  If the address is a 
> link-local 
> > address formed from an interface identifier, the interface 
> SHOULD be 
> > disabled.
> > '
> > The route table entry and interface used for sending/receiving is 
> > again implementation specific.
> > 
> > Basically the point is that the issue of duplicate addresses being 
> > assigned to  multi-homed hosts needs to be addressed in the IPv6 
> > maintenance WG or elsewhere. Solving this problem is not in 
> the scope 
> > of PMIP6 or the Netlmm WG. The problem of course arises in the PMI6 
> > protocol scenario. But it is a generic IPv6 issue that needs to be 
> > dealt with elsewhere.
> > 
> > Rgds,
> > -Raj
> >

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 28 Sep 2007 23:21:15 -0700

Hi Raj,

> Sent: Friday, September 28, 2007 8:58 PM
> To: Narayanan, Vidya; ext Genadi Velev; Sri Gundavelli
> >> PMIP6 domain will result in the LMA having a BCE for the last 
> >> received PBU. Host behavior when multiple interfaces have the same 
> >> address is unspecified and we can just leave it at that. In the 
> >> context of this document, we do not need to solve it.
> >> 
> > 
> > for the network to determine if the MN is attaching to 
> multiple MAGs 
> > or just one (I can imagine somewhat more complicated ways 
> of figuring 
> > that out with additional help from the lower layers, but, we can't 
> > rely on that), if we left it unsolved, that just means that an MN 
> > which happens to have multiple interfaces may suffer lack of IP 
> > connectivity or toggling/intermittent connectivity.  So, I 
> think we do 
> > need to state that the MN-ID used must be 
> interface-specific.  How a 
> > system ensures that the ID used is interface-specific 
> doesn't need to be mandated.
> 
> I agree that the LMA does not have a way of realizing if the 
> PBU from MAG2 is a result of the MN doing a HO vs the MN 
> attaching to MAG2 via an alternate interface. And as you 
> state there can be out-of-band means to detect it but cannot 
> be relied on being available in all networks.
> 
> I think that in the context of the base PMIP6 protocol it is 
> acceptable to state that an MN may suffer IP connectivity 
> loss in multi-homing cases. I think we are trying to solve a 
> corner case here. 

I'm not sure why this is a corner case.  Multihomed devices are common
today and they are only going to increase. 

> Because the behavior of an MN which has 
> duplicate addresses configured on its interfaces is 
> implementation specific, we cannot really conclude that there 
> is IP connectivity loss. Analyzing this further we (authors) 
> concluded that the address configured on the interfaces will 
> be a duplicate only in the case when RFC3041 type of 
> addresses are generated based on the prefix in the RA.
> If EUI64 or DHCP is used for address config, the addresses 
> for the interfaces will be unique although the prefix in the 
> RAs from both MAGs are identical. 

Not true.  If the MN used DHCP, in accordance with PMIP, wouldn't it get
the same IP address?  There is no requirement on the MN doing DHCP-PD.
So, a regular MN would just be requesting an IP address, not a prefix.
Also, in the IPv4 case, this is only an address.  In the model where the
MAG obtains the prefix from the LMA and serves as a DHCP server to the
MN will provide the same address to the MN - in the IPv4 case, there is
no other information available to the MAG, except for a single address.
I'll also note that RFC3041-style addresses are not that uncommon.  

Regards,
Vidya

> The LMA will however have 
> only a single MAG in the BCE and this will be the one from 
> which the most recent PBU was received.
> MAG2) as a result of the MAGs periodically sending PBUs to 
> the LMA. However I do not think this is a problem that can be 
> completely scoped or solved in the context of the base PMIP6 
> protocol. It is best to acknowledge the issues and move 
> forward. After all, there are many things that need to be 
> specified in addition to the basic operation of PMIP6 to make 
> this really work. This issue would be one of those topics.
> 
> 
> -Raj
> 
> > 
> > Vidya
> > 
> >> -Raj
> >> 
> 
> >> 
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 28 Sep 2007 23:28:23 -0700

Hi Raj,
 
> I don't think we want to take the route of making the MN-ID 
> being interface specific. We can consider adding other hints 
> to the LMA that can be used as a means to interpret that it 
> is the same MN attaching via an alternate interface... But 
> not change MN-ID to be interface specific.
> 

Any thoughts on what other hints we can use?  I don't it is necessary to
even correlate it to the same MN.  It should be sufficient to
distinguish the interfaces such that the LMA treats those as separate IP
addresses and separate PMIP sessions. 

Vidya

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 28 Sep 2007 23:42:01 -0700

Hi Vidya,

> missing something fundamental.  

As I stated before..

A normal (unmodified) IPv6 stack, will not allow more than one
interface to configure the same IPv6 address. I've verified this
on Cisco's implementation. This is true for other popular platforms
as well. 

HA(config)#int ethernet 0/1
HA(config-if)#ipv6 address abab::1/64
HA(config-if)#exit

HA(config)#int ethernet 0/2
HA(config-if)#ipv6 address abab::1/64
%Ethernet0/2: Error: ABAB::1/64 is in use on Ethernet0/1

So, we are just discussing about some issue on the host when
multihoming is enabled and that belongs to the work item that is
not in scope of the charter. Why are we wasting our time on this
multihoming issue ?

And I dont see any *consensus* or even *remote interest* from any
one in the WG on this issue. None of the other reviewers even talked
about this issue, in their review comments.

Please understand, we need to complete this work. This is really
frustrating. If need be, this can be addressed in a different 
document.

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sat, 29 Sep 2007 10:11:13 -0700

All, 
I think several people have understood the problem we are discussing
here, but, there still seems to be some confusion.  Here is a second
attempt at describing the problem, this time in some more detail: 

* MN has two interfaces attached to MAG1 and MAG2 under the same LMA
* Let's say MAG1 first created the binding at the LMA and acquired a
prefix/address for the MN, using MN-ID1
* MN obtains the prefix/address on Interface1; if the MN is using DHCP,
it will only get an address (since there is no requirement on the MN to
do DHCP-PD)
* MAG2 now sends a PBU with MN-ID1 also (very possible when the ID is
something like an NAI)
* LMA thinks the MN moved, updates the binding and returns the same
prefix for the MN to MAG2
* MN receives the same prefix/address via DHCP or RA over Interface2; MN
detects a duplicate address and per RFC2462, does not configure that
address on Interface2; Interface2 is now not enabled for IP forwarding; 
* If the MN is using stateless autoconfiguration, it may end up with a
different address for Interface2; in this case, Interface2 is enabled;
the assigned prefix, however, is no longer just over a point-to-point
link, although, the MAG thinks it is
* The LMA has a binding for MAG2 (corresponding to Interface2)
* If the MN never enabled Interface2 due to duplicate address issues,
the MN will try to use Interface1, but, unsuccessfully, since the LMA
will drop those packets; LMA will send packets to MAG2 (Interface2),
which will not be received by the MN
* If the MN has enabled Interface2 with a different address, depending
on the implementation, the MN may use Interface1 or Interface2 (some OSs
will just pick one); any communication attempted via Interface 1 will
fail
* In the meantime, the binding may keep toggling between MAG1 and MAG2
at the LMA, due to corresponding PBUs received; the MN may have
intermittent connectivity as a result of this

I've tried going through this issue with several developers and everyone
agress that this problem exists for unmodified IP hosts.  Several people
have acknowledged that on this list as well (as part of this thread and
also discussions back in early August).  

Among those who believe there is no issue here, I'd appreciate if
someone could walk through the steps and explain why this is not a
technical issue and how the MN can use at least one interface for stable
IP connectivity.  

I'm as eager to close this thread as anyone.  I don't see a solution
other than ensuring that separate IP addresses/prefixes are assigned to
each interface and that those are treated as separate PMIP sessions.  I
look forward to either hearing why this is not a problem or possible
solutions to it. 

Thanks,
Vidya