Network Working Group G. Tsirtsis
Internet-Draft Qualcomm
Intended status: Standards Track S. Krishnan
Expires: September 26, 2008 Ericsson
October 20, 2008
Behavior of Collocated HA/LMA
draft-tsirtsis-logically-separate-lmaha-01.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 April 23, 2009.
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.
Tsirtsis & Krishnan Expires April 23, 2009 [Page 1]
Internet-Draft Behavior of Collocated HA/LMA March 2008
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. The Case for Logically Separate LMA and HA . . . . . . . . . . 3
4.1. Logical Relationship Between Colocated LMA/HA . . . . . . . 3
4.1.1. BCE Overwritting is Wrong . . . . . . . . . . . . . . . 4
4.1.2. Shared State between LMA and HA . . . . . . . . . . . . 5
5. Detailed Bootstrapping and Handoff Considerations . . . . . . . 5
5.1. Bootstrapping on Emulated Home Link . . . . . . . . . . . . 5
5.2. Connecting to Foreign Link . . . . . . . . . . . . . . . . 6
5.3. Connecting Back to Emulated Home Link . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Tsirtsis & Krishnan Expires April 23, 2009 [Page 2]
Internet-Draft Behavior of Collocated HA/LMA March 2008
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].
2. Acknowledgments
We would like to thank the authors of PMIPv6-MIPv6 interactions draft
[I-D.giaretta-netlmm-mip-interactions] for providing the basis for
this discussion.
3. Introduction
In PMIPv6-MIPv6 interactions draft
[I-D.giaretta-netlmm-mip-interactions], 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] local mobility agent is
collocated with a MIPv6 [RFC3775] 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.
Tsirtsis & Krishnan Expires April 23, 2009 [Page 3]
Internet-Draft Behavior of Collocated HA/LMA March 2008
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.
Tsirtsis & Krishnan Expires April 23, 2009 [Page 4]
Internet-Draft Behavior of Collocated HA/LMA March 2008
Directing traffic between Multiple links: MEXT WG is also working
on [I-D.ietf-monami6-multiplecoa] and
[I-D.soliman-monami6-flow-binding] 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
Tsirtsis & Krishnan Expires April 23, 2009 [Page 5]
Internet-Draft Behavior of Collocated HA/LMA March 2008
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] or by any of the
bootstrapping mechanisms [RFC5026]
[I-D.ietf-mip6-bootstrapping-integrated-dhc].
The MN proceeds to establish a security association with it using
IKEv2. According to [RFC5026], 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.
Tsirtsis & Krishnan Expires April 23, 2009 [Page 6]
Internet-Draft Behavior of Collocated HA/LMA March 2008
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
[I-D.giaretta-netlmm-mip-interactions]
Giaretta, G., "Interactions between PMIPv6 and MIPv6:
scenarios and related issues",
draft-giaretta-netlmm-mip-interactions-02 (work in
progress), November 2007.
[I-D.ietf-mip6-bootstrapping-integrated-dhc]
Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in
Tsirtsis & Krishnan Expires April 23, 2009 [Page 7]
Internet-Draft Behavior of Collocated HA/LMA March 2008
progress), July 2007.
[I-D.ietf-monami6-multiplecoa]
Ernst, T., Nagami, K., and V. Devarapalli, "Multiple
Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-06 (work in progress),
February 2008.
[I-D.ietf-netlmm-proxymip6]
Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-11 (work in progress),
February 2008.
[I-D.soliman-monami6-flow-binding]
Soliman, H., Montavont, N., Fikouras, N., and K.
Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic
Support", draft-soliman-monami6-flow-binding-05 (work in
progress), November 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007.
Authors' Addresses
George Tsirtsis
Qualcomm
Email: tsirtsis@googlemail.com
Suresh Krishnan
Ericsson
Email: suresh.krishnan@ericsson.com
Tsirtsis & Krishnan Expires April 23, 2009 [Page 8]
Internet-Draft Behavior of Collocated HA/LMA March 2008
Full Copyright Statement
Copyright (C) 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.
Tsirtsis & Krishnan Expires April 23, 2009 [Page 9]