Subject: Re: [netlmm] Re: Proposed text for resolving the multi-homed host issue

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 01 Oct 2007 09:40:01 +0200

Vijay Devarapalli wrote:
> Hi Raj,
> 
> Further changes. I don't think a typical host implementation would 
> assign the same address to two different interfaces. Here is the new
>  text.
> 
> Folks, please comment on the following text.
> 
> A mobile node which has multiple interfaces may attach to different 
> MAGs in a Proxy Mobile IPv6 domain simultaneously. If the mobile node
>  is identified by a common MN-ID, the LMA will receive multiple proxy
>  Binding Updates from the MAGs to which the mobile node is attached 
> to via its multiple interfaces. The LMA cannot differentiate whether
>  the Proxy Binding Update from a given MAG is a result of the mobile
>  node performing a handoff or if the mobile node attaching via a 
> second interface to another MAG in the Proxy Mobile IPv6 domain.
> 
> Since the mobile node is attached to the same Proxy Mobile IPv6 
> domain with both interfaces, it may receive the same prefix on both 
> interfaces. Typical host implementations do not allow assigning the 
> same address to two different interfaces. If the mobile node performs
>  IPv6 stateless address auto-configuration using different interface 
> identifiers, then it would end up with different addresses from the 
> same prefix on the two interfaces. Then it becomes a multi-homed host
> in the Proxy Mobile IPv6 domain.
> 
> As far as this document is concerned, the LMA maintains only a single
>  binding cache entry for the mobile node at any given time. This 
> binding cache entry will have the IP address of the MAG that last 
> sent successful Proxy Binding Update as the care-of address. Since 
> the mobile node is attached to multiple MAGs, each MAG will keep 
> attempting to refresh the binding cache entry in the LMA. This will 
> cause the binding cache entry for the mobile node in the LMA to keep 
> oscillating between MAGs. This situation becomes recoverable if the 
> mobile node turns of the one of the interfaces or if the LMA 
> instructs one of the MAGs to stop sending proxy BUs for the mobile 
> node.
> 
> In the context of this document, where no changes or enhancements to 
> the mobile node are possible, a complete solution for multi-homed 
> hosts is considered to be out-of-scope.

Vijay, this text somehow correctly resumes the discussion and puts many
things out of scope; it makes some sense.

But I'm afraid it's too long and tries to hide problems behind
descriptions. It is not only a matter of multi-homed MNs or compromised
MAGs.

It is also an issue to rely PMIP6 on AAA exclusively; and an issue of
designing a new address auto-configuration mechanism.

PMIP6 should work without NAIs and AAA too.  What do folks think about
this?  To which extent does PMIP6 rely on NAIs and AAA?  Is this ok?
MUST AAA be deployed in order for PMIP6 to work?  Isn't it better to
rely PMIP6 on _addresses_ first and then on NAIs?

PMIP6 should work without assigning prefixes in PBAck.  What do folks
think about this?  MUST PMIP6 always do (::/0 in PBU and then HNP in
PBAck) what DHCPv6-PD already does?  And mandatorily?

You can open issues and subsequently close them all it with text
proposals that reflect some consensus, and such that to reach deadlines.
  But the fundamental issues are still there.  Once you put them in RFCs 
- neutral people will keep raising them along the years.

Alex

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

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

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Mon, 01 Oct 2007 15:09:32 +0300

Everybody,

<chair hat off>
I have now read all the mails related to this topic and I'm not sure I
understand the issue compeletely. It seems that the scenarios when this
could happen is when a MN would have try to access the same access
technology twice with different interfaces. As an example, two WLAN cards
were used. I wonder if this wouldn't be really a corner case.

First of all, why would anybody try to do it?

Secondly, if this does happen, I think the problem would also solve itself:
You cannot really connect currently to a Wireless WAN with the same identity
twice (At least 3GPP, or Wimax don't seem to support it, perhaps 3GPP2
does). So, the only technology currently that would support something like
that is WLAN. However, with WLAN the address configuration for the interface
is usually based on the MAC address of the WLAN card itself. Thus, even if
the two cards would see the same prefix they would use a different IID. So,
they would look to be on the same subnet, but with different addresses. I
guess that should be ok. Anyways, such a scenario looks like a configuration
error.

Hence, I would be ok with just marking that this is currently out of scope
and enabling it would need additional work. I'm ok with the text Raj has
provided, though, it seems a bit of an overkill (which is fine).

I wonder if I'm missing something here.

Cheers,

Jonne.

On 10/1/07 1:31 AM, "Basavaraj Patil" <[email-masked]> wrote:

> 
> Hello,
> 
> Below is proposed text for resolving the current impasse on the multi-homed
> host issue. 
> 
> At this time, we do not seem to be making much headway on closing this
> issue. We (authors) recognize the issue... But we believe that a complete
> solution to the problem needs to be dealt with separately and hence it is
> perfectly okay to state that it is out-of-scope of this specification. The
> WG can decide to work on the issue as a separate effort.
> 
> The proposed text will hopefully be sufficient to close this issue and move
> forward. Else we would like to request the chairs to get consensus from the
> WG on the proposed text.
> 
> "
> 
> Sec x.y TBD
> 
>    Binding Updates from the MAGs to which the mobile node is attached to
>    via its multiple interfaces. The LMA cannot differentiate whether the
>    Proxy Binding Update from the second MAG is a result of:
>    a. the mobile node performing a handoff or
>    b. the mobile node attaching via a second interface to another
>       MAG in the Proxy Mobile IPv6 domain.
> 
>    A host which receives the same prefix from different access routers
>    (i.e MAGs) may end up with duplicate addresses being configured on the
>    interfaces when IPv6 stateless address auto-configuration is used and
>    not based on a unique ID such as an L2 identifier. The behavior of the
>    mobile node in such a scenario is unpredictable as it depends on the
>    implementation of how duplicate addresses on the interfaces of the
>    host are handled. Therefore this  behavior of a multi-homed host
>    attaching to a Proxy Mobile IP6 domain via multiple interfaces is
>    implementation dependent and out-of-scope for this document.
> 
>    binding cache will have the IP address of the MAG that last sent
>    a successful Proxy Binding Update as the care-of address. Since the
>    mobile node is attached to multiple MAGs, each MAG will keep
>    mobile node turns off one of the interfaces or if the LMA instructs
>    one of the MAGs to stop sending proxy BUs for the mobile node.
> 
> "
> -Raj

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: "CASATI, Alessio \(Alessio\)" <[email-masked]>
Date: Mon, 1 Oct 2007 14:44:41 +0200

All,

The multihoming topic needs also to cover this case: a single MAG that
connects to different LMA's for a single user, and the MAG happens to
provide this connectivity for a single host via different technologies
(e.g. WLAN and LTE) or a single technology that supports natively the
concept of multiple PDNs attachment (e.g. UMTS, GERAN and, extrapolating
a bit, LTE).

I guess the current version of PMIP can support this (note that this
will imply the effort on the support of non overlapping IP addresses
when private IPv4 is used as user protocol)? It seems like the physical
MAG described above needs to behave like a set of different logical MAGs
from the standpoint of the LMA? 

Can the authors express an opinion on this matter?

regards
Alessio

