idnits 2.17.1 draft-wu-dime-pmip6-lr-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.ii 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 26, 2009) is 5289 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MN1' is mentioned on line 302, but not defined == Missing Reference: 'MN2' is mentioned on line 302, but not defined == Missing Reference: 'MAG2' is mentioned on line 308, but not defined == Missing Reference: 'LMA2' is mentioned on line 255, but not defined ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) == Outdated reference: A later version (-06) exists of draft-ietf-netext-pmip6-lr-ps-00 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Wu 3 Internet-Draft J. Xia 4 Intended status: Standards Track Y. Wang 5 Expires: April 29, 2010 Huawei 6 G. Zorn, Ed. 7 Network Zen 8 October 26, 2009 10 AAA Support for PMIP6 mobility entities Locating and Discovery during 11 localized routing 12 draft-wu-dime-pmip6-lr-01 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 29, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the 51 the Mobile Access Gateway (MAG) to which it is attached are typically 52 tunneled to a Local Mobility Anchor (LMA) for routing. The term 53 "localized routing" refers to a method by which packets are routed 54 directly by the MAG without involving the LMA. In order to establish 55 a localized routing session between two Mobile Access Gateways in a 56 Proxy Mobile IPv6 domain, two tasks must be accomplished: 58 1. The usage of local routing must be authorized for both MAGs and 60 2. The address of the MAG to which the Correspondent Node (CN) is 61 attached must be discovered 63 This document specifies how to accomplish these tasks using the 64 Diameter protocol 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Locating the Recipient of Localized Routing . . . . . . . . . 6 72 5. Diameter Server Authorizes a MAG Location Query . . . . . . . 8 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 Proxy Mobile IPv6 (PMIPv6 [RFC5213] allows the Mobility Access 83 Gateway to optimize media delivery by locally routing packets within 84 itself, avoiding tunneling them to the Mobile Node's Local Mobility 85 Anchor. This is referred to as "local routing" in RFC 5213. 86 However, this mechanism is not applicable to the typical scenario 87 where the MN and CN are under different MAGs and belong to different 88 LMAs. In this scenario (described in [I-D.ietf-netext-pmip6-lr-ps]), 89 the relevant information needed to set up a localized routing path 90 (e.g., the Mobile Access Gateways to which the MN and CN are 91 respectively attached) is distributed between their respective Local 92 Mobility Anchors. This may complicate the setup and maintenance of 93 localized routing. 95 Therefore, in order to establish a localized routing path between the 96 two Mobile Access Gateways, the Mobile Node's MAG must discover which 97 LMA is managing the Correspondent Node's traffic and then fetch the 98 address of the Correspondent Node's MAG from that LMA. In Proxy 99 Mobile IPv6, the LMA to be assigned to CN may be maintained as a 100 configured entry in the Correspondent Node's policy profile located 101 on a Authentication, Authorization and Accounting (AAA) server. 102 However, there is no relevant work discussing how the Correspondent 103 Node's LMA is discovered by Mobile Node's MAG in terms of the 104 Correspondent Node's Home Network Prefix (HNP) using AAA-based 105 mechanisms during the setup of localized routing. The method by 106 which the Mobile Node's MAG interacts with the Correspondent Node's 107 LMA to identify the Correspondent Node's MAG is also unspecified. 109 This document describes AAA support for the authorization and 110 discovery of PMIPv6 mobility entities during localized routing. In 111 LMA discovery, Diameter [RFC3588] is used to authorize the localized 112 routing service and provide the Mobile Node's MAG/LMA with 113 information regarding the Correspondent Node's LMA. In MAG 114 discovery, AAA is used to determine whether Mobile Node's MAG is 115 allowed to fetch the address of the Correspondent Node's MAG from the 116 Correspondent Node's LMA. If MAG discovery is successful, the the 117 Correspondent Node's LMA will respond to the Mobile Node's MAG with 118 the address of the Correspondent Node's MAG. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 3. Solution Overview 128 MAG/LMA resolution is a prerequisite to the establishment of a direct 129 routing path between MAG1 and MAG2 (associated with MN1 and MN2 130 respectively), this document addresses how to resolve the destination 131 MN's MAG by means of interaction between the MAG and the AAA server, 132 and between the LMA and the AAA server. Figure 1 shows the reference 133 architecture for the MAG resolution. This reference architecture 134 assumes 136 o MN1 and MN2 belong to different LMA 138 o the MAG and LMA support Diameter client functionality 140 LMA2? +---------+ 141 +-------------->| AAA & | 142 | LMA2? | Policy |<--------------+ 143 | +-->| Profile | | 144 | Diameter+---------+ Diameter 145 Diameter AAA(a) AAA(b) 146 AAA(a) +--+-+ +----+ | 147 | |LMA1| +----->|LMA2|<-------+ 148 | +----+ | +----+ 149 | | | | 150 | // | \\ 151 | // PMIP \\ 152 | // | \\ 153 | | | | 154 | +----+ MAG2? | +----+ 155 +---->|MAG1|<--------+ |MAG2| 156 +----+ +----+ 157 : : 158 +---+ +---+ 159 |MN1| |MN2| 160 +---+ +---+ 162 Figure 1: Local Routing Service Authorization Reference Architecture 164 The interaction of the MAG and LMA with the AAA server is a two step 165 procedure involving 167 1. Interaction between MAG1 or LMA1 and the AAA server authorizing 168 the use of localized routing between MAG1 and MAG2 and (if 169 successful) fetching the IP address of LMA2 (step 'a' in 170 (Figure 1)) 172 2. Interaction between LMA2 and the AAA server authorizing the use 173 of localized routing between MAG1 and MAG2 and (if successful) 174 fetching the IP address of MAG2 (step 'b' in (Figure 1)) 176 4. Locating the Recipient of Localized Routing 178 Figure 2 shows a scenario where MAG1 acts as a Diameter client, 179 processing the data packet from MN1 to MN2 and requesting the 180 recipient of localized routing. In this scenario, MN1 and MN2 are 181 anchored to LMA1 and LMA2 respectively. In order to initiate a 182 localized routing path with NMAG2, MAG1 must first locate the entity 183 that maintains the data required to setup the path (i.e., LMA2). The 184 Diameter client in MAG1 sends an AA-Request (AAR) message to the 185 Diameter server. The message contains an instance of the Service- 186 Type AVP ([RFC4005], section 6.1). with the value "PMIPv6 Localized 187 Routing Authorization" Section 7 and an instance of the MIP6-Home- 188 Link-Prefix AVP ([RFC5447], section 4.2.4) containing the IP address 189 of MN2. The Diameter server checks if localized routing is allowed 190 between MAG1 and MAG2 and if so, responds with an AA-Answer (AAA) 191 message encapsulating an instance of the MIP6-Agent-Info AVP 192 [I-D.ietf-dime-pmip6] containing the IP address and/or Fully 193 Qualified Domain Name (FQDN) of LMA2. MAG1 then determines the IP 194 address of LMA2 using the data returned in the MIP6-Agent-Info, 195 requests the address of MAG2 from LMA2 and uses that address to setup 196 the localized routing path between itself and MAG2 via the Proxy 197 Binding Update (PBU)/Proxy Binding Acknowledgement (PBA) message 198 exchange [RFC5213]. 200 +---+ +----+ +----+ +---+ +----+ +----+ +---+ 201 |MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2| 202 +-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+ 203 | | | | | | | 204 | Anchored | | | Anchored | 205 o----------------o | o-------+--------o 206 Data[MN1->MN2] | | | | | 207 |------->|AAR(service type,MN2) | | | 208 | |----------------->| | | | 209 | |AAA(LMA2) | | | | 210 | |<-----------------| | | | 211 | | |PBU(LR[MN1,MN2]) | | | 212 | |-------+----------+--------->| | | 213 | | | PBA(LR[MAG2]) | | | 214 | |<--------------------------- | | | 215 | | MAGs PBU/PBA exchange | | | 216 | |<----------------------------------->| | 217 | | | | | | | 218 | |====================================>|------->| 219 | | | | | |Data[MN2->MN1] 220 |<------ |<====================================|<-------| 221 | | | | | | | 223 Figure 2: Locating the Recipient of Localized Routing 225 Figure 3 shows another scenario, in which LMA1 acts as a Diameter 226 client, processing the data packet from MN1 to MN2 and requesting the 227 recipient of localized routing. In this scenario, MN1 and MN2 are 228 anchored to LMA1 and LMA2 respectively. In contrast with the 229 signaling flow of Figure 2 the difference is that it is LMA1 instead 230 of MAG1 who solicits the IP address of LMA2 from the Diameter server. 232 The Diameter client in LMA1 sends an AA-Request (AAR) message to the 233 Diameter server. The message contains an instance of the Service- 234 Type AVP ([RFC4005], section 6.1). with the value "PMIPv6 Localized 235 Routing Authorization" Section 7 and an instance of the MIP6-Home- 236 Link-Prefix AVP ([RFC5447], section 4.2.4) containing the IP address 237 of MN2. The Diameter server checks if localized routing is allowed 238 between MAG1 and MAG2 and if so, responds with an AA-Answer (AAA) 239 message encapsulating an instance of the MIP6-Agent-Info AVP 240 [I-D.ietf-dime-pmip6] containing the IP address and/or Fully 241 Qualified Domain Name (FQDN) of LMA2. LMA1 then determines the IP 242 address of LMA2 using the data returned in the MIP6-Agent-Info and 243 forwards it to MAG1 in the Notification Request message. 245 +---+ +----+ +----+ +---+ +----+ +----+ +---+ 246 |MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2| 247 +-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+ 248 | | | | | | | 249 | Anchored | | | Anchored | 250 o----------------o | o-------+--------o 251 Data[MN1->MN2] | | | | | 252 |------->|=====-> AAR(Service Type,MN2)| | | 253 | | |--------->| | | | 254 | Notification|AAA(LMA2) | | | 255 | Req[LMA2] <----------| | | | 256 | |<------| PBU(LR[MN1,MN2]) | | | 257 | |-------+----------+--------->| | | 258 | | | PBA(LR[MAG2]) | | | 259 | |<--------------------------- | | | 260 | | MAGs PBU/PBA exchange | | | 261 | |<----------------------------------->| | 262 | | | | 263 | |===================================->| | 264 | | | | | |------->| 265 | | | | | |Data[MN2->MN1] 266 |<------ |<-===================================|<-------| 267 | | | | | | | 269 Figure 3: Locating the Recipient of Localized Routing 271 5. Diameter Server Authorizes a MAG Location Query 273 Figure 4 shows a scenario in which LMA2 acts as a Diameter client, 274 receiving location request and requesting authorization for MAG 275 location lookup. In this scenario, MN1 and MN2 are anchored to LMA1 276 and LMA2 respectively. Upon receiving an upstream data packet, MAG1 277 needs to determine the recipient of localized routing, i.e., LMA2. 278 And then MAG1 solicit the LMA2 to lookup IP address of MAG2 to which 279 MN2 is currently attached by sending localized routing request 280 message containing IP address/HNP of MN1 and MN2. In this step, the 281 LMA2 needs to validate the request from MAG1 by sending an AAR to the 282 AAA server. In the AAR message, IP address/HNP of MN1 and the new 283 service type for localized routing are included. The Diameter Server 284 makes authorization based on the IP address/HNP of MN1 and checks the 285 new service type for localized routing encapsulated in the LMA-AAA 286 AVPs. In successful case, the Diameter Server responds to the LMA 287 with success status. And then LMA2 lookup IP address of MAG2 based 288 on the IP address/HNP of MN2 and respond to the MAG1 with the IP 289 address of MAG2. 291 +---+ +----+ +----+ +---+ +----+ +----+ +---+ 292 |MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2| 293 +-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+ 294 | | | | | | | 295 | Anchored | | | Anchored | 296 o----------------o | o-------+--------o 297 Data[MN1->MN2] | | | | | 298 |------->| | | | | | 299 |+--------------+| | | | | 300 ||Recipient=LMA2|| | | | | 301 |+--------------+| | | | | 302 | | PBU(LR[MN1,MN2]) | | | 303 | |-------+----------+--------->| | | 304 | | | |AAR(Service Type,MN1) | 305 | | | |<-------- | | | 306 | | | | AAA | | | 307 | | | |--------->| | | 308 | | |PBA(LR[MAG2]) | | | 309 | |<--------------------------- | | | 310 | | MAGs PBU/PBA exchange | | | 311 | |<----------------------------------->| | 312 | | | | 313 | |===================================->| | 314 | | | | | |------->| 315 | | | | | |Data[MN2->MN1] 316 |<------ |<-===================================|<-------| 317 | | | | | | | 319 Figure 4: Diameter Server Authorizes MAG Location Query 321 6. Security Considerations 323 The security considerations for the Diameter NASREQ [RFC4005] and 324 Diameter Proxy Mobile IPv6 applications [I-D.ietf-dime-pmip6] are 325 applicable to this document. 327 The service authorization solicited by the MAG or the LMA relies upon 328 the existing trust relationship between the MAG or LMA and the AAA 329 server. 331 7. IANA considerations 333 The IANA is requested to allocate a new value for the Service-Type 334 AVP as follows: PMIPv6 Localized Routing Authorization 335 according to the "IETF Review" policy [RFC5225]. 337 8. References 339 8.1. Normative References 341 [I-D.ietf-dime-pmip6] 342 Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., 343 and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access 344 Gateway and Local Mobility Anchor Interaction with 345 Diameter Server", draft-ietf-dime-pmip6-04 (work in 346 progress), September 2009. 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 352 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 354 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 355 "Diameter Network Access Server Application", RFC 4005, 356 August 2005. 358 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 359 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 361 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 362 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 363 UDP-Lite", RFC 5225, April 2008. 365 [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., 366 and K. Chowdhury, "Diameter Mobile IPv6: Support for 367 Network Access Server to Diameter Server Interaction", 368 RFC 5447, February 2009. 370 8.2. Informative References 372 [I-D.ietf-netext-pmip6-lr-ps] 373 Liebsch, M., Jeong, S., and W. Wu, "PMIPv6 Localized 374 Routing Problem Statement", 375 draft-ietf-netext-pmip6-lr-ps-00 (work in progress), 376 September 2009. 378 Authors' Addresses 380 Qin Wu 381 Huawei Technologies Co., Ltd. 382 Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd. 383 Nanjing, JiangSu 210001 384 China 386 Phone: +86-25-84565892 387 Email: Sunseawq@huawei.com 389 Jinwei Xia 390 Huawei Technologies Co., Ltd. 391 Huihong Mansion, No.91 Baixia Rd. 392 Nanjing, Jiangsu 21001 393 China 395 Phone: +86-025-8456-5890 397 Yungui Wang 398 Huawei Technologies Co., Ltd. 399 Huihong Mansion, No.91 Baixia Rd. 400 Nanjing, Jiangsu 21001 401 China 403 Phone: +86-025-8456-5893 405 Glen Zorn (editor) 406 Network Zen 407 1310 East Thomas Street 408 Seattle, Washington 98102 409 +1 (206) 377-9035 411 Email: gwz@net-zen.net