Behavior of Collocated HA/LMA
draft-tsirtsis-logically-separate-lmaha-00.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 26, 2008.

Abstract

In discussions about PMIPv6-MIPv6 interactions in NETLMM WG, scenario C describes the case of collocation of LMA and HA function. In this case a PMIP network emulates the "home link" for MNs using MIPv6. This document argues that even when LMA and HA functions are Collocated they MUST be treated as logically separate entities. In particular this draft argues that PMIP BCEs MUST NOT overwrite MIPv6 BCEs and vice versa.

Table of Contents

1.  Requirements notation
2.  Acknowledgments
3.  Introduction
4.  The Case for Logically Separate LMA and HA
    4.1.  Logical Relationship Between Colocated LMA/HA
        4.1.1.  BCE Overwritting is Wrong
        4.1.2.  Shared State between LMA and HA
5.  Detailed Bootstrapping and Handoff Considerations
    5.1.  Bootstrapping on Emulated Home Link
    5.2.  Connecting to Foreign Link
    5.3.  Connecting Back to Emulated Home Link
6.  Security Considerations
7.  IANA Considerations
8.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Requirements notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Acknowledgments

We would like to thank the authors of PMIPv6-MIPv6 interactions draft [I‑D.giaretta‑netlmm‑mip‑interactions] (Giaretta, G., “Interactions between PMIPv6 and MIPv6: scenarios and related issues,” November 2007.) for providing the basis for this discussion.

3.  Introduction

In PMIPv6-MIPv6 interactions draft [I‑D.giaretta‑netlmm‑mip‑interactions] (Giaretta, G., “Interactions between PMIPv6 and MIPv6: scenarios and related issues,” November 2007.), scenario C describes the case of collocation of LMA and HA function. In this case a PMIP network emulates the "home link" for MNs using MIPv6. This document argues that even when LMA and HA functions are Collocated they MUST be treated as logically separate entities. In particular this draft argues that PMIP BCEs MUST NOT overwrite MIPv6 BCEs and vice versa.

4.  The Case for Logically Separate LMA and HA

When a PMIPv6 [I‑D.ietf‑netlmm‑proxymip6] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” February 2008.) local mobility agent is collocated with a MIPv6 [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) home agent, the PMIPv6 network can be configured to emulate the MIPv6 "home link" for a mobile node using MIPv6. This configuration and its implications are discussed below.

4.1.  Logical Relationship Between Colocated LMA/HA

A PMIPv6 network comprising an LMA and multiple MAGs emulates a single link. When a PMIPv6 LMA and a MIPv6 HA are Collocated, PMIPv6 is used to handle mobility between MAGs in the same PMIPv6 network emulating the link, and MIPv6 is used to handle mobility between different links (emulated or physical).

In that sense, logically, the PMIPv6 LMA operates at a lower layer than the MIPv6 HA. This means that when a packet is received by the LMA/HA, the destination address of the packet is first matched against Binding Cache Entries (BCE) created by MIPv6 BUs. If there are no MIPv6 BCEs for this destination address (i.e., the MN is deregistered at MIPv6 level) then LMA BCEs are searched.

This simple way of thinking about logically separating the two functions, ensures that MNs can move between PMIPv6 emulated links and other links the same way the do between physical links and without require any specific implementation of the combined LMA/HA.

Indeed, the two logical functions can be implemented as two different but communicating processes or as a single integrated process. The BCE tables of the LMA and the HA can also be combined in a single table or they can be maintained as separate tables. This draft does not impose, propose, or in any other way imply any specific implementation. Instead, this draft describes the required external behavior of such a combined LMA/HA implementation and argues against PMIPv6 BCEs overwriting MIPv6 BCEs.

4.1.1.  BCE Overwritting is Wrong

There is currently a school of thought in the NETLMM WG that wants PMIPv6 PBUs to overwrite state created by PMIPv6 BUs and vice versa. This school of thought comes from a fundamental assumptions that as MNs move from one link to another, they only maintain ONE link at a time. In other words the assumption is that during a handoff an MN will disconnect from one link and connect to another. In that sense, when a combined HA/LMA receives a MIPv6 BU over a foreign link, it can overwrite any state created in the LMA for the same mobile (since presumably the MN is no longer connected to the MAG). Based on the same logic when an combined HA/LMA receives a PMIPv6 BU over a MAG on the home link, it can overwrite any state created in the HA for the same mobile (since presumably the MN is no longer connected to a foreign link).

This logic breaks down if one considers MNs that are capable of maintaining more than one link at the same time. Such capability is common and can be utilised in many different way, while specifically MIPv6 allows for the following behavior:

Directing traffic between foreign links: If an MN can maintain two links at the same time, it can direct traffic to one or the other link by simply sending a BU to its HA, registering the CoA corresponding to one or the other link.

Directing traffic between home and foreign link: If one of the links maintained is the home link, the MN can direct traffic to it by sending a deregistration MIPv6 BU to the HA over the home link, while it can also direct traffic to the foreign link by sending a MIPv6 BU to the HA directing traffic to the CoA of the foreign link.

Directing traffic between Multiple links: MEXT WG is also working on [I‑D.ietf‑monami6‑multiplecoa] (Ernst, T., Nagami, K., and V. Devarapalli, “Multiple Care-of Addresses Registration,” February 2008.) and [I‑D.soliman‑monami6‑flow‑binding] (Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi, “Flow Bindings in Mobile IPv6 and Nemo Basic Support,” November 2007.) specifications allowing an MN to register multiple links (multiple CoAs and the home link) to its HA at the same time and even direct different flows to different links.