*-----Original Message-----
*From: Soininen Jonne (NSN FI/Espoo) [mailto:[email-masked]] 
*Sent: 01 October 2007 13:10
*To: Basavaraj Patil; [email-masked]
*Cc: Vijay Devarapalli
*Subject: [netlmm] Re: Proposed text for resolving the 
*multi-homed host issue
*
*Everybody,
*
*<chair hat off>
*I have now read all the mails related to this topic and I'm 
*not sure I understand the issue compeletely. It seems that the 
*scenarios when this could happen is when a MN would have try 
*to access the same access technology twice with different 
*interfaces. As an example, two WLAN cards were used. I wonder 
*if this wouldn't be really a corner case.
*
*First of all, why would anybody try to do it?
*
*Secondly, if this does happen, I think the problem would also 
*solve itself:
*You cannot really connect currently to a Wireless WAN with the 
*same identity twice (At least 3GPP, or Wimax don't seem to 
*support it, perhaps 3GPP2 does). So, the only technology 
*currently that would support something like that is WLAN. 
*However, with WLAN the address configuration for the interface 
*is usually based on the MAC address of the WLAN card itself. 
*Thus, even if the two cards would see the same prefix they 
*would use a different IID. So, they would look to be on the 
*same subnet, but with different addresses. I guess that should 
*be ok. Anyways, such a scenario looks like a configuration error.
*
*Hence, I would be ok with just marking that this is currently 
*out of scope and enabling it would need additional work. I'm 
*ok with the text Raj has provided, though, it seems a bit of 
*an overkill (which is fine).
*
*I wonder if I'm missing something here.
*
*Cheers,
*
*Jonne.
*
*
*On 10/1/07 1:31 AM, "Basavaraj Patil" <[email-masked]> wrote:
*
*> 
*> Hello,
*> 
*> Below is proposed text for resolving the current impasse on the 
*> multi-homed host issue.
*> 
*> At this time, we do not seem to be making much headway on 
*closing this 
*> issue. We (authors) recognize the issue... But we believe that a 
*> complete solution to the problem needs to be dealt with 
*separately and 
*> hence it is perfectly okay to state that it is out-of-scope of this 
*> specification. The WG can decide to work on the issue as a 
*separate effort.
*> 
*> The proposed text will hopefully be sufficient to close this 
*issue and 
*> move forward. Else we would like to request the chairs to get 
*> consensus from the WG on the proposed text.
*> 
*> "
*> 
*> Sec x.y TBD
*> 
*>    A mobile node which has multiple interfaces may attach to 
*different
*>    MAGs in a Proxy Mobile IPv6 domain simultaneously. If the 
*mobile node
*>    is identified by a common MN-ID, the LMA will receive 
*multiple proxy
*>    Binding Updates from the MAGs to which the mobile node is 
*attached to
*>    via its multiple interfaces. The LMA cannot differentiate 
*whether the
*>    Proxy Binding Update from the second MAG is a result of:
*>    a. the mobile node performing a handoff or
*>    b. the mobile node attaching via a second interface to another
*>       MAG in the Proxy Mobile IPv6 domain.
*> 
*>    A host which receives the same prefix from different 
*access routers
*>    (i.e MAGs) may end up with duplicate addresses being 
*configured on the
*>    interfaces when IPv6 stateless address auto-configuration 
*is used and
*>    not based on a unique ID such as an L2 identifier. The 
*behavior of the
*>    mobile node in such a scenario is unpredictable as it 
*depends on the
*>    implementation of how duplicate addresses on the interfaces of the
*>    host are handled. Therefore this  behavior of a multi-homed host
*>    attaching to a Proxy Mobile IP6 domain via multiple interfaces is
*>    implementation dependent and out-of-scope for this document.
*> 
*>    As far as this document is concerned, the LMA maintains 
*only a single
*>    binding cache entry for the mobile node at any given time. This
*>    binding cache will have the IP address of the MAG that last sent
*>    a successful Proxy Binding Update as the care-of address. 
*Since the
*>    mobile node is attached to multiple MAGs, each MAG will keep
*>    attempting to refresh the binding cache entry in the LMA. 
*This will
*>    cause the binding cache entry for the mobile node in the 
*LMA to keep
*>    oscillating between MAGs. This situation becomes 
*recoverable if the
*>    mobile node turns off one of the interfaces or if the LMA 
*instructs
*>    one of the MAGs to stop sending proxy BUs for the mobile node.
*> 
*>    In the context of this document, where no changes or 
*enhancements to
*>    the mobile node are possible, a complete solution for multi-homed
*>    hosts is considered to be out-of-scope.
*> "
*> 
*> -Raj
*> 
*
*--
*Jonne Soininen
*Nokia Siemens Networks
*
*Tel: +358 40 527 46 34
*E-mail: [email-masked]
*
*
*
*
*_______________________________________________
*netlmm mailing list
[email-masked]
*https://www1.ietf.org/mailman/listinfo/netlmm
*

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 01 Oct 2007 08:02:32 -0700

Hi Alex,

Alexandru Petrescu wrote:
> descriptions. 

Not my choice. We have two options, point out the problem and say a 
solution for that is out-of-scope or work on complete solutions for the 
problems identified.

> It is also an issue to rely PMIP6 on AAA exclusively; 

The proposed text does not talk about AAA at all.

> and an issue of

We are sticking with current address auto-configuration mechanisms for 
this draft. Lets see if we can improve the proposed text.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 01 Oct 2007 17:28:00 +0200

Hi Vijay,

Vijay Devarapalli wrote:
>> Vijay, this text somehow correctly resumes the discussion and puts 
>> many things out of scope; it makes some sense.
>> 
> solution for that is out-of-scope or work on complete solutions for 
> the problems identified.

The other solution is to reduce more from the PMIP6 solution and change
its semantics a little bit.

> The proposed text does not talk about AAA at all.

AAA and NAI is intrinsic in the PMIP6 solution:
      "The local mobility anchor MUST identify the mobile node from the
       identifier present in the NAI option [RFC-4283] of the Proxy
       Binding Update request.  If the NAI option is not present in the
       Proxy Binding Update request, the local mobility anchor MUST
       reject the request and send a Proxy Binding Acknowledgement
       message with Status field set to MISSING_MN_IDENTIFIER_OPTION
       (Missing mobile node identifier)."

If overall the text agreed that LMA could use something else than the
NAI then the proposed multi-homing resolving text could be much simpler,
ie disappear.

>> and an issue of designing a new address auto-configuration 
>> mechanism.
> 
> We are sticking with current address auto-configuration mechanisms 
> for this draft. Lets see if we can improve the proposed text.

Ok, I suggest to modify this draft text:
> The local mobility anchor MUST identify the mobile node from the 
> identifier present in the NAI option [RFC-4283] of the Proxy Binding 
> Update request.  If the NAI option is not present in the Proxy 
> Binding Update request, the local mobility anchor MUST reject the 
> request and send a Proxy Binding Acknowledgement message with Status 
> field set to MISSING_MN_IDENTIFIER_OPTION (Missing mobile node 
> identifier).

Into: "LMA must id the MN from the Home Address present in the PBU; the
MAG puts the Home Address into the PBU after having learned it from the
existing and deployed address auto-congifuration mechanism (DHCP, PPP)".

This is a change in semantics, yes, but it is one possible way to not
rely completely in NAI, and completely avoid the multihoming discussion
and issues.  There may be others...

Alex

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 1 Oct 2007 09:13:19 -0700

Hi Alessio,

> -----Original Message-----
> From: CASATI, Alessio (Alessio) [mailto:[email-masked]] 
> Sent: Monday, October 01, 2007 5:45 AM
> To: Soininen Jonne (NSN FI/Espoo); Basavaraj Patil; [email-masked]
> Cc: Vijay Devarapalli
> Subject: RE: [netlmm] Re: Proposed text for resolving the 
> multi-homed hostissue
> 
> All,
> 

There can be multiple LMA's in a PMIP6 domain. However, once a LMA is
associated with a given mobile, that relation will survive throught out
that mobility session. That LMA will remain as the serving anchor.

The document does not specify any restrictions on the enabled access
technologies in a PMIP6 domain.

> from the standpoint of the LMA? 

Yes. The overlapping use case is solved using the GRE key and there is
a draft on this. It allows the required logical seperation.

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 1 Oct 2007 11:45:59 -0500

Hi Jonnie,
Please see comment inline.

Regards,
Ahmad

> From: Soininen Jonne (NSN FI/Espoo) [mailto:[email-masked]] 
> Sent: Monday, October 01, 2007 7:10 AM
> To: Basavaraj Patil; [email-masked]
> Cc: Vijay Devarapalli
> Subject: [netlmm] Re: Proposed text for resolving the 
> multi-homed host issue
> 
> Everybody,
> 
> <chair hat off>
> I have now read all the mails related to this topic and I'm 
> not sure I understand the issue compeletely. It seems that 
> the scenarios when this could happen is when a MN would have 
> try to access the same access technology twice with different 
> interfaces. As an example, two WLAN cards were used. I wonder 
> if this wouldn't be really a corner case.
> 
> You cannot really connect currently to a Wireless WAN with 
> the same identity twice (At least 3GPP, or Wimax don't seem 
> to support it, perhaps 3GPP2 does). So, the only technology 
> currently that would support something like that is WLAN. 
> However, with WLAN the address configuration for the 
> interface is usually based on the MAC address of the WLAN 
> card itself. Thus, even if the two cards would see the same 
> prefix they would use a different IID. So, they would look to 
> be on the same subnet, but with different addresses. I guess 
> that should be ok. Anyways, such a scenario looks like a 
> configuration error.
> 
> Hence, I would be ok with just marking that this is currently 
> out of scope and enabling it would need additional work. I'm 
> ok with the text Raj has provided, though, it seems a bit of 
> an overkill (which is fine).
> 

