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

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 1 Oct 2007 12:26:42 -0700 (PDT)

Hi Jonne,
  Do you think that it is time to start a discussion on rechartering netlmm now? 
  It seems that such a discussion might help ease the pressure on the base PMIP6 and maybe we can get a WGLC faster this way?

Kind regards,

Behcet

----- Original Message ----
From: Soininen Jonne (NSN FI/Espoo) <[email-masked]>
To: Basavaraj Patil <[email-masked]>; "[email-masked]" <[email-masked]>
Cc: Vijay Devarapalli <[email-masked]>
Sent: Monday, October 1, 2007 7:09:32 AM
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

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 1 Oct 2007 21:20:13 -0700

> > 
> [KC>] As I said before, this could happen with private IPv4 
> addressing over these access technologies. What is the remedy 
> for that?
> 

With private IPv4 addressing with no PMIP, the MN may obtain the same IP
address over multiple prefixes and will likely refrain from configuring
the duplicate address on the second interface.  This is similar to the
case here that the MN will not configure the duplicate address on the
second interface here either.  But, the similarity ends there. 

Now the difference - in the case with no PMIP, the MN is still able to
use its first interface.  In the case with PMIP, the LMA will drop
packets sent from the first interface, since the binding towards the
second interface is the right one from a PMIP perspective.  Hence, the
MN is unable to use its first interface.  This is the important
difference that makes both interfaces of the MN useless when PMIP is
enabled, vs. just one being useless upon regular duplicate IP address
detection without PMIP. 

Vidya

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 2 Oct 2007 01:07:47 -0400

Vidya,

The purpose of those two sentences regarding collision of private v4
address over multiple interfaces of a host was to point out to you that
address collision might happen even w/o the use of PMIP6 or MIP6. The
context was limited to the possibility of address collision in the MN.
However, your reply is not telling us what the remedy is for such
address collision (the question that I asked). Rather it goes on a
pedantic tangent...

Please see inline....

> -----Original Message-----
> From: Narayanan, Vidya [mailto:[email-masked]]
> Sent: Monday, October 01, 2007 11:20 PM
> To: Chowdhury, Kuntal; Vijay Devarapalli
> Cc: Soininen Jonne (NSN FI/Espoo); Basavaraj Patil; [email-masked];
ext
> Sri Gundavelli
> Subject: RE: Proposed text for resolving the multi-homed host issue
> 
> > >
[KC>] for v4 if it is *likely* that the MN will refrain from configuring
the same address over the second interface why isn't it *likely* that
the MN will refrain from doing the same for v6? After all, that's' what
Sri pointed out using his Cisco native IPv6 implementation...

> enabled, vs. just one being useless upon regular duplicate IP address
[KC>] This issue was raised before on this thread and it was countered
by Vijay. Here are two possible fallback / recovery mechanisms that you
should note down: (cut and paste from previous email)

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

---

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

Some comments on the text below.  

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

This will only happen if the MN actually shut down its second interface.
As we have heard many times on this thread now, if the MN doesn't shut
down its interface, but, just doesn't configure the address, MAG2 would
not know that that interface of the MN is not active, for instance.  

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

Even if the binding corresponding to MAG2 were to be deleted and MAG1's
refresh were to take effect, the lifetime of the PMIP session would
determine how quickly connectivity can be restored to the MN. 

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

I don't understand how the above would work.  If MAG1 was told that the
MN's binding was being revoked, the MAG should be revoking access to the
MN, outside of the PMIP protocol.  So, the MN will not be able to
connect via that MAG again.  So, I don't see how MAG1 can send another
PBU after the binding has been revoked.  And, the MAG2 not sending a PBU
again relies on the interface being shut down, which, may not be the
case. 

Thanks,
Vidya