idnits 2.17.1 draft-ietf-netlmm-proxymip6-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2712. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2723. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2730. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2736. 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 ([RFC-3775]), 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 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o The Home Address option MUST not be present in the Destination Option extension header of the Proxy Binding Update message. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o If the received Proxy Binding Acknowledgement message has the Status field value set to PROXY_REG_NOT_ENABLED (Proxy registration not enabled for the mobile node), the mobile access gateway SHOULD not send binding registration requests again for that mobile node. It must also deny the mobility service to that mobile node. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 23, 2007) is 6053 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2472 (Obsoleted by RFC 5072, RFC 5172) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 2030 (ref. 'RFC-4330') (Obsoleted by RFC 4330) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-01 == Outdated reference: A later version (-09) exists of draft-ietf-dna-protocol-06 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM WG S. Gundavelli 3 Internet-Draft K. Leung 4 Intended status: Standards Track Cisco 5 Expires: March 26, 2008 V. Devarapalli 6 Azaire Networks 7 K. Chowdhury 8 Starent Networks 9 B. Patil 10 Nokia Siemens Networks 11 September 23, 2007 13 Proxy Mobile IPv6 14 draft-ietf-netlmm-proxymip6-06.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on March 26, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This specification describes a network-based mobility management 48 protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 50 [RFC-3775]. This protocol enables mobility support to a host without 51 requiring its participation in any mobility related signaling. The 52 design principle in the case of a network-based mobility management 53 protocol relies on the network being in control of the mobility 54 management. The mobility entities in the network are responsible for 55 tracking the movements of the host and initiating the required 56 mobility signaling on its behalf. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 5 62 2.1. Conventions used in this document . . . . . . . . . . . . 5 63 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Proxy Mobile IPv6 Protocol Overview . . . . . . . . . . . . . 8 65 4. Proxy Mobile IPv6 Protocol Security . . . . . . . . . . . . . 13 66 4.1. Peer Authorization Database Entries . . . . . . . . . . . 13 67 4.2. Security Policy Database Entries . . . . . . . . . . . . . 14 68 5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 15 69 5.1. Extensions to Binding Cache Entry Data Structure . . . . . 15 70 5.2. Supported Home Network Prefix Models . . . . . . . . . . . 16 71 5.3. Signaling Considerations . . . . . . . . . . . . . . . . . 16 72 5.4. Timestamp Option for Message Ordering . . . . . . . . . . 21 73 5.5. Routing Considerations . . . . . . . . . . . . . . . . . . 24 74 5.5.1. Bi-Directional Tunnel Management . . . . . . . . . . . 24 75 5.5.2. Forwarding Considerations . . . . . . . . . . . . . . 25 76 5.6. Local Mobility Anchor Address Discovery . . . . . . . . . 25 77 5.7. Mobile Prefix Discovery Considerations . . . . . . . . . . 26 78 5.8. Route Optimizations Considerations . . . . . . . . . . . . 26 79 6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 27 80 6.1. Extensions to Binding Update List Entry Data Structure . . 27 81 6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 28 82 6.3. Supported Access Link Types . . . . . . . . . . . . . . . 29 83 6.4. Supported Address Configuration Models . . . . . . . . . . 29 84 6.5. Access Authentication & Mobile Node Identification . . . . 30 85 6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 30 86 6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 31 87 6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 31 88 6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 33 89 6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 33 90 6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 36 91 6.9.3. Retransmissions and Rate Limiting . . . . . . . . . . 37 92 6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 37 93 6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 38 94 6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 38 95 6.10.3. Routing State . . . . . . . . . . . . . . . . . . . . 39 96 6.10.4. Local Routing . . . . . . . . . . . . . . . . . . . . 40 97 6.10.5. Tunnel Management . . . . . . . . . . . . . . . . . . 40 98 6.10.6. Forwarding Rules . . . . . . . . . . . . . . . . . . . 40 99 6.11. Supporting DHCPv6 based Address Configuration on the 100 Access Link . . . . . . . . . . . . . . . . . . . . . . . 42 101 6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 43 102 6.13. Mobile Node Detachment Detection and Resource Cleanup . . 43 103 6.14. Allowing network access to other IPv6 nodes . . . . . . . 44 104 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 44 105 7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 45 106 7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 46 107 7.3. IPv6 Host Protocol Parameters . . . . . . . . . . . . . . 46 108 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 47 109 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 48 110 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 49 111 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 50 112 8.4. Link-local Address Option . . . . . . . . . . . . . . . . 52 113 8.5. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 53 114 8.6. Status Values . . . . . . . . . . . . . . . . . . . . . . 53 115 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 55 116 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 117 11. Security Considerations . . . . . . . . . . . . . . . . . . . 56 118 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57 119 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 120 13.1. Normative References . . . . . . . . . . . . . . . . . . . 57 121 13.2. Informative References . . . . . . . . . . . . . . . . . . 58 122 Appendix A. Proxy Mobile IPv6 interactions with AAA 123 Infrastructure . . . . . . . . . . . . . . . . . . . 59 124 Appendix B. Supporting Shared-Prefix Model using DHCPv6 . . . . . 59 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 126 Intellectual Property and Copyright Statements . . . . . . . . . . 62 128 1. Introduction 130 Mobile IPv6 [RFC-3775] is the enabler for IPv6 mobility. It requires 131 Mobile IPv6 client functionality in the IPv6 stack of a mobile node. 132 Signaling between the mobile node and home agent enables the creation 133 and maintenance of a binding between the mobile node's home address 134 and care-of-address. Mobile IPv6 has been designed to be an integral 135 part of the IPv6 stack in a host. However there exist IPv6 stacks 136 today that do not have Mobile IPv6 functionality and there would 137 likely be IPv6 stacks without Mobile IPv6 client functionality in the 138 future as well. It is desirable to support IP mobility for all hosts 139 irrespective of the presence or absence of mobile IPv6 functionality 140 in the IPv6 stack. 142 It is possible to support mobility for IPv6 nodes by extending Mobile 143 IPv6 [RFC-3775] signaling and reusing the home agent via a proxy 144 mobility agent in the network. This approach to supporting mobility 145 does not require the mobile node to be involved in the signaling 146 required for mobility management. The proxy mobility agent in the 147 network performs the signaling and does the mobility management on 148 behalf of the mobile node. Because of the use and extension of 149 Mobile IPv6 signaling and home agent functionality, this protocol is 150 referred to as Proxy Mobile IPv6 (PMIPv6). 152 Network deployments which are designed to support mobility would be 153 agnostic to the capability in the IPv6 stack of the nodes which it 154 serves. IP mobility for nodes which have mobile IP client 155 functionality in the IPv6 stack as well as those hosts which do not, 156 would be supported by enabling Proxy Mobile IPv6 protocol 157 functionality in the network. The advantages of developing a network 158 based mobility protocol based on Mobile IPv6 are: 160 o Reuse of home agent functionality and the messages/format used in 161 mobility signaling. Mobile IPv6 is a mature protocol with several 162 implementations that have been through interoperability testing. 164 o A common home agent would serve as the mobility agent for all 165 types of IPv6 nodes. 167 o Addresses a real deployment need. 169 The problem statement and the need for a network based mobility 170 protocol solution has been documented in [RFC-4830]. Proxy Mobile 171 IPv6 is a solution that addresses these issues and requirements. 173 2. Conventions & Terminology 175 2.1. Conventions used in this document 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC 2119 [RFC-2119]. 181 2.2. Terminology 183 All the general mobility related terms used in this document are to 184 be interpreted as defined in the Mobile IPv6 base specification [RFC- 185 3775]. 187 This document adopts the terms, Local Mobility Anchor (LMA) and 188 Mobile Access Gateway (MAG) from the NETLMM Goals document [RFC- 189 4831]. This document also provides the following context specific 190 explanation to the following terms used in this document. 192 Proxy Mobile IPv6 Domain (PMIPv6-Domain) 194 Proxy Mobile IPv6 domain refers to the network where the mobility 195 management of a mobile node is handled using the Proxy Mobile IPv6 196 protocol as defined in this specification. The Proxy Mobile IPv6 197 domain includes local mobility anchors and mobile access gateways 198 between which security associations can be setup and authorization 199 for sending Proxy Binding Updates on behalf of the mobile nodes 200 can be ensured. 202 Local Mobility Anchor (LMA) 204 Local Mobility Anchor is the home agent for the mobile node in the 205 Proxy Mobile IPv6 domain. It is the topological anchor point for 206 the mobile node's home network prefix and is the entity that 207 manages the mobile node's reachability state. It is important to 208 understand that the local mobility anchor has the functional 209 capabilities of a home agent as defined in Mobile IPv6 base 210 specification [RFC-3775] and with the additional capabilities 211 required for supporting Proxy Mobile IPv6 protocol as defined in 212 this specification. 214 Mobile Access Gateway (MAG) 215 Mobile Access Gateway is a function that manages the mobility 216 related signaling for a mobile node that is attached to its access 217 link. It is responsible for tracking the mobile node's movements 218 on the access link and for signaling the mobile node's local 219 mobility anchor. 221 Mobile Node (MN) 223 Throughout this document, the term mobile node is used to refer to 224 an IP host whose mobility is managed by the network. The mobile 225 node may be operating in IPv6 mode, IPv4 mode or in IPv4/IPv6 dual 226 mode. The mobile node is not required to participate in any 227 mobility related signaling for achieving mobility for an IP 228 address that is obtained in that Proxy Mobile IPv6 domain. This 229 document further uses explicit text when referring to a mobile 230 node that is involved in mobility related signaling as per Mobile 231 IPv6 specification [RFC-3775]. 233 LMA Address (LMAA) 235 The address that is configured on the interface of the local 236 mobility anchor and is the transport endpoint of the bi- 237 directional tunnel established between the local mobility anchor 238 and the mobile access gateway. This is the address to where the 239 mobile access gateway sends the Proxy Binding Update messages. 240 When supporting IPv4 traversal, i.e., when the network between the 241 local mobility anchor and the mobile access gateway is an IPv4 242 network, this address will be an IPv4 address and will be referred 243 to as IPv4-LMAA, as specified in [ID-IPV4-PMIP6]. 245 Proxy Care-of Address (Proxy-CoA) 247 Proxy-CoA is the address configured on the interface of the mobile 248 access gateway and is the transport endpoint of the tunnel between 249 the local mobility anchor and the mobile access gateway. The 250 local mobility anchor views this address as the Care-of Address of 251 the mobile node and registers it in the Binding Cache entry for 252 that mobile node. When the transport network between the mobile 253 access gateway and the local mobility anchor is an IPv4 network 254 and if the care-of address that is registered at the local 255 mobility anchor is an IPv4 address, the term, IPv4-Proxy-CoA is 256 used, as specified in [ID-IPV4-PMIP6]. 258 Mobile Node's Home Address (MN-HoA) 259 MN-HoA is the home address of a mobile node in a Proxy Mobile IPv6 260 domain. It is an address from its home network prefix obtained by 261 a mobile node in a Proxy Mobile IPv6 domain. The mobile node can 262 continue to use this address as long as it is attached to the 263 network that is in the scope of that Proxy Mobile IPv6 domain. 265 Mobile Node's Home Network Prefix (MN-HNP) 267 This is the on-link IPv6 prefix that is always present in the 268 Router Advertisements that the mobile node receives when it is 269 attached to any of the access links in that Proxy Mobile IPv6 270 domain. This home network prefix is topologically anchored at the 271 mobile node's local mobility anchor. The mobile node configures 272 its interface with an address from this prefix. 274 Mobile Node's Home Link 276 This is the link on which the mobile node obtained its initial 277 address configuration after it moved into that Proxy Mobile IPv6 278 domain. This is the link that conceptually follows the mobile 279 node. The network will ensure the mobile node always sees this 280 link with respect to the layer-3 network configuration, on any 281 access link that it attaches to in that Proxy Mobile IPv6 domain. 283 Mobile Node Identifier (MN-Identifier) 285 The identity of a mobile node in the Proxy Mobile IPv6 domain. 286 This is the stable identifier of a mobile node that the mobility 287 entities in a Proxy Mobile IPv6 domain can always acquire and 288 using which a mobile node can predictably be identified. This is 289 typically an identifier such as Mobile Node NAI [RFC-4282]. 291 Proxy Binding Update (PBU) 293 A binding registration request message sent by a mobile access 294 gateway to a mobile node's local mobility anchor for establishing 295 a binding between the mobile node's MN-HNP and the Proxy-CoA. 297 Proxy Binding Acknowledgement (PBA) 299 A binding registration reply message sent by a local mobility 300 anchor in response to a Proxy Binding Update request message that 301 it received from a mobile access gateway. 303 3. Proxy Mobile IPv6 Protocol Overview 305 This specification describes a network-based mobility management 306 protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 307 [RFC-3775]. 309 Proxy Mobile IPv6 protocol is intended for providing network-based 310 mobility management support to a mobile node, without requiring the 311 participation of the mobile node in any mobility related signaling. 312 The mobility entities in the network will track the mobile node's 313 movements and will initiate the mobility signaling and setup the 314 required routing state. 316 The core functional entities in the NETLMM infrastructure are the 317 Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The 318 local mobility anchor is responsible for maintaining the mobile 319 node's reachability state and is the topological anchor point for the 320 mobile node's home network prefix. The mobile access gateway is the 321 entity that performs the mobility management on behalf of a mobile 322 node and it resides on the access link where the mobile node is 323 anchored. The mobile access gateway is responsible for detecting the 324 mobile node's movements on its access link and for sending binding 325 registrations to the mobile node's local mobility anchor. The 326 architecture of a Proxy Mobile IPv6 domain is shown in Figure 1. 328 +----+ +----+ 329 |LMA1| |LMA2| 330 +----+ +----+ 331 LMAA1 -> | | <-- LMAA2 332 | | 333 \\ //\\ 334 \\ // \\ 335 \\ // \\ 336 +---\\------------- //------\\----+ 337 ( \\ IPv4/IPv6 // \\ ) 338 ( \\ Network // \\ ) 339 +------\\--------//------------\\-+ 340 \\ // \\ 341 \\ // \\ 342 \\ // \\ 343 Proxy-CoA1--> | | <-- Proxy-CoA2 344 +----+ +----+ 345 |MAG1|-----{MN2} |MAG2| 346 +----+ | +----+ 347 | | | 348 MN-HoA1 --> | MN-HoA2 | <-- MN-HoA3 349 {MN1} {MN3} 351 Figure 1: Proxy Mobile IPv6 Domain 353 Once a mobile node enters a Proxy Mobile IPv6 domain and attaches to 354 an access network, the mobile access gateway on that access network, 355 after identifying the mobile node and acquiring its identifier, will 356 determine if the mobile node is authorized for network-based mobility 357 management service. 359 If the network determines that the network-based mobility management 360 service needs to be offered to that mobile node, the network will 361 ensure that the mobile node using any of the address configuration 362 mechanisms permitted by the network, will be able to obtain an 363 address from its home network prefix and move anywhere in that proxy 364 mobile IPv6 domain. From the perspective of the mobile node, the 365 entire proxy mobile IPv6 domain appears as a single link, the network 366 ensures that the mobile node believes it is always on the same link 367 where it obtained its initial address configuration, even after 368 changing its point of attachment in that network. 370 The mobile node may be operating in an IPv4-only mode, IPv6-only mode 371 or in dual IPv4/IPv6 mode. Based on what is enabled in the network 372 for that mobile node, the mobile node will be able to obtain an IPv4, 373 IPv6 or dual IPv4/IPv6 addresses and move any where in that Proxy 374 Mobile IPv6 domain. However, the specific details related to the 375 IPv4 addressing or IPv4 transport support is specified in the 376 companion document [ID-IPV4-PMIP6]. 378 +-----+ +-----+ +-----+ 379 | MN | | MAG | | LMA | 380 +-----+ +-----+ +-----+ 381 | | | 382 MN Attached | | 383 | | | 384 | MN Attached Event | 385 | (Acquire MN-Id and Profile) | 386 | | | 387 | |----- PBU ----------->| 388 | | | 389 | | Accept PBU 390 | | (Allocate MN-HNP, Setup BCE and Tunnel) 391 | | | 392 | |<--------- PBA -------| 393 | | | 394 | Accept PBA | 395 | (Setup Tunnel and Routing) | 396 | | | 397 | |==== Bi-Dir Tunnel ===| 398 | | | 399 |--- Rtr Sol --------->| | 400 | | | 401 |<------- Rtr Adv -----| | 402 | | | 403 IP Address | | 404 Configuration | | 405 | | | 407 Figure 2: Mobile Node Attachment - Signaling Call Flow 409 Figure 2 shows the signaling call flow, when the mobile node enters 410 the Proxy Mobile IPv6 domain. 412 For updating the local mobility anchor about the current location of 413 the mobile node, the mobile access gateway sends a Proxy Binding 414 Update message to the mobile node's local mobility anchor. Upon 415 accepting this Proxy Binding Update message, the local mobility 416 anchor sends a Proxy Binding Acknowledgement message including the 417 mobile node's home network prefix. It also creates the Binding Cache 418 entry and establishes a bi-directional tunnel to the mobile access 419 gateway. 421 The mobile access gateway on receiving the Proxy Binding 422 Acknowledgement message sets up a bi-directional tunnel to the local 423 mobility anchor and sets up the data path for the mobile node's 424 traffic. At this point the mobile access gateway will have all the 425 required information for emulating the mobile node's home link. It 426 sends Router Advertisement messages to the mobile node on the access 427 link advertising the mobile node's home network prefix as the hosted 428 on-link-prefix. 430 The mobile node on receiving these Router Advertisement messages on 431 the access link will attempt to configure its interface either using 432 stateful or stateless address configuration modes, based on the modes 433 that are permitted on that access link. At the end of a successful 434 address configuration procedure, the mobile node will end up with an 435 address from its home network prefix. 437 Once the address configuration is complete, the mobile node has a 438 valid address from its home network prefix at the current point of 439 attachment. The serving mobile access gateway and the local mobility 440 anchor also have proper routing states for handling the traffic sent 441 to and from the mobile node using an address from its home network 442 prefix. 444 The local mobility anchor, being the topological anchor point for the 445 mobile node's home network prefix, receives any packets that are sent 446 by any correspondent node to the mobile node. Local mobility anchor 447 forwards these received packets to the mobile access gateway through 448 the bi-directional tunnel. The mobile access gateway on other end of 449 the tunnel, after receiving the packet, removes the outer header and 450 forwards the packet on the access link to the mobile node. 452 The mobile access gateway typically acts as a default router on the 453 access link. Any packet that the mobile node sends to any 454 correspondent node will be received by the mobile access gateway and 455 will be sent to its local mobility anchor through the bi-directional 456 tunnel. The local mobility anchor on the other end of the tunnel, 457 after receiving the packet, removes the outer header and routes the 458 packet to the destination. 460 +-----+ +-----+ +-----+ +-----+ 461 | MN | |p-MAG| | LMA | |n-MAG| 462 +-----+ +-----+ +-----+ +-----+ 463 | | | | 464 | |==Bi-Dir Tunnel=| | 465 MN Detached | | | 466 | MN Detached Event | | 467 | | | | 468 | |-- PBU -------->| | 469 | | | | 470 | | Accept PBU | 471 | | (Start BCE delete timer) | 472 | | | | 473 | |<-------- PBA --| | 474 | | | | 475 MN Attached | | | 476 | | | MN Attached Event 477 | | | (Acquire MN-Id and Profile) 478 .... 479 Registration steps as in fig 2. 480 .... 481 | | |==Bi-Dir Tunnel=| 482 |--- Rtr Sol ------------------------------------->| 483 | | | | 484 |<------------------------------------ Rtr Adv ----| 485 | | | | 486 MN retains HoA/HNP 487 | | | | 489 Figure 3: Mobile Node Handoff - Signaling Call Flow 491 Figure 3 shows the signaling call flow for the mobile node's handoff 492 scenario. 494 After obtaining the initial address configuration in the Proxy Mobile 495 IPv6 domain, if the mobile node changes its point of attachment, the 496 mobile access gateway on the new access link will signal the local 497 mobility anchor for updating the binding and routing state. The 498 mobile node will continue to receive the Router Advertisements 499 containing its home network prefix, making it believe it's still on 500 the same link and can use the same address configuration on the new 501 access link. 503 4. Proxy Mobile IPv6 Protocol Security 505 The signaling messages, Proxy Binding Update and Proxy Binding 506 Acknowledgement, exchanged between the mobile access gateway and the 507 local mobility anchor MUST be protected using end-to-end security 508 association(s) offering integrity and data origin authentication. A 509 security association with the mobile node for which the signaling 510 message is issued is not required for protection of these messages. 512 The mobile access gateway and the local mobility anchor MUST 513 implement IPsec for protecting the Proxy Mobile IPv6 signaling 514 messages [RFC-4301]. IPsec is the default security mechanism for 515 securing the signaling messages. However in certain deployments of 516 this protocol, other security mechanisms MAY be applied and the 517 signaling messages must be protected using the semantics provided by 518 that respective mechanism. 520 IPsec ESP [RFC-4303] in transport mode with mandatory integrity 521 protection SHOULD be used for protecting the signaling messages. 522 Confidentiality protection of these messages is not required. 524 IKEv2 [RFC-4306] SHOULD be used to setup security associations 525 between the mobile access gateway and the local mobility anchor to 526 protect the Proxy Binding Update and Proxy Binding Acknowledgement 527 messages. The mobile access gateway and the local mobility anchor 528 can use any of the authentication mechanisms, as specified in IKEv2, 529 for mutual authentication. 531 The Mobile IPv6 specification [RFC-3775] requires the home agent to 532 prevent a mobile node from creating security associations or creating 533 binding cache entries for another mobile node's home address. In the 534 protocol described in this document, the mobile node is not involved 535 in creating security associations for protecting the signaling 536 messages or sending binding updates. Therefore, this is not a 537 concern. However, the local mobility anchor MUST allow only 538 authorized mobile access gateways to create binding cache entries on 539 behalf of the mobile nodes. The actual mechanism by which the local 540 mobility anchor verifies if a specific mobile access gateway is 541 authorized to send Proxy Binding Updates on behalf of a mobile node 542 is outside the scope of this document. One possible way this could 543 be achieved is by sending a query to the policy store, such as AAA. 545 4.1. Peer Authorization Database Entries 547 This section describes PAD entries on the mobile access gateway and 548 the local mobility anchor. The PAD entries are only example 549 configurations. Note that the PAD is a logical concept and a 550 particular mobile access gateway or a local mobility anchor 551 implementation can implement the PAD in any implementation specific 552 manner. The PAD state may also be distributed across various 553 databases in a specific implementation. 555 mobile access gateway PAD: 556 - IF remote_identity = lma_identity_1 557 Then authenticate (shared secret/certificate/EAP) 558 and authorize CHILD_SA for remote address lma_addres_1 560 local mobility anchor PAD: 561 - IF remote_identity = mag_identity_1 562 Then authenticate (shared secret/certificate/EAP) 563 and authorize CHILD_SAs for remote address mag_address_1 565 The list of authentication mechanisms in the above examples is not 566 exhaustive. There could be other credentials used for authentication 567 stored in the PAD. 569 4.2. Security Policy Database Entries 571 This section describes the security policy entries on the mobile 572 access gateway and the local mobility anchor required to protect the 573 Proxy Mobile IPv6 signaling messages. The SPD entries are only 574 example configurations. A particular mobile access gateway or a 575 local mobility anchor implementation could configure different SPD 576 entries as long as they provide the required security. 578 In the examples shown below, the identity of the mobile access 579 gateway is assumed to be mag_1, the address of the mobile access 580 gateway is assumed to be mag_address_1, and the address of the local 581 mobility anchor is assumed to be lma_address_1. 583 mobile access gateway SPD-S: 584 - IF local_address = mag_address_1 & 585 remote_address = lma_address_1 & 586 proto = MH & local_mh_type = BU & remote_mh_type = BA 587 Then use SA ESP transport mode 588 Initiate using IDi = mag_1 to address lma_address_1 590 local mobility anchor SPD-S: 591 - IF local_address = lma_address_1 & 592 remote_address = mag_address_1 & 593 proto = MH & local_mh_type = BA & remote_mh_type = BU 594 Then use SA ESP transport mode 596 5. Local Mobility Anchor Operation 598 For supporting the Proxy Mobile IPv6 protocol specified in this 599 document, the home agent function, specified in [RFC-3775] requires 600 certain functional modifications and enhancements. The home agent 601 with these modifications and enhanced capabilities for supporting 602 Proxy Mobile IPv6 protocol is referred to as the local mobility 603 anchor. 605 This section describes the operational details of the local mobility 606 anchor. 608 5.1. Extensions to Binding Cache Entry Data Structure 610 Every local mobility anchor MUST maintain a Binding Cache entry for 611 each currently registered mobile node. Binding Cache entry is a 612 conceptual data structure, described in Section 9.1 [RFC-3775]. 614 For supporting this specification, the Binding Cache Entry data 615 structure needs to be extended with the following additional fields. 617 o A flag indicating whether or not this Binding Cache entry is 618 created due to a proxy registration. This flag is enabled for 619 Binding Cache entries that are proxy registrations and is turned 620 off for all other entries that are created due to the 621 registrations directly sent by the mobile node. 623 o The identifier of the registered mobile node, MN-Identifier. This 624 identifier is obtained from the NAI Option [RFC-4283] present in 625 the received Proxy Binding Update request. 627 o The Link-local address of the mobile node on the interface 628 attached to the access link. This is obtained from the Link-local 629 Address option, present in the Proxy Binding Update request. 631 o The IPv6 home network prefix of the registered mobile node. The 632 home network prefix of the mobile node may have been statically 633 configured in the mobile node's policy profile, or, it may have 634 been dynamically allocated by the local mobility anchor. The IPv6 635 home network prefix also includes the corresponding prefix length. 637 o The interface identifier of the bi-directional tunnel established 638 between the local mobility anchor and the mobile access gateway 639 where the mobile node is currently anchored. The tunnel interface 640 identifier is acquired during the tunnel creation. 642 o The 64-bit timestamp value of the most recently accepted Proxy 643 Binding Update request sent for this mobile node. This is 644 obtained from the Timestamp option, present in the request. 646 5.2. Supported Home Network Prefix Models 648 This specification supports Per-MN-Prefix model and does not support 649 Shared-Prefix model. As per the Per-MN-Prefix model, there will be 650 an unique home network prefix assigned to each mobile node and no 651 other node shares an address from that prefix. 653 The mobile node's home network prefix is always hosted on the access 654 link where the mobile node is anchored. Conceptually, the entire 655 home network prefix follows the mobile node as it moves within the 656 Proxy Mobile IPv6 domain. The local mobility anchor is not required 657 to perform any proxy ND operations [RFC-2461] for defending the 658 mobile node's home address on the home link. However, from the 659 routing perspective, the home network prefix is topologically 660 anchored on the local mobility anchor. 662 5.3. Signaling Considerations 664 Processing Binding Registrations 666 Upon receiving a Proxy Binding Update request from a mobile access 667 gateway on behalf of a mobile node, the local mobility anchor MUST 668 process the request as defined in Section 10.3 [RFC-3775], with one 669 exception that this request is a proxy binding registration request 670 and hence the following additional considerations must be applied. 672 o The local mobility anchor MUST observe the rules described in 673 Section 9.2 [RFC-3775] when processing Mobility Headers in the 674 received Proxy Binding Update request. 676 o The local mobility anchor MUST identify the mobile node from the 677 identifier present in the NAI option [RFC-4283] of the Proxy 678 Binding Update request. If the NAI option is not present in the 679 Proxy Binding Update request, the local mobility anchor MUST 680 reject the request and send a Proxy Binding Acknowledgement 681 message with Status field set to MISSING_MN_IDENTIFIER_OPTION 682 (Missing mobile node identifier). 684 o If the local mobility anchor cannot identify the mobile node, from 685 the NAI option [RFC-4283] present in the request, it MUST reject 686 the Proxy Binding Update request and send a Proxy Binding 687 Acknowledgement message with Status field set to 133 (Not home 688 agent for this mobile node). 690 o If the local mobility anchor determines that the mobile node is 691 not authorized for network-based mobility management service, it 692 MUST reject the request and send a Proxy Binding Acknowledgement 693 message with Status field set to PROXY_REG_NOT_ENABLED (Proxy 694 Registration not enabled). 696 o The local mobility anchor MUST ignore the check, specified in 697 Section 10.3.1 [RFC-3775], related to the presence of Home Address 698 destination option in the Proxy Binding Update request. 700 o The local mobility anchor MUST authenticate the Proxy Binding 701 Update request as described in Section 4.0. It MUST use the SPI 702 in the IPSec header [RFC-4306] of the received packet for locating 703 the security association needed for authenticating the Proxy 704 Binding Update request. 706 o The local mobility anchor MUST apply the required policy checks, 707 as explained in Section 4.0, to verify the sender is a trusted 708 mobile access gateway, authorized to send proxy binding 709 registration requests on behalf of this mobile node. 711 o If the local mobility anchor determines that the requesting node 712 is not authorized to send proxy binding registration requests, it 713 MUST reject the Proxy Binding Update request and send a Proxy 714 Binding Acknowledgement message with Status field set to 715 MAG_NOT_AUTHORIZED_FOR_PROXY_REG (Not authorized to send proxy 716 registrations). 718 o If the Home Network Prefix option is not present in the Proxy 719 Binding Update request, the local mobility anchor MUST reject the 720 Proxy Binding Update request and send a Proxy Binding 721 Acknowledgement message with Status field set to 129 722 (Administratively Prohibited). 724 o The local mobility anchor MUST apply the considerations specified 725 in Section 5.4, for processing the Sequence Number field and the 726 Timestamp option, in the Proxy Binding Update request. 728 o The local mobility anchor MUST use the identifier in the NAI 729 option [RFC-4283] present in the Proxy Binding Update request for 730 performing the Binding Cache entry existence test. If the entry 731 does not exist, the local mobility anchor MUST consider this 732 request as an initial binding registration request. If the entry 733 exists, the local mobility anchor MUST consider this request as an 734 binding re-registration request. However, from the perspective of 735 the mobile access gateway that sent the request, this binding re- 736 registration request may be an initial Binding Update request 737 after the mobile node's attachment to that mobile access gateway. 739 Initial Binding Registration: 741 o If the Home Network Prefix option present in the Proxy Binding 742 Update request has the value 0::/0, the local mobility anchor MUST 743 allocate a prefix for the mobile node and send a Proxy Binding 744 Acknowledgement message including the Home Network Prefix option 745 containing the allocated prefix value. The specific details on 746 how the local mobility anchor allocates the home network prefix is 747 outside the scope of this document. The local mobility anchor 748 MUST ensure the allocated prefix is not in use by any other mobile 749 node. 751 o If the local mobility anchor is unable to allocate a home network 752 prefix for the mobile node, it MUST reject the request and send a 753 Proxy Binding Acknowledgement message with Status field set to 130 754 (Insufficient resources). 756 o If the Home Network Prefix option present in the request has a 757 specific prefix hint, the local mobility anchor before accepting 758 that request, MUST ensure the prefix is owned by the local 759 mobility anchor and further the mobile node is authorized to use 760 that prefix. If the mobile node is not authorized to use that 761 prefix, the local mobility anchor MUST reject the request and send 762 a Proxy Binding Acknowledgement message with Status field set to 763 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (Mobile node not authorized 764 to use that prefix). 766 o Upon accepting the request, the local mobility anchor MUST create 767 a Binding Cache entry for the mobile node. It must set the fields 768 in the Binding Cache entry to the accepted values for that 769 binding. If there is a Link-local Address option present in the 770 request, the address must be copied to the link-local address 771 field in the Binding Cache entry. 773 o Upon accepting the Proxy Binding Update request, the local 774 mobility anchor MUST establish a bi-directional tunnel to the 775 mobile access gateway, as described in [RFC-2473]. Considerations 776 from Section 5.5 must be applied. 778 Binding Re-Registration: 780 o If the requesting prefix in the Home Network Prefix option is a 781 non 0::/0 value and is different from what is present in the 782 currently active Binding Cache entry for that mobile node, the 783 local mobility anchor MUST reject the request and send a Proxy 784 Binding Acknowledgement message with Status field set to 129 785 (Administratively Prohibited). 787 o If there is a Link-local Address option present in the request 788 with a value other than ALL_ZERO (not set), and upon accepting the 789 binding re-registration request, the local mobility anchor MUST 790 update the link-local address field in the Binding Cache entry to 791 the address value received in the request. 793 o Upon accepting a Proxy Binding Update request for extending the 794 lifetime of a currently active binding for a mobile node, the 795 local mobility anchor MUST update the existing Binding Cache entry 796 for this mobile node. Unless there exists an established bi- 797 directional tunnel to the mobile access gateway with the same 798 transport and encapsulation mode, the local mobility anchor MUST 799 create a tunnel to the mobile access gateway, as described in 800 [RFC-2473] and also delete the existing tunnel route to the 801 previous mobile access gateway. It MUST also send a Proxy Binding 802 Acknowledgement message to the mobile access gateway with the 803 Status field set to 0 (Proxy Binding Update Accepted). 805 Binding De-Registration: 807 o If the prefix in the Home Network Prefix option is a non 0::/0 808 value and is different from what is present in the currently 809 active Binding Cache entry for that mobile node, the local 810 mobility anchor MUST reject the request and send a Proxy Binding 811 Acknowledgement message with Status field set to 129 812 (Administratively Prohibited). 814 o If the received Proxy Binding Update request with the lifetime 815 value of zero, has a Source Address in the IPv6 header, different 816 from what is present in the Proxy-CoA address field in the Binding 817 Cache entry existing for that mobile node, the local mobility 818 anchor MAY either choose to ignore the request or send a valid 819 Proxy Binding Acknowledgement message with the Status field set to 820 0 (Proxy Binding Update Accepted). However, it MUST NOT delete 821 the mobile node's Binding Cache entry or modify the routing state 822 created for that mobile node. 824 o Upon accepting the Proxy Binding Update request for a mobile node, 825 with the lifetime value of zero, the local mobility anchor MUST 826 wait for MinDelayBeforeBCEDelete amount of time, before it deletes 827 the mobile node's Binding Cache entry. Within this wait period, 828 if the local mobility anchor receives a Proxy Binding Update 829 request message for the same mobile node with the lifetime value 830 of greater than zero, and if that request is accepted, then the 831 Binding Cache entry MUST NOT be deleted, but must be updated with 832 the newly accepted registration values. The local mobility anchor 833 MUST send the Proxy Binding Acknowledgement message, immediately 834 upon accepting the request. However, within this wait period, if 835 the local mobility anchor does not receive any valid binding 836 registration request for that mobile node, then at the end of this 837 wait period, it MUST delete the mobile node's Binding Cache entry 838 and remove the routing state created for that mobile node. 840 Constructing the Proxy Binding Acknowledgement Message: 842 o The local mobility anchor when sending the Proxy Binding 843 Acknowledgement message to the mobile access gateway MUST 844 construct the message as specified below. 846 IPv6 header (src=LMAA, dst=Proxy-CoA) 847 Mobility header 848 -BA /*P flag is set*/ 849 Mobility Options 850 - Home Network Prefix Option 851 - Link-local Address Option (optional) 852 - Timestamp Option (optional) 853 - NAI Option 855 Proxy Binding Acknowledgement message format 857 o The Source Address field in the IPv6 header of the message SHOULD 858 be set to the destination address of the received Proxy Binding 859 Update request. 861 o The Destination Address field in the IPv6 header of the message 862 SHOULD be set to the source address of the received Proxy Binding 863 Update request. 865 o The Home Network Prefix option MUST be present in the Proxy 866 Binding Acknowledgement message if and only if the same option was 867 present in the corresponding Proxy Binding Update request message. 869 o If the Status field is set to a value greater than or equal to 870 128, i.e., if the binding request was rejected, then the prefix 871 value in the Home Network Prefix option MUST be set to the prefix 872 value from the received Home Network Prefix option. For all other 873 cases, the prefix value MUST be set to the allocated prefix value 874 for that mobile node. 876 o The Link-local Address option MUST be present in the Proxy Binding 877 Acknowledgement message if and only if the same option was present 878 in the corresponding Proxy Binding Update request message. 880 o If the Status field is set to a value greater than or equal to 881 128, i.e., if the binding request was rejected, then the link- 882 local address value in the Link-local Address option MUST be set 883 to the value from the received Link-local Address option. 885 o If there is an existing Binding Cache entry for the mobile node 886 with the link-local address value of ALL_ZERO (value not set), or 887 if there was no existing Binding Cache entry, then the link-local 888 address MUST be copied from the Link-local Address option in the 889 received Proxy Binding Update request. For all other cases, it 890 MUST be copied from the mobile node's Binding Cache entry. 892 o Considerations from Section 5.4 must be applied for constructing 893 the Timestamp option. 895 o The identifier in the NAI option [RFC-4283] MUST be copied from 896 the received Proxy Binding Update request. If the Status field 897 value is set to MISSING_MN_IDENTIFIER_OPTION, the NAI option MUST 898 NOT be present in the Proxy Binding Acknowledgement message. 900 o The message MUST be protected by using IPsec, using the security 901 association existing between the local mobility anchor and the 902 mobile access gateway. 904 o The Type 2 Routing header MUST NOT be present in the IPv6 header 905 of the packet. 907 5.4. Timestamp Option for Message Ordering 909 Mobile IPv6 [RFC-3775] uses the Sequence Number field in binding 910 registration messages as a way for the home agent to process the 911 binding updates in the order they were sent by a mobile node. The 912 home agent and the mobile node are required to manage this counter 913 over the lifetime of a binding. However, in Proxy Mobile IPv6, as 914 the mobile node moves from one mobile access gateway to another and 915 in the absence of context transfer mechanism, the serving mobile 916 access gateway will be unable to determine the sequence number that 917 it needs to use in the signaling messages. Hence, the sequence 918 number scheme, as specified in [RFC-3775], will be insufficient for 919 Proxy Mobile IPv6. 921 If the local mobility anchor cannot determine the sending order of 922 the received binding registration messages, it may potentially 923 process an older message sent by a mobile access gateway where the 924 mobile node was previously anchored, resulting in an incorrect 925 Binding Cache entry. 927 For solving this problem, this specification adopts two alternative 928 solutions. One is based on timestamps and the other based on 929 sequence numbers, as defined in [RFC-3775]. 931 The basic principle behind the use of timestamps in binding 932 registration messages is that the node generating the message inserts 933 the current time-of-day, and the node receiving the message checks 934 that this timestamp is greater than all previously accepted 935 timestamps. The timestamp based solution may be used, when the 936 serving mobile access gateways in a Proxy Mobile IPv6 domain do not 937 have the ability to obtain the last sequence number that was sent in 938 a binding registration message for updating a given mobile node's 939 binding. 941 As an alternative to the Timestamp based approach, the specification 942 also allows the use of Sequence Number based scheme, as per [RFC- 943 3775]. However, for this scheme to work, the serving mobile access 944 gateways in a Proxy Mobile IPv6 domain MUST have the ability to 945 obtain the last sequence number that was sent in a binding 946 registration message for updating a given mobile node's binding. The 947 sequence number MUST be maintained on a per mobile node basis and 948 MUST be synchronized between the serving mobile access gateways. 949 This may be achieved by using context transfer schemes or by 950 maintaining the sequence number in a policy store. However, the 951 specific details on how the mobile node's sequence number is 952 synchronized between different mobile access gateways is outside the 953 scope of this document. 955 Using Timestamps based approach: 957 o A local mobility anchor implementation MUST support Timestamp 958 option. If the Timestamp option is present in the received Proxy 959 Binding Update request message, then the local mobility anchor 960 MUST include a valid Timestamp option in the Proxy Binding 961 Acknowledgement message that it sends to the mobile access 962 gateway. 964 o All the mobility entities in a Proxy Mobile IPv6 domain that are 965 exchanging binding registration messages using the Timestamp 966 option must have adequately synchronized time-of-day clocks. This 967 is the essential requirement for this solution to work. If this 968 requirement is not met, the solution will not predictably work in 969 all cases. 971 o The mobility entities in a Proxy Mobile IPv6 domain SHOULD 972 synchronize their clocks to a common time source. For 973 synchronizing the clocks, the nodes may use Network Time Protocol 974 [RFC-4330]. Deployments may also adopt other approaches suitable 975 for that specific deployment. 977 o When generating the timestamp value for building the Timestamp 978 option, the mobility entities MUST ensure that the generated 979 timestamp is the elapsed time past the same reference epoch, as 980 specified in the format for the Timestamp option [Section 8.5]. 982 o If the Timestamp option is present in the received Proxy Binding 983 Update message, the local mobility anchor MUST ignore the sequence 984 number field in the message. However, it MUST copy the sequence 985 number from the received Proxy Binding Update message to the Proxy 986 Binding Acknowledgement message. 988 o Upon receipt of a Proxy Binding Update message with the Timestamp 989 option, the local mobility anchor MUST check the timestamp field 990 for validity. In order for it to be considered valid, the 991 timestamp value contained in the Timestamp option MUST be close 992 enough to the local mobility anchor's time-of-day clock and the 993 timestamp MUST be greater than all previously accepted timestamps 994 in the Proxy Binding Update messages sent for that mobile node. 996 o If the timestamp value in the received Proxy Binding Update is 997 valid (validity as specified in the above considerations), the 998 local mobility anchor MUST return the same timestamp value in the 999 Timestamp option included in the Proxy Binding Acknowledgement 1000 message that it sends to the mobile access gateway. 1002 o If the timestamp value in the received Proxy Binding Update is not 1003 valid (validity as specified in the above considerations), the 1004 local mobility anchor MUST reject the Proxy Binding Update and 1005 send a Proxy Binding Acknowledgement message with Status field set 1006 to TIMESTAMP_MISMATCH (Timestamp mismatch). The message MUST also 1007 include the Timestamp option with the value set to the current 1008 time-of-day on the local mobility anchor. 1010 Using Sequence Number based approach: 1012 o If the Timestamp option is not present in the received Proxy 1013 Binding Update request, the local mobility anchor MUST fallback to 1014 the Sequence Number based scheme. It MUST process the sequence 1015 number field as specified in [RFC-3775]. Also, it MUST NOT 1016 include the Timestamp option in the Proxy Binding Acknowledgement 1017 messages that it sends to the mobile access gateway. 1019 o An implementation MUST support Sequence Number based scheme, as 1020 per [RFC-3775]. 1022 5.5. Routing Considerations 1024 5.5.1. Bi-Directional Tunnel Management 1026 o A bi-directional tunnel is established between the local mobility 1027 anchor and the mobile access gateway with IP-in-IP encapsulation, 1028 as described in [RFC-2473]. The tunnel end points are the Proxy- 1029 CoA and LMAA. When using IPv4 transport with a specific 1030 encapsulation mode, the end points of the tunnel are the IPv4-LMAA 1031 and IPv4-Proxy-CoA, as specified in [ID-IPV4-PMIP6]. 1033 o The bi-directional tunnel is used for routing the mobile node's 1034 data traffic between the mobile access gateway and the local 1035 mobility anchor. The tunnel hides the topology and enables a 1036 mobile node to use an address from its home network prefix from 1037 any access link attached to the mobile access gateway. 1039 o The bi-directional tunnel is established after accepting the Proxy 1040 Binding Update request message. The created tunnel may be shared 1041 with other mobile nodes attached to the same mobile access gateway 1042 and with the local mobility anchor having a Binding Cache entry 1043 for those mobile nodes. Implementations MAY choose to use static 1044 tunnels instead of dynamically creating and tearing them down on a 1045 need basis. 1047 o The tunnel between the local mobility anchor and the mobile access 1048 gateway is typically a shared tunnel and can be used for routing 1049 traffic streams for different mobile nodes attached to the same 1050 mobile access gateway. 1052 o Implementations typically use a software timer for managing the 1053 tunnel lifetime and a counter for keeping a count of all the 1054 mobile nodes that are sharing the tunnel. The timer value will be 1055 set to the accepted binding life-time and will be updated after 1056 each periodic re-registration for extending the lifetime. If the 1057 tunnel is shared for multiple mobile nodes, the tunnel lifetime 1058 will be set to the highest binding lifetime that is granted to any 1059 one of those mobile nodes sharing that tunnel. 1061 5.5.2. Forwarding Considerations 1063 Intercepting Packets Sent to the Mobile Node's Home Network: 1065 o When the local mobility anchor is serving a mobile node, it MUST 1066 be able to receive packets that are sent to the mobile node's home 1067 network. In order for it to receive those packets, it MUST 1068 advertise a connected route in to the Routing Infrastructure for 1069 the mobile node's home network prefix or for an aggregated prefix 1070 with a larger scope. This essentially enables IPv6 routers in 1071 that network to detect the local mobility anchor as the last-hop 1072 router for that prefix. 1074 Forwarding Packets to the Mobile Node: 1076 o On receiving a packet from a correspondent node with the 1077 destination address matching a mobile node's home network prefix, 1078 the local mobility anchor MUST forward the packet through the bi- 1079 directional tunnel setup for that mobile node. The format of the 1080 tunneled packet is shown below. However, when using IPv4 1081 transport, the format of the packet is as described in [ID-IPV4- 1082 PMIP6]. 1084 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 1085 IPv6 header (src= CN, dst= MN-HOA ) /* Packet Header */ 1086 Upper layer protocols /* Packet Content*/ 1088 Figure 7: Tunneled Packets from LMA to MAG 1090 Forwarding Packets Sent by the Mobile Node: 1092 o All the reverse tunneled packets that the local mobility anchor 1093 receives from the mobile access gateway, after removing the tunnel 1094 header MUST be routed to the destination specified in the inner 1095 packet header. These routed packets will have the source address 1096 field set to the mobile node's home address. 1098 5.6. Local Mobility Anchor Address Discovery 1100 Dynamic Home Agent Address Discovery, as explained in Section 10.5 1101 [RFC-3775], allows a mobile node to discover all the home agents on 1102 its home link by sending an ICMP Home Agent Address Discovery Request 1103 message to the Mobile IPv6 Home-Agents anycast address, derived from 1104 its home network prefix. 1106 The DHAAD message in the current form cannot be used in Proxy Mobile 1107 IPv6 for discovering the address of the mobile node's local mobility 1108 anchor. In Proxy Mobile IPv6, the local mobility anchor will not be 1109 able to receive any messages sent to the Mobile IPv6 Home-Agents 1110 anycast address corresponding to the mobile node's home network 1111 prefix, as the prefix is not hosted on any of its interfaces. 1112 Further, the mobile access gateway will not predictably be able to 1113 locate the serving local mobility anchor that has the mobile node's 1114 binding cache entry. Hence, this specification does not support 1115 Dynamic Home Agent Address Discovery protocol. 1117 In Proxy Mobile IPv6, the address of the local mobility anchor 1118 configured to serve a mobile node can be discovered by the mobility 1119 entities in other ways. This may be a configured entry in the mobile 1120 node's policy profile, or it may be obtained through mechanisms 1121 outside the scope of this document. 1123 5.7. Mobile Prefix Discovery Considerations 1125 The ICMP Mobile Prefix Advertisement message, described in Section 1126 6.8 and Section 11.4.3 of [RFC-3775], allows a home agent to send a 1127 Mobile Prefix Advertisement to the mobile node. 1129 In Proxy Mobile IPv6, the mobile node's home network prefix is hosted 1130 on the access link connected to the mobile access gateway, but it is 1131 topologically anchored on the local mobility anchor. Since there is 1132 no physical home-link for the mobile node's home network prefix on 1133 the local mobility anchor and as the mobile node is always on the 1134 link where the prefix is hosted, any prefix change messages can just 1135 be advertised by the mobile access gateway on the access link and 1136 thus there is no applicability of this message for Proxy Mobile IPv6. 1137 Hence, this specification does not support Mobile Prefix Discovery. 1139 5.8. Route Optimizations Considerations 1141 The Route Optimization in Mobile IPv6, as defined in [RFC-3775], 1142 enables a mobile node to communicate with a correspondent node 1143 directly using its care-of address and further the Return Routability 1144 procedure enables the correspondent node to have reasonable trust 1145 that the mobile node is reachable at both its home address and 1146 care-of address. 1148 In Proxy Mobile IPv6, the mobile node is not involved in any mobility 1149 related signaling. The mobile node uses only its home address for 1150 all its communication and the Care-of address (Proxy-CoA) is not 1151 visible to the mobile node. Hence, the Return Routability procedure 1152 as defined in Mobile IPv6 cannot be used in Proxy Mobile IPv6. 1154 6. Mobile Access Gateway Operation 1156 The Proxy Mobile IPv6 protocol described in this document introduces 1157 a new functional entity, the Mobile Access Gateway (MAG). The mobile 1158 access gateway is the entity that is responsible for detecting the 1159 mobile node's movements on its access link and sending the binding 1160 registration requests to the local mobility anchor. In essence, the 1161 mobile access gateway performs mobility management on behalf of a 1162 mobile node. 1164 The mobile access gateway is a function that typically runs on an 1165 access router. However, implementations MAY choose to split this 1166 function and run it across multiple systems. The specifics on how 1167 that is achieved or the signaling interactions between those 1168 functional entities are beyond the scope of this document. 1170 The mobile access gateway has the following key functional roles: 1172 o It is responsible for detecting the mobile node's movements on the 1173 access link and for initiating the mobility signaling with the 1174 mobile node's local mobility anchor. 1176 o Emulation of the mobile node's home link on the access link by 1177 sending Router Advertisements with the mobile node's home network 1178 prefix information. 1180 o Responsible for setting up the data path for enabling the mobile 1181 node to configure an address from its home network prefix and use 1182 it from its access link. 1184 6.1. Extensions to Binding Update List Entry Data Structure 1186 Every mobile access gateway MUST maintain a Binding Update List. 1187 Each entry in the Binding Update List represents a mobile node's 1188 mobility binding with its local mobility anchor. The Binding Update 1189 List is a conceptual data structure, described in Section 11.1 [RFC- 1190 3775]. 1192 For supporting this specification, the conceptual Binding Update List 1193 entry data structure needs be extended with the following additional 1194 fields. 1196 o The Identifier of the attached mobile node, MN-Identifier. This 1197 identifier is acquired during the mobile node's attachment to the 1198 access link or through mechanisms outside the scope of this 1199 document. 1201 o The Link-layer address of the mobile node. This address can be 1202 acquired from the received Router Solicitation messages from the 1203 mobile node or during the mobile node's attachment to the access 1204 network. 1206 o The IPv6 home network prefix of the attached mobile node. The 1207 home network prefix of the mobile node is acquired from the mobile 1208 node's local mobility anchor through the received Proxy Binding 1209 Acknowledgement messages. The IPv6 home network prefix also 1210 includes the corresponding prefix length. 1212 o The Link-local address of the mobile node on the interface 1213 attached to the access link. 1215 o The IPv6 address of the local mobility anchor serving the attached 1216 mobile node. This address is acquired from the mobile node's 1217 policy profile. 1219 o The interface identifier of the access link where the mobile node 1220 is currently attached. The interface identifier is acquired 1221 during the mobile node's attachment to the access link. 1223 o The interface identifier of the bi-directional tunnel between the 1224 mobile node's local mobility anchor and the mobile access gateway. 1225 The tunnel interface identifier is acquired during the tunnel 1226 creation. 1228 6.2. Mobile Node's Policy Profile 1230 A mobile node's policy profile contains the essential operational 1231 parameters that are required by the network entities for managing the 1232 mobile node's mobility service. These policy profiles are stored in 1233 a local or a remote policy store. The mobile access gateway and the 1234 local mobility anchor MUST be able to obtain a mobile node's policy 1235 profile. The policy profile may also be handed over to a serving 1236 mobile access gateway as part of a context transfer procedure during 1237 a handoff. The exact details on how this achieved is outside the 1238 scope of this document. However, this specification requires that a 1239 mobile access gateway serving a mobile node MUST have access to its 1240 policy profile. 1242 The following are the mandatory fields of the policy profile: 1244 o The mobile node's identifier (MN-Identifier) 1245 o The IPv6 address of the local mobility anchor (LMAA) 1247 o Supported address configuration procedures on the link (Stateful, 1248 Stateless or both) 1250 The following are the optional fields of the policy profile: 1252 o The mobile node's IPv6 home network prefix (MN-HNP) 1254 6.3. Supported Access Link Types 1256 This specification supports only point-to-point access link types and 1257 thus it assumes that the mobile node and the mobile access gateway 1258 are the only two nodes on the access link. The link is assumed to 1259 have multicast capability. This protocol may also be used on other 1260 link types, as long as the link is configured in such a way that it 1261 guarantees a point-to-point delivery between the mobile node and the 1262 mobile access gateway for all the protocol traffic. 1264 6.4. Supported Address Configuration Models 1266 A mobile node in the Proxy Mobile IPv6 domain can configure one or 1267 more IPv6 addresses on its interface using Stateless or Stateful 1268 address autoconfiguration procedures. The Router Advertisement 1269 messages sent on the access link specify the address configuration 1270 methods permitted on that access link for that mobile node. However, 1271 the advertised flags with respect to the address configuration will 1272 be consistent for a mobile node, on any of the access links in that 1273 Proxy Mobile IPv6 domain. Typically, these configuration settings 1274 will be based on the domain wide policy or based on a policy specific 1275 to each mobile node. 1277 When stateless address autoconfiguration is supported on the link, 1278 the mobile node can generate one or more IPv6 addresses by combining 1279 the network prefix advertised on the access link with an interface 1280 identifier, using the techniques described in Stateless 1281 Autoconfiguration specification [RFC-2462] or as per Privacy 1282 extension specification [RFC-3041]. 1284 When stateful address autoconfiguration is supported on the link, the 1285 mobile node can obtain the address configuration from the DHCPv6 1286 server using DHCPv6 client protocol, as specified in DHCPv6 1287 specification [RFC-3315]. 1289 Additionally, other address configuration mechanisms specific to the 1290 access link between the mobile node and the mobile access gateway may 1291 also be used for pushing the address configuration to the mobile 1292 node. 1294 6.5. Access Authentication & Mobile Node Identification 1296 When a mobile node attaches to an access link connected to the mobile 1297 access gateway, the deployed access security protocols on that link 1298 SHOULD ensure that the network-based mobility management service is 1299 offered only after authenticating and authorizing the mobile node for 1300 that service. The exact specifics on how this is achieved or the 1301 interactions between the mobile access gateway and the access 1302 security service is outside the scope of this document. This 1303 specification goes with the stated assumption of having an 1304 established trust between the mobile node and mobile access gateway, 1305 before the protocol operation begins. 1307 6.6. Acquiring Mobile Node's Identifier 1309 All the network entities in a Proxy Mobile IPv6 domain MUST be able 1310 to identify a mobile node, using its MN-Identifier. This identifier 1311 MUST be stable across the Proxy Mobile IPv6 domain and the entities 1312 must be able to use this identifier in the signaling messages. 1313 Typically, this identifier is obtained as part of the access 1314 authentication or through other means as specified below. 1316 o The identifier of the mobile node that the mobile access gateway 1317 obtains as part of the access authentication or from the notified 1318 network attachment event, can be a temporary identifier and this 1319 identifier may also change at each re-authentication. However, 1320 the mobile access gateway MUST be able to authenticate the mobile 1321 node based on this identifier and MUST be able to obtain the MN- 1322 Identifier from the policy store, such as from the RADIUS 1323 attribute, Chargeable-User-Identifier. 1325 o The MN-Identifier that the policy store delivers to the mobile 1326 access gateway may not be the true identifier of the mobile node. 1327 However, the mobility access gateway MUST be able to use this 1328 identifier in the signaling messages exchanged with the local 1329 mobility anchor. 1331 o The mobile access gateway MUST be able identify the mobile node by 1332 its MN-Identifier and it MUST be able to associate this identity 1333 to the sender of any IPv4 or IPv6 packets on the access link. 1335 6.7. Home Network Emulation 1337 One of the key functions of a mobile access gateway is to emulate the 1338 mobile node's home network on the access link. It must ensure, the 1339 mobile node believes it is still connected to its home link or on the 1340 link where it obtained its initial address configuration after it 1341 moved into that Proxy Mobile IPv6 domain. 1343 For emulating the mobile node's home link on the access link, the 1344 mobile access gateway must be able to send Router Advertisements 1345 advertising the mobile node's home network prefix and other address 1346 configuration parameters consistent with its home link properties. 1348 Typically, the mobile access gateway learns the mobile node's home 1349 network prefix information from the received Proxy Binding 1350 Acknowledgement message or it may be obtained from the mobile node's 1351 policy profile. However, the mobile access gateway SHOULD send the 1352 Router Advertisements advertising the mobile node's home network 1353 prefix only after successfully completing the binding registration 1354 with the mobile node's local mobility anchor. 1356 When advertising the home network prefix in the Router Advertisement 1357 messages, the mobile access gateway MAY set the prefix lifetime value 1358 for the advertised prefix to any chosen value at its own discretion. 1359 An implementation MAY choose to tie the prefix lifetime to the mobile 1360 node's binding lifetime. The prefix lifetime can also be an optional 1361 configuration parameter in the mobile node's policy profile. 1363 6.8. Link-Local and Global Address Uniqueness 1365 A mobile node in the Proxy Mobile IPv6 domain, as it moves from one 1366 mobile access gateway to the other, will continue to detect its home 1367 network and thus making it believe it is still on the same link. 1368 Every time the mobile node attaches to a new link, the event related 1369 to the interface state change will trigger the mobile node to perform 1370 DAD operation on the link-local and global addresses. However, if 1371 the mobile node is DNAv6 enabled, as specified in [ID-DNAV6], it may 1372 not detect the link change due to DNAv6 optimizations and may not 1373 trigger the duplicate address detection (DAD) procedure for 1374 establishing the link-local address uniqueness on that new link. 1375 Further, if the mobile node uses an interface identifier that is not 1376 based on EUI-64 identifier, such as specified in IPv6 Stateless 1377 Autoconfiguration specification [RFC-2462], there is a very low 1378 possibility of a link-local address collision between the two 1379 neighbors on that access link. 1381 For solving this problem, this specification allows the mobile access 1382 gateway to upload the mobile node's link-local address to the local 1383 mobility anchor using the Link-local Address option, exchanged in the 1384 binding registration messages. The mobile access gateway can learn 1385 the mobile node's link-local address, by snooping the DAD messages 1386 sent by the mobile node for establishing the link-local address 1387 uniqueness on the access link. Subsequently, at each handoff, the 1388 mobile access gateway can obtain this address from the local mobility 1389 anchor to ensure link-local address uniqueness and may change its own 1390 link-local address, if it detects a collision. 1392 Alternatively, one of the workarounds for this issue is to set the 1393 DNAv6 configuration parameter, DNASameLinkDADFlag to TRUE and that 1394 will force the mobile node to redo DAD operation every time the 1395 interface detects a handover, even when DNAv6 does not detect a link 1396 change. 1398 However, this issue will not impact point-to-point links based on a 1399 PPP session. Each time the mobile node moves and attaches to a new 1400 mobile access gateway, either the PPP session [RFC-1661] is 1401 reestablished or the PPP session may be moved as part of context 1402 transfer procedures between the old and the new mobile access 1403 gateway. 1405 When the mobile node tries to establish a PPP session with the mobile 1406 access gateway, the PPP goes through the Network layer Protocol phase 1407 and the IPv6 Control Protocol, IPV6CP [RFC-2472] gets triggered. 1408 Both the PPP peers negotiate a unique identifier using Interface- 1409 Identifier option in IPV6CP and the negotiated identifier is used for 1410 generating a unique link-local address on that link. Now, if the 1411 mobile node moves to a new mobile access gateway, the PPP session 1412 gets torn down with the old mobile access gateway and a new PPP 1413 session gets established with the new mobile access gateway, and the 1414 mobile node obtains a new link-local address. So, even if the mobile 1415 node is DNAv6 capable, the mobile node always configures a new link- 1416 local address when ever it moves to a new link. 1418 If the PPP session state is moved to the new mobile access gateway as 1419 part of context transfer procedures that are in place, there will not 1420 be any change to the interface identifiers of the two nodes on that 1421 point-to-point change. The whole link is moved to the new mobile 1422 access gateway and there will not be any need for establishing link- 1423 local address uniqueness on that link. 1425 The issue of address collision is not relevant to the mobile node's 1426 global address. Since there is an unique home network prefix 1427 assigned for each mobile node, the uniqueness for the mobile node's 1428 global address is assured on the access link. 1430 6.9. Signaling Considerations 1432 6.9.1. Binding Registrations 1434 Mobile Node Attachment and Initial Binding Registration: 1436 o After detecting a new mobile node on its access link, the mobile 1437 access gateway must identify the mobile node and acquire its MN- 1438 Identifier. If it determines that the network-based mobility 1439 management service needs to be offered to the mobile node, it MUST 1440 send a Proxy Binding Update message to the local mobility anchor. 1442 o The Proxy Binding Update message MUST have the NAI option [RFC- 1443 4283], identifying the mobile node, the Home Network Prefix 1444 option, either the Timestamp option or a valid sequence number and 1445 optionally the Link-local Address option. When Timestamp option 1446 is added to the message, the mobile access gateway MAY set the 1447 Sequence Number field to a value of a monotonically increasing 1448 counter and the local mobility anchor will ignore this field, but 1449 will return the same value in the Proxy Binding Acknowledgement 1450 message. This will be useful for matching the reply to the 1451 request message. 1453 o The Home Address option MUST not be present in the Destination 1454 Option extension header of the Proxy Binding Update message. 1456 o If the mobile access gateway learns the mobile node's home network 1457 prefix either from its policy store or from other means, the 1458 mobile access gateway MAY choose to specify the same in the Home 1459 Network Prefix option for requesting the local mobility anchor to 1460 allocate that prefix. If the specified value is 0::/0, then the 1461 local mobility anchor will consider this as a request for prefix 1462 allocation. 1464 Receiving Binding Registration Reply: 1466 o The mobile access gateway MUST observe the rules described in 1467 Section 9.2 [RFC-3775] when processing Mobility Headers in the 1468 received Proxy Binding Acknowledgement message. 1470 o The message MUST be authenticated as described in Section 4.0. 1471 The SPI in the IPSec header [RFC-4306] of the received packet must 1472 be used for locating the security association needed for 1473 authenticating the message. 1475 o The mobile access gateway MUST apply the considerations specified 1476 in Section 5.4 for processing the Sequence Number field and the 1477 Timestamp option, in the message. 1479 o The mobile access gateway MUST ignore any checks, specified in 1480 [RFC-3775] related to the presence of Type 2 Routing header in the 1481 Proxy Binding Acknowledgement message. 1483 o If the Timestamp option is present in the received Proxy Binding 1484 Acknowledgement message and with the Status field value set to any 1485 value other than TIMESTAMP_MISMATCH (Invalid Timestamp), the 1486 mobile access gateway MAY use the timestamp value for matching the 1487 response to the request message that it sent recently. For all 1488 other cases, it MAY use the sequence number in combination with 1489 the identifier present in the NAI option for matching the response 1490 to the request. 1492 o If the received Proxy Binding Acknowledgement message has the 1493 Status field value set to PROXY_REG_NOT_ENABLED (Proxy 1494 registration not enabled for the mobile node), the mobile access 1495 gateway SHOULD not send binding registration requests again for 1496 that mobile node. It must also deny the mobility service to that 1497 mobile node. 1499 o If the received Proxy Binding Acknowledgement message has the 1500 Status field value set to TIMESTAMP_MISMATCH (Invalid Timestamp), 1501 the mobile access gateway SHOULD try to register again only after 1502 it has synchronized its clock to a common time source that is used 1503 by all the mobility entities in that domain for their clock 1504 synchronization. The mobile access gateway SHOULD NOT synchronize 1505 its clock to the local mobility anchor's system clock, based on 1506 the timestamp present in the received message. 1508 o If the received Proxy Binding Acknowledgement message has the 1509 Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX 1510 (Not authorized for that prefix), the mobile access gateway SHOULD 1511 try to request for that prefix in the binding registration 1512 request, only after it learned the validity of that prefix. 1514 o If the received Proxy Binding Acknowledgement message has the 1515 Status field value set to any value greater than or equal to 128 1516 (i.e., if the binding is rejected), the mobile access gateway MUST 1517 NOT advertise the mobile node's home network prefix in the Router 1518 Advertisements sent on that access link and there by denying 1519 mobility service to the mobile node. 1521 o If the received Proxy Binding Acknowledgement message has the 1522 Status field value set to 0 (Proxy Binding Update accepted) and if 1523 there is no existing Binding Update List entry for that mobile 1524 node, the mobile access gateway MUST create a Binding Update List 1525 entry and must setup the routing state, as explained in section 1526 6.10. But, if there is an existing Binding Update List entry for 1527 that mobile node, the entry MUST be updated reflecting the 1528 accepted binding registration. 1530 o If the received Proxy Binding Acknowledgement message has the 1531 address in the Link-local Address option set to a value that 1532 matches its own link-local address on that access interface where 1533 the mobile node is anchored, the mobile access gateway MUST change 1534 its link-local address on that interface. 1536 Extending Binding Lifetime: 1538 o For extending the lifetime of a currently registered mobile node 1539 (i.e., if there exists a Binding Update List entry for that mobile 1540 node), the mobile access gateway MUST send a Proxy Binding Update 1541 message to the local mobility anchor. The prefix value in the 1542 Home Network Prefix option present in the request SHOULD be set to 1543 the currently registered home network prefix and the value in the 1544 Link-local Address option may be set to ALL_ZERO or to the link- 1545 local address of the mobile node. 1547 Mobile Node Detachment and Binding De-Registration: 1549 o At any point, if the mobile access gateway detects that the mobile 1550 node has moved away from its access link, it MUST send a Proxy 1551 Binding Update message to the local mobility anchor with the 1552 lifetime value set to zero. 1554 o Either upon receipt of a Proxy Binding Acknowledgement message 1555 from the local mobility anchor or after a certain timeout waiting 1556 for the reply, the mobile access gateway MUST remove the binding 1557 entry for that mobile node from its Binding Update List and 1558 withdraw the mobile node's home network prefix as the hosted on- 1559 link prefix on that access link. 1561 Constructing the Proxy Binding Update Message: 1563 o The mobile access gateway when sending the Proxy Binding Update 1564 request to the local mobility anchor MUST construct the message as 1565 specified below. 1567 IPv6 header (src=Proxy-CoA, dst=LMAA) 1568 Mobility header 1569 -BU /*P & A flags are set*/ 1570 Mobility Options 1571 - Home Network Prefix option 1572 - Link-local Address option (Optional) 1573 - Timestamp Option (optional) 1574 - NAI Option 1576 Proxy Binding Update message format 1578 o The Source Address field in the IPv6 header of the message SHOULD 1579 be set to the address of the mobile access gateway. 1581 o The Destination Address field in the IPv6 header of the message 1582 SHOULD be set to the local mobility anchor address. 1584 o The Home Network Prefix option MUST be present. The prefix value 1585 may be set 0::/0 or to a specific prefix value. 1587 o The Link-local Address option MAY be present. The value may be 1588 set to ALL_ZERO or the mobile node's link-local address. 1590 o Considerations from Section 5.4 must be applied for constructing 1591 the Timestamp option. 1593 o The NAI option [RFC-4283] MUST be present, the identifier field in 1594 the option MUST be set to mobile node's identifier, MN-Identifier. 1596 o The message MUST be protected by using IPsec, using the security 1597 association existing between the local mobility anchor and the 1598 mobile access gateway. 1600 6.9.2. Router Solicitation Messages 1602 The mobile node sends a Router Solicitation message on the access 1603 link when ever the link-layer detects a media change. The Source 1604 Address in the IPv6 header of the Router Solicitation message may 1605 either be the link-local address of the mobile node or an unspecified 1606 address (::). 1608 o The mobile access gateway on receiving the Router Solicitation 1609 message SHOULD send a Router Advertisement containing the mobile 1610 node's home network prefix as the on-link prefix. However, before 1611 sending the Router Advertisement message containing the mobile 1612 node's home network prefix, it SHOULD complete the binding 1613 registration process with the mobile node's local mobility anchor. 1615 o If the local mobility anchor rejects the binding registration 1616 request, or, if the mobile access gateway failed to complete the 1617 binding registration process for what ever reasons, the mobile 1618 access gateway MUST NOT advertise the mobile node's home network 1619 prefix in the Router Advertisement messages that it sends on the 1620 access link. However, it MAY choose to advertise a local visitor 1621 network prefix to enable the mobile node for simple IPv6 access. 1623 6.9.3. Retransmissions and Rate Limiting 1625 The mobile access gateway is responsible for retransmissions and rate 1626 limiting the binding registration requests that it sends for updating 1627 a mobile node's binding. Implementations MUST follow the below 1628 guidelines. 1630 o When the mobile access gateway sends a Proxy Binding Update 1631 request, it should use the constant, INITIAL_BINDINGACK_TIMEOUT 1632 [RFC-3775], for configuring the retransmission timer. 1634 o If the mobile access gateway fails to receive a valid matching 1635 response within the retransmission interval, it SHOULD retransmit 1636 the message until a response is received. 1638 o As specified in Section 11.8 [RFC-3775], the mobile access gateway 1639 MUST use an exponential back-off process in which the timeout 1640 period is doubled upon each retransmission, until either the node 1641 receives a response or the timeout period reaches the value 1642 MAX_BINDACK_TIMEOUT [RFC-3775]. The mobile access gateway MAY 1643 continue to send these messages at this slower rate indefinitely. 1645 o If Timestamp based scheme is in use, the retransmitted Proxy 1646 Binding Update messages MUST use the latest timestamp. If 1647 Sequence number scheme is in use, the retransmitted Proxy Binding 1648 Update messages MUST use a Sequence Number value greater than that 1649 used for the previous transmission of this Proxy Binding Update 1650 message, just as specified in [RFC-3775]. 1652 6.10. Routing Considerations 1654 This section describes how the mobile access gateway handles the 1655 traffic to/from the mobile node that is attached to one of its access 1656 interface. 1658 Proxy-CoA LMAA 1659 | | 1660 +--+ +---+ +---+ +--+ 1661 |MN|----------|MAG|======================|LMA|----------|CN| 1662 +--+ +---+ +---+ +--+ 1663 IPv6 Tunnel 1665 6.10.1. Transport Network 1667 The transport network between the local mobility anchor and the 1668 mobile access gateway can be either an IPv6 or IPv4 network. 1669 However, this specification only deals with the IPv6 transport and 1670 the companion document [ID-IPV4-PMIP6] specifies the required 1671 extensions for negotiating IPv4 transport and the corresponding 1672 encapsulation mode for supporting this protocol operation. 1674 6.10.2. Tunneling & Encapsulation Modes 1676 The IPv6 address that a mobile node uses from its home network prefix 1677 is topologically anchored at the local mobility anchor. For a mobile 1678 node to use this address from an access network attached to a mobile 1679 access gateway, proper tunneling techniques have to be in place. 1680 Tunneling hides the network topology and allows the mobile node's 1681 IPv6 datagrams to be encapsulated as a payload of another IPv6 packet 1682 and to be routed between the local mobility anchor and the mobile 1683 access gateway. The Mobile IPv6 base specification [RFC-3775] 1684 defines the use of IPv6-over-IPv6 tunneling, between the home agent 1685 and the mobile node and this specification extends the use of the 1686 same tunneling mechanism between the local mobility anchor and the 1687 mobile access gateway. 1689 On most operating systems, tunnels are implemented as a virtual 1690 point-to-point interface. The source and the destination address of 1691 the two end points of this virtual interface along with the 1692 encapsulation mode are specified for this virtual interface. Any 1693 packet that is routed over this interface gets encapsulated with the 1694 outer header and the addresses as specified for that point to point 1695 tunnel interface. For creating a point to point tunnel to any local 1696 mobility anchor, the mobile access gateway may implement a tunnel 1697 interface with the source address field set to its Proxy-CoA address 1698 and the destination address field set to the LMA address. 1700 The following are the supported packet encapsulation modes that can 1701 be used by the mobile access gateway and the local mobility anchor 1702 for routing mobile node's IPv6 datagrams. 1704 o IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet [RFC- 1705 2473]. 1707 o IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet. The 1708 details on how this mode is negotiated is specified in [ID-IPV4- 1709 PMIP6]. 1711 o IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP 1712 packet. This mode is specified in [ID-IPV4-PMIP6]. 1714 6.10.3. Routing State 1716 The following section explains the routing state for a mobile node on 1717 the mobile access gateway. This routing state reflects only one 1718 specific way of implementation and one MAY choose to implement it in 1719 other ways. The policy based route defined below acts as a traffic 1720 selection rule for routing a mobile node's traffic through a specific 1721 tunnel created between the mobile access gateway and that mobile 1722 node's local mobility anchor and with the specific encapsulation 1723 mode, as negotiated. 1725 The below example identifies the routing state for two visiting 1726 mobile nodes, MN1 and MN2 with their respective local mobility 1727 anchors LMA1 and LMA2. 1729 For all traffic from the mobile node, identified by the mobile node's 1730 MAC address, ingress interface or source prefix (MN-HNP) to 1731 _ANY_DESTINATION_ route via interface tunnel0, next-hop LMAA. 1733 +==================================================================+ 1734 | Packet Source | Destination Address | Destination Interface | 1735 +==================================================================+ 1736 | MAC_Address_MN1, | _ANY_DESTINATION_ | Tunnel0 | 1737 | (IPv6 Prefix or |----------------------------------------------| 1738 | Input Interface) | Locally Connected | Tunnel0 | 1739 +------------------------------------------------------------------+ 1740 | MAC_Address_MN2, | _ANY_DESTINATION_ | Tunnel1 | 1741 + (IPv6 Prefix or -----------------------------------------------| 1742 | Input Interface | Locally Connected | direct | 1743 +------------------------------------------------------------------+ 1745 Example - Policy based Route Table 1747 +==================================================================+ 1748 | Interface | Source Address | Destination Address | Encapsulation | 1749 +==================================================================+ 1750 | Tunnel0 | Proxy-CoA | LMAA1 | IPv6-in-IPv6 | 1751 +------------------------------------------------------------------+ 1752 | Tunnel1 |IPv4-Proxy-CoA | IPv4-LMA2 | IPv6-in-IPv4 | 1753 +------------------------------------------------------------------+ 1755 Example - Tunnel Interface Table 1757 6.10.4. Local Routing 1759 If there is data traffic between a visiting mobile node and a 1760 correspondent node that is locally attached to an access link 1761 connected to the mobile access gateway, the mobile access gateway MAY 1762 optimize on the delivery efforts by locally routing the packets and 1763 by not reverse tunneling them to the mobile node's local mobility 1764 anchor. However, this has an implication on the mobile node's 1765 accounting and policy enforcement as the local mobility anchor is not 1766 in the path for that traffic and it will not be able to apply any 1767 traffic policies or do any accounting for those flows. 1769 This decision of path optimization SHOULD be based on the policy 1770 configured on the mobile access gateway, but enforced by the mobile 1771 node's local mobility anchor. The specific details on how this is 1772 achieved are beyond of the scope of this document. 1774 6.10.5. Tunnel Management 1776 All the considerations mentioned in Section 5.5.1 for the tunnel 1777 management on the local mobility anchor apply for the mobile access 1778 gateway as well. 1780 6.10.6. Forwarding Rules 1782 Forwarding Packets sent to the Mobile Node's Home Network: 1784 o On receiving a packet from the bi-directional tunnel established 1785 with the mobile node's local mobility anchor, the mobile access 1786 gateway MUST use the destination address of the inner packet for 1787 forwarding it on the interface where the destination network 1788 prefix is hosted. The mobile access gateway MUST remove the outer 1789 header before forwarding the packet. If the mobile access gateway 1790 cannot find the connected interface for that destination address, 1791 it MUST silently drop the packet. For reporting an error in such 1792 a scenario, in the form of ICMP control message, the 1793 considerations from Generic Packet Tunneling specification [RFC- 1794 2473] must be applied. 1796 o On receiving a packet from a correspondent node that is locally 1797 connected and which is destined to a mobile node that is on 1798 another locally connected access link, the mobile access gateway 1799 MUST check the configuration variable, EnableMAGLocalRouting, to 1800 ensure the mobile access gateway is allowed to route the packet 1801 directly to the mobile node. If the mobile access gateway is not 1802 allowed to route the packet directly, it MUST route the packet 1803 through the bi-directional tunnel established between itself and 1804 the mobile node's local mobility anchor. Otherwise, it can route 1805 the packet directly to the mobile node. 1807 Forwarding Packets Sent by the Mobile Node: 1809 o On receiving a packet from a mobile node connected to its access 1810 link, the mobile access gateway MUST ensure that there is an 1811 established binding for that mobile node with its local mobility 1812 anchor before forwarding the packet directly to the destination or 1813 before tunneling the packet to the mobile node's local mobility 1814 anchor. 1816 o On receiving a packet from a mobile node connected to its access 1817 link, to a destination that is locally connected, the mobile 1818 access gateway MUST check the configuration variable, 1819 EnableMAGLocalRouting, to ensure the mobile access gateway is 1820 allowed to route the packet directly to the destination. If the 1821 mobile access gateway is not allowed to route the packet directly, 1822 it MUST route the packet through the bi-directional tunnel 1823 established between itself and the mobile node's local mobility 1824 anchor. Otherwise, it can route the packet directly to the 1825 destination. 1827 o On receiving a packet from the mobile node connected to its access 1828 link, to a destination that is not directly connected, the packet 1829 MUST be forwarded to the local mobility anchor through the bi- 1830 directional tunnel established between itself and the mobile 1831 node's local mobility anchor. However, the packets that are sent 1832 with the link-local source address MUST NOT be forwarded. The 1833 format of the tunneled packet is shown below. However, when using 1834 IPv4 transport, the format of the tunneled packet is as described 1835 in [ID-IPV4-PMIP6]. 1837 IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */ 1838 IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */ 1839 Upper layer protocols /* Packet Content*/ 1840 Figure 12: Tunneled Packets from MAG to LMA 1842 6.11. Supporting DHCPv6 based Address Configuration on the Access Link 1844 This non-normative section explains how Stateful Address 1845 Configuration using DHCPv6 can be enabled on the access link attached 1846 to a mobile access gateway and how a mobile node attached to that 1847 link can obtain an address from its home network prefix using DHCPv6. 1849 o The DHCPv6 relay agent [RFC-3315] service needs to be enabled on 1850 each of the access links in the Proxy Mobile IPv6 domain. 1851 Further, as specified in Section 20 [RFC-3315], the relay agent 1852 should be configured to use a list of destination addresses, which 1853 MAY include unicast addresses, the All_DHCP_Servers multicast 1854 address, or other addresses selected by the network administrator. 1856 o The DHCPv6 server in the Proxy Mobile IPv6 domain can be 1857 configured with a list of address pools (P1, P2, ..., Pn). Each 1858 one of these prefix pools corresponds to a home network prefix 1859 that a local mobility anchor allocates to a mobile node in that 1860 domain. However, the DHCPv6 server will not know the relation 1861 between a given address pool and a mobile node to which the 1862 corresponding prefix is allocated. It just views these pools as 1863 prefixes hosted on different links in that domain. 1865 o When a mobile node sends a DHCPv6 request message, the DHCP relay 1866 agent function on the access link will set the link-address field 1867 in the DHCP message to the mobile node's home network prefix, so 1868 as to provide a prefix hint to the DHCP Server for the address 1869 pool selection. The DHCP server on receiving the request from the 1870 mobile node, will allocate an address from the prefix pool present 1871 in the link-address field of the request. 1873 o Once the mobile node obtains an address and moves to a different 1874 link, the DHCP relay agent on the new link will set the prefix 1875 hint in the DHCP messages to the mobile node's home network 1876 prefix. The DHCP server will identify the client from the Client 1877 Identifier option present in the request and will allocate the 1878 same address as before. 1880 o The DHCP based address configuration is not recommended for 1881 deployments where the local mobility anchor and the mobile access 1882 gateways are located in different administrative domains. For 1883 this configuration to work, all the mobile access gateways in the 1884 Proxy Mobile IPv6 domain should be able to ensure that the DHCP 1885 requests from a given mobile node anchored on any of the access 1886 links in that domain, will always be handled by the same DHCP 1887 server. 1889 o The DHCP server should be configured to offer low address lease 1890 times. A lease time that is too large prevents the DHCP server 1891 from reclaiming the address even after the local mobility anchor 1892 deletes the mobile node's binding cache entry. 1894 6.12. Home Network Prefix Renumbering 1896 If the mobile node's home network prefix gets renumbered or becomes 1897 invalid during the middle of a mobility session, the mobile access 1898 gateway MUST withdraw the prefix by sending a Router Advertisement on 1899 the access link with zero prefix lifetime for the mobile node's home 1900 network prefix. Also, the local mobility anchor and the mobile 1901 access gateway MUST delete the routing state for that prefix. 1902 However, the specific details on how the local mobility anchor 1903 notifies the mobile access gateway about the mobile node's home 1904 network prefix renumbering are outside the scope of this document. 1906 6.13. Mobile Node Detachment Detection and Resource Cleanup 1908 Before sending a Proxy Binding Update message to the local mobility 1909 anchor for extending the lifetime of a currently existing binding of 1910 a mobile node, the mobile access gateway MUST make sure the mobile 1911 node is still attached to the connected link by using some reliable 1912 method. If the mobile access gateway cannot predictably detect the 1913 presence of the mobile node on the connected link, it MUST NOT 1914 attempt to extend the registration lifetime of the mobile node. 1915 Further, in such scenario, the mobile access gateway SHOULD terminate 1916 the binding of the mobile node by sending a Proxy Binding Update 1917 message to the mobile node's local mobility anchor with lifetime 1918 value set to 0. It MUST also remove any local state such as the 1919 Binding Update List created for that mobile node. 1921 The specific detection mechanism of the loss of a visiting mobile 1922 node on the connected link is specific to the access link between the 1923 mobile node and the mobile access gateway and is outside the scope of 1924 this document. Typically, there are various link-layer specific 1925 events specific to each access technology that the mobile access 1926 gateway can depend on for detecting the node loss. In general, the 1927 mobile access gateway can depend on one or more of the following 1928 methods for the detection presence of the mobile node on the 1929 connected link: 1931 o Link-layer event specific to the access technology 1933 o PPP Session termination event on point-to-point link types 1935 o IPv6 Neighbor Unreachability Detection event from IPv6 stack 1936 o Notification event from the local mobility anchor 1938 o Absence of data traffic from the mobile node on the link for a 1939 certain duration of time 1941 6.14. Allowing network access to other IPv6 nodes 1943 In some Proxy Mobile IPv6 deployments, network operators may want to 1944 provision the mobile access gateway to offer network-based mobility 1945 management service only to some visiting mobile nodes and enable just 1946 regular IP access to some other nodes. This requires the network to 1947 have control on when to enable network-based mobility management 1948 service to a mobile node and when to enable regular IPv6 access. 1949 This specification does not disallow such configuration. 1951 Upon detecting a mobile node on its access link and after policy 1952 considerations, the mobile access gateway MUST determine if network- 1953 based mobility management service should be offered to that mobile 1954 node. This decision may also be influenced by the mobile node's 1955 host-based mobility capabilities and preferences. This may be 1956 negotiated using link-layer message exchange or through other means 1957 outside the scope of this specification. If the mobile node is 1958 entitled for network-based mobility management service, then the 1959 mobile access gateway must ensure the mobile node believes it is on 1960 its home link, as explained in various sections of this 1961 specification. 1963 If the mobile node is not entitled for the network-based mobility 1964 management service, as determined from the policy considerations, the 1965 mobile access gateway MAY choose to offer regular IPv6 access to the 1966 mobile node and in such scenario the normal IPv6 considerations 1967 apply. If IPv6 access is enabled, the mobile node SHOULD be able to 1968 obtain an IPv6 address using normal IPv6 address configuration 1969 procedures. The obtained address must be from a local visitor 1970 network prefix. This essentially ensures that the mobile access 1971 gateway functions as a normal access router to a mobile node attached 1972 to its access link and with out impacting its host-based mobility 1973 protocol operation. 1975 7. Mobile Node Operation 1977 This non-normative section explains the mobile node's operation in a 1978 Proxy Mobile IPv6 domain. 1980 7.1. Moving into a Proxy Mobile IPv6 Domain 1982 Once a mobile node enters a Proxy Mobile IPv6 domain and attaches to 1983 an access network, the mobile access gateway on the access link 1984 detects the attachment of the mobile node and completes the binding 1985 registration with the mobile node's local mobility anchor. If the 1986 binding update operation is successfully performed, the mobile access 1987 gateway will create the required state and setup the data path for 1988 the mobile node's data traffic. 1990 If the mobile node is IPv6 enabled, on attaching to the access link, 1991 it will typically send Router Solicitation message [RFC-2461]. The 1992 mobile access gateway on the access link will respond to the Router 1993 Solicitation message with a Router Advertisement. The Router 1994 Advertisement will have the mobile node's home network prefix, 1995 default-router address and other address configuration parameters. 1997 If the mobile access gateway on the access link, receives a Router 1998 Solicitation message from the mobile node, before it completed the 1999 signaling with the mobile node's local mobility anchor, the mobile 2000 access gateway may not know the mobile node's home network prefix and 2001 may not be able to emulate the mobile node's home link on the access 2002 link. In such scenario, the mobile node may notice a slight delay 2003 before it receives a Router Advertisement message. 2005 If the received Router Advertisement has the Managed Address 2006 Configuration flag set, the mobile node, as it would normally do, 2007 will send a DHCPv6 Request [RFC-3315]. The DHCP relay service 2008 enabled on that access link will ensure the mobile node will obtain 2009 its IPv6 address as a lease from its home network prefix. 2011 If the received Router Advertisement does not have the Managed 2012 Address Configuration flag set and if the mobile node is allowed to 2013 use an autoconfigured address, the mobile node will be able to obtain 2014 an IPv6 address using an interface identifier generated as per the 2015 Autoconf specification [RFC-2462] or as per the Privacy Extensions 2016 specification [RFC-3041]. 2018 If the mobile node is IPv4 enabled and if the network permits, it 2019 will be able to obtain the IPv4 address configuration for the 2020 connected interface by using DHCP [RFC-2131]. The details related to 2021 IPv4 support is specified in the companion document [ID-IPV4-PMIP6]. 2023 Once the address configuration is complete, the mobile node can 2024 continue to use this address configuration as long as it is attached 2025 to the network that is in the scope of that Proxy Mobile IPv6 domain. 2027 7.2. Roaming in the Proxy Mobile IPv6 Domain 2029 After obtaining the address configuration in the Proxy Mobile IPv6 2030 domain, as the mobile node moves and changes its point of attachment 2031 from one mobile access gateway to the other, it can still continue to 2032 use the same address configuration. As long as the attached access 2033 network is in the scope of that Proxy Mobile IPv6 domain, the mobile 2034 node will always detect the same link, where it obtained its initial 2035 address configuration. If the mobile node performs DHCP operation, 2036 it will always obtain the same address as before. 2038 However, the mobile node will always detect a new default-router on 2039 each connected link, but still advertising the mobile node's home 2040 network prefix as the on-link prefix and with the other configuration 2041 parameters consistent with its home link properties. 2043 7.3. IPv6 Host Protocol Parameters 2045 This specification does not require any changes to the mobile node's 2046 IP stack. It assumes the mobile node to be a normal IPv4/IPv6 node, 2047 with its protocol operation consistent with the respective 2048 specifications. 2050 However, this specification recommends that the following IPv6 2051 operating parameters on the mobile node be adjusted to the below 2052 recommended values for protocol efficiency and for achieving faster 2053 hand-offs. 2055 Lower Default-Router List Cache Time-out: 2057 As per the base IPv6 specification [RFC-2461], each IPv6 host is 2058 required to maintain certain host data structures including a 2059 Default-Router list. This is the list of on-link routers that have 2060 sent Router Advertisement messages and are eligible to be default 2061 routers on that link. The Router Lifetime field in the received 2062 Router Advertisement defines the life of this entry. 2064 In case of Proxy Mobile IPv6, when a mobile node moves from one link 2065 to another, the source address of the received Router Advertisement 2066 messages advertising the mobile node's home network prefix will be 2067 from a different link-local address and thus making the mobile node 2068 believe that there is a new default-router on the link. It is 2069 important that the mobile node uses the newly learnt default-router 2070 and not the previously known default-router. The mobile node must 2071 update its default-router list with the new default router entry and 2072 must age out the previously learnt default router entry from its 2073 cache, just as specified in Section 6.3.5 [RFC-2461]. This action is 2074 critical for minimizing packet losses during a hand off switch. 2076 On detecting a reachability problem, the mobile node will certainly 2077 detect the default-router loss by performing the Neighbor 2078 Unreachability Detection procedure, but it is important that the 2079 mobile node times out the previous default router entry at the 2080 earliest. If a given IPv6 host implementation has the provision to 2081 adjust these flush timers, still conforming to the base IPv6 ND 2082 specification, it is desirable to keep the flush-timers to suit the 2083 above consideration. 2085 In access network where SEND [RFC-3971] is not deployed, the mobile 2086 access gateway may withdraw the previous default-router entry, by 2087 sending a Router Advertisement using the link-local address that of 2088 the previous mobile access gateway and with the Router Lifetime field 2089 set to value 0, then this will force the flush of the Previous 2090 Default-Router entry from the mobile node's cache. This certainly 2091 requires context-transfer mechanisms in place for notifying the link- 2092 local address of the default-router on the previous link to the 2093 mobile access gateway on the new link. 2095 There are other solutions possible for this problem, including the 2096 assignment of a fixed link-local address for all the mobility 2097 entities in a Proxy Mobile IPv6 domain and where SEND [RFC-3971] is 2098 not deployed. In such scenario, the mobile node is not required to 2099 update the default-router entry. However, this is an implementation 2100 choice and has no bearing on the protocol interoperability. 2101 Implementations are free to adopt the best approach that suits their 2102 target deployments. 2104 8. Message Formats 2106 This section defines extensions to the Mobile IPv6 [RFC-3775] 2107 protocol messages. 2109 8.1. Proxy Binding Update Message 2111 0 1 2 3 2112 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 | Sequence # | 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 |A|H|L|K|M|R|P| Reserved | Lifetime | 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 | | 2119 . . 2120 . Mobility options . 2121 . . 2123 | | 2124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 Figure 13: Proxy Binding Update Message 2128 A Binding Update message that is sent by a mobile access gateway to a 2129 local mobility anchor is referred to as the "Proxy Binding Update" 2130 message. A new flag (P) is included in the Binding Update message. 2131 The rest of the Binding Update message format remains the same as 2132 defined in [RFC-3775]. 2134 Proxy Registration Flag (P) 2136 A new flag (P) is included in the Binding Update message to 2137 indicate to the local mobility anchor that the Binding Update 2138 message is a proxy registration. The flag MUST be set to the 2139 value of 1 for proxy registrations and MUST be set to 0 for direct 2140 registrations sent by a mobile node. 2142 Mobility Options 2144 Variable-length field of such length that the complete Mobility 2145 Header is an integer multiple of 8 octets long. This field 2146 contains zero or more TLV-encoded mobility options. The encoding 2147 and format of defined options are described in Section 6.2 [RFC- 2148 3775]. The local mobility anchor MUST ignore and skip any options 2149 which it does not understand. 2151 As per this specification, the following mobility options are 2152 valid in a Proxy Binding Update message: 2154 Home Network Prefix option 2156 Link-local Address option 2158 NAI Option 2160 Timestamp option 2162 For descriptions of other fields present in this message, refer to 2163 section 6.1.7 [RFC-3775]. 2165 8.2. Proxy Binding Acknowledgement Message 2167 0 1 2 3 2168 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | Status |K|R|P|Reserved | 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 | Sequence # | Lifetime | 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 | | 2175 . . 2176 . Mobility options . 2177 . . 2178 | | 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 Figure 14: Proxy Binding Acknowledgement Message 2183 A Binding Acknowledgement message that is sent by a local mobility 2184 anchor to a mobile access gateway is referred to as the "Proxy 2185 Binding Acknowledgement" message. A new flag (P) is included in the 2186 Binding Acknowledgement message. The rest of the Binding 2187 Acknowledgement message format remains the same as defined in [RFC- 2188 3775]. 2190 Proxy Registration Flag (P) 2191 A new flag (P) is included in the Binding Acknowledgement message 2192 to indicate that the local mobility anchor that processed the 2193 corresponding Proxy Binding Update message supports proxy 2194 registrations. The flag is set only if the corresponding Proxy 2195 Binding Update had the Proxy Registration Flag (P) set to value of 2196 1. 2198 Mobility Options 2200 Variable-length field of such length that the complete Mobility 2201 Header is an integer multiple of 8 octets long. This field 2202 contains zero or more TLV-encoded mobility options. The encoding 2203 and format of defined options are described in Section 6.2 [RFC- 2204 3775]. The mobile access gateway MUST ignore and skip any options 2205 which it does not understand. 2207 As per this specification, the following mobility options are 2208 valid in a Proxy Binding Acknowledgement message: 2210 Home Network Prefix option 2212 Link-local Address option 2214 NAI Option 2216 Timestamp option 2218 Status 2220 8-bit unsigned integer indicating the disposition of the Proxy 2221 Binding Update. Values of the Status field less than 128 indicate 2222 that the Proxy Binding Update was accepted by the local mobility 2223 anchor. Values greater than or equal to 128 indicate that the 2224 binding registration was rejected by the local mobility anchor. 2225 Section 8.6 defines the Status values that can used in Proxy 2226 Binding Acknowledgement message. 2228 For descriptions of other fields present in this message, refer to 2229 the section 6.1.8 [RFC-3775]. 2231 8.3. Home Network Prefix Option 2233 A new option, Home Network Prefix Option is defined for using it in 2234 the Proxy Binding Update and Proxy Binding Acknowledgement messages 2235 exchanged between a local mobility anchor and a mobile access 2236 gateway. This option is used for exchanging the mobile node's home 2237 network prefix information. 2239 The Home Network Prefix Option has an alignment requirement of 8n+4. 2240 Its format is as follows: 2242 0 1 2 3 2243 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2245 | Type | Length | Reserved | Prefix Length | 2246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2247 | | 2248 + + 2249 | | 2250 + Home Network Prefix + 2251 | | 2252 + + 2253 | | 2254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 Type 2257 2259 Length 2261 8-bit unsigned integer indicating the length of the option 2262 in octets, excluding the type and length fields. This field 2263 MUST be set to 18. 2265 Reserved 2267 This field is unused for now. The value MUST be initialized 2268 to 0 by the sender and MUST be ignored by the receiver. 2270 Prefix Length 2272 8-bit unsigned integer indicating the prefix length of the 2273 IPv6 prefix contained in the option. 2275 Home Network Prefix 2277 A sixteen-byte field containing the mobile node's IPv6 Home 2278 Network Prefix. 2280 Figure 15: Home Network Prefix Option 2282 8.4. Link-local Address Option 2284 A new option, Link-local Address Option is defined for using it in 2285 the Proxy Binding Update and Proxy Binding Acknowledgement messages 2286 exchanged between a local mobility anchor and a mobile access 2287 gateway. This option is used for exchanging the mobile node's link- 2288 local address. 2290 The Link-local Address option has an alignment requirement of 8n+6. 2291 Its format is as follows: 2293 0 1 2 3 2294 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2296 | Type | Length | 2297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2298 | | 2299 + + 2300 | | 2301 + Link-local Address + 2302 | | 2303 + + 2304 | | 2305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2307 Type 2308 2310 Length 2312 8-bit unsigned integer indicating the length of the option 2313 in octets, excluding the type and length fields. This field 2314 MUST be set to 16. 2316 Link-local Address 2318 A sixteen-byte field containing the mobile node's link-local 2319 address. 2321 Figure 16: Link-local Address Option 2323 8.5. Timestamp Option 2325 A new option, Timestamp Option is defined for use in the Proxy 2326 Binding Update and Proxy Binding Acknowledgement messages. 2328 The Timestamp option has an alignment requirement of 8n+2. Its 2329 format is as follows: 2331 0 1 2 3 2332 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2334 | Option Type | Option Length | 2335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 | | 2337 + Timestamp + 2338 | | 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2341 Type 2342 2344 Length 2346 8-bit unsigned integer indicating the length in octets of 2347 the option, excluding the type and length fields. The value 2348 for this field MUST be set to 8. 2350 Timestamp 2352 A 64-bit unsigned integer field containing a timestamp. The value 2353 indicates the number of seconds since January 1, 1970, 00:00 UTC, 2354 by using a fixed point format. In this format, the integer number 2355 of seconds is contained in the first 48 bits of the field, and the 2356 remaining 16 bits indicate the number of 1/64K fractions of a 2357 second. 2359 Figure 17: Timestamp Option 2361 8.6. Status Values 2363 This document defines the following new Status values for use in 2364 Proxy Binding Acknowledgement message. These values are to be 2365 allocated from the same number space, as defined in Section 6.1.8 2366 [RFC-3775]. 2368 Status values less than 128 indicate that the Proxy Binding Update 2369 request was accepted by the local mobility anchor. Status values 2370 greater than 128 indicate that the Proxy Binding Update was rejected 2371 by the local mobility anchor. 2373 PROXY_REG_NOT_ENABLED: 2375 Proxy Registration not enabled for the mobile node. 2377 MAG_NOT_AUTHORIZED_FOR_PROXY_REG: 2379 The mobile access gateway is not authorized to send proxy binding. 2380 updates. 2382 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX 2384 The mobile node is not authorized for the requesting home network 2385 prefix. 2387 TIMESTAMP_MISMATCH: 2389 Invalid Timestamp value in the received Proxy Binding Update 2390 message. 2392 MISSING_MN_IDENTIFIER_OPTION: 2394 Missing mobile node identifier in the Proxy Binding Update 2395 message. 2397 Additionally, the following Status values defined in [RFC-3775] can 2398 also be used in Proxy Binding Acknowledgement message. 2400 0 Proxy Binding Update accepted 2402 128 Reason unspecified 2404 129 Administratively prohibited 2406 130 Insufficient resources 2407 133 Not local mobility anchor for this mobile node 2409 9. Protocol Configuration Variables 2411 The mobile access gateway MUST allow the following variables to be 2412 configured by the system management. 2414 EnableMAGLocalrouting 2416 This flag indicates whether or not the mobile access gateway is 2417 allowed to enable local routing of the traffic exchanged between a 2418 visiting mobile node and a correspondent node that is locally 2419 connected to one of the interfaces of the mobile access gateway. 2420 The correspondent node can be another visiting mobile node as 2421 well, or a local fixed node. 2423 The default value for this flag is set to "FALSE", indicating that 2424 the mobile access gateway MUST reverse tunnel all the traffic to 2425 the mobile node's local mobility anchor. 2427 When the value of this flag is set to "TRUE", the mobile access 2428 gateway MUST route the traffic locally. 2430 This aspect of local routing MAY be defined as policy on a per 2431 mobile basis and when present will take precedence over this flag. 2433 The local mobility anchor MUST allow the following variables to be 2434 configured by the system management. 2436 MinDelayBeforeBCEDelete 2438 This variable specifies the amount of time in milliseconds the 2439 local mobility anchor MUST wait before it deletes a Binding Cache 2440 entry of a mobile node, upon receiving a Proxy Binding Update 2441 message from a mobile access gateway with a lifetime value of 0. 2442 During this wait time, if the local mobility anchor receives a 2443 Proxy Binding Update for the same mobile node, identified by its 2444 MN-Identifier, with lifetime value greater than 0, then it must 2445 update the binding cache entry with the accepted binding values. 2446 At the end of this wait-time, if the local mobility anchor did not 2447 receive any valid Proxy Binding Update message, it MUST delete the 2448 Binding Cache entry for that mobile node. 2450 The default value for this variable is 1000 milliseconds. 2452 10. IANA Considerations 2454 This document defines a three new Mobility Header Options, the Home 2455 Network Prefix option, Link-local Address option and the Timestamp 2456 option. These options are described in Sections 8.3, 8.4 and 8.5 2457 respectively. The Type value for these options needs to be assigned 2458 from the same numbering space as allocated for the other mobility 2459 options, as defined in [RFC-3775]. 2461 This document also defines new Binding Acknowledgement status values 2462 as described in Section 8.6. The status values MUST be assigned from 2463 the same number space used for Binding Acknowledgement status values, 2464 as defined in [RFC-3775]. The allocated values for each of these 2465 status values MUST be greater than 128. 2467 11. Security Considerations 2469 The potential security threats against any network-based mobility 2470 management protocol are described in [RFC-4832]. This section 2471 explains how Proxy Mobile IPv6 protocol defends itself against those 2472 threats. 2474 Proxy Mobile IPv6 protocol requires the signaling messages, Proxy 2475 Binding Update and Proxy Binding Acknowledgement, exchanged between 2476 the mobile access gateway and the local mobility anchor to be 2477 protected using IPsec, using the established security association 2478 between them. This essentially eliminates the threats related to the 2479 impersonation of the mobile access gateway or the local mobility 2480 anchor. 2482 This specification allows a mobile access gateway to send binding 2483 registration messages on behalf of a mobile node. If proper 2484 authorization checks are not in place, a malicious node may be able 2485 to hijack a mobile node's session or may carry out a denial-of- 2486 service attack. To prevent this attack, this specification requires 2487 the local mobility anchor to allow only authorized mobile access 2488 gateways to send binding registration messages on behalf of a mobile 2489 node. 2491 To eliminate the threats on the interface between the mobile access 2492 gateway and the mobile node, this specification requires an 2493 established trust between the mobile access gateway and the mobile 2494 node and to authenticate and authorize the mobile node before it is 2495 allowed to access the network. Further, the established 2496 authentication mechanisms enabled on that access link will ensure 2497 that there is a secure binding between the mobile node's identity and 2498 its link-layer address. The mobile access gateway will definitively 2499 identify the mobile node from the packets that it receives on that 2500 access link. 2502 To eliminate the threats related to a compromised mobile access 2503 gateway, this specification recommends that the local mobility anchor 2504 before accepting a Proxy Binding Update message for a given mobile 2505 node, should ensure the mobile node is definitively attached to the 2506 mobile access gateway that sent the binding registration request. 2508 The issues related to a compromised mobile access gateway in the 2509 scenario where the local mobility anchor and the mobile access 2510 gateway in different domains, is outside the scope of this document. 2511 This scenario is beyond the applicability of this document. 2513 12. Acknowledgements 2515 The authors would like to specially thank Julien Laganier, Christian 2516 Vogt, Pete McCann, Brian Haley, Ahmad Muhanna, JinHyeock Choi for 2517 their thorough review of this document. 2519 The authors would also like to thank Alex Petrescu, Alice Qinxia, 2520 Alper Yegin, Ashutosh Dutta, Behcet Sarikaya, Fred Templing, Genadi 2521 Velev, George Tsirtsis, Gerardo Giaretta, Henrik Levkowetz, Hesham 2522 Soliman, James Kempf, Jari Arkko, Jean-Michel Combes, John Zhao, 2523 Jong-Hyouk Lee, Jonne Soininen, Jouni Korhonen, Kilian Weniger, Marco 2524 Liebsch, Mohamed Khalil, Nishida Katsutoshi, Phil Roberts, Ryuji 2525 Wakikawa, Sangjin Jeong, Suresh Krishnan, Vidya Narayanan, Youn-Hee 2526 Han and many others for their passionate discussions in the working 2527 group mailing list on the topic of localized mobility management 2528 solutions. These discussions stimulated much of the thinking and 2529 shaped the draft to the current form. We acknowledge that ! 2531 The authors would also like to thank Ole Troan, Akiko Hattori, Parviz 2532 Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer and 2533 Tim Stammers for their input on this document. 2535 13. References 2537 13.1. Normative References 2539 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 2540 Requirement Levels", BCP 14, RFC 2119, March 1997. 2542 [RFC-2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 2543 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 2545 [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2546 IPv6 Specification", RFC 2473, December 1998. 2548 [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 2549 M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 2550 RFC 3315, July 2003. 2552 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 2553 IPv6", RFC 3775, June 2004. 2555 [RFC-4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 2556 Network Access Identifier", RFC 4282, November 2005. 2558 [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 2559 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, 2560 November 2005. 2562 [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the 2563 Internet Protocol", RFC 4301, December 2005. 2565 [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC 2566 4303, December 2005. 2568 13.2. Informative References 2570 [RFC-1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 2571 51, RFC 1661, July 1994. 2573 [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2574 2131, March 1997. 2576 [RFC-2462] Thompson, S., Narten, T., "IPv6 Stateless Address 2577 Autoconfiguration", RFC 2462, December 1998. 2579 [RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", RFC 2580 2472, December 1998. 2582 [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for 2583 Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. 2585 [RFC-3971] Arkko, J., Ed., Kempf, J., Sommerfeld, B., Zill, B., and 2586 P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2587 2005. 2589 [RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2) 2590 Protocol", RFC 4306, December 2005. 2592 [RFC-4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 2593 for IPv4, IPv6 and OSI", RFC 2030, October 1996. 2595 [RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 2596 G., Liebsch, M., "Problem Statement for Network-based Localized 2597 Mobility Management", September 2006. 2599 [RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 2600 G., Liebsch, M., "Goals for Network-based Localized Mobility 2601 Management", October 2006. 2603 [RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based 2604 Localized Mobility Management", September 2006. 2606 [ID-IPV4-PMIP6] Wakikawa, R. and Gundavelli, S., "IPv4 Support for 2607 Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-01.txt, May 2608 2007. 2610 [ID-DNAV6] Kempf, J., et al "Detecting Network Attachment in IPv6 2611 Networks (DNAv6)", draft-ietf-dna-protocol-06.txt, October 2006. 2613 Appendix A. Proxy Mobile IPv6 interactions with AAA Infrastructure 2615 Every mobile node that roams in a proxy Mobile IPv6 domain, would 2616 typically be identified by an identifier, MN-Identifier, and that 2617 identifier will have an associated policy profile that identifies the 2618 mobile node's home network prefix, permitted address configuration 2619 modes, roaming policy and other parameters that are essential for 2620 providing network-based mobility service. This information is 2621 typically configured in AAA. It is possible the home network prefix 2622 is dynamically allocated for the mobile node when it boots up for the 2623 first time in the network, or it could be a statically configured 2624 value on per mobile node basis. However, for all practical purposes, 2625 the network entities in the proxy Mobile IPv6 domain, while serving a 2626 mobile node will have access to this profile and these entities can 2627 query this information using RADIUS/DIAMETER protocols. 2629 Appendix B. Supporting Shared-Prefix Model using DHCPv6 2631 This specification supports Per-MN-Prefix model. However, it is 2632 possible to support Shared-Prefix model under the following 2633 guidelines. 2635 The mobile node is allowed to use stateful address configuration 2636 using DHCPv6 for obtaining its address configuration. The mobile 2637 node is not allowed to use any of the stateless autoconfiguration 2638 techniques. The permitted address configuration models for the 2639 mobile node on the access link can be enforced by the mobile access 2640 gateway, by setting the relevant flags in the Router Advertisements, 2641 as per [RFC-2461]. 2643 The Home Network Prefix option that is sent by the mobile access 2644 gateway in the Proxy Binding Update message, must contain the 128-bit 2645 host address that the mobile node obtained via DHCPv6. 2647 Routing state at the mobile access gateway: 2649 For all IPv6 traffic from the source MN-HoA::/128 to 2650 _ANY_DESTINATION_, route via tunnel0, next-hop LMAA, where tunnel0 is 2651 the MAG to LMA tunnel. 2653 Routing state at the local mobility anchor: 2655 For all IPv6 traffic to destination MN-HoA::/128, route via tunnel0, 2656 next-hop Proxy-CoA, where tunnel0 is the LMA to MAG tunnel. 2658 Authors' Addresses 2660 Sri Gundavelli 2661 Cisco 2662 170 West Tasman Drive 2663 San Jose, CA 95134 2664 USA 2666 Email: sgundave@cisco.com 2668 Kent Leung 2669 Cisco 2670 170 West Tasman Drive 2671 San Jose, CA 95134 2672 USA 2674 Email: kleung@cisco.com 2675 Vijay Devarapalli 2676 Azaire Networks 2677 4800 Great America Pkwy 2678 Santa Clara, CA 95054 2679 USA 2681 Email: vijay.devarapalli@azairenet.com 2683 Kuntal Chowdhury 2684 Starent Networks 2685 30 International Place 2686 Tewksbury, MA 2688 Email: kchowdhury@starentnetworks.com 2690 Basavaraj Patil 2691 Nokia Siemens Networks 2692 6000 Connection Drive 2693 Irving, TX 75039 2694 USA 2696 Email: basavaraj.patil@nsn.com 2698 Full Copyright Statement 2700 Copyright (C) The IETF Trust (2007). 2702 This document is subject to the rights, licenses and restrictions 2703 contained in BCP 78, and except as set forth therein, the authors 2704 retain all their rights. 2706 This document and the information contained herein are provided on an 2707 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2708 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2709 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2710 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2711 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2712 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2714 Intellectual Property 2716 The IETF takes no position regarding the validity or scope of any 2717 Intellectual Property Rights or other rights that might be claimed to 2718 pertain to the implementation or use of the technology described in 2719 this document or the extent to which any license under such rights 2720 might or might not be available; nor does it represent that it has 2721 made any independent effort to identify any such rights. Information 2722 on the procedures with respect to rights in RFC documents can be 2723 found in BCP 78 and BCP 79. 2725 Copies of IPR disclosures made to the IETF Secretariat and any 2726 assurances of licenses to be made available, or the result of an 2727 attempt made to obtain a general license or permission for the use of 2728 such proprietary rights by implementers or users of this 2729 specification can be obtained from the IETF on-line IPR repository at 2730 http://www.ietf.org/ipr. 2732 The IETF invites any interested party to bring to its attention any 2733 copyrights, patents or patent applications, or other proprietary 2734 rights that may cover technology that may be required to implement 2735 this standard. Please address the information to the IETF at 2736 ietf-ipr@ietf.org. 2738 Acknowledgment 2740 Funding for the RFC Editor function is provided by the IETF 2741 Administrative Support Activity (IASA).