[Ahmad]
No. I do not think so. Actually I share the same views. 
I believe we need to document that multi-homing is out-of-scope and move
on in order for the draft to progress and meet our target dates.

Thanks.
Ahmad
> > Below is proposed text for resolving the current impasse on the 
> > multi-homed host issue.
> > 
> > issue. We (authors) recognize the issue... But we believe that a 
> > complete solution to the problem needs to be dealt with 
> separately and 
> > hence it is perfectly okay to state that it is out-of-scope of this 
> > specification. The WG can decide to work on the issue as a 
> separate effort.
> > 
> > The proposed text will hopefully be sufficient to close 
> this issue and 
> > move forward. Else we would like to request the chairs to get 
> > consensus from the WG on the proposed text.
> > 
> > "
> > 
> > Sec x.y TBD
> >

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 1 Oct 2007 10:53:56 -0700

Hi Jonne,

> I wonder if I'm missing something here.

No. We share the same view.

The document provides a solution for providing mobility to a host
that is connected to the network over one single interface at
any point of time. Multi-homing is out of scope.

When a operator qualifies and enables a host in PMIP6 domain for
simultaneous access over multiple interfaces, most likely they
will provide some application software such as connection manager
or create a virtual interface with the physical access interface
abstraction. Its not magic that we enable multiple interfaces on
a host, the system will do load balancing over the radio links, do
the source address selection and if one interface shutdown, it
will move the flows to the other interface. Even in fixed
infrastructures, the behavior of the multi-homed host is
unspecified and nothing new in PMIP6. We cannot just say, we need
to absolutely ensure a multi-homed host will use all the links
affectively or get the routing correctly. The host stack may not
even find the route properly, it may route traffic that is using
a source address from one network over the other network, leading
to source-address filtering, or it may have two active links
initially and later may have active link and still end up loosing
connectivity, as the host may not be able to adopt to the change.
So, this is not an issue of the protocol, but the configuration
that is incorrect and the deployment needs to manage that aspect.

As every one pointed to this, we will state this issue and 
close it with the proposed text.

Regards
Sri

> Sent: Monday, October 01, 2007 5:10 AM
> Cc: ext Narayanan, Vidya; ext Sri Gundavelli; Vijay 
> Devarapalli; Chowdhury, Kuntal
> Subject: Re: Proposed text for resolving the multi-homed host issue
> 
> Everybody,
> 
> <chair hat off>
> the same identity
> out of scope
> this issue and move

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 1 Oct 2007 11:00:14 -0700

Hi Jonne,
We currently don't have a restriction in the document that says that a
given LMA must only serve one access technology.  Hence, a mobile node
that has LTE and WLAN access connecting to the same operator network may
very well have this problem, since the MAGs for LTE access and for WLAN
access may be connected to the same LMA.  

I think I mentioned in one of my emails that by explicitly placing a
restriction that a given PMIP domain MUST NOT serve multiple access
technologies, this problem can be made a corner case.  Even still, I've
had an 802.11a and 802.11b/g cards simultaneously plugged in and
connected not that infrequently and I know several others who have :) As
we introduce 802.11n, we have introduced one more variant here.  So, it
is feasible to run into this problem even with that restriction, but, at
that point, I'd be more comfortable calling it a corner case.  

Hope that helps. 

Regards,
Vidya 

> Cc: Narayanan, Vidya; ext Sri Gundavelli; Vijay Devarapalli; 
> Chowdhury, Kuntal

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 01 Oct 2007 11:06:41 -0700

Vidya,

> access may be connected to the same LMA.  

If we go down this path, then we have to start talking about the SDO 
architectures. In the particular example you quoted, there is always an 
IPsec tunnel on top of the WLAN interface with the IPsec tunnel 
providing a point-to-point link between the mobile node and a security 
gateway. The security gateway in turns becomes the MAG. We are no longer 
talking a simple IP host that gets the same prefix across LTE and WLAN 
interfaces. In fact in this case there will *not* be a conflict since 
the WLAN interface will not get the PMIPv6 home address. It would get a 
local address from a 802.11 access network.

> connected not that infrequently and I know several others who have :) 

For what? Makes no sense to me.

As
> that point, I'd be more comfortable calling it a corner case.  

Frankly, I don't think it is worth our time to address a mobile node 
with three different 802.11 cards plugged in and trying to connect to 
the same access network. :)

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 1 Oct 2007 11:17:48 -0700

Vijay, 

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Monday, October 01, 2007 11:07 AM
> To: Narayanan, Vidya
> Cc: Soininen Jonne (NSN FI/Espoo); Basavaraj Patil; 
> [email-masked]; ext Sri Gundavelli; Chowdhury, Kuntal
> > that has LTE and WLAN access connecting to the same 
> operator network 
> > may very well have this problem, since the MAGs for LTE 
> access and for 
> > WLAN access may be connected to the same LMA.
> 
> If we go down this path, then we have to start talking about 
> the SDO architectures. In the particular example you quoted, 
> there is always an IPsec tunnel on top of the WLAN interface 
> with the IPsec tunnel providing a point-to-point link between 
> the mobile node and a security gateway. The security gateway 
> in turns becomes the MAG. We are no longer talking a simple 
> IP host that gets the same prefix across LTE and WLAN 
> interfaces. In fact in this case there will *not* be a 
> conflict since the WLAN interface will not get the PMIPv6 
> home address. It would get a local address from a 802.11 
> access network.
> 

I don't understand.  Are you saying that the two accesses are then not
part of the same PMIPv6 domain?  Let's then abstract it - can there ever
be an architecture where multiple access technologies that an MN could
simultaneously use are part of the same PMIPv6 domain?  If we place that
restriction on the protocol, I can buy that this problem reduces to a
corner case.  It cannot be implicit and left out of the document,
because it is an important guideline for deployments. 

Thanks,
Vidya

> > technologies, this problem can be made a corner case.  Even still, 
> > I've had an 802.11a and 802.11b/g cards simultaneously 
> plugged in and 
> > we introduce 802.11n, we have introduced one more variant 
> here.  So, 
> > it is feasible to run into this problem even with that restriction, 
> > but, at that point, I'd be more comfortable calling it a 
> corner case.
> 
> Frankly, I don't think it is worth our time to address a 
> mobile node with three different 802.11 cards plugged in and 
> trying to connect to the same access network. :)
> 
> Vijay
> 
> > 
> > Hope that helps. 
> > 
> > Regards,
> > Vidya
> > 
> >> I have now read all the mails related to this topic and 
> I'm not sure 
> >> I understand the issue compeletely. It seems that the 
> scenarios when 
> >> this could happen is when a MN would have try to access the same 
> >> access technology twice with different interfaces. As an 
> example, two 
> >> WLAN cards were used. I wonder if this wouldn't be really a corner 
> >> case.
> >>
> >> Secondly, if this does happen, I think the problem would 
> also solve 
> >> itself:
> the same 
> >> identity twice (At least 3GPP, or Wimax don't seem to support it, 
> >> perhaps 3GPP2 does). So, the only technology currently that would 
> >> support something like that is WLAN.
> >> However, with WLAN the address configuration for the interface is 
> >> usually based on the MAC address of the WLAN card itself. 
> Thus, even 
> >> if the two cards would see the same prefix they would use 
> a different 
> >> IID. So, they would look to be on the same subnet, but 
> with different 
> >> addresses. I guess that should be ok. Anyways, such a 
> scenario looks 
> >> like a configuration error.
> >>
> >> Hence, I would be ok with just marking that this is 
> currently out of 
> >> scope and enabling it would need additional work. I'm ok with the 
> >> text Raj has provided, though, it seems a bit of an 
> overkill (which 
> >> is fine).
> >>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 01 Oct 2007 11:23:25 -0700

Narayanan, Vidya wrote:
> I don't understand.  

I would like to avoid getting into SDO architectures on the NETLMM 
mailing list.

> Are you saying that the two accesses are then not
> part of the same PMIPv6 domain?  

They would be, but it won't be the LTE and WLAN interfaces, it would be 
the LTE and the IPsec tunnel interfaces. And here we are not talking 
about a plain IP host. It does a lot more.

 > Let's then abstract it - can there ever

