idnits 2.17.1 draft-ietf-netlmm-lma-discovery-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 23, 2009) is 5359 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-ietf-dime-pmip6-02 == Outdated reference: A later version (-14) exists of draft-ietf-mipshop-pfmipv6-08 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network-based Localized Mobility J. Korhonen 3 Management (NetLMM) Nokia Siemens Networks 4 Internet-Draft V. Devarapalli 5 Intended status: Informational WiChorus 6 Expires: February 24, 2010 August 23, 2009 8 LMA Discovery for Proxy Mobile IPv6 9 draft-ietf-netlmm-lma-discovery-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on February 24, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 Large Proxy Mobile IPv6 deployments would benefit from a 48 functionality, where a Mobile Access Gateway could dynamically 49 discover a Local Mobility Anchor for a Mobile Node attaching to a 50 Proxy Mobile IPv6 domain. The purpose of the dynamic discovery 51 functionality is to reduce the amount of static configuration in the 52 Mobile Access Gateway. This specification describes a number of 53 possible dynamic Local Mobility Anchor discovery solutions. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. AAA-based Discovery Solutions . . . . . . . . . . . . . . . . . 3 59 2.1. Receiving LMA Address during the Network Access 60 Authentication . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2. Receiving LMA FQDN during the Network Access 62 Authentication . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Lower Layers based Discovery Solutions . . . . . . . . . . . . 5 64 3.1. Constructing the LMA FQDN from a mobile node Identity . . . 5 65 3.2. Receiving LMA FQDN or IP Address from Lower Layers . . . . 6 66 3.3. Constructing the LMA FQDN from a Service Name . . . . . . . 6 67 4. Domain Name System Considerations . . . . . . . . . . . . . . . 6 68 5. Handover Considerations . . . . . . . . . . . . . . . . . . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 72 9. Informative References . . . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Large Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployments would benefit 78 from a functionality, where a Mobile Access Gateway (MAG) could 79 dynamically discover a Local Mobility Anchor (LMA) for a Mobile Node 80 (MN) attaching to a PMIPv6 domain. The purpose of the dynamic 81 discovery functionality is to reduce the amount of static 82 configuration in the MAG. Other drivers for the dynamic discovery of 83 a LMA include LMA load balancing solutions and selecting LMA based on 84 desired services (i.e. allowing service-specific routing of traffic). 85 This document describes a number of possible dynamic LMA discovery 86 solutions. 88 There are a number of different ways for dynamically discovering the 89 LMA at the MAG. The following list briefly introduces solutions that 90 will be discussed in this specification: 92 o LMA Address from AAA during the network access authentication 93 procedure when the MN attaches to the MAG. 95 o LMA FQDN from AAA during the network access authentication, 96 followed by a Domain Name System (DNS) lookup. 98 o LMA FQDN derived from the MN identity received from the lower 99 layers during the network attachment, followed by a DNS lookup. 101 o LMA FQDN or IP address received from the lower layers during the 102 network attachment followed by an optional DNS lookup. 104 o LMA FQDN derived from the service selection indication received 105 from lower layers during the network attachment, followed by a DNS 106 lookup. 108 When a MN performs a handover from one MAG to another, the new MAG 109 must use the same LMA that the old MAG was using. This is required 110 for session continuity. The LMA discovery mechanism used by the new 111 MAG should be able to return the information about the same LMA that 112 was being used by the old MAG. This document also discusses 113 solutions for LMA discovery during a handover. 115 2. AAA-based Discovery Solutions 117 This section presents a LMA discovery solution that requires a MAG to 118 be connected to an AAA infrastructure. The AAA infrastructure is 119 also assumed to be aware of and support PMIPv6 functionality. A MN 120 attaching to a PMIPv6 domain is typically required to authenticate to 121 the network access and to be authorized for the mobility services 122 before the MN is allowed to send or receive any IP packets or even 123 complete its IP level configuration. 125 The AAA-based LMA discovery solution hooks into the network access 126 authentication and authorization procedure. The MAG has also the 127 role of a Network Access Server (NAS) at this step. While the MN is 128 attaching to the network, the PMIPv6 related parameters are 129 bootstrapped at the same time the MN is authenticated for the network 130 access and authorized for the mobility services using the AAA 131 infrastructure. The PMIPv6 parameters bootstrapping involves the 132 Policy Profile download over the AAA infrastructure to the MAG. The 133 procedure for the Policy Profile download resembles largely the 134 client Mobile IPv6 Integrated Scenario bootstrapping [RFC5447]. 136 2.1. Receiving LMA Address during the Network Access Authentication 138 After the MN has successfully authenticated for the network access 139 and authorized for the mobility service, the MAG receives the LMA IP 140 address(es) from the AAA server over the AAA infrastructure. The LMA 141 IP address information would be part of the AAA message(s) that ends 142 the successful authentication and authorization AAA exchange. 144 Once the MAG receives the LMA IP address(es), it sends Proxy Binding 145 Update (PBU) message for the newly authenticated and authorized MN. 146 The MAG trusts that the LMA returned by the AAA server is able to 147 provide mobility session continuity for the MN, i.e. after a handover 148 the LMA would be the same the MN already has a mobility session set 149 up with. 151 2.2. Receiving LMA FQDN during the Network Access Authentication 153 This solution is identical to the procedure described in Section 2.1. 154 The difference is that the MAG receives a Fully Qualified Domain Name 155 (FQDN) of the LMA instead of the IP address(es). The MAG has to 156 query the DNS infrastructure in order to resolve the FQDN to the LMA 157 IP address(es). 159 The LMA FQDN might be a generic to a PMIPv6 domain resolving to one 160 or more LMAs in the said domain. Alternatively the LMA FQDN might 161 resolve to exactly one LMA within the PMIPv6 domain. The latter 162 approach would obviously be useful if a new target MAG after a 163 handover should resolve the LMA FQDN to the LMA IP address where the 164 MN mobility session is already located. 166 The procedures described in this section and in Section 2.1 may also 167 be used together. For example, the AAA server might return a generic 168 LMA FQDN during the MN initial attach and once the LMA gets selected, 169 return the LMA IP address during the subsequent attachments to other 170 MAGs in the PMIPv6 domain. In order for this to work, the resolved 171 and selected LMA IP address must be updated to the remote Policy 172 Store. For example, the LMA could perform the update once it 173 receives the initial PBU from the MAG for the new mobility session. 175 3. Lower Layers based Discovery Solutions 177 The following section discusses solutions, where the MAG receives 178 information from lower layers below the IP layer when the MN attaches 179 to the MAG. Based on this information, the MAG is then able to 180 determine which LMA to contact. These solution could essentially 181 allow large PMIPv6 deployments without the AAA infrastructure. The 182 lower layers discussed here are not explicitly defined but could 183 include different radio access technologies and tunneling solutions 184 such as IKEv2 [RFC4306] IPsec tunnel [RFC4303]. 186 3.1. Constructing the LMA FQDN from a mobile node Identity 188 Depending on the actual network access technology, the MAG may be 189 able to receive a MN identity (or actually the subscription identity 190 but from now on we assume that the MN identity equals to the 191 subscription identity, which is a rather broad simplification) as a 192 result of the network access attachment procedure. The MN may signal 193 its identity as part of the attachment signaling or alternatively the 194 MAG receives the MN identity from a remote policy store. 196 Once the MAG has acquired the MN identity, the MAG can use the 197 information embedded in the identity to construct a generic LMA FQDN 198 (based on some pre-configured formatting rules) and then proceed to 199 resolve the LMA IP address(es) using the DNS. Obviously, the MN 200 identity must embed information elements that can be extracted and at 201 minimum used to determine the entity hosting and operating the LMA 202 for the MN. Thus the MN identity in this solution cannot be a "flat" 203 identity without any structure and "clear text" parts containing the 204 hosting entity information. Examples of such identities are the 205 International Mobile Subscriber Identity (IMSI) or Globally Unique 206 Temporary User Equipment Identity (GUTI) [3GPP.23.003] that both 207 contain information of the operator owning the given subscription. 209 The solution discussed in this section has issues if MN's identity 210 does not embed enough information. In a case the MN identity does 211 not embed any LMA hosting entity information, the MAG might use a 212 local database to map MN identities to corresponding LMAs. However, 213 this solution is unlikely to scale outside a limited PMIPv6 domain. 215 3.2. Receiving LMA FQDN or IP Address from Lower Layers 217 The solution described in this section is similar to the solution 218 discussed in Section 3.1. Instead of deriving the LMA FQDN from the 219 MN identity, the MAG receives explicit LMA FQDN or IP address 220 information from lower layers. This usually means the MN is the 221 originator of the LMA information and explicitly participates to the 222 mobility management signaling (even if that only means providing LMA 223 discovery assisting information). 225 3.3. Constructing the LMA FQDN from a Service Name 227 Some network access technologies (including tunneling solutions) 228 allow the MN to signal the service name that identifies a particular 229 service or the external network it wants to access. If the MN 230 originated service name also embeds the information of the entity 231 hosting the service or the external network, then the MAG can 232 construct a generic LMA FQDN (e.g., based on some pre-configured 233 formatting rules) providing an access to the service or the external 234 network. Once the MAG has the FQDN it can proceed to resolve the LMA 235 IP address(es) using the DNS. Example of such service or external 236 network name is the Access Point Name (APN) [3GPP.23.003] that 237 contain information of the operator providing the access to the given 238 service or the external network. 240 4. Domain Name System Considerations 242 A number of LMA discovery solutions described in Section 2 and 243 Section 3 eventually depend on the DNS. This section discusses 244 impacts of the DNS response caching and issues related to the Dynamic 245 DNS [RFC2136] updates. 247 The caching (positive or negative) properties of the DNS [RFC2308] 248 and the fact that updates to the DNS take time to propagate globally, 249 need to be considered when applying DNS-based solutions to the PMIPv6 250 domain. First, the caching of DNS responses effectively delay the 251 propagation of up to date FQDN to IP address mappings (after both 252 addition and deletion). Hosts in the PMIPv6 domain keep using the 253 stale cached DNS response (positive or negative) until they give up 254 or the caching times out. The delay can be in order of hours in the 255 worst case. On the other hand, DNS administrators can lower the 256 resource record caching time (the Time To Live (TTL) value). 257 Obviously, too low TTL values increase the number of DNS queries 258 considerably. Second, the secondary DNS servers do not get 259 immediately updated when the masters do. These updates are also 260 periodic, usually in order of several hours, and may cause 261 considerable delay on global propagation of the updated naming 262 information. Third, some DNS resolvers ignore low TTLs, replacing 263 them with a higher default value. This could lead to outdated LMA 264 information being around for longer than desired. 266 The above considerations are valid when, for example, the PMIPv6 267 domain LMA availability or load information is dynamically updated 268 into the DNS. There are incentives for doing so, however, the 269 concerns described above need to be understood clearly in that case. 271 5. Handover Considerations 273 Whenever a MN moves and attaches to a new MAG in a PMIPv6 domain, all 274 the MAGs that the MN attaches to, should use the same LMA. If there 275 is only one LMA per PMIPv6 domain, then there is no issue. If there 276 is a context transfer mechanism available between the MAGs, then the 277 new MAG knows the LMA information from the old MAG. Such a mechanism 278 is described in [I-D.ietf-mipshop-pfmipv6]. If the MN related 279 context is not transferred between the MAGs, then a mechanism to 280 deliver the current LMA information to the new MAG is required. 282 Relying on DNS during handovers is not generally a working solution 283 if the PMIPv6 domain has more than one LMA, unless the DNS 284 consistently assigns a specific LMA for each given MN. In most cases 285 described in Section 3, where the MAG derives the LMA FQDN, there is 286 no prior knowledge whether the LMA FQDN resolves to one or more LMA 287 IP address(es) in the PMIPv6 domain. However, depending on the 288 deployment and deployment related regulation (such as inter-operator 289 roaming consortium agreements) the situation might not be this 290 desperate. For example, a MAG might be able to synthesize a LMA 291 specific FQDN (e.g. out of MN identity or some other service specific 292 parameters). Another alternative could that MAG uses, for example, a 293 MN identity as an input to an algorithm that deterministically 294 assigns the same LMA out of a pool of LMAs (assuming the MAG has e.g. 295 learned a group of LMA FQDNs via SRV [RFC2782] query). These 296 approaches would guarantee that DNS returns always the same LMA 297 Address to the MAG. 299 Once the MN completes its initial attachment to a PMIPv6 domain, the 300 information about the LMA that is selected to serve the MN is stored 301 in the Policy Store (or the AAA server). The LMA information is 302 conveyed to the policy store by the LMA after the initial attachment 303 is completed [I-D.ietf-dime-pmip6]. Typically AAA infrastructure is 304 used for exchanging information between the LMA and the Policy Store. 306 When the MN moves and attaches to another MAG in the PMIPv6 domain, 307 then the AAA servers delivers the existing LMA information to the new 308 MAG as part of the authentication and authorization procedure as 309 described in Section 2.1 311 6. Security Considerations 313 The use of DNS for obtaining the IP address of a mobility agent 314 carries certain security risks. These are explained in detail in 315 Section 9.1 of RFC 5026 [RFC5026]. However, the risks described in 316 RFC 5026 are mitigated to a large extent in this document, since the 317 MAG and the LMA belong belong to the same PMIPv6 domain. The DNS 318 server that the MAG queries is also part of the same PMIPv6 domain. 319 Even if the MAG obtains the IP address of a bogus LMA from a bogus 320 DNS server, further harm is prevented since the MAG and the LMA 321 should authenticate each other before exchanging PMIPv6 signaling 322 messages. RFC 5213 [RFC5213] specifies the use of IKEv2 [RFC4306] 323 between the MAG and the LMA to authenticate each other and setup 324 IPsec security associations for protecting the PMIPv6 signaling 325 messages. 327 The AAA infrastructure may be used to transport the LMA discovery 328 related information between the MAG and the AAA server via one or 329 more AAA brokers and/or AAA proxies. In this case the MAG to the AAA 330 server communication relies on the security properties of the 331 intermediate AAA brokers and AAA proxies. 333 7. IANA Considerations 335 This specification has no actions for IANA. 337 8. Acknowledgements 339 The authors would like to thank Julien Laganier, Christian Vogt, 340 Ryuji Wakikawa, Frank Xia and Behcet Sarikaya for their comments and 341 suggestions on this document. 343 9. Informative References 345 [3GPP.23.003] 346 3GPP, "Numbering, addressing and identification", 3GPP 347 TS 23.003 8.2.0, September 2008. 349 [I-D.ietf-dime-pmip6] 350 Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., 351 and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access 352 Gateway and Local Mobility Anchor Interaction with 353 Diameter Server", draft-ietf-dime-pmip6-02 (work in 354 progress), April 2009. 356 [I-D.ietf-mipshop-pfmipv6] 357 Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 358 Xia, "Fast Handovers for Proxy Mobile IPv6", 359 draft-ietf-mipshop-pfmipv6-08 (work in progress), 360 July 2009. 362 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 363 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 364 RFC 2136, April 1997. 366 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 367 NCACHE)", RFC 2308, March 1998. 369 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 370 specifying the location of services (DNS SRV)", RFC 2782, 371 February 2000. 373 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 374 RFC 4303, December 2005. 376 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 377 RFC 4306, December 2005. 379 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 380 Bootstrapping in Split Scenario", RFC 5026, October 2007. 382 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 383 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 385 [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., 386 and K. Chowdhury, "Diameter Mobile IPv6: Support for 387 Network Access Server to Diameter Server Interaction", 388 RFC 5447, February 2009. 390 Authors' Addresses 392 Jouni Korhonen 393 Nokia Siemens Networks 394 Linnoitustie 6 395 FIN-02600 Espoo 396 Finland 398 Email: jouni.nospam@gmail.com 399 Vijay Devarapalli 400 WiChorus 401 3950 North First Street 402 San Jose, CA 95134 403 USA 405 Email: vijay@wichorus.com