draft-ietf-netlmm-lma-discovery-04.txt   draft-ietf-netlmm-lma-discovery-05.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 Vasona Networks
Expires: November 25, 2010 May 24, 2010 Expires: March 17, 2011 September 13, 2010
LMA Discovery for Proxy Mobile IPv6 LMA Discovery for Proxy Mobile IPv6
draft-ietf-netlmm-lma-discovery-04.txt draft-ietf-netlmm-lma-discovery-05.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.
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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on March 17, 2011.
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 November 25, 2010.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
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. 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. Domain Name System Considerations . . . . . . . . . . . . . . 6 4. Handover Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Handover Considerations . . . . . . . . . . . . . . . . . . . 7 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. Informative References . . . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Large Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployments would benefit A Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployment would benefit from
from a functionality, where a Mobile Access Gateway (MAG) could a functionality, where a Mobile Access Gateway (MAG) can dynamically
dynamically discover a Local Mobility Anchor (LMA) for a Mobile Node discover a Local Mobility Anchor (LMA) for a Mobile Node (MN)
(MN) attaching to a PMIPv6 domain. The purpose of the dynamic attaching to a PMIPv6 domain. The purpose of the dynamic discovery
discovery functionality is to reduce the amount of static functionality is to reduce the amount of static configuration in the
configuration in the MAG. Other drivers for the dynamic discovery of MAG. Other drivers for the dynamic discovery of a LMA include LMA
a LMA include LMA load balancing solutions and selecting a LMA based load balancing solutions and selecting a LMA based on desired
on desired services (i.e. allowing service-specific routing of services (i.e. allowing service-specific routing of traffic)
traffic) [RFC5149]. This document describes several possible dynamic [RFC5149]. This document describes several possible dynamic LMA
LMA discovery solutions. discovery approaches and makes a recommendation of the preferred one.
The following list briefly introduces solutions that will be The following list briefly introduces solution approaches that will
discussed in this document: be discussed in this document:
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.
o LMA FQDN derived from the MN identity received from the lower o LMA FQDN derived from the MN identity received from the lower
layers during the network attachment, followed by a DNS lookup. layers during the network attachment, followed by a DNS lookup.
o LMA FQDN or IP address received from the lower layers during the o LMA FQDN or IP address received from the lower layers during the
network attachment. The reception of an FQDN from the lower network attachment. The reception of an FQDN from the lower
layers is followed by a DNS lookup. layers is followed by a DNS lookup.
o LMA FQDN derived from the service selection indication received o LMA FQDN derived from the service selection indication received
from lower layers during the network attachment, followed by a DNS from lower layers during the network attachment, followed by a DNS
lookup. lookup.
When a MN performs a handover from one MAG to another, the new MAG 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 must use the same LMA that the old MAG was using. This is required
for session continuity. The LMA discovery mechanism used by the new for session continuity. The LMA discovery mechanism in the new MAG
MAG should be able to return the information about the same LMA that should be able to return the information of the same LMA that was
was being used by the old MAG. This document also discusses being used by the old MAG. This document also discusses solutions
solutions for LMA discovery during a handover. for LMA discovery during a handover.
2. AAA-based Discovery Solutions 2. AAA-based Discovery Solutions
This section presents a LMA discovery solution that requires a MAG to This section presents a LMA discovery solution that requires a MAG to
be connected to an AAA infrastructure. The AAA infrastructure is be connected to an AAA infrastructure for instance as described in
also assumed to be aware of and support PMIPv6. A MN attaching to a [RFC5779]. The AAA infrastructure is also assumed to be aware of
PMIPv6 domain is typically required to provide authentication for PMIPv6. A MN attaching to a PMIPv6 domain is typically required to
network access and to be authorized for mobility services before the provide authentication for network access and to be authorized for
MN is allowed to send or receive any IP packets or even complete its mobility services before the MN is allowed to send or receive any IP
IP level configuration. packets or even complete its IP level configuration.
The AAA-based LMA discovery solution hooks into the network access The AAA-based LMA discovery solution hooks into the network access
authentication and authorization procedure. The MAG has also the authentication and authorization process. The MAG has also the role
role of a Network Access Server (NAS) at this step. While the MN is of a Network Access Server (NAS) at this step. While the MN is
attaching to the network, the PMIPv6 related parameters are attaching to the network, the PMIPv6 related parameters are
bootstrapped at the same time the MN is authenticated for the network bootstrapped in parallel with authentication for the network access
access and authorized for the mobility services using the AAA and authorization for the mobility services. The PMIPv6 parameters
infrastructure. The PMIPv6 parameters bootstrapping involves the bootstrapping involves the Policy Profile download over the AAA
Policy Profile download over the AAA infrastructure to the MAG (see infrastructure to the MAG (see Appendix A of [RFC5213]).
Appendix A of [RFC5213]).
2.1. Receiving LMA Address during the Network Access Authentication 2.1. Receiving LMA Address during the Network Access Authentication
After the MN has successfully authenticated for the network access After the MN has successfully authenticated for the network access
and authorized for the mobility service, the MAG receives the LMA IP and authorized for the mobility service, the MAG receives the LMA IP
address(es) from the AAA server over the AAA infrastructure. The LMA address(es) from the AAA server over the AAA infrastructure. The LMA
IP address information would be part of the AAA message(s) that ends IP address information would be part of the AAA message that ends the
the successful authentication and authorization AAA exchange. successful authentication and authorization AAA exchange.
Once the MAG receives the LMA IP address(es), it sends Proxy Binding Once the MAG receives the LMA IP address(es), it sends Proxy Binding
Update (PBU) message for the newly authenticated and authorized MN. Update (PBU) message for the newly authenticated and authorized MN.
The MAG trusts that the LMA returned by the AAA server is able to 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 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 the LMA would be the same one the MN already has a mobility session
set up with. set up with.
2.2. Receiving LMA FQDN during the Network Access Authentication 2.2. Receiving LMA FQDN during the Network Access Authentication
This solution is similar to the procedure described in Section 2.1. This solution is similar to the procedure described in Section 2.1.
The difference is that the MAG receives a Fully Qualified Domain Name 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 (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 query the DNS infrastructure in order to resolve the FQDN to the LMA
skipping to change at page 5, line 10 skipping to change at page 5, line 9
be used together. For example, the AAA server might return a generic 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, LMA FQDN during the MN initial attach and once the LMA gets selected,
return the LMA IP address during the subsequent attachments to other return the LMA IP address during the subsequent attachments to other
MAGs in the PMIPv6 domain. In order for this to work, the resolved 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 and selected LMA IP address must be updated to the remote Policy
Store. For example, the LMA could perform the update once it Store. For example, the LMA could perform the update once it
receives the initial PBU from the MAG for the new mobility session. receives the initial PBU from 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 the MAG receives The following section discusses solutions, where a MAG acquires
information from lower layers below the IP layer when the MN attaches information from layers below the IP layer. Based on this
to the MAG. Based on this information, the MAG is then able to information, the MAG is able to determine which LMA to contact when
determine which LMA to contact. These solutions could allow large the MN attaches to the MAG. The lower layers discussed here are not
PMIPv6 deployments without any AAA infrastructure. The lower layers explicitly defined but include different radio access technologies
discussed here are not explicitly defined but could include different and tunneling solutions such as IKEv2 [RFC4306] IPsec tunnel
radio access technologies and tunneling solutions such as IKEv2 [RFC4303].
[RFC4306] IPsec tunnel [RFC4303].
3.1. Constructing the LMA FQDN from a Mobile Node Identity 3.1. Constructing the LMA FQDN from a Mobile Node Identity
Depending on the actual network access technology, the MAG may be A MAG acquires a MN identity from lower layers. The MAG can use the
able to receive a MN identity as a result of the network access
attachment procedure. The MN may signal its identity as part of the
attachment signaling or alternatively the MAG may receive the MN
identity from a remote policy store.
Once the MAG has acquired the MN identity, 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 determine the identity must embed information that can be used to uniquely identify
entity hosting and operating the LMA for the MN. Examples of such the entity hosting and operating the LMA for the MN. Examples of
identities are the International Mobile Subscriber Identity (IMSI) or such MN identities are the International Mobile Subscriber Identity
Globally Unique Temporary User Equipment Identity (GUTI) (IMSI) and Globally Unique Temporary User Equipment Identity (GUTI)
[3GPP.23.003] that both contain information of the operator owning [3GPP.23.003]. These MN identities contain information that can
the given subscription. uniquely identify the operator where the subscription belongs to.
The solution discussed in this section has issues if MN identity does
not embed enough information. If the MN identity does not embed any
LMA hosting entity information, the MAG might use a local database to
map MN identities to corresponding LMAs. However, this solution is
unlikely to scale outside a limited PMIPv6 domain.
3.2. Receiving LMA FQDN or IP Address from Lower Layers 3.2. Receiving LMA FQDN or IP Address from Lower Layers
The solution described in this section is similar to the solution The solution described here is similar to the solution discussed in
discussed in Section 3.1. Instead of deriving the LMA FQDN from the Section 3.1. A MAG receives a LMA FQDN or an IP address from lower
MN identity, the MAG receives a LMA FQDN or an IP address information layers, for example, as a part of the normal lower layer signaling
from lower layers, for example, as a part of the normal lower layer when the MN attaches to the network. IKEv2 could be existing example
signaling when the MN attaches to the network. IKEv2 could be of such lower layer signaling where IPsec is the "lower layer" for
existing example of such lower layer signaling when IPsec is the the MN [3GPP.24.302]. IKEv2 has an IKEv2 IDr payload, which is used
"lower layer" for the MN. IKEv2 has an IKEv2 IDr payload, which is by the IKEv2 initiator (i.e. the MN in this case) to specify which of
used by the IKEv2 initiator (i.e. the MN in this case) to specify the responder's identities (i.e. the LMA in this case) it wants to
which of the responder's identities (i.e. the LMA in this case) it talk to. And here the responder identity could be an FQDN or an IP
wants to talk to. And here the responder identity could be an FQDN address of the LMA (as the IKEv2 identification payload can be an IP
or an IP address of the LMA (as the IKEv2 identification payload can address or an FQDN). Another existing example is the Access Point
be an IP address or an FQDN). Another existing example is the Access Name Information Element (APN IE) in 3GPP radio's network access
Point Name Information Element (APN IE) in 3GPP radio's network signaling capable of carrying a FQDN [3GPP.24.008]. However, in
access signaling capable of carrying a FQDN [3GPP.24.008]. However, general this means the MN is also the originator of the LMA
in general this means the MN is also the originator of the LMA
information. The LMA information content as such can be transparent information. The LMA information content as such can be transparent
to the MN, meaning the MN does not associate the information with any to the MN, meaning the MN does not associate the information with any
LMA function.. LMA function.
3.3. Constructing the LMA FQDN from a Service Name 3.3. Constructing the LMA FQDN from a Service Name
Some network access technologies (including tunneling solutions) Some network access technologies (including tunneling solutions)
allow the MN to signal the service name that identifies a particular allow the MN to signal the service name that identifies a particular
service or the external network it wants to access [3GPP.24.302] service or the external network it wants to access [3GPP.24.302]
[RFC4306]. If the MN originated service name also embeds the [RFC4306]. If the MN originated service name also embeds the
information of the entity hosting the service or the hosting information of the entity hosting the service or the hosting
information can be derived from other information available at the information can be derived from other information available at the
same time (e.g., see Section 3.1), then the MAG can construct a same time (e.g., see Section 3.1), then the MAG can construct a
skipping to change at page 6, line 40 skipping to change at page 6, line 27
operators that belong to the same inter-operator roaming consortium operators that belong to the same inter-operator roaming consortium
or by network infrastructure vendors defining an open networking or by network infrastructure vendors defining an open networking
system architecture. system architecture.
Once the MAG has the FQDN it can proceed to resolve the LMA IP 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 address(es) using the DNS. An example of such service or external
network name is the Access Point Name (APN) [3GPP.23.003] that network name is the Access Point Name (APN) [3GPP.23.003] that
contain information of the operator providing the access to the given contain information of the operator providing the access to the given
service or the external network. service or the external network.
4. Domain Name System Considerations 4. Handover Considerations
Some LMA discovery solutions described in Section 2 and Section 3
eventually depend on the DNS. This section discusses impacts of the
DNS response caching and issues related to the Dynamic DNS [RFC2136]
updates. The impacts and related issues can mostly be avoided by a
proper DNS administration that takes PMIPv6 domain deployment aspects
into consideration.
The caching (positive or negative) properties of the DNS [RFC2308]
and the fact that updates to the DNS take time to propagate globally,
need to be considered when applying DNS-based solutions to the PMIPv6
domain. First, the caching of DNS responses effectively delays the
propagation of up to date FQDN to IP address mappings (after both
addition and deletion). Hosts in the PMIPv6 domain keep using the
stale cached DNS response (positive or negative) until they give up
or the cached data times out. The delay can be in order of hours in
the worst case. On the other hand, DNS administrators can lower the
resource record caching time (the Time To Live (TTL) value). Low TTL
values increase the number of DNS queries considerably. Second, the
secondary DNS servers do not get immediately updated when the masters
do. These updates are also periodic, usually in order of several
hours, and may cause considerable delay on global propagation of the
updated naming 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
domain LMA availability or load information is dynamically updated
into the DNS. There are incentives for doing so, however, the
concerns described above need to be understood clearly in that case.
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.
skipping to change at page 8, line 18 skipping to change at page 7, line 19
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 [RFC5779]. Typically AAA infrastructure is used for is completed [RFC5779]. Typically AAA infrastructure is used for
exchanging information between the LMA and the Policy Store. 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
5. Recommendations
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 [RFC5213] does not require.
Solutions in Section 3 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.
Solutions in Section 2 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, 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.
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,
further harm is prevented since the MAG and the LMA should further harm is prevented since the MAG and the LMA should
skipping to change at page 8, line 46 skipping to change at page 8, line 22
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 document has no actions for IANA. This document has no actions for IANA.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Julien Laganier, Christian Vogt, The authors would like to thank Julien Laganier, Christian Vogt,
Ryuji Wakikawa, Frank Xia, Behcet Sarikaya, Charlie Perkins, Qin Wu Ryuji Wakikawa, Frank Xia, Behcet Sarikaya, Charlie Perkins, Qin Wu,
and Xiangsong Cui for their comments, extensive discussions and Jari Arkko and Xiangsong Cui for their comments, extensive
suggestions on this document. discussions and suggestions on this document.
9. Informative References 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.
[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 8.5.0, non-3GPP access networks", 3GPP TS 24.302 10.0.0,
March 2010. June 2010.
[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-14 (work in progress), draft-ietf-mipshop-pfmipv6-14 (work in progress),
May 2010. May 2010.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[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.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
skipping to change at page 10, line 19 skipping to change at page 9, line 37
Jouni Korhonen Jouni Korhonen
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
FIN-02600 Espoo FIN-02600 Espoo
Finland Finland
Email: jouni.nospam@gmail.com Email: jouni.nospam@gmail.com
Vijay Devarapalli Vijay Devarapalli
WiChorus Vasona Networks
3950 North First Street
San Jose, CA 95134
USA
Email: vijay@wichorus.com Email: dvijay@gmail.com
 End of changes. 29 change blocks. 
154 lines changed or deleted 112 lines changed or added

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