It should be clear that none of this can be possible if every time the MN connects to its home link, the corresponding PMIPv6 BCE overwrites the HA BCEs for the same mobile or every time the MN sends a BU to its HA over a foreign link, the MIPv6 BCE overwrites the LMA BCE entry for the same MN.

4.1.2.  Shared State between LMA and HA

If the HA is configured as a virtual home link HA (i.e., there is no direct link between MN and HA), there are no need to share any parameters between HA and LMA functions. The LMA and HA function, however, need to share certain parameters in a Collocated implementation if the PMIPv6 network is used as a home link, i.e., if the PMIPv6 network emulates a direct connection between the MN and the HA. The parameters that need to be shared in this case have to do with the addresses assigned to the MN by the two entities. Specifically:

When an LMA receives a PBU for a new MN, it MUST first check if the MN is associated with the Collocated HA e.g. based on the MN-ID. If the HA already has a home address associated with this MN, then the LMA MUST allocate the same address over the PMIPv6 home link.

When an HA receives an IKEv2 bootstrapping request for a new MN, it MUST first check if the MN is associated with the Collocated LMA e.g. based on the MN-ID. If the LMA already has a prefix associated with this MN, then the HA provide the MN with the same HNP over the IKEv2 session.

5.  Detailed Bootstrapping and Handoff Considerations

5.1.  Bootstrapping on Emulated Home Link

When an MN connects to a MAG in a PMIPv6 network, it receives an RA indicating a prefix that is topologically correct at the LMA and unique to the MN. This prefix can be used by the MN to autoconfigure one (or more) IPv6 address. This address continues to be valid as the MN moves between MAGs in the same PMIPv6 network. This is so since every time the MN moves to a new MAG, the MAG sends a PBU to the LMA creating a PMIPv6 Binding Cache Entry (BCE), binding the MN's prefix with a MAG's address. Any packet with a destination address matching the MN's prefix, is directed to the LMA, which based on the BCE table it tunnels the packet to the appropriate MAG which then delivers it to the MN.

Assume now that the MN, equipped with an IPv6 address derived from a prefix provided to it over the link emulated by the PMIPv6 network, wants to bootstrap MIPv6. Also assume that the HA used by the MN is the one Collocated with the LMA of the PMIPv6 network the MN is connected to. This address is maybe discovered by Dynamic HA Address Detection (DHAAD) as defined in [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) or by any of the bootstrapping mechanisms [RFC5026] (Giaretta, G., Kempf, J., and V. Devarapalli, “Mobile IPv6 Bootstrapping in Split Scenario,” October 2007.) [I‑D.ietf‑mip6‑bootstrapping‑integrated‑dhc] (Chowdhury, K. and A. Yegin, “MIP6-bootstrapping for the Integrated Scenario,” July 2007.).

The MN proceeds to establish a security association with it using IKEv2. According to [RFC5026] (Giaretta, G., Kempf, J., and V. Devarapalli, “Mobile IPv6 Bootstrapping in Split Scenario,” October 2007.), as part of this procedure the HA can provide the home network prefix (HNP) to the MN. The MN immediately understands that it is attached to its MIPv6 home link since the prefix advertised to it directly over the link (in an RA) matches the HNP provided to it by the HA. In this case the MN does not need to send a MIPv6 BU to the HA and the logical HA function does not get initiated.

In other words, any packet sent to the MN's prefix is still intercepted by the LMA and redirected to the appropriate MAG (according to PMIPv6 BCE table) for delivery to the MN over the emulated home link.

5.2.  Connecting to Foreign Link

If the MN connects to an access router that is not part of the same PMIPv6 network as before i.e., on a foreign link, it will receive an RA with a different prefix (say a foreign prefix) and generates an IP address on the foreign link.

Note that up to now nothing has changed at the Collocated LMA/HA. All traffic is still redirected by the LMA to the registered MAG according to the state in the PMIPv6 BCE table. For this to change the MN needs to send a MIPv6 BU to the HA. The BU introduces an entry to the MIPv6 BCE, binding the MN's prefix to the CoA. Any packets now reaching the LMA/HA will now match the MIPv6 BCE and be redirected to the CoA.

Note that the MIPv6 BCE created by the BU sent over the foreign link MUST NOT overwrite the PMIPv6 BCE for the same MN. The PMIPv6 BCE for this MN is removed only if and when the MN disconnects from the MAG in the PMIPv6 domain and has nothing to do with the HA state. Indeed, according to when a MAG an MN disconnects from a MAG, the MAG is supposed to send a deregistration BU to the LMA removing the corresponding BCE for that MN.

5.3.  Connecting Back to Emulated Home Link

Now say that after the MN has disconnected to from the PMIPv6 MAG and registered to the HA via a foreign link, the MN connects again to its emulated home link via one of the MAGs in the PMIPv6 network.

The MAG the MN connects to, is supposed to send a PBU to the LMA. Since the MN maintains a relationship with the HA, the LMA should provide the same prefix as before i.e., the HNP. This means that when the MN receives the RA from the MAG, which includes the a prefix matching its HNP, it will detect that this emulated link is its home link.

Note that the PBU sent by the MAG MUST NOT overwrite the MIPv6 BCE pointing to the foreign link for this MN. This is because the MAG can not possibly know whether the MN still maintains the foreign link or not. Indeed, if the MN wants to receive its traffic over the home link it will sent a deregistration MIPv6 BU to the HA and remove the MIPv6 BCE. When that happens packets will again reach the LMA and be redirected according to the PMIPv6 BCE to the appropriate MAG.

6.  Security Considerations

This document does not introduce security issues

7.  IANA Considerations

This document requires no action from IANA.

8. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.