draft-ietf-netlmm-lma-discovery-07.txt   draft-ietf-netlmm-lma-discovery-08.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 Vasona Networks Intended status: Informational Vasona Networks
Expires: April 15, 2011 October 12, 2010 Expires: April 25, 2011 October 22, 2010
LMA Discovery for Proxy Mobile IPv6 LMA Discovery for Proxy Mobile IPv6
draft-ietf-netlmm-lma-discovery-07.txt draft-ietf-netlmm-lma-discovery-08.txt
Abstract Abstract
Large Proxy Mobile IPv6 deployments would benefit from a Large Proxy Mobile IPv6 deployments would benefit from a
functionality, where a Mobile Access Gateway could dynamically functionality, where a Mobile Access Gateway could dynamically
discover a Local Mobility Anchor for a Mobile Node attaching to a discover a Local Mobility Anchor for a Mobile Node attaching to a
Proxy Mobile IPv6 domain. The purpose of the dynamic discovery Proxy Mobile IPv6 domain. The purpose of the dynamic discovery
functionality is to reduce the amount of static configuration in the functionality is to reduce the amount of static configuration in the
Mobile Access Gateway. This document describes several possible Mobile Access Gateway. This document describes several possible
dynamic Local Mobility Anchor discovery solutions. dynamic Local Mobility Anchor discovery solutions.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on April 15, 2011. This Internet-Draft will expire on April 25, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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. Discovery Solutions based on Data from Lower Layers . . . . . . 5 3. Discovery Solutions based on Data from Lower Layers . . . . . . 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 . . . . 5
3.3. Constructing the LMA FQDN from a Service Name . . . . . . . 6 3.3. Constructing the LMA FQDN from a Service Name . . . . . . . 6
4. Handover Considerations . . . . . . . . . . . . . . . . . . . . 6 4. Handover Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
A Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployment would benefit from A Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployment would benefit from
skipping to change at page 3, line 19 skipping to change at page 3, line 19
discover a Local Mobility Anchor (LMA) for a Mobile Node (MN) discover a Local Mobility Anchor (LMA) for a Mobile Node (MN)
attaching to a PMIPv6 domain. The purpose of the dynamic discovery attaching to a PMIPv6 domain. The purpose of the dynamic discovery
functionality is to reduce the amount of static configuration in the functionality is to reduce the amount of static configuration in the
MAG. Other drivers for the dynamic discovery of a LMA include LMA MAG. Other drivers for the dynamic discovery of a LMA include LMA
load balancing solutions and selecting a LMA based on desired load balancing solutions and selecting a LMA based on desired
services (i.e. allowing service-specific routing of traffic) services (i.e. allowing service-specific routing of traffic)
[RFC5149]. This document describes several possible dynamic LMA [RFC5149]. This document describes several possible dynamic LMA
discovery approaches and makes a recommendation of the preferred one. discovery approaches and makes a recommendation of the preferred one.
The following list briefly introduces solution approaches that will The following list briefly introduces solution approaches that will
be discussed in this document: be discussed in this document. The approaches discussed do not
include all possible discovery mechanisms, but are limited to those
considered to fit most simply into the PMIPv6 environment.
o LMA Address is retrieved from the Authentication, Authorization o LMA Address is retrieved from the Authentication, Authorization
and Accounting (AAA) infrastructure during the network access and Accounting (AAA) infrastructure during the network access
authentication procedure when the MN attaches to the MAG. authentication procedure when the MN attaches to the MAG.
o LMA Fully Qualified Domain Name (FQDN) is retrieved from the AAA o LMA Fully Qualified Domain Name (FQDN) is retrieved from the AAA
infrastructure during the network access authentication, followed infrastructure during the network access authentication, followed
by a Domain Name System (DNS) lookup. by a Domain Name System (DNS) lookup.
o LMA FQDN is derived from the MN identity received from the lower o LMA FQDN is derived from the MN identity received from the lower
skipping to change at page 5, line 16 skipping to change at page 5, line 18
using the AAA infrastructure once it receives the initial PBU from using the AAA infrastructure once it receives the initial PBU from
the MAG for the new mobility session. the MAG for the new mobility session.
3. Discovery Solutions based on Data from Lower Layers 3. Discovery Solutions based on Data from Lower Layers
The following section discusses solutions, where a MAG acquires The following section discusses solutions, where a MAG acquires
information from layers below the IP layer. Based on this information from layers below the IP layer. Based on this
information, the MAG is able to determine which LMA to contact when information, the MAG is able to determine which LMA to contact when
the MN attaches to the MAG. The lower layers discussed here are not the MN attaches to the MAG. The lower layers discussed here are not
explicitly defined but include different radio access technologies explicitly defined but include different radio access technologies
and tunneling solutions such as IKEv2 [RFC5996] IPsec tunnel and tunneling solutions such as an IKEv2 [RFC5996] IPsec tunnel
[RFC4303]. [RFC4303].
3.1. Constructing the LMA FQDN from a Mobile Node Identity 3.1. Constructing the LMA FQDN from a Mobile Node Identity
A MAG acquires a MN identity from lower layers. The MAG can use the A MAG acquires a MN identity from lower layers. The MAG can use the
information embedded in the identity to construct a generic LMA FQDN information embedded in the identity to construct a generic LMA FQDN
(based on some pre-configured formatting rules) and then proceed to (based on some pre-configured formatting rules) and then proceed to
resolve the LMA IP address(es) using the DNS. Obviously, the MN resolve the LMA IP address(es) using the DNS. Obviously, the MN
identity must embed information that can be used to uniquely identify identity must embed information that can be used to uniquely identify
the entity hosting and operating the LMA for the MN. Examples of the entity hosting and operating the LMA for the MN. Examples of
skipping to change at page 7, line 40 skipping to change at page 7, line 43
interactions with them are generally out of scope of IETF, and interactions with them are generally out of scope of IETF, and
specific to a certain system and architecture. specific to a certain system and architecture.
Solutions in Section 2 depend on the existence of an AAA Solutions in Section 2 depend on the existence of an AAA
infrastructure, which is able to provide a MAG either a LMA IP infrastructure, which is able to provide a MAG either a LMA IP
address or a LMA FQDN. While there can be system and architecture address or a LMA FQDN. While there can be system and architecture
specific details regarding the AAA interactions and the use of DNS, specific details regarding the AAA interactions and the use of DNS,
the dynamic LMA discovery can be implemented in an access and the dynamic LMA discovery can be implemented in an access and
technology agnostic manner, and work in the same way across technology agnostic manner, and work in the same way across
heterogeneous environments. Therefore, using AAA based LMA discovery heterogeneous environments. Therefore, using AAA based LMA discovery
solutions are recommended by this document. solutions are recommended by this document. Furthermore, following
the guidance in Section 4.1 of [RFC1958] the use of FQDNs should be
preferred over IP addresses in the context of AAA based LMA discovery
solutions.
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
Section 9.1 of [RFC5026]. However, the risks described in [RFC5026] Section 9.1 of [RFC5026]. However, the risks described in [RFC5026]
are mitigated to a large extent in this document, since the MAG and are mitigated to a large extent in this document, since the MAG and
the LMA belong to the same PMIPv6 domain. The DNS server that the the LMA belong to the same PMIPv6 domain. The DNS server that the
MAG queries is also part of the same PMIPv6 domain. Even if the MAG MAG queries is also part of the same PMIPv6 domain. Even if the MAG
obtains the IP address of a bogus LMA from a bogus DNS server, obtains the IP address of a bogus LMA from a bogus DNS server,
skipping to change at page 9, line 5 skipping to change at page 9, line 14
[3GPP.24.008] [3GPP.24.008]
3GPP, "Mobile radio interface Layer 3 specification", 3GPP 3GPP, "Mobile radio interface Layer 3 specification", 3GPP
TS 24.008 8.6.0, June 2009. TS 24.008 8.6.0, June 2009.
[3GPP.24.302] [3GPP.24.302]
3GPP, "Access to the 3GPP Evolved Packet Core (EPC) via 3GPP, "Access to the 3GPP Evolved Packet Core (EPC) via
non-3GPP access networks", 3GPP TS 24.302 10.0.0, non-3GPP access networks", 3GPP TS 24.302 10.0.0,
June 2010. June 2010.
[RFC1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. 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.
[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.
 End of changes. 8 change blocks. 
7 lines changed or deleted 15 lines changed or added

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