I am sure the SDOs would rather like the NETLMM mailing list staying out 
of deployments. :) It is especially harmful if the NETLMM WG tries to 
recommend something regarding "LTE and WLAN deployment using PMIPv6" in 
the PMIPv6 base specification. :)

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 01 Oct 2007 13:27:50 -0500

Hi Vidya,

On 10/1/07 1:17 PM, "ext Narayanan, Vidya" <[email-masked]> wrote:

---snip---

> because it is an important guideline for deployments.

Would the text that we proposed (basically implying that behavior of
multi-homed hosts attaching to the same PMIP6 domain is implementation
dependent and out of scope) not be considered as sufficient guidelines for
deployments?

Do we want a solution to the problem or is it enough to recognize the issue
in this document and deal with it elsewhere....?

As a guideline, the proposed text IMO is sufficient.

-Raj

---

From: "Tsirtsis, George" <[email-masked]>
Date: Mon, 1 Oct 2007 11:33:08 -0700

Hi Vijay et.al.,

The stated objective is that PMIP must not require any changes in the IP
stack of the host. I presume that this means that any "legal" IP stack
that attaches to a PMIP domain should work without knowing anything
about PMIP.

Claiming that you satisfy the objective by placing multi-homing out of
scope is a contradiction in terms, since any IP stack that is capable of
multi-homing, will not work properly when it is attached to a PMIP
domain, thus breaking the stated objective.

Instead of pushing this under the rag, a cursory look at multi-homing as
a general IP capability reveals the following. Multi-homing can be
achieved in the following ways, immediately pointing to corresponding
solutions regarding PMIP's compatibility with it:

1) Multiple connections over different technologies.
Given no changes to the end host, the only way to ensure that PMIP is
compatible with multi-technology capable hosts, is to make sure that a
PMIP domain NEVER spans network technologies. IF this is clearly
defined, and IF the protocol is used legally, then a multi-technology
mobile can never connect more than one of its interfaces to the same
PMIP domain.

2) Multiple connections over the same technology but to different
administrative domains.
The only way to ensure that PMIP is compatible with hosts multi-homing
to different administrative domains, is to make sure that a PMIP domain
NEVER spans administrative domains. 
IF this is clearly defined, and IF the protocol is used legally, then
hosts multi-homing to different admin domains can never connect to the
same PMIP domain.

3) Multiple connections with the same technology and to the same
administrative domain.
As far as I can tell, it is NOT possible to ensure that PMIP is
compatible with hosts multi-homing on the same technology and the same
administrative domain (albeit a rare case for common wireless links). 
For this reason, however, it should be clearly stated in an
applicability section that access technologies that allow multiple
connections from the same host and with the same identifier MUST NOT
deploy PMIP....at least in its current form. 

Regards
George

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Monday, October 01, 2007 1:17 AM
To: Basavaraj Patil
Cc: [email-masked]
Subject: [netlmm] Re: Proposed text for resolving the multi-homed host
issue

Hi Raj,

   A mobile node which has multiple interfaces may attach to different
   MAGs in a Proxy Mobile IPv6 domain simultaneously. If the mobile node
   is identified by a common MN-ID, the LMA will receive multiple proxy
   Binding Updates from the MAGs to which the mobile node is attached to
   via its multiple interfaces. The LMA cannot differentiate whether the
   Proxy Binding Update from a given MAG is a result of the mobile node
   performing a handoff or if the mobile node attaching via a second
   interface to another MAG in the Proxy Mobile IPv6 domain.

domain
   with both interfaces, it may receive the same prefix on both

sent
   successful Proxy Binding Update as the care-of address. Since the
instructs

Vijay

> Below is proposed text for resolving the current impasse on the
multi-homed
> issue. We (authors) recognize the issue... But we believe that a
complete
>    Binding Updates from the MAGs to which the mobile node is attached
to

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 1 Oct 2007 11:38:08 -0700

Vijay,
I'm not recommending getting into SDO architectures at all here.  This
is a generic problem that can happen when any two access technologies
that an MN may turn on simultaneously connect to the same LMA.  It has
nothing to do with a specific SDO architecture.  You seem to be taking
an example I provided to mean something more specific that I intended. 

Vidya 

> Sent: Monday, October 01, 2007 11:23 AM
> To: Narayanan, Vidya
> >> architectures. In the particular example you quoted, there 
> is always 
> >> an IPsec tunnel on top of the WLAN interface with the IPsec tunnel 
> >> providing a point-to-point link between the mobile node and a 
> >> security gateway. The security gateway in turns becomes 
> the MAG. We 
> >> are no longer talking a simple IP host that gets the same prefix 
> >> across LTE and WLAN interfaces. In fact in this case there 
> will *not* 
> >> be a conflict since the WLAN interface will not get the 
> PMIPv6 home 
> >> address. It would get a local address from a 802.11 access network.
> >>
> > 
> > I don't understand.  
> 
> I would like to avoid getting into SDO architectures on the 
> NETLMM mailing list.
> 
> > Are you saying that the two accesses are then not part of the same 
> > PMIPv6 domain?
> 
> They would be, but it won't be the LTE and WLAN interfaces, 
> it would be the LTE and the IPsec tunnel interfaces. And here 
> we are not talking about a plain IP host. It does a lot more.
> 
> > simultaneously use are part of the same PMIPv6 domain?  If we place 
> > that restriction on the protocol, I can buy that this 
> problem reduces 
> > to a corner case.  It cannot be implicit and left out of 
> the document, 
> I am sure the SDOs would rather like the NETLMM mailing list 
> staying out of deployments. :) It is especially harmful if 
> the NETLMM WG tries to recommend something regarding "LTE and 
> WLAN deployment using PMIPv6" in the PMIPv6 base specification. :)
> 
> Vijay
> 
> > 
> > Thanks,
> > Vidya
> > 
> mobile node 
> interface is

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 01 Oct 2007 11:48:01 -0700

Hi George,

Did you take a look at the text at all? We had one solution in the third 
paragraph, where the LMA, when it detects constant change in the binding 
cache entry due to two MAGs sending proxy BUs for the same mobile node 
identifier, tells one of the MAGs to stop.

Regarding your comments, please see inline.

> domain, thus breaking the stated objective.

You are missing something fundamental here. Getting a multi-homed host 
working with PMIPv6 was never a requirement either for the NETLMM WG, 
let alone the base PMIPv6 specification.

> Instead of pushing this under the rag, 

For the base PMIPv6 specification, yes. But for the NETLMM WG no. If and 
when NETLMM is re-chartered, I assume we have to deal with some of those 
things we declared out-of-scope for the base PMIPv6 specification.

a cursory look at multi-homing as
> mobile can never connect more than one of its interfaces to the same

This has some SDO agenda written all over it. Sorry George, can't agree 
to this.

> hosts multi-homing to different admin domains can never connect to the

I am assuming here that different administrative domains imply different 
mobile node identifiers. In that case, you would end up with two 
different LMAs for the mobile node.

> deploy PMIP....at least in its current form. 

I don't think this is likely to happen. As I said mentioned to Vidya in 
another email, it is not worth our time spending on this.

Vijay

---

From: "Tsirtsis, George" <[email-masked]>
Date: Mon, 1 Oct 2007 13:04:35 -0700

inline

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Monday, October 01, 2007 7:48 PM
To: Tsirtsis, George
Cc: Basavaraj Patil; [email-masked]
Subject: Re: PMIP compatibility with multihoming RE: [netlmm] Re:
Proposed text for resolving the multi-homed host issue

Hi George,

Did you take a look at the text at all? 

GT> yes, obviously/

We had one solution in the third 
paragraph, where the LMA, when it detects constant change in the binding

GT> yes, a mitigation measure.

GT> No I do not think I am missing anything. Multi-homing was never a
requirement. What was, and is, a requirement is for PMIP not to require
changes to end hosts (some of which may have multi-homing capabilities).

GT> So, until this WG re-charters and deals with these issues, we need
clear guidelines about how this protocol is used *in its current form*. 

GT> Vijay I do not appreciate such comments. So please stop it, ok?
...if and when you are ready, you can tell me what is wrong with what I
am saying and how you will manage to make PMIP compatible to
multi-technology terminals without changing anything in them e.g.,
without a virtual interface hiding the individual technology interfaces.

