draft-ietf-netlmm-lma-discovery-00.txt   draft-ietf-netlmm-lma-discovery-01.txt 
Network-based Localized Mobility J. Korhonen Network-based Localized Mobility J. Korhonen
Management (NetLMM) Nokia Siemens Networks Management (NetLMM) Nokia Siemens Networks
Internet-Draft V. Devarapalli Internet-Draft V. Devarapalli
Intended status: Informational WiChorus Intended status: Informational WiChorus
Expires: November 26, 2009 May 25, 2009 Expires: February 24, 2010 August 23, 2009
LMA Discovery for Proxy Mobile IPv6 LMA Discovery for Proxy Mobile IPv6
draft-ietf-netlmm-lma-discovery-00.txt draft-ietf-netlmm-lma-discovery-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 26, 2009. This Internet-Draft will expire on February 24, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. AAA-based Discovery Solutions . . . . . . . . . . . . . . . . . 3 2. AAA-based Discovery Solutions . . . . . . . . . . . . . . . . . 3
2.1. Receiving LMA Address during the Network Access 2.1. Receiving LMA Address during the Network Access
Authentication . . . . . . . . . . . . . . . . . . . . . . 4 Authentication . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Receiving LMA FQDN during the Network Access 2.2. Receiving LMA FQDN during the Network Access
Authentication . . . . . . . . . . . . . . . . . . . . . . 4 Authentication . . . . . . . . . . . . . . . . . . . . . . 4
3. Lower Layers based Discovery Solutions . . . . . . . . . . . . 5 3. Lower Layers based Discovery Solutions . . . . . . . . . . . . 5
3.1. Constructing the LMA FQDN from a mobile node Identity . . . 5 3.1. Constructing the LMA FQDN from a mobile node Identity . . . 5
3.2. Receiving LMA FQDN or IP Address from Lower Layers . . . . 5 3.2. Receiving LMA FQDN or IP Address from Lower Layers . . . . 6
3.3. Constructing the LMA FQDN from a Service Name . . . . . . . 6 3.3. Constructing the LMA FQDN from a Service Name . . . . . . . 6
4. Domain Name System Considerations . . . . . . . . . . . . . . . 6 4. Domain Name System Considerations . . . . . . . . . . . . . . . 6
5. Handover Considerations . . . . . . . . . . . . . . . . . . . . 7 5. Handover Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. Informative References . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. Informative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Large Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployments would benefit Large Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployments would benefit
from a functionality, where a Mobile Access Gateway (MAG) could from a functionality, where a Mobile Access Gateway (MAG) could
dynamically discover a Local Mobility Anchor (LMA) for a Mobile Node dynamically discover a Local Mobility Anchor (LMA) for a Mobile Node
(MN) attaching to a PMIPv6 domain. The purpose of the dynamic (MN) attaching to a PMIPv6 domain. The purpose of the dynamic
discovery functionality is to reduce the amount of static discovery functionality is to reduce the amount of static
configuration in the MAG. This specification describes a number of configuration in the MAG. Other drivers for the dynamic discovery of
possible dynamic LMA discovery solutions. a LMA include LMA load balancing solutions and selecting LMA based on
desired services (i.e. allowing service-specific routing of traffic).
This document describes a number of possible dynamic LMA discovery
solutions.
There are a number of different ways for dynamically discovering the There are a number of different ways for dynamically discovering the
LMA at the MAG. The following list briefly introduces solutions that LMA at the MAG. The following list briefly introduces solutions that
will be discussed in this specification: will be discussed in this specification:
o LMA Address from AAA during the network access authentication o LMA Address from AAA during the network access authentication
procedure when the MN attaches to the MAG. procedure when the MN attaches to the MAG.
o LMA FQDN from AAA during the network access authentication, o LMA FQDN from AAA during the network access authentication,
followed by a Domain Name System (DNS) lookup. followed by a Domain Name System (DNS) lookup.
skipping to change at page 6, line 46 skipping to change at page 7, line 4
addition and deletion). Hosts in the PMIPv6 domain keep using the addition and deletion). Hosts in the PMIPv6 domain keep using the
stale cached DNS response (positive or negative) until they give up stale cached DNS response (positive or negative) until they give up
or the caching times out. The delay can be in order of hours in the or the caching times out. The delay can be in order of hours in the
worst case. On the other hand, DNS administrators can lower the worst case. On the other hand, DNS administrators can lower the
resource record caching time (the Time To Live (TTL) value). resource record caching time (the Time To Live (TTL) value).
Obviously, too low TTL values increase the number of DNS queries Obviously, too low TTL values increase the number of DNS queries
considerably. Second, the secondary DNS servers do not get considerably. Second, the secondary DNS servers do not get
immediately updated when the masters do. These updates are also immediately updated when the masters do. These updates are also
periodic, usually in order of several hours, and may cause periodic, usually in order of several hours, and may cause
considerable delay on global propagation of the updated naming considerable delay on global propagation of the updated naming
information. information. Third, some DNS resolvers ignore low TTLs, replacing
them with a higher default value. This could lead to outdated LMA
information being around for longer than desired.
The above considerations are valid when, for example, the PMIPv6 The above considerations are valid when, for example, the PMIPv6
domain LMA availability or load information is dynamically updated domain LMA availability or load information is dynamically updated
into the DNS. There are incentives for doing so, however, the into the DNS. There are incentives for doing so, however, the
concerns described above need to be understood clearly in that case. concerns described above need to be understood clearly in that case.
5. Handover Considerations 5. Handover Considerations
Whenever a MN moves and attaches to a new MAG in a PMIPv6 domain, all Whenever a MN moves and attaches to a new MAG in a PMIPv6 domain, all
the MAGs that the MN attaches to, should use the same LMA. If there the MAGs that the MN attaches to, should use the same LMA. If there
is only one LMA per PMIPv6 domain, then there is no issue. If there is only one LMA per PMIPv6 domain, then there is no issue. If there
is a context transfer mechanism available between the MAGs, then the is a context transfer mechanism available between the MAGs, then the
new MAG knows the LMA information from the old MAG. Such a mechanism new MAG knows the LMA information from the old MAG. Such a mechanism
is described in [I-D.ietf-mipshop-pfmipv6]. If the MN related is described in [I-D.ietf-mipshop-pfmipv6]. If the MN related
context is not transferred between the MAGs, then a mechanism to context is not transferred between the MAGs, then a mechanism to
deliver the current LMA information to the new MAG is required. deliver the current LMA information to the new MAG is required.
Obviously, relying on DNS during handovers is not a working solution
if the PMIPv6 domain has more than one LMA. In most cases described Relying on DNS during handovers is not generally a working solution
in Section 3, where the MAG derives the LMA FQDN, there is no prior if the PMIPv6 domain has more than one LMA, unless the DNS
knowledge whether the LMA FQDN resolves to one or more LMA IP consistently assigns a specific LMA for each given MN. In most cases
address(es) in the PMIPv6 domain. described in Section 3, where the MAG derives the LMA FQDN, there is
no prior knowledge whether the LMA FQDN resolves to one or more LMA
IP address(es) in the PMIPv6 domain. However, depending on the
deployment and deployment related regulation (such as inter-operator
roaming consortium agreements) the situation might not be this
desperate. For example, a MAG might be able to synthesize a LMA
specific FQDN (e.g. out of MN identity or some other service specific
parameters). Another alternative could that MAG uses, for example, a
MN identity as an input to an algorithm that deterministically
assigns the same LMA out of a pool of LMAs (assuming the MAG has e.g.
learned a group of LMA FQDNs via SRV [RFC2782] query). These
approaches would guarantee that DNS returns always the same LMA
Address to the MAG.
Once the MN completes its initial attachment to a PMIPv6 domain, the Once the MN completes its initial attachment to a PMIPv6 domain, the
information about the LMA that is selected to serve the MN is stored information about the LMA that is selected to serve the MN is stored
in the Policy Store (or the AAA server). The LMA information is in the Policy Store (or the AAA server). The LMA information is
conveyed to the policy store by the LMA after the initial attachment conveyed to the policy store by the LMA after the initial attachment
is completed [I-D.ietf-dime-pmip6]. is completed [I-D.ietf-dime-pmip6]. Typically AAA infrastructure is
used for exchanging information between the LMA and the Policy Store.
When the MN moves and attaches to another MAG in the PMIPv6 domain, When the MN moves and attaches to another MAG in the PMIPv6 domain,
then the AAA servers delivers the existing LMA information to the new then the AAA servers delivers the existing LMA information to the new
MAG as part of the authentication and authorization procedure as MAG as part of the authentication and authorization procedure as
described in Section 2.1 described in Section 2.1
6. Security Considerations 6. Security Considerations
The use of DNS for obtaining the IP address of a mobility agent The use of DNS for obtaining the IP address of a mobility agent
carries certain security risks. These are explained in detail in carries certain security risks. These are explained in detail in
skipping to change at page 8, line 13 skipping to change at page 8, line 32
The AAA infrastructure may be used to transport the LMA discovery The AAA infrastructure may be used to transport the LMA discovery
related information between the MAG and the AAA server via one or related information between the MAG and the AAA server via one or
more AAA brokers and/or AAA proxies. In this case the MAG to the AAA more AAA brokers and/or AAA proxies. In this case the MAG to the AAA
server communication relies on the security properties of the server communication relies on the security properties of the
intermediate AAA brokers and AAA proxies. intermediate AAA brokers and AAA proxies.
7. IANA Considerations 7. IANA Considerations
This specification has no actions for IANA. This specification has no actions for IANA.
8. Informative References 8. Acknowledgements
The authors would like to thank Julien Laganier, Christian Vogt,
Ryuji Wakikawa, Frank Xia and Behcet Sarikaya for their comments and
suggestions on this document.
9. Informative References
[3GPP.23.003] [3GPP.23.003]
3GPP, "Numbering, addressing and identification", 3GPP 3GPP, "Numbering, addressing and identification", 3GPP
TS 23.003 8.2.0, September 2008. TS 23.003 8.2.0, September 2008.
[I-D.ietf-dime-pmip6] [I-D.ietf-dime-pmip6]
Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A.,
and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access
Gateway and Local Mobility Anchor Interaction with Gateway and Local Mobility Anchor Interaction with
Diameter Server", draft-ietf-dime-pmip6-02 (work in Diameter Server", draft-ietf-dime-pmip6-02 (work in
progress), April 2009. progress), April 2009.
[I-D.ietf-mipshop-pfmipv6] [I-D.ietf-mipshop-pfmipv6]
Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for Proxy Mobile IPv6", Xia, "Fast Handovers for Proxy Mobile IPv6",
draft-ietf-mipshop-pfmipv6-04 (work in progress), draft-ietf-mipshop-pfmipv6-08 (work in progress),
May 2009. July 2009.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997. RFC 2136, April 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998. NCACHE)", RFC 2308, March 1998.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007. Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
 End of changes. 13 change blocks. 
18 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/