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

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Mon, 1 Oct 2007 14:46:28 -0400

> -----Original Message-----
> From: Narayanan, Vidya [mailto:[email-masked]]
> Sent: Monday, October 01, 2007 1:38 PM
> To: Vijay Devarapalli
> Cc: Soininen Jonne (NSN FI/Espoo); Basavaraj Patil; [email-masked];
ext
> Sri Gundavelli; Chowdhury, Kuntal
> Subject: RE: Proposed text for resolving the multi-homed host issue
> 
> 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.
> 
[KC>] As I said before, this could happen with private IPv4 addressing
over these access technologies. What is the remedy for that?

> Vidya
> 
> > -----Original Message-----
> > From: Vijay Devarapalli [mailto:[email-masked]]
> > Sent: Monday, October 01, 2007 11:23 AM
> > To: Narayanan, Vidya
> > Cc: Soininen Jonne (NSN FI/Espoo); Basavaraj Patil;
> > [email-masked]; ext Sri Gundavelli; Chowdhury, Kuntal
> > Subject: Re: Proposed text for resolving the multi-homed host issue
> >
> > Narayanan, Vidya wrote:
> > > Vijay,
> > >
> > >> -----Original Message-----
> > >> 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
> > >> Subject: Re: Proposed text for resolving the multi-homed host
issue
> > >>
> > >> 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.
> > >> 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.
> >
> > 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
> > > 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.
> >
> > 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
> > >
> > >>> 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 :)
> > >>
> > >> For what? Makes no sense to me.
> > >>
> > >> 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.
> > >>
> > >> 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
> > >>>
> > >>>> -----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
> > >>>> Subject: 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: "Tsirtsis, George" <[email-masked]>
Date: Tue, 2 Oct 2007 01:25:56 -0700

Kuntal,

There is no remedy for that, because IPv4 is broken i.e., it does not
guaranty that IP addresses are unique. Remember this is the main reason
IPv6 was invented. Just because IPv4 has a bug, it should not mean we
should artificially now replicate the same bug in IPv6.

Regards
George 

-----Original Message-----
From: Chowdhury, Kuntal [mailto:[email-masked]] 
Sent: Monday, October 01, 2007 7:46 PM
To: Narayanan, Vidya; Vijay Devarapalli
Cc: [email-masked]
Subject: [netlmm] RE: Proposed text for resolving the multi-homed host
issue

ext

issue
tunnel
network.
place
same
the
document.
keep