GT> You can make such an assumption if you state clearly that roaming is
NOT allowed. If you allow roaming, then the same (home) ID can be used
to access two remote administrative domains at the same time.

GT> Not likely does not mean that it does not happen. Stating the
protocols applicability clearly should not be based on what is *likely*
but on what *is*.

George

to
>> solution to the problem needs to be dealt with separately and hence
it
> is
>> perfectly okay to state that it is out-of-scope of this
specification.
> The
>> The proposed text will hopefully be sufficient to close this issue
and
> move

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 1 Oct 2007 13:24:32 -0700

Hi George,
 
> > scope is a contradiction in terms, since any IP stack that 
> is capable
> of

Multi-homing is not a baseline feature. When some configuration
is out of scope, it is indeed out of scope. If the scope of the
document creates a limitation or if the protocol does not work
for some deployments using that configuration which is not
supported, that is the known limitation as the protocol does not
support that configuration.

You can configure terminals and networks in million different
ways, where the protocol will break. Its is not the protocol
problem to work in that configuration, its a deployment error.
The burden is on the deployment that leverages this protocol
to ensure it uses the protocol in the supported mode. We dont
have to use this reason to restrict PMIP6 domain to single
access and we all know the implications of that restriction.

What we plan to do is document the issue around that configuration
and leave it future work, if at all if some one needs a solution
for multi-homing.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 01 Oct 2007 13:44:06 -0700

> GT> yes, a mitigation measure.

Ok, IMO, thats the best we can do in this document.

> changes to end hosts (some of which may have multi-homing capabilities).

And we did not require changes in the base PMIPv6 draft so far. Take a 
look at the draft again. The proposed text that Raj and I sent yesterday 
do not suggest changes to the host either. So not sure what you are 
commenting on.

> clear guidelines about how this protocol is used *in its current form*. 

Which is what I thought the proposed text that was sent out yesterday does.

> GT> Vijay I do not appreciate such comments. So please stop it, ok?

I stand by my statement. When you want some text in the base PMIPv6 
specification that has a direct impact on something that is getting done 
in an SDO, what do you want me to think?

> to access two remote administrative domains at the same time.

But you would need to give some additional information to the MAG so 
that the MAG can figure out when to use the LMA in the visited network 
and when to use the LMA in the home network. In the previous email I had 
assumed it is the mobile node identifier. If not, there should be some 
additional piece of information from the mobile node to the MAG.

> protocols applicability clearly should not be based on what is *likely*

I see no point in discussing case 3) anymore.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 01 Oct 2007 23:25:48 +0200

Vijay Devarapalli wrote:
> Vidya,
> 
> Narayanan, Vidya wrote:
>> Hi Jonne, We currently don't have a restriction in the document
>> that says that a given LMA must only serve one access technology.
>> Hence, a mobile node that has LTE and WLAN access connecting to the
>> same operator network may very well have this problem, since the
>> MAGs for LTE access and for WLAN access may be connected to the
>> same LMA.
> 
>  architectures. In the particular example you quoted, there is always
> security gateway. The security gateway in turns becomes the MAG. We
> across LTE and WLAN interfaces. In fact in this case there will *not*
> be a conflict since the WLAN interface will not get the PMIPv6 home
>> I think I mentioned in one of my emails that by explicitly placing
>> a restriction that a given PMIP domain MUST NOT serve multiple
>> access technologies, this problem can be made a corner case.  Even
>> still, I've had an 802.11a and 802.11b/g cards simultaneously
>> plugged in and connected not that infrequently and I know several
>> others who have :)
> 
>> we introduce 802.11n, we have introduced one more variant here.
>> So, it is feasible to run into this problem even with that
>> restriction, but, at that point, I'd be more comfortable calling it
>> a corner case.
> 
>  with three different 802.11 cards plugged in and trying to connect
> to the same access network. :)

That was but an example.

Consider your favorite mobile phone you buy at the next shop: has in
average three interfaces, two of which are IEEE-like (WPAN and WLAN) and
the third behaving more and more as an IEEE-like interface (HSDPA to
802.16).  To this add the USB when in cradle.

This makes for _4_ interfaces on a typical handset...  only one of them
is likely to behave as you would like it to use MN-Id and NAI.

This is not a far-fetched future prototype phone, it's now and here.

Add to this the large number of PDAs, blackberries and so on.

Come to downtown Paris, it's covered by WiFi for free, here and now; I
heard similar news in San Francisco and Mountain View.  Why ignoring all
these?

Alex

> 
> Vijay
> 
>> 
>> Hope that helps. Regards, Vidya
>>> -----Original Message----- From: Soininen Jonne (NSN FI/Espoo)
>>> [mailto:[email-masked]] Sent: Monday, October 01, 2007
>>> 5:10 AM To: Basavaraj Patil; [email-masked] Cc: Narayanan,
>>> Vidya; ext Sri Gundavelli; Vijay Devarapalli; Chowdhury, Kuntal 
>>> <chair hat off> I have now read all the mails related to this
>>> topic and I'm not sure I understand the issue compeletely. It
>>> seems that the scenarios when this could happen is when a MN
>>> would have try to access the same access technology twice with
>>> different interfaces. As an example, two WLAN cards were used. I
>>> wonder if this wouldn't be really a corner case.
>>> 
>>> Secondly, if this does happen, I think the problem would also
>>> solve itself: You cannot really connect currently to a Wireless
>>> WAN with the same identity twice (At least 3GPP, or Wimax don't
>>> seem to support it, perhaps 3GPP2 does). So, the only technology
>>> usually based on the MAC address of the WLAN card itself. Thus,
>>> even if the two cards would see the same prefix they would use a
>>> different IID. So, they would look to be on the same subnet, but
>>> with different addresses. I guess that should be ok. Anyways,
>>> such a scenario looks like a configuration error.
>>> 
>>> Hence, I would be ok with just marking that this is currently out
>>> of scope and enabling it would need additional work. I'm ok with
>>> the text Raj has provided, though, it seems a bit of an overkill
>>> (which is fine).
>>> 
>>>> issue. We (authors) recognize the issue... But we believe that
>>>> a complete solution to the problem needs to be dealt with
>>> separately and
>>>> hence it is perfectly okay to state that it is out-of-scope of
>>>> this specification. The WG can decide to work on the issue as a
>>>> 
>>> separate effort.
>>>> Proxy Binding Update from the second MAG is a result of: a. the
>>>> mobile node performing a handoff or b. the mobile node
>>>> attaching via a second interface to another MAG in the Proxy
>>>> Mobile IPv6 domain.
>>>> 
>>>> host are handled. Therefore this  behavior of a multi-homed
>>>> host attaching to a Proxy Mobile IP6 domain via multiple
>>>> interfaces is implementation dependent and out-of-scope for
>>>> this document.
>>>> 
>>>>  binding cache will have the IP address of the MAG that last
>>>> sent a successful Proxy Binding Update as the care-of
>>> address. Since the
>>>> the mobile node are possible, a complete solution for
>>>> multi-homed hosts is considered to be out-of-scope. "
>>>> 
>>>> -Raj
>>>> 
>>> -- Jonne Soininen Nokia Siemens Networks
>>> 
>>> Tel: +358 40 527 46 34 E-mail: [email-masked]
>>> 
>>> 
> 
> 
> 
> _______________________________________________ netlmm mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 01 Oct 2007 14:32:21 -0700

>> to the same access network. :)

I was specifically talking about using multiple interfaces of the same 
access technology.

> 802.16).  To this add the USB when in cradle.

We do need to consider these mobile phones.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 01 Oct 2007 23:40:13 +0200

> I was specifically talking about using multiple interfaces of the same 

The multihoming issue is true even when the access technologies are 
different.

A not-so-advanced Access Router ("Radio Gateway" would say some) has a 
wifi antenna and a wpan antenna and a umts base station.  If we're to 
put a MAG on this access router then that multi-homing must work 
naturally, with a different (set of) prefix(es) for each antenna, and a 
different address assigned to each MN interface... and surely not 
identify the node by a unique user-specific NAI...

> We do need to consider these mobile phones.

ok.

Alex

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 2 Oct 2007 15:36:16 +1000

Folks, 

This thread is going on for a lot longer than it needs to be. As the person
who raised this issue in Chicago, I'd like to make a few comments on this
issue below.

