One document matched: draft-ietf-netlmm-lma-discovery-06.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2136 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2136.xml'>
<!ENTITY rfc2308 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2308.xml'>
<!ENTITY rfc2845 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2845.xml'>
<!ENTITY rfc4033 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml'>
<!ENTITY rfc4283 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4283.xml'>
<!ENTITY rfc4282 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4282.xml'>
<!ENTITY rfc5213 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml'>
<!ENTITY rfc4303 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml'>
<!ENTITY rfc4306 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml'>
<!ENTITY rfc5026 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5026.xml'>
<!ENTITY rfc2782 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml'>
<!ENTITY rfc5779 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5779.xml'>
<!ENTITY I-D.ietf-mipshop-pfmipv6 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mipshop-pfmipv6.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc compact="yes" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc autobreaks="yes" ?>
<rfc category="info" ipr="trust200902" docName="draft-ietf-netlmm-lma-discovery-06.txt">
<front>
<title abbrev="LMA Discovery">LMA Discovery for Proxy Mobile IPv6</title>
<author initials='J.' surname="Korhonen" fullname='Jouni Korhonen'>
<organization abbrev="Nokia Siemens Networks">Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<code>FIN-02600 Espoo</code>
<country>Finland</country>
</postal>
<email>jouni.nospam@gmail.com</email>
</address>
</author>
<author initials='V' surname="Devarapalli" fullname='Vijay Devarapalli'>
<organization abbrev='Vasona Networks'>Vasona Networks</organization>
<address>
<email>dvijay@gmail.com</email>
</address>
</author>
<date year="2010"/>
<area>Internet</area>
<workgroup>Network-based Localized Mobility Management (NetLMM)</workgroup>
<abstract>
<t>Large Proxy Mobile IPv6 deployments would benefit from a
functionality, where a Mobile Access Gateway could
dynamically discover a Local Mobility Anchor for a Mobile
Node attaching to a Proxy Mobile IPv6 domain. The purpose
of the dynamic discovery functionality is to reduce the
amount of static configuration in the Mobile Access
Gateway. This document describes several possible
dynamic Local Mobility Anchor discovery solutions.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>A Proxy Mobile IPv6 (PMIPv6) <xref target="RFC5213"/>
deployment would benefit from a functionality, where a
Mobile Access Gateway (MAG) can dynamically discover a
Local Mobility Anchor (LMA) for a Mobile Node (MN)
attaching to a PMIPv6 domain. The purpose of
the dynamic discovery functionality is to reduce the
amount of static configuration in the MAG. Other drivers for the
dynamic discovery of a LMA include LMA load balancing solutions and
selecting a LMA based on desired services. This
document describes several possible dynamic LMA
discovery approaches and makes a recommendation of the preferred one.
</t>
<t>The following list briefly
introduces solution approaches that will be discussed in this
document:
<vspace blankLines="1"/>
<list style='hanging'>
<t hangText="o">LMA Address from AAA during the network
access authentication procedure when the MN
attaches to the MAG.
<vspace blankLines="1"/></t>
<t hangText="o">LMA FQDN from AAA during the network access
authentication, followed by a Domain Name System (DNS)
lookup.
<vspace blankLines="1"/></t>
<t hangText="o">LMA FQDN derived from the MN
identity received from the lower layers during the
network attachment, followed by a DNS lookup.
<vspace blankLines="1"/>
</t>
<t hangText="o">LMA FQDN or IP address received from the lower
layers during the network attachment. The reception of an FQDN
from the lower layers is followed by a DNS lookup.
<vspace blankLines="1"/>
</t>
<t hangText="o">LMA FQDN derived from the service selection
indication received from lower layers during the network
attachment, followed by a DNS lookup.
</t>
</list>
</t>
<t>When a MN performs a handover from one MAG to
another, the new MAG must use the same LMA that the old
MAG was using. This is required for session
continuity. The LMA discovery mechanism in the new
MAG should be able to return the information of the
same LMA that was being used by the old MAG. This document
also discusses solutions for LMA discovery during a
handover.
</t>
</section>
<section title="AAA-based Discovery Solutions" anchor="aaasol">
<t>This section presents a LMA discovery solution that
requires a MAG to be connected to an AAA
infrastructure for instance as described in <xref target="RFC5779"/>. The AAA infrastructure is also assumed to be aware of PMIPv6. A MN
attaching to a PMIPv6 domain is typically required to provide
authentication for network access and to be authorized for
mobility services before the MN is allowed to
send or receive any IP packets or even complete its IP level
configuration.
</t>
<t>The AAA-based LMA discovery solution hooks into the
network access authentication and authorization
process. The MAG has also the role of a Network Access
Server (NAS) at this step. While the MN is
attaching to the network, the PMIPv6 related parameters
are bootstrapped in parallel with authentication for the network
access and authorization for the mobility services. The
PMIPv6 parameters bootstrapping involves the
Policy Profile download over the AAA infrastructure to the
MAG (see Appendix A of <xref target="RFC5213"/>).
</t>
<section title="Receiving LMA Address during the Network
Access Authentication" anchor="aaalma">
<t>After the MN has successfully authenticated for the
network access and authorized for the mobility
service, the MAG receives the LMA IP address from
the AAA server over the AAA infrastructure. The LMA IP
address information would be part of the AAA message
that ends the successful authentication and
authorization AAA exchange.
</t>
<t>Once the MAG receives the LMA IP address, it sends
Proxy Binding Update (PBU) message for the newly
authenticated and authorized MN. The MAG expects
that the LMA returned by the AAA server is able to
provide mobility session continuity for the MN,
i.e. after a handover the LMA would be the same one the
MN already has a mobility session set up with.
</t>
</section>
<section title="Receiving LMA FQDN during the Network
Access Authentication" anchor="dnsaaalma">
<t>This solution is similar to the procedure described in
<xref target="aaalma"/>. The difference is that the MAG
receives a Fully Qualified Domain Name (FQDN) of the LMA
instead of the IP address(es). The MAG has to query the
DNS infrastructure in order to resolve the FQDN to the
LMA IP address(es).
</t>
<t>The LMA FQDN might be a generic name for a PMIPv6 domain
that resolves to one or more LMAs in the PMIPv6 domain.
Alternatively the LMA FQDN might be resolved to
exactly one LMA within the PMIPv6 domain. The latter
approach would obviously be useful if a new target MAG
after a handover should resolve the LMA FQDN to the LMA
IP address where the MN mobility session is already
located.
</t>
<t>The procedures described in this section and in <xref
target="aaalma"/> may also be used together. For
example, the AAA server might return a generic LMA FQDN
during the MN initial attach and once the LMA
gets selected, return the LMA IP address during the
subsequent attachments to other MAGs in the PMIPv6 domain.
In order for this to work, the resolved and selected LMA IP address
must be updated to the remote Policy Store. For example, the LMA
could perform the Policy Store update using the AAA infrastructure
once it receives the initial PBU from the MAG for the new mobility
session.
</t>
</section>
</section>
<section title="Discovery Solutions based on Data from Lower Layers" anchor="lowsol">
<t>The following section discusses solutions, where a MAG
acquires information from layers below the IP layer.
Based on this 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 explicitly defined but
include different radio access technologies and
tunneling solutions such as IKEv2 <xref target="RFC4306"/>
IPsec tunnel <xref target="RFC4303"/>.
</t>
<section title="Constructing the LMA FQDN from a Mobile Node Identity" anchor="lowid">
<t>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 (based on some
pre-configured formatting rules) and then proceed to
resolve the LMA IP address(es) using the DNS. Obviously,
the MN identity must embed information
that can be used to uniquely identify
the entity hosting and operating the LMA for the MN.
Examples of such MN identities are the
International Mobile Subscriber Identity (IMSI) and
Globally Unique Temporary User Equipment Identity (GUTI) <xref
target="3GPP.23.003"/>. These MN identities contain
information that can uniquely identify the operator where the
subscription belongs to.
</t>
</section>
<section title="Receiving LMA FQDN or IP Address from Lower Layers ">
<t>The solution described here is similar to the solution
discussed in <xref target="lowid"/>.
A MAG receives a LMA FQDN or an
IP address from lower layers, for example, as a part
of the normal lower layer signaling when the MN attaches to the
network. IKEv2 could be existing example of such lower layer signaling
where IPsec is the "lower layer" for the MN <xref target="3GPP.24.302"/>.
IKEv2 has an
IKEv2 IDr payload, which is used by the IKEv2 initiator (i.e. the
MN in this case) to specify which of the responder's identities (i.e.
the LMA in this case) it wants to talk to. And here the responder
identity could be an FQDN or an IP address of the LMA (as the
IKEv2 identification payload can be an IP address or an FQDN).
Another existing example is the Access Point Name Information
Element (APN IE) in 3GPP radio's network access signaling
capable of carrying a FQDN <xref target="3GPP.24.008"/>.
However, in general this means the MN is also the originator of the
LMA information. The LMA information content as such can
be transparent to the MN, meaning the MN does not associate the
information with any LMA function.
</t>
</section>
<section title="Constructing the LMA FQDN from a Service Name">
<t>
Some network access technologies (including tunneling
solutions) allow the MN to signal the service
name that identifies a particular service or the
external network it wants to access <xref target="3GPP.24.302"/>
<xref target="RFC4306"/>. If the MN originated service name
also embeds the information
of the entity hosting the service or the hosting information can
be derived from other information available at the same time
(e.g., see <xref target="lowid"/>), then the MAG can construct a
generic LMA FQDN (e.g., based on some pre-defined formatting rules)
providing an access to the service or the external
network. The pre-defined formatting rules <xref target="3GPP.23.003"/>
are usually agreed on
among operators that belong to the same inter-operator roaming
consortium or by network infrastructure vendors defining an open
networking system architecture.
</t>
<t>Once the MAG has the FQDN it can proceed to
resolve the LMA IP address(es) using the DNS. An example
of such service or external network name is the Access
Point Name (APN) <xref target="3GPP.23.003"/> that
contain information of the operator providing the access
to the given service or the external network. For example, an
FQDN for an "ims" APN could be "ims.apn.epc.mnc015.mcc234.3gppnetwork.org".
</t>
</section>
</section>
<section title="Handover Considerations" anchor="hocon">
<t>
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 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 new
MAG knows the LMA information from the old MAG. Such a
mechanism is described in <xref
target="I-D.ietf-mipshop-pfmipv6"/>. If the MN
related context is not transferred between the MAGs, then a
mechanism to deliver the current LMA information to the new
MAG is required.
</t>
<t>Relying on DNS during handovers
is not generally a working solution if the PMIPv6 domain has more than
one LMA, unless the DNS consistently assigns a specific LMA for
each given MN. In most cases described in <xref target="lowsol"/>,
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).
Alternatively, the MAG could use (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 <xref target="RFC2782"/> query). These approaches would
guarantee that DNS returns always the same LMA Address to the MAG.
</t>
<t>
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 in the Policy Store (or
the AAA server). The LMA information is conveyed to the
policy store by the LMA after the initial attachment is
completed <xref target="RFC5779"/>. Typically
AAA infrastructure is used for exchanging information between the
LMA and the Policy Store.
</t>
<t>
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 MAG as part of the authentication and
authorization procedure as described in <xref
target="aaalma"/>
</t>
</section>
<section title="Recommendations">
<t>This document discussed several solution approaches for a dynamic LMA
discovery. All discussed solution approaches actually require additional
functionality or infrastructure support that the base PMIPv6
<xref target="RFC5213"/> does not require.
</t>
<t>Solutions in <xref target="lowsol"/> all depend on lower layers being
able to provide information that a MAG can then use to query DNS and
discover a suitable LMA. The capabilities of the lower layers and
the interactions with them are generally out of scope of IETF, and
specific to a certain system and architecture.
</t>
<t>
Solutions in <xref target="aaasol"/> depend on the existence of an AAA
infrastructure, which is able to provide a MAG either a LMA IP
address or a LMA FQDN. While there can be system and architecture
specific details regarding the AAA interactions and the use of DNS, the
dynamic LMA discovery can be entirely implemented using protocols and
technologies developed in IETF. Therefore, using AAA based LMA
discovery solutions are recommended by this document.
</t>
</section>
<section title="Security Considerations">
<t>
The use of DNS for obtaining the IP address of a mobility
agent carries certain security risks. These are explained
in detail in Section 9.1 of <xref target="RFC5026"/>. However,
the risks described in <xref target="RFC5026"/>
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 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, further harm is prevented since the MAG and
the LMA should authenticate each other before exchanging
PMIPv6 signaling messages. <xref target="RFC5213"/> specifies the
use of IKEv2 between the
MAG and the LMA to authenticate each other and setup IPsec
security associations for protecting the PMIPv6
signaling messages.
</t>
<t>
The AAA infrastructure may be used to transport the LMA
discovery 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 server
communication relies on the security properties of the
intermediate AAA brokers and AAA proxies.
</t>
</section>
<section title="IANA Considerations">
<t>This document has no actions for IANA.
</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Julien Laganier, Christian Vogt,
Ryuji Wakikawa, Frank Xia, Behcet Sarikaya, Charlie Perkins, Qin
Wu, Jari Arkko and Xiangsong Cui for their comments, extensive discussions and
suggestions on this document.
</t>
</section>
</middle>
<back>
<references title="Informative References">
&rfc5213;
&rfc5026;
&rfc4303;
&rfc4306;
&I-D.ietf-mipshop-pfmipv6;
&rfc5779;
&rfc2782;
<reference anchor="3GPP.23.003">
<front>
<title>Numbering, addressing and identification</title>
<author>
<organization>3GPP</organization>
</author>
<date day="23" month="September" year="2008"/>
</front>
<seriesInfo name="3GPP TS" value="23.003 8.2.0"/>
<format type="HTML" target="http://www.3gpp.org/ftp/Specs/html-info/23003.htm"/>
</reference>
<reference anchor="3GPP.24.008">
<front>
<title>Mobile radio interface Layer 3 specification</title>
<author>
<organization>3GPP</organization>
</author>
<date day="8" month="June" year="2009"/>
</front>
<seriesInfo name="3GPP TS" value="24.008 8.6.0"/>
<format type="HTML" target="http://www.3gpp.org/ftp/Specs/html-info/24008.htm"/>
</reference>
<reference anchor="3GPP.24.302">
<front>
<title>Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks</title>
<author>
<organization>3GPP</organization>
</author>
<date day="15" month="June" year="2010"/>
</front>
<seriesInfo name="3GPP TS" value="24.302 10.0.0"/>
<format type="HTML" target="http://www.3gpp.org/ftp/Specs/html-info/24302.htm"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:28:04 |