idnits 2.17.1 draft-zuniga-netext-wimax-mn-ar-if-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5213]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 06, 2009) is 5278 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2865' is mentioned on line 232, but not defined == Missing Reference: 'RFC3588' is mentioned on line 232, but not defined ** Obsolete undefined reference: RFC 3588 (Obsoleted by RFC 6733) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group JC. Zuniga 3 Internet-Draft M. Perras 4 Intended status: Informational InterDigital Communications, LLC 5 Expires: May 10, 2010 T. Melia 6 Alcatel-Lucent Bell Labs 7 C. Bernardos 8 Universidad Carlos III de Madrid 9 November 06, 2009 11 Support of Proxy MIP in the context of WiMAX Networks 12 draft-zuniga-netext-wimax-mn-ar-if-00 14 Abstract 16 This ID documents the support of Proxy MIP in the context of WiMAX 17 networks (WiMAX-to-WiMAX using PMIP). The main goal is to support 18 the Netext working group in the discussions regarding how RFC 5213 19 [RFC5213] has been deployed by other SDOs. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on May 10, 2010. 50 Copyright Notice 52 Copyright (c) 2009 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the BSD License. 65 Table of Contents 67 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Differences between PMIP in WiMAX and IETF specifications . . 5 70 3.1. New parameters introduced to indicate IP service 71 capability . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.2. Authenticator/NAS function introduced . . . . . . . . . . 6 73 3.3. In-band protocol security applied between MAG/LMA . . . . 6 74 4. PMIPv6 support - CSN anchored mobility management . . . . . . 6 75 4.1. Network attachment . . . . . . . . . . . . . . . . . . . . 7 76 4.1.1. Network Service Capability Negotiation . . . . . . . . 7 77 4.1.2. IP address configuration . . . . . . . . . . . . . . . 8 78 4.2. PMIPv6 connection setup . . . . . . . . . . . . . . . . . 8 79 4.3. PMIPv6 CSN-anchored mobility handover . . . . . . . . . . 9 80 4.4. PMIPv6 session termination . . . . . . . . . . . . . . . . 10 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 86 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Terminology 91 This document uses the following terminology: 93 A-DPF ASN-GW DPF 95 ASN Access Service Network 97 CSN Connectivity Service Network 99 DPF Data Path Function 101 FA Foreign Agent 103 HA Home Agent 105 LMA Local Mobility Anchor 107 MAG Mobile Access Gateway 109 NAS Network Access Server 111 NSP Network Service Provider 113 2. Introduction 115 The WiMAX Forum specified the WiMAX Network Architecture. Figure 1 116 introduces the network reference model that shows several 117 interoperability reference points. 119 R2 120 |--------------------------------------------------------------| 121 | R3 | 122 | |-----------------------------------------| | 123 | _______|______ _____________ _____|__|____ 124 | | NAP | | V_NSP | | H_NSP | 125 | | | | | | | 126 +--|--+ | +----------+ | | +---------+ | | +---------+ | 127 | | | | ASN | | | | CSN | | | | CSN | | 128 | MS | R1 | | | | R3 | | | | R5 | | | | 129 | |------| | ASN GW | |-------| | AAA | |------| | AAA | | 130 | | | | | | | | proxy | | | | home | | 131 | | | | FA/MAG | | | | | | | | | | 132 +-----+ | | | | | | | | | | HA/LMA | | 133 | | NAS | | | +---------+ | | +---------+ | 134 | +----------+ | |_____________| |_____________| 135 | | | | 136 | | R4 | | 137 | | | | 138 | +----------+ | | 139 | | ASN | | | 140 | | | | | 141 | | ASN GW | | | 142 | | | | | 143 | | FA/MAG | | | 144 | | | | | 145 | | NAS | | |-----| 146 | +----------+ | | 147 |______________| _.----|-----. 148 ,-'' `--._ 149 / \ 150 ( Internet ) 151 \ / 152 `--. _.--' 153 `----------'' 154 Legend of lines: 155 control plane --------- 157 Figure 1: Network Reference Model with HA in home NSP 159 Figure 1 shows the WiMAX Reference Model. Reference Point R1 160 consists of the protocols and procedures between MS and ASN as per 161 the air interface specifications. Reference Point R2 consists of 162 protocols and procedures between the MS and CSN associated with 163 Authentication, Services Authorization and IP Host Configuration 164 management. Reference Point R3 consists of the set of Control Plane 165 protocols between the ASN and the CSN to support AAA, policy 166 enforcement and mobility management capabilities. It also 167 encompasses the Bearer Plane methods (e.g., tunneling) to transfer 168 user data between the ASN and the CSN. Reference Point R4 consists 169 of the set of Control and Bearer Plane protocols originating/ 170 terminating in various functional entities of an ASN that coordinate 171 MS mobility between ASNs and ASN-GWs. Reference Point R5 consists of 172 the set of Control Plane and Bearer Plane protocols for 173 internetworking between the CSN operated by the home NSP and that 174 operated by a visited NSP. 176 In PMIPv6 supported network, in order to provide the IP mobility 177 service connectivity to MS that does not have mobility capability, 178 LMA in CSN will assign a home prefix or an IPv4 MN-HoA to the MS (if 179 not statically allocated from the AAA server). Depending on the 180 network configuration, the home prefix(es) could be assigned by 181 either V-LMA (if VCSN exists) or H-LMA. Authentication, 182 authorization and accounting information as well as policy control 183 are handled by the home NSP over R3 and/or R5 reference points. 185 In the remainder of this document we assume PMIPv6 is the selected 186 mobility management protocol. 188 3. Differences between PMIP in WiMAX and IETF specifications 190 The WiMAX network architecture is specified in [WMF-T32-002-R010v04 191 Part 1]. The PMIPv6 protocol support in WiMAX is specified in [WiMAX 192 Forum Network Working Group Proxy MIPv6 support Stage 2]. The main 193 differences between the PMIPv6 protocol specified in [RFC5213] and 194 the PMIPv6 protocol specified by WiMAX Forum are listed here and 195 described in more details in the following sub-sections. These 196 differences are mainly: 1) the introduction of new parameters used to 197 indicate the IP service capability of the ASN and VCSN, 2) the 198 introduction of the Authenticator/NAS function and 3) the in-band 199 protocol security applied by the MAG/LMA to the PBU/PBA. 201 3.1. New parameters introduced to indicate IP service capability 203 The new parameters named ASN IP Service Capabilities and VCSN IP 204 Service Capabilities are used to indicate the IP service capability 205 of the ASN and VCSN and are introduced in the WiMAX network. 207 It should be noted that these parameters are conveyed from ASN (VCSN) 208 to (H)CSN through AAA request message. Once the MS is successfully 209 authenticated by the HAAA and HCSN has authorized one or more IP 210 Services, the Authorized IP Services and Authorized Anchor Location 211 attributes are passed to ASN through AAA Response message. 213 These parameters are not specified in the PMIP specifications 214 [RFC5213] 216 3.2. Authenticator/NAS function introduced 218 The Authenticator/NAS negotiates the PMIPv6 security mode with the 219 HAAA and makes that information available to the MAG. If the 220 negotiated security mode is in-band, then the Authenticator/NAS 221 facilitates authentication and authorization functions with the aim 222 to acquire, store and distribute keys and related security 223 information required for PMIPv6 operation. Authenticator interworks 224 with MAG in the process of establishing the LMA trust relationships 225 and appropriately securing mobility signaling. 227 The Authenticator/NAS functionally is specific to the WiMAX 228 specifications. What is specified in [RFC4285] is only concerning 229 the authentication and AAA server: "The network entities in the Proxy 230 Mobile IPv6 domain, while serving a mobile node, will have access to 231 the mobile node's policy profile and these entities can query this 232 information using RADIUS [RFC2865] or DIAMETER [RFC3588] protocols". 234 3.3. In-band protocol security applied between MAG/LMA 236 There are two mandatory-to-implement and optional-to-use security 237 modes for PMIP6: One using [RFC4285] (in-band security), and the 238 other not using any PMIP6-specific security but relying on the R3/R5 239 control plane security (lower-layer security). NSP and NAP decide 240 which mode to operate based on their local policy and the dynamic 241 negotiation during the network access authentication of the MS. MAG 242 learns the negotiated mode from the authenticator in order to 243 generate the PBU and process the PBA accordingly. 245 Proxy MIPv6 [RFC5213] specifies IPsec as a mandatory-to-implement 246 security mechanism. It also specifies that the use of IPsec for 247 protecting a mobile node's data traffic is optional. Additionally, 248 it specifies that other documents may specify alternative for 249 securing Proxy Mobile IPv6 signaling messages. In WiMAX networks, 250 the PMIPv6 signaling messages are secured using the security mode 251 defined in [RFC4285] (use of AE in the PBU/PBA). 253 4. PMIPv6 support - CSN anchored mobility management 255 As stated before we focus here on the use of PMIPv6. We summarize in 256 the following sections the attachment procedures, PMIPv6 connection 257 setup, CSN-anchored mobility handover and detachment procedures 258 focusing on the PMIPv6 usage and MAG, Authenticator, LMA functions. 260 4.1. Network attachment 262 CSN anchored mobility management based on PMIPv6 is transparent to 263 the MS. At the time of the network entry, MS undergoes the regular 264 attachment procedures without directly participating in mobility 265 signaling; selects the network, performs the network entry and 266 proceeds by configuring the IP address. For a given MS, the network 267 determines whether to use PMIPv6 or not. 269 4.1.1. Network Service Capability Negotiation 271 Simple IP, CMIP and PMIP services for IPv4 as well as IPv6 may be 272 simultaneously provided by a network. Such network configuration 273 provides coexistence of Simple IP service and MIP service support on 274 a per user basis. Whether the Simple IP service or PMIP or CMIP 275 service is invoked by the network for a given user will depend on the 276 user profile, network capabilities negotiation between ASN, VCSN and 277 HCSN along with the operator policy. 279 4.1.1.1. Selection Scheme 281 The Network Service Capability Negotiation and Selection scheme 282 expands the network access authentication and authorization process 283 adding capability to negotiate the appropriate IP service among ASN, 284 VCSN (when exists) and HCSN. Two new RADIUS attributes named ASN IP 285 Service Capability and V-CSN IP Service Capabilities have been 286 defined to indicate IP service capabilities of ASN and VCSN, 287 respectively. 289 These parameters are conveyed from ASN (VCSN) to (H)CSN through AAA 290 request message. Once the MS is successfully authenticated by the 291 HAAA and HCSN has authorized one or more IP Services, the Authorized 292 IP Services and Authorized Anchor Location attributes are passed to 293 ASN through AAA Response message. 295 Depending on the outcome of this capability negotiation, ASN offers 296 only one of authorized Simple IP, PMIP or CMIP services to the 297 mobile. When multiple IP services are authorized it is the ASN 298 network that makes the final decision of whether or not to allow MS 299 request and assign the appropriate IP service support for this MS. 301 4.1.1.2. Selection Flow 303 During MS authentication phase, the AAA Request message is sent by 304 the ASN to the H-AAA of the MS (may be sent via the AAA Proxy at the 305 VCSN). In particular, ASN includes the ASN IP Service Capabilities 306 attribute in the AAA Request to provide current ASN IP service 307 capability information of this ASN to the HAAA. 309 After receiving AAA Request message, the VCSN adds VCSN IP Service 310 Capabilities attribute to this message and forward the message to 311 HAAA Server at the HCSN. 313 Once the HAAA Server successfully authenticates and authorizes the MS 314 services, the HAAA returns the AAA Response message to the NAS in ASN 315 via the AAA Proxy at the VCSN. Together with other MS subscriber and 316 IP configuration parameters, the Authorized IP Services (and Visited 317 Authorized IP Services if VCSN anchoring is permitted) attribute are 318 also included in the AAA Response message. 320 The AAA Proxy in VCSN relays this AAA Response message to ASN. The 321 ASN extracts out the Authorized IP Services and Visited Authorized IP 322 Services information, stores them locally and makes it available to 323 use by the appropriate IP service function entities within ASN. 324 Depending on the outcome of the capability negotiation, the ASN 325 selects among the authorized services and offers a single IP service 326 to the MS. 328 4.1.2. IP address configuration 330 WiMAX network supports both stateless and stateful IPv6 address 331 autoconfiguration methods within the PMIPv6 scope. Depending on the 332 configuration and preferences, MS can try to configure an IPv4 333 address by DHCPv4, one or more IPv6 addresses by DHCPv6 or stateless 334 address autoconfiguration. 336 If for any reason the network needs to enforce a specific 337 configuration method it must set the particular address configuration 338 flags in the RA messages (ManagedFlag and OtherConfigFlag) to do so. 340 The HNP for the PMIPv6 MN-HoA may be allocated from two sources, the 341 LMA or the AAA server. 343 - Prefix/HoA can be bootstrapped from the dedicated AAA server during 344 the network authentication process. 346 - PMIPv6 LMA assigns the unique/64 IPv6 prefix in response to the PBU 347 message from the AR/MAG (ASN) with Home Prefix option set to 348 ALL_ZERO, when HNP has not been obtained through network 349 authentication. 351 4.2. PMIPv6 connection setup 353 The network authentication enables the ASN/NAS to negotiate and 354 boostrap the necessary PMIPv6 mobility parameters and network 355 configuration, including the assigned IP address or IPv6 prefix, 356 security related settings, authorized address configuration mode(s), 357 etc. 359 The PMIPv6 connection setup takes place after the initial network 360 entry and access authentication is completed. The prerequisite for 361 the procedure is the network decision to assign the network-based 362 PMIPv6 service for MS IP session. The mobility binding registration 363 from the AR/MAG can occur at any moment following the access 364 authentication response that brought the required IP capabilities and 365 services authorization from the H/VCSN to the ASN where MS is 366 attaching. 368 The connection setup procedures are differentiated by the address 369 configuration process the MS undergoes. For an IPv6 MS the WiMAX 370 network should provide both stateful and stateless address 371 (auto)configuration modes with per-MS unique prefix assignment, while 372 for IPv4 MS, the DHCPv4 support is needed to distribute the IPv4 MN- 373 HoA to the MS. 375 The MS is not involved in PMIPv6 mobility procedures and only 376 required to perform the common address acquisition and configuration 377 procedure to obtain IP mobility management via PMIPv6. 379 4.3. PMIPv6 CSN-anchored mobility handover 381 PMIPv6 mobility handover comes as a result of the A-DPF handover and 382 R3 path relocation to the new serving ASN. There are no specific 383 requirements towards the MS for the case of PMIPv6 handover. The new 384 serving ASN(b) SHOULD assure the appropriate link configuration and 385 the same address of the first-hop AR/MAG get consistently advertised 386 to the MS after the HO, to hide the actual change of the attaching 387 link. 389 If not performed during the Idle Mode, the process is preceded by 390 regular ASN-MM procedures where the PMIPv6 MAG remains anchored at 391 the previous serving ASN-GW/ASN(a) until the Push/Pull A-DPF HO is 392 triggered. In course of the process the new ASN-GW/ASN(b) obtains 393 all mobility and security wise session information from the serving 394 ASN(a) and Anchor Authenticator, and is able to register the MS new 395 location at the LMA. Successful PMIPv6 registration from the new MAG 396 (new Proxy CoA) results with a refresh to binding cache at the LMA, 397 extension to MS PMIPv6 session and an update to MS forwarding tunnel 398 now redirected towards the new serving MAG at the ASN(b). 400 In case of idle mode, when the MS has established the data path on 401 the new serving ASN(b), triggered by one of the HO events, the 402 serving ASN(b) may initiate PMIPv6 HO by sending the 403 Anchor_DPF_HO_Trigger message to the anchor ASN(a) for PULL handover 404 mode. The anchor ASN(a) either responds or self-initiates the 405 handover (PUSH mode) by sending the Anchor_DPF_HO_Req to the serving 406 ASN(b). The message contains the relevant information associated 407 with the specific PMIPv6 session; allocated HNP or IPv4 HoA, LMA IP 408 address, protocol configuration details such as DHCP and security 409 mode (if applicable), etc. The target ASN(b) sends an 410 Anchor_DPF_Relocate_Req message to the anchor Authenticator 411 requesting a PMIP6 HO. If the ongoing PMIPv6 session requires in- 412 band protocol security, the target ASN(b) requests the keying 413 information from the anchor Authenticator needed to protect the 414 forthcoming PMIPv6 signaling exchange with the LMA. 416 In case that target AR/MAG in ASN(b) receives Anchor_DPF_ 417 Relocate_Rsp message from the anchor Authenticator, it triggers PBU/ 418 PBA procedure to register MS new location and create the PMIPv6 419 tunnel between itself and the LMA. the target ASN(b) updates the 420 anchor Authenticator with new AR/MAG location by sending the 421 Anchor_DPF_Relocate_Ack message with success code. The target ASN(b) 422 also informs the ASN(a) of the PBU registration result by sending an 423 Anchor_DPF_HO_Rsp with an appropriate result code. 425 Target AR/MAG performs the PBU registration procedure following the 426 guidelines specified in [RFC5213] . The PBU MUST contain the MN ID, 427 HNP or IPv6 HoA options, the Access Technology Type (set to value 428 WIMAX), the Handoff Indicator option (set to value of 3) as well as 429 the Link-local Address option (set to value ALL_ZERO, requesting the 430 LMA to provide current in-use AR downlink address). 432 The LMA updates the MS binding cache entry with the new location 433 information storing the new Proxy-CoA address. Upon successfully 434 updating the MS BCE, the LMA establishes PMIPv6 tunnel towards the 435 new AR/MAG together and installs the corresponding forwarding rules, 436 and simultaneously tears down the tunnel towards the previous AR/MAG 437 (old Proxy-CoA). If the AAA indicates in-band protocol security is 438 needed for the ongoing PMIPv6 session (i.e., use of AE in PBA/PBU), 439 the LMA requires and derives the necessary security parameters as to 440 protect the PBA before it is sent to the target AR/MAG. 442 Upon receiving PBA from the LMA indicating registration success, the 443 new AR/MAG in ASN(b) updates its local MS context and mobility 444 binding with the information obtained, creates PMIPv6 transport 445 tunnel towards the LMA and install the needed forwarding rules. 447 4.4. PMIPv6 session termination 449 MS self-initiates PMIPv6 session termination when detaching from the 450 network with graceful network exit, or simply performing the IP/DHCP 451 release procedure for its IP session. The designated network 452 entities may also initiate the IP session termination if discovering 453 the MS has detached/lost connectivity, prohibited from continuing the 454 service or for some other operative or administrative reason. The 455 ASN-GW/A-DPF, LMA or the AAA server induce the path deregistration by 456 issuing a corresponding trigger message towards the serving ASN-GW/ 457 ASN. Session termination SHALL follow the common NWG procedures and 458 signaling exchange to achieve R4/R6 (R6 is the interface between the 459 BS and MAG in the ASN) path release, MS state change and accounting 460 stop. If applicable, the network-initiated session termination 461 includes PMIPv6 De-registration at the LMA as well as IP/DHCP release 462 on the MS side. 464 5. Security Considerations 466 For constructing the PBU and processing PBA response from the LMA, 467 the AR/MAG follows requirements from [RFC5213] on MS attachment and 468 initial binding registration, and receiving the PBA section, with one 469 key difference. Inline with PMIPv6 service authorization results 470 from the Access-Accept, the AR/MAG must apply in-band protocol 471 security to the PBU sent to the LMA. When lower-layer transport 472 security is requested by the HCSN, AR/MAG abandons explicit 473 protection of PMIPv6 control plane. In any case, trust relationship 474 MUST be established between LMA and its corresponding MAGs. 476 When in-band security is enabled (use of AE in the PBU/PBA), the LMA 477 retrieves all necessary keying information from the AAA. Then the 478 PBU includes a valid MAG-LMA derivation in the MN-HA mobility message 479 authentication option [RFC4285]. 481 The received PBU that entails signaling protection in form of valid 482 authentication option MUST be replied a PBA using the same protection 483 mechanism. The PBUs received without embedded signaling protection 484 is processed and acknowledged only if the source MAG is considered 485 trusted and use of AE options is not enforced for that PMIPv6 peer. 487 In case MS handovers from one ASN where R3 security is present to 488 another ASN where it is not present and the target ASN wants to 489 initiate change of PMIPv6 security mode, a re-authentication has to 490 take place in order to change the negotiated security mechanism upon 491 the handover. This change is feasible only to the LMA that supports 492 the change of the security mechanism from in-band to lower-layer, or 493 vice-versa, for the same MS upon an R3 handover. 495 When the negotiated mechanism is the lower-layer security, then the 496 MAG/LMA does not include Mobility Message Authentication Option 497 [RFC4285] in the PBU/PBAs, and MAG/LMA does not drop any incoming 498 PBU/PBA which carries that option. 500 6. IANA Considerations 502 This document makes no request of IANA. 504 7. Acknowledgements 506 8. References 508 8.1. Normative References 510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP 14, RFC 2119, March 1997. 513 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 514 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 516 8.2. Informative References 518 [RFC4285] IETF, "Authentication Protocol for Mobile IPv6", 519 January 2006. 521 [WMF-T32-002-R010v04 Part 1] 522 WiMAX Forum Network Architecture, "WiMAX Forum Network 523 Architecture Stage 2 Part 1", Stage 2 R010v04, 524 February 2009. 526 [WiMAX Forum Network Working Group Proxy MIPv6 support Stage 2] 527 WiMAX Forum Network Working Group, "Proxy MIPv6 support", 528 Stage 2 1.0.0, January 2009. 530 Authors' Addresses 532 Juan Carlos Zuniga 533 InterDigital Communications, LLC 535 Email: JuanCarlos.Zuniga@InterDigital.com 537 Michelle Perras 538 InterDigital Communications, LLC 540 Email: Michelle.Perras@InterDigital.com 541 Telemaco Melia 542 Alcatel-Lucent Bell Labs 544 Email: telemaco.melia@alcatel-lucent.com 546 Carlos J. Bernardos 547 Universidad Carlos III de Madrid 549 Email: cjbc@it.uc3m.es