Facts:
- Any IPv6 host can be multihomed by simply enabling two or more interfaces.
- Both interfaces can be connected to the same network/admin domain. 
- Configuring the same address on more than one interface makes this address
an anycast address and breaks several aspects of IP communications. 
- PMIPv6 **can** support this scenario by allocating different addresses to
the node.

Irrelevant points:
- PMIPv6 is not meant to support multihoming. This is a useless argument
because we're talking about hosts that already have these features and how
PMIPv6 will *break* them. If we want to get a spec out in IETF we have to
make sure we don't break existing implementations. 
- An admin domain will only support one interface. This is just not true. 
- Having two interfaces connected to the same network is a corner case. This
is a subjective and irrlevant point to the discussion.

So based on the above, I see no other way for the spec to become standard
without being able to allocated a different address for each interface. How
this is done is a separate issue, but it needs to be done. Otherwise we'd be
producing a buggy specification and we can't do that.

Hesham

 > From: Tsirtsis, George [mailto:[email-masked]] 
 > Sent: Tuesday, October 02, 2007 4:33 AM
 > To: Vijay Devarapalli; Basavaraj Patil
 > Cc: [email-masked]
 > Subject: PMIP compatibility with multihoming RE: [netlmm] 
 > Re: Proposed textfor resolving the multi-homed host issue
 > 
 > Hi Vijay et.al.,
 > 
 > is capable of
 > multi-homed host
 > > solution to the problem needs to be dealt with separately 
 > and hence it
 > is
 > >    via its multiple interfaces. The LMA cannot 
 > differentiate whether
 > the
 > >    (i.e MAGs) may end up with duplicate addresses being 
 > configured on
 > the
 > >    interfaces when IPv6 stateless address 
 > auto-configuration is used
 > and
 > >    not based on a unique ID such as an L2 identifier. The 
 > behavior of
 > the
 > >    In the context of this document, where no changes or 
 > enhancements
 > to

---

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 2 Oct 2007 01:10:10 -0700

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Monday, October 01, 2007 9:44 PM
To: Tsirtsis, George
Cc: Basavaraj Patil; [email-masked]
Subject: Re: PMIP compatibility with multihoming RE: [netlmm] Re:

...

GT2> Vijay, I am really disappointed in you even trying this in a public
mailing list like this. It is unprofessional from your part and offense
to me and if you have any sense of professional conduct you will
apologize.

GT2> When I propose text for the base (or any) specification, I expect
everyone to take it at face value and agree or disagree with it on
technical grounds. If every time one makes an argument, others can
dismiss it based on fantastic allegations of the argument serving some
undefined secret agenda we will never get anything done and will create
an atmosphere.

GT2> BTW, the idea that what we write in the base spec affects the work
of other SDOs is false ...see my e-mail to Sri about that.

George

---

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 2 Oct 2007 01:22:04 -0700

Sri et.al.,

First of all let me reiterate that making multi-homing out of scope is
just not reasonable. You can not prevent multi-homing hosts from
connecting to a multi-system, multi-technology PMIP domain so making
them out of scope is just meaningless. 

I think some people are getting in a bit of a panic with the idea of
clearly restricting the protocol to its current limitations, due to the
fact that organizations like 3GPP (and others) are already using PMIP as
a global mobility management system in inter-technology and inter-domain
scenarios....something that is clearly not in the current scope of this
WG. So there is a (wrong) perception that if the IETF restricts this
protocol, somehow the work of these other organizations is going to be
derailed.

This is of course nonsense, since these organizations already know the
scope of the NETLMM work in the IETF and they obviously do not care.
What the same people are missing is that PMIP's incompatibility with
multi-homing is based on the fact that as part of the base specification
in the IETF, the end nodes are not supposed to be changed i.e.,
base-PMIP must be compatible with any legal IP stack already in
existence.

Such limitations do not exist in 3GPP and other organizations. In 3GPP
for example, for better or for worse, the fact that there will be a
virtual interface hiding physical interfaces is common knowledge and
entirely acceptable. 3GPP is also currently discussing how mobiles will
be signaling their capabilities in terms of inter-system mobility
management directly or indirectly; again this allows them to deal with
mobiles that do and do not support PMIP more effectively.

So, the IETF should do its job properly and define the limitations
imposed to base specification by the fact that (in the context of the
IETF, i.e., the whole Internet as opposed to a specific SDO) the end
hosts are not supposed to be changed in this version of the protocol. A
follow up version then will attempt to resolve some of the limitations,
and so on.

What other organizations do with this protocol in the mean time is not
up to the IETF to say...it never was.

George

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Monday, October 01, 2007 9:25 PM
To: Tsirtsis, George; 'Vijay Devarapalli'
Cc: [email-masked]
Subject: RE: PMIP compatibility with multihoming RE: [netlmm] Re:
Proposedtext for resolving the multi-homed host issue

Hi George,

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Oct 2007 07:26:01 -0700

> undefined secret agenda we will never get anything done and will create

I am not sure what you are so upset about. Today we do have folks that 
are active in multiple standardization bodies like IETF and 3GPP. A 
little bit of skepticism is natural when someone proposes some text in 
one organization which has direct impact on something else that is 
happening in another organization.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Oct 2007 07:50:59 -0700

Hi Hesham,

I have a couple of more facts to add to your list.

> an anycast address and breaks several aspects of IP communications. 

Host implementations prevent configuring the same address on two 
different interfaces. If there is an implementation out there that 
allows assigning the same address to two different interfaces at the 
same time, please let me know.

> - PMIPv6 **can** support this scenario by allocating different addresses to

In PMIPv6 the default mechanism for address configuration is stateless 
address auto-configuration. The home network prefix is advertised to the 
mobile node by the MAG. If the mobile node uses an interface identifier 
it does end up with two different addresses from the same prefix.

> make sure we don't break existing implementations. 

hmm.... I think some folks are also saying "leave it out of scope for 
the base specification". I am fine with taking it up separately in the 
NETLMM WG. It needs extensions either to the PMIPv6 protocol or the host 
implementation (which is not allowed by the current charter). We can 
however mitigate the impact by the LMA detecting this ping pong of proxy 
BUs from the two MAGs and stopping one MAG. This was in the proposed 
text that was sent out.

> - An admin domain will only support one interface. This is just not true. 

This is tied to the way PMIPv6 uses the mobile node ID. The mobile node 
is always identified by this identifier. Even binding cache lookups are 
done based on the identifier. So in the context of PMIPv6 base spec, 
this is true. You could of course argue for including support for this 
in the base PMIPv6 spec. We can't have a scenario of a mobile node with 
one identifier but two different PMIPv6 home addresses attached to the 
same LMA. It won't work.

There are other configurations possible. The MAG could connect the 
mobile node to two different LMAs (with two different PMIPv6 home 
addresses). This will work.

> is a subjective and irrlevant point to the discussion.

Here I disagree. A mobile node having two interfaces of the access 
technology type, both trying to connect to the same interface *is* a 
corner case.

> producing a buggy specification and we can't do that.

Hope what I wrote helps.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Oct 2007 08:12:26 -0700

> follow up version then will attempt to resolve some of the limitations,

Isn't this what we are trying to do with the text below? The text below 
describes the problem, describes the impact (the oscillating part), 
proposes one solution for minimizing the impact and points out that 
dealing with this without host changes is not possible in the current 
document. What did we miss? We can of course revise the text if you 
think something is not covered.

   Since the mobile node is attached to the same Proxy Mobile IPv6 domain

   binding cache entry will have the IP address of the MAG that last sent
   mobile node turns of the one of the interfaces or if the LMA instructs

> up to the IETF to say...it never was.

I would like to avoid an SDO using a protocol in a way that is 
prohibited by IETF specifications.

Vijay

---

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 2 Oct 2007 08:54:47 -0700

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Tuesday, October 02, 2007 3:26 PM
To: Tsirtsis, George
Cc: Basavaraj Patil; [email-masked]
Subject: Re: PMIP compatibility with multihoming RE: [netlmm] Re:

GT3> Yes and you are one of these people attending multiple forums. I
can also say that the only reason you are refusing to properly limit the
scope of the base specification is because you have an agenda in an SDO
about using this protocol in ways that are not sanction by the IETF.
This statement may or may not be true but I do not believe it helps this
discussion one bit.

GT3> Now my public opinions in the IETF also happen to span company
affiliations, never mind projects in SDOs, so do not find it strange
that I take offence. I take even more offence by the fact that you
refuse to apologize for something so obviously wrong.

George

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Oct 2007 09:28:04 -0700

> about using this protocol in ways that are not sanction by the IETF.

Sure you could. Fact is I do not like to see an SDO using an IETF 
protocol in a manner that is prohibited by the IETF. Not good in the 
long run. Tomorrow we don't know what else the SDO might ignore from the 
IETF specification.

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 2 Oct 2007 11:17:32 -0700

Hi Hesham et al,

> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Monday, October 01, 2007 10:36 PM
> To: [email-masked]
> Subject: RE: PMIP compatibility with multihoming RE: [netlmm] 
> Re: Proposedtextfor resolving the multi-homed host issue
> 
> Folks, 
> 

A host will not configure the same identifier and in the same prefix
on more than one interface at any point of time. This is true on all
IPv6 platforms that have passed any basic IPv6 host compliance test.
I've already copied the output from cisco implementation. This is true
for Linux 2.6 and NETBSD. I do know why this comment keeps comming
back from Vidya and now you made this comment. Initially Vidya claimed
the host will shutdown both the interfaces if it configures the same
address and we keep asking which IPv6 implementation configures the
same address and shuts down its interfaces ?  The answer never comes
from her.

> - PMIPv6 **can** support this scenario by allocating 

If you want that restriction for what ever reasons, that is ok. But,
its not multi-homing that is the reason for the restriction, lets agree
to that.

The document specifies what it supports and what it does not. Operator
can decide what suits their requirements.

The NETLMM's idea of host not required to participate in any mobility
signaling, we are taking this line to the extreme limits. Sure, the host
is not required in mobility related signaling. It does not imply the
operator will have zero software addition to the host. If multi-homing
is desired, they will install the connection manager software and that
will have the logic what interfaces to enable or disable and the
interface preferences. 

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 2 Oct 2007 11:30:24 -0700

Hi George, 

> Sent: Tuesday, October 02, 2007 1:22 AM
> To: Sri Gundavelli; Vijay Devarapalli
> Cc: [email-masked]
> Re: Proposedtext for resolving the multi-homed host issue
> 
> Sri et.al.,
> 

The protocol is not requiring changes to end-host behaviour. We are using
this multi-homing argument to justify some thing else. When an IP host
is connected to the network and for simultaneous access, there needs to
be a connection manager, else the connectivity of the host is unspecified
and unpredictable. This is irrelevant of the fact, if the node is using
the same prefix on multiple interface or different prefixes in different
interfaces and it is also irrelevant of the fact if the node is in a 
PMIP6 domain or outside.

As I said yesterday, its not magic that we enable multiple interfaces on
a host, the system will do load balancing over the links, do the source
address selection and if one interface shutdown, it will move the flows
to the other interface. The host will use ONLY one active link at any
time and thats the basic limitation of a multi-homed host. So, when 
some one connects a multi-homed host to the PMIP6 network or to any
network, there needs  to be additional software on the host or virtual
interface abstracting the physical interfaces. Today, why does all the
operators ship the cellular data cards with connection manager software ?
To essentially manage the multi-host behaviour and PMIP6 requires the 
same.

I do not see any valid arguments from Vidya or any one of you three folks,
as why we should restrict PMIP6 to the point of uselesness. Its incredible,
NETLMM group never considered multi-homing work item, even when the DT was
working on it. This was never in the charter, there is no open issue on
this. From no where and just before the LC is done and after none of the
other official reviewers even mentioned about this, Vidya brings this
multi-homing argument and stops the document. We were working so much to
meet the dates and here we loose all the time on some work item which is
not scope. 

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 2 Oct 2007 13:23:35 -0700

>Initially Vidya claimed the host will shutdown both 
> the interfaces if it configures the same address and we keep 
> asking which IPv6 implementation configures the same address 
> and shuts down its interfaces ?  The answer never comes from her.

You may want to read emails more carefully.  I never said the host will
shut down both interfaces.  I also clarified that shutting down an
interface upon duplicate address detection is one possibility and that
regardless of whether the interface is shut down or not, IP forwarding
will not be enabled on the second interface (as a result of the address
not being configured on that interface). 

Vidya

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 2 Oct 2007 13:30:15 -0700

Ok ! Fine. Can you explain why two interfaces will endup with the
same address in PMIP6 domain ?

- When using 3041 
- When using 2462
- When using 3315 

Thanks
Sri

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Tuesday, October 02, 2007 1:24 PM
> To: Sri Gundavelli; Hesham Soliman; [email-masked]
> Re:Proposedtextfor resolving the multi-homed host issue
>

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 02 Oct 2007 15:30:16 -0500

Hi Hesham,

Good points...

A few comments below:

> - Any IPv6 host can be multihomed by simply enabling two or more interfaces.

Raj> Yes. 

> - Both interfaces can be connected to the same network/admin domain.

Raj> Yes. This is possible.

> an anycast address and breaks several aspects of IP communications.

Raj> I think the same address being configured on the interface is actually
quite remote (however not impossible). If address config is via SLAAC and
the host receives the same prefix, the address would be unique if an IEEE
identifier like a MAC address is used. If DHCP is used for address
assignment, the DHCP server (which maintains the pool for that prefix) would
assign a different address from the one assigned to IF1 (since the address
assigned to IF1 was already leased). The only possibility for the host to
create a duplicate address is if RFC3041 type approach was taken to address
creation. But even in such a case the probability is low.
So I don't think there will be duplicate addresses assigned to the
interfaces (and the probability of such duplication is very low).

> - PMIPv6 **can** support this scenario by allocating different addresses to

Raj> A host which receives the same prefix (in an RA) via different
interfaces (as a result of attaching to MAGs in the same PMIP6 domain) will
result in different addresses being generated (or assigned).

-Raj

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 2 Oct 2007 13:56:18 -0700

Sri,
I think I am now repeating myself several times here.  I never claimed
that duplicate addresses will actually be *assigned* to muultiple
interfaces.  The problem exists due to the disparity in the interface
being recognized by PMIP vs. the interface that is actually active on
the MN.  

Please read at least the Take 2  of the problem description I sent to
the list again.  It describes the problem in detail and how it exists
whether or not the actual same address gets assigned to the multiple
interfaces.  

Vidya 

> Sent: Tuesday, October 02, 2007 1:30 PM
> To: Narayanan, Vidya; 'Hesham Soliman'; [email-masked]
> Ok ! Fine. Can you explain why two interfaces will endup with 
> the same address in PMIP6 domain ?
> 
> - When using 3041
> - When using 2462
> - When using 3315 
> 
> Thanks
> Sri
> 
> 
>  
> 
> > >Initially Vidya claimed the host will shutdown both  the 
> interfaces 
> > >if it configures the same address and we keep  asking which IPv6 
> > >implementation configures the same address  and shuts down its 
> > >interfaces ?  The answer never comes from her.
> > 
> > You may want to read emails more carefully.  I never said the host 
> > will shut down both interfaces.  I also clarified that 
> shutting down 
> > an interface upon duplicate address detection is one 
> possibility and 
> > that regardless of whether the interface is shut down or not, IP 
> > forwarding will not be enabled on the second interface (as 
> a result of 
> > the address not being configured on that interface).
> > 
> > Vidya
>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 2 Oct 2007 14:01:48 -0700 (PDT)

Vidya,

Please answer one question or repeat one more time.

Will an IPv6 host in a Proxy Mobile IPv6 domain end up configuring
the same 128-bit IPv6 address on more than one interface at any
point of time ? [Yes/No]

Thanks
Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Oct 2007 14:03:30 -0700

> being recognized by PMIP vs. the interface that is actually active on

See http://www1.ietf.org/mail-archive/web/netlmm/current/msg03409.html

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Oct 2007 23:21:02 +0200

> not being configured on that interface). 

It is very probable that a IPv6 host with two interfaces on same subnet 
and same address, doing DAD on both link-local and on global _will_ shut 
these interfaces down.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Oct 2007 23:26:49 +0200

Basavaraj Patil wrote:
>> This thread is going on for a lot longer than it needs to be. As 
>> the person who raised this issue in Chicago, I'd like to make a few
>>  comments on this issue below.
>> 
>> Facts: - Any IPv6 host can be multihomed by simply enabling two or
>>  more interfaces.
> 
> Raj> Yes.
> 
>> - Configuring the same address on more than one interface makes 
>> this address an anycast address and breaks several aspects of IP 
>> communications.
> 
> Raj> I think the same address being configured on the interface is 
> actually quite remote (however not impossible). If address config is
>  via SLAAC and the host receives the same prefix, the address would
> be unique if an IEEE identifier like a MAC address is used. If DHCP
> is used for address assignment, the DHCP server (which maintains the
>  pool for that prefix) would assign a different address from the one
>  assigned to IF1 (since the address assigned to IF1 was already 
> leased).

In order for DHCP to do that, it will have to identify the node, and to
identify it it will use MAC address, or subscriber-id, or remote-id.
And it will _not_ use NAI.  PMIP6 uses NAI exclusively.  So PMIP6 can't
ensure the same uniqueness DHCP can.

> The only possibility for the host to create a duplicate address is if
>  RFC3041 type approach was taken to address creation. But even in 
> such a case the probability is low.

It's not the only possibility.

If the mobile has a ppp and a usb interface, the iid negotiation happens
by some unknown rules (for ppp we have an rfc but for usb there isn't,
just implementations) - the risk of colliding on the link-local address
between these two interfaces is _very_ high.

> interfaces (and the probability of such duplication is very low).

I think it's higher than just rfc3041 randomness.

>> - PMIPv6 **can** support this scenario by allocating different 
>> addresses to the node.
> 
> interfaces (as a result of attaching to MAGs in the same PMIP6 
> domain) will result in different addresses being generated (or 
> assigned).

_Iff_ their IIDs are MAC addresses assigned by IEEE.  (USB isn't, and
Wireless USB isn't either I believe).

Alex

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 2 Oct 2007 15:05:18 -0700

That email said that the MN will "see" the same address on its new
interface - i.e., see the assigned address being the same; not that it
will actually configure it.  I have now tried to clarify the confusion
on duplicate address "configuration" or interface shutting down several
times.  See this message where I tried to explain in detail: 

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

Vidya

> Sent: Tuesday, October 02, 2007 2:04 PM
> To: Narayanan, Vidya
> Cc: Sri Gundavelli; Hesham Soliman; [email-masked]
> Subject: Re: PMIP compatibility with multihoming RE: [netlmm] 
> > interfaces.  The problem exists due to the disparity in the 
> interface=From [email-masked] Tue Oct 02 18:06:16 2007
Content-class: urn:content-classes:message
Subject: RE: [netlmm] Way forward on PMIP multihoming discussion
Date: Wed, 3 Oct 2007 00:04:18 +0200
From: <[email-masked]>
To: <[email-masked]>,
	<[email-masked]>,
	<[email-masked]>
Cc: 

--=======25960253=
Content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64

+IFN1YmplY3Q6IFJFOiBbbmV0

--=======25960253=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--=======25960253=--

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 2 Oct 2007 15:05:18 -0700

Vidya

> interface

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 2 Oct 2007 15:06:01 -0700

Sri,  

> Sent: Tuesday, October 02, 2007 2:02 PM
> To: Narayanan, Vidya
> Cc: Hesham Soliman; [email-masked]
> Will an IPv6 host in a Proxy Mobile IPv6 domain end up 
> configuring the same 128-bit IPv6 address on more than one 
> interface at any point of time ? [Yes/No]
> 

No, in case it hasn't been clear in all my emails already.  This is also
clear from RFC2462. 

Vidya

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 2 Oct 2007 15:18:19 -0700 (PDT)

> No, in case it hasn't been clear in all my emails already.  This is also

Ok. Thank you.

So, if multiple interfaces configure different addresses, do you agree
if we  support simultaneous bindings, there will not be any further
issues. The host will not see any network disruption even when using
multi-homing [Yes/No]

Thanks
Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 2 Oct 2007 15:23:40 -0700

> 
> So, if multiple interfaces configure different addresses, do 
> you agree if we  support simultaneous bindings, there will 
> not be any further issues. The host will not see any network 
> disruption even when using multi-homing [Yes/No]
> 

I hope we are not into a sequential Q&A session discussing this whole
issue again.  To this question: 

No and please read
http://www1.ietf.org/mail-archive/web/netlmm/current/msg03559.html for
why there is still an issue with disruption. 

Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Oct 2007 15:46:21 -0700

Narayanan, Vidya wrote:
> times.  

Never mind then. :) It is good that you agree that the same address is 
not typically assigned to two interfaces.

Now lets go to your take2.

> * 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; 

In this case there is only one interface up, interface1.

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

In this case the mobile node ends up with two different addresses on the
two interfaces from the same prefix. Do you agree so far?

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

This is recoverable. Since interface2 is down, MAG2 de-registers with
the LMA. MAG1 refreshes its binding and now routing is setup through
MAG1. The MN is now able to send/receive packets through Interface1.
This takes time however, there will be a period of time when the UE is
not able to send/receive packets.

> * 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 this both MAG1 and MAG2 keep trying to refresh the binding
constantly. This results in what we called the "oscillation" before. The
binding cache entry on the LMA keeps changing constantly based on the
last proxy BU received.

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

When the LMA detects this constant toggling, it rejects the proxy BUs
from one of the MAGs. If the LMA rejects the proxy BUs from MAG1, the
mobile node has connectivity though interface2. If the LMA rejects the
proxy BUs from MAG2, the mobile node has connectivity through inteface1.
We would need a new error code in the Proxy Binding Ack for this. Again,
there will be a period of time when the UE is not able to send/receive
packets.

So where is the issue?

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 2 Oct 2007 16:50:59 -0700

> Sent: Tuesday, October 02, 2007 3:24 PM
> To: Sri Gundavelli

No. It will. Support for simultaneous bindings will fix it and that
can be done in a seperate document. I will send the call flows tonight
or tomorrow.

Thanks
Sri

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 3 Oct 2007 10:44:34 +1000

> it does end up with two different addresses from the same prefix.

=> And as I'm sure everyone knows, the IPv6 model requires a unique prefix
per link.
So this model of address allocation is broken.

 > This is tied to the way PMIPv6 uses the mobile node ID. 

=> I'm not talking about PMIPv6. I'm talking about the real world. 

 > technology type, 

=> I didn't say anything about access technology types. I said two
interfaces connected to the same network, whether they are the same access
technology or not is irrelevant.

Hesham

---

From: "Tsirtsis, George" <[email-masked]>
Date: Thu, 4 Oct 2007 01:03:52 -0700

Vijay, please see some notes inline...

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Tuesday, October 02, 2007 11:46 PM
To: Narayanan, Vidya
Cc: [email-masked]
Subject: Re: PMIP compatibility with multihoming RE:[netlmm]

...

the LMA. 

GT> It is not obvious that this is always a realistic assumption.
Whether turning off an IP interface results automatically in bringing
the corresponding L2 down and thus, at some point informing MAG2 of that
fact, is both a device implementation and access technology issue.

MAG1 refreshes its binding and now routing is setup through
MAG1. 

GT> Why would MAG1 reregister? Nothing has changed in the link between
the MN and MAG1. Are you talking about refreshing because of the
Lifetime? That could typically be every 30min or even hours, it is
entirely system dependent and it is so long that it can not be used to
detect anything useful here! I think the rest of your argument below
depends on this point so could you please clear this up first before we
continue?

The MN is now able to send/receive packets through Interface1.
This takes time however, there will be a period of time when the UE is
not able to send/receive packets.

So where is the issue?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 05 Oct 2007 11:07:08 -0700

Hi George,

Sorry for the delay in responding.

> fact, is both a device implementation and access technology issue.

hmm... I agree it might result in a "L2 down event", but we do have a 
requirement for the MAG to check if the mobile node is still connected 
once in a while in the base PMIPv6 specification. So the MAG2 will 
detect that the mobile node is not responding and de-register with the LMA.

> depends on this point so could you please clear this up first before we

Yes it would take quite a bit of time. But it can be faster if for 
example the MAG1 detects no traffic coming from the LMA for the mobile 
node or the LMA were to send a revocation message back to the MAG1 when 
MAG2 updated the binding cache entry. Another option is for us to use 
the Binding Error mobility header message. This message is used when the 
node things it has a binding cache entry and sends a packet whereas 
there is no corresponding binding cache entry. We could have the LMA 
send a binding error when it sees tunneled packets for the mobile node's 
home network prefix with MAG1 as the source address on the outer IP 
header when the binding cache entry at the LMA says MAG2 is the current 
CoA for the mobile node's home network prefix.

Vijay