idnits 2.17.1 draft-sgundave-mip6-proxymip6-01.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1624. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 283: '..., the home agent MUST allow only autho...' RFC 2119 keyword, line 369: '...d by relaxing the MUST requirement for...' RFC 2119 keyword, line 430: '...ically a shared tunnel and MAY be used...' RFC 2119 keyword, line 436: '...ss of the tunnel MUST be the address t...' RFC 2119 keyword, line 440: '... The home agent SHOULD use a Tunnel-L...' (28 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (January 5, 2007) is 6321 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4' on line 130 -- Looks like a reference, but probably isn't: '2' on line 133 == Missing Reference: 'MS1' is mentioned on line 192, but not defined == Missing Reference: 'MS2' is mentioned on line 192, but not defined == Missing Reference: 'MS5' is mentioned on line 196, but not defined == Missing Reference: 'MS3' is mentioned on line 198, but not defined == Missing Reference: 'MS4' is mentioned on line 198, but not defined == Missing Reference: 'MN' is mentioned on line 198, but not defined == Missing Reference: 'RFC3775' is mentioned on line 1300, but not defined ** Obsolete undefined reference: RFC 3775 (Obsoleted by RFC 6275) == Missing Reference: 'RFC-4285' is mentioned on line 405, but not defined == Missing Reference: 'RFC-3344' is mentioned on line 878, but not defined ** Obsolete undefined reference: RFC 3344 (Obsoleted by RFC 5944) == Missing Reference: 'RFC-1305' is mentioned on line 575, but not defined ** Obsolete undefined reference: RFC 1305 (Obsoleted by RFC 5905) -- Looks like a reference, but probably isn't: '1' on line 1211 == Missing Reference: 'RFC-2131' is mentioned on line 971, but not defined == Unused Reference: 'RFC1305' is defined on line 1487, but no explicit reference was found in the text == Unused Reference: 'RFC-2462' is defined on line 1496, but no explicit reference was found in the text == Unused Reference: 'RFC-2473' is defined on line 1499, but no explicit reference was found in the text == Unused Reference: 'RFC4283' is defined on line 1513, but no explicit reference was found in the text == Unused Reference: 'RFC-4303' is defined on line 1520, but no explicit reference was found in the text == Unused Reference: 'RFC-1332' is defined on line 1540, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 1549, but no explicit reference was found in the text == Unused Reference: 'RFC3344' is defined on line 1555, but no explicit reference was found in the text == Unused Reference: 'RFC-3756' is defined on line 1558, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 2406 (ref. 'RFC-4303') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 2472 (Obsoleted by RFC 5072, RFC 5172) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) Summary: 15 errors (**), 0 flaws (~~), 22 warnings (==), 14 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 Expires: July 9, 2007 Cisco Systems 5 V. Devarapalli 6 Azaire Networks 7 K. Chowdhury 8 Starent Networks 9 January 5, 2007 11 Proxy Mobile IPv6 12 draft-sgundave-mip6-proxymip6-01 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July 9, 2007. 39 Copyright Notice 41 Copyright (C) The Internet Society (2007). 43 Abstract 45 This specification describes a network-based mobility management 46 protocol. It is called Proxy Mobile IPv6 (PMIPv6) and is based on 47 Mobile IPv6. This protocol is for providing mobility support to any 48 IPv6 host within a restricted and topologically localized portion of 49 the network and with out requiring the participation of the host in 50 any mobility related signaling. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Conventions used in this document . . . . . . . . . . . . . . 4 56 3. Proxy Mobile IPv6 Protocol Overview . . . . . . . . . . . . . 5 57 4. Proxy Mobile IPv6 Protocol Security . . . . . . . . . . . . . 7 58 4.1. Peer Authorization Database Entries . . . . . . . . . . . 8 59 4.2. Security Policy Database Entries . . . . . . . . . . . . . 9 60 5. Home Agent Considerations . . . . . . . . . . . . . . . . . . 9 61 5.1. Extensions to Binding Cache Conceptual Data Structure . . 10 62 5.2. Bi-Directional Tunnel Management . . . . . . . . . . . . . 11 63 5.3. Routing Considerations . . . . . . . . . . . . . . . . . . 12 64 5.4. Dynamic Home Agent Address Discovery Considerations . . . 13 65 5.5. Sequencing Number Considerations . . . . . . . . . . . . . 14 66 5.6. IPv4 Home Address Mobility Support . . . . . . . . . . . . 15 67 5.7. Route Optimizations Considerations . . . . . . . . . . . . 15 68 5.8. Mobile Prefix Discovery Considerations . . . . . . . . . . 16 69 5.9. Home Agent Operation Summary . . . . . . . . . . . . . . . 16 70 6. Proxy Mobile Agent Considerations . . . . . . . . . . . . . . 17 71 6.1. Address Configuration Models . . . . . . . . . . . . . . . 18 72 6.2. Access Authentication . . . . . . . . . . . . . . . . . . 19 73 6.3. Home Network Emulation . . . . . . . . . . . . . . . . . . 19 74 6.4. Link-Local and Global Address Uniqueness . . . . . . . . . 20 75 6.5. IPv4 Home Address Mobility Support . . . . . . . . . . . . 20 76 6.6. Tunnel Management . . . . . . . . . . . . . . . . . . . . 21 77 6.7. Routing Considerations . . . . . . . . . . . . . . . . . . 21 78 6.8. Interaction with DHCP Relay Agent . . . . . . . . . . . . 23 79 6.9. Coexistence of CMIP & PMIP Nodes . . . . . . . . . . . . . 23 80 6.10. Proxy Mobile Agent Operation Summary . . . . . . . . . . . 24 81 6.11. Conceptual Data Structures . . . . . . . . . . . . . . . . 26 82 7. Mobile Node Considerations . . . . . . . . . . . . . . . . . . 26 83 7.1. Booting in the Proxy Mobile IPv6 Network . . . . . . . . . 27 84 7.2. Roaming in the Proxy Mobile IPv6 Network . . . . . . . . . 28 85 7.3. IPv6 Host Protocol Parameters . . . . . . . . . . . . . . 28 86 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 29 87 8.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . . 30 88 8.2. Proxy Binding Acknowledgment . . . . . . . . . . . . . . . 30 89 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 31 90 8.4. Time Stamp Option . . . . . . . . . . . . . . . . . . . . 32 91 8.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 33 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 94 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 96 12.1. Normative References . . . . . . . . . . . . . . . . . . . 36 97 12.2. Informative References . . . . . . . . . . . . . . . . . . 37 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 99 Intellectual Property and Copyright Statements . . . . . . . . . . 39 101 1. Introduction 103 The IP Mobility protocols designed in the IETF so far involve the 104 host in mobility management. There are some deployment scenarios 105 where a network-based mobility management protocol is considered 106 appropriate. The advantages to using a network-based mobility 107 protocol include avoiding tunneling overhead over the air and support 108 for hosts that do not implement any mobility management protocol. 110 The document describes a network-based mobility management protocol 111 based on Mobile IPv6. it is called Proxy Mobile IPv6 (PMIPv6). One 112 of the most important design considerations behind PMIPv6 has been to 113 re-use as much as possible from the existing mobility protocols. 115 There are many advantages to develop a protocol based on Mobile IPv6. 116 Mobile IPv6 is a very mature mobility protocol for IPv6. There have 117 been many implementations and inter-operability events where Mobile 118 IPv6 has been tested. There also numerous specifications enhancing 119 Mobile IPv6 that can be re-used. Further, the Proxy MIPv6 solution 120 described in this document allows the same Home Agent to provide 121 mobility to hosts that use Mobile IPv6 and hosts that do not use any 122 mobility management protocol. Proxy Mobile IPv6 provides solution to 123 a real deployment problem. 125 2. Conventions used in this document 127 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [4]. 131 The following new terminology and abbreviations are introduced in 132 this document and all other general mobility related terms as 133 defined in Mobile IPv6 specification [2]. 135 Proxy Mobile Agent (PMA) 137 The proxy mobile agent is a functional element on the access 138 router. This is the entity that makes the mobile node believe 139 it is on its home link, by emulating the home link properties. 140 It registers the location of the mobile node to the home agent 141 and establishes a tunnel for receiving packets sent to the 142 mobile node's home address. 144 Mobile Node (MN) 145 This document uses the term mobile node to refer to an IPv6 146 host. This specification does not require the mobile node to 147 have the Mobile IPv6 client stack. 149 3. Proxy Mobile IPv6 Protocol Overview 151 This specification describes a network-based mobility management 152 protocol. It is called Proxy Mobile IPv6 (PMIPv6) and is based on 153 Mobile IPv6. This protocol is for providing mobility support to any 154 IPv6 host, within a restricted and topologically localized portion of 155 the network and with out requiring the participation of the host in 156 any mobility related signaling. 158 Every mobile node that roams in a Proxy Mobile IPv6 network, would 159 typically be identified by an identifier, such as NAI and that 160 identifier will have an associated policy profile that identifies the 161 mobile's home network prefix, permitted address configuration modes, 162 roaming policy and other parameters that are essential for providing 163 network based mobility service. This information is typically 164 configured in a policy store, such as in AAA infrastructure. All the 165 network entities in the Proxy Mobile IPv6 network will have access to 166 this information. 168 Once a mobile node enters its Proxy Mobile IPv6 domain and performs 169 access authentication, the network will ensure the mobile node is 170 always on its home network and further ensures the mobile can always 171 obtain its home address on the access link and using any of the 172 address configuration procedures. In other words, there is home 173 address/prefix that is assigned for a mobile node and that address 174 always follows the node, where ever it roams within that PMIP domain. 175 From the perspective of the mobile node, the entire Proxy Mobile IPv6 176 domain appears as a single link. 178 +-----+ +-----+ 179 | HA1 | | HA2 | 180 +-----+ +-----+ 181 | HAA1 | HAA2 182 +-\\----------------//-\\------+ 183 | \\ PMIP Network// \\ | 184 +---\\------------//-----\\----+ 185 \\ // \\ 186 \\ // \\ 187 \\ // \\ 188 \\ // \\ 189 \\ // \\ 190 | CoA1 | CoA2 191 +----+ +----+ 192 [MS1].__.|PMA1|.__.[MS2] |PMA2| 193 +----+ +----+ 194 | . 195 | | 196 ------------------- [MS5] 197 | | | 198 [MS3] [MS4] [MN] 200 Figure 1: Proxy Mobile IPv6 Domain 202 The Proxy Mobile IPv6 scheme introduces a new function, the Proxy 203 Mobile Agent (PMA). It is a function that runs on the access router 204 and is the entity that does the mobility related signaling on behalf 205 of the mobile node. From the perspective of the home agent, the 206 proxy mobile agent is a special element in the network that sends 207 Mobile IPv6 signaling messages on behalf of mobile node. 209 When the mobile node attaches to a link on the access router running 210 proxy mobile agent, the mobile node presents its identity to the 211 network in the form of NAI as part of the access authentication 212 procedure. After a successful authentication, the proxy mobile agent 213 obtains the mobile's profile from the policy store, such as from a 214 AAA infrastructure. It can now emulate the mobile's home network on 215 the access link. The proxy mobile agent sends Router Advertisements 216 to the mobile node advertising its home prefix. 218 The mobile node on receiving this Router Advertisement will try to 219 configure its interface either using statefull or stateless address 220 configuration modes, based on the permitted configuration modes on 221 that link. In any case, the mobile node will be able to obtain its 222 home address. 224 For updating the home agent about the current location of the mobile, 225 the proxy mobile agent sends a Binding Update message to the mobile 226 node's home agent. The message will have the mobile node's NAI 227 identifier option. The source address of that message will be the 228 address of the proxy mobile agent on the egress interface. Upon 229 accepting the Binding Update request, the home agent sets up a tunnel 230 to the proxy mobile agent. It also sets up a route to the mobile 231 node's home address over the tunnel and sends Binding Acknowledgment 232 to the proxy mobile agent. 234 The proxy mobile agent on receiving this Binding Acknowledgment sets 235 up a tunnel to the home agent and adds a default route over the 236 tunnel to the home agent. All traffic from the mobile node gets 237 routed to the mobile node's home agent over the tunnel. 239 At this point, the mobile node has a valid home address at the point 240 of current attachment, the serving proxy mobile agent and the home 241 agent have proper routing states for handling the traffic sent by the 242 mobile node and also for the incoming traffic to the mobile station. 244 Home agent being the topological anchor point for the mobile's home 245 prefix, receives any packet from any corresponding node that is sent 246 to the mobile node. Home agent forwards the received packet to the 247 proxy mobile agent through the tunnel. The proxy mobile agent on 248 other end of the tunnel, after receiving the packet removes the 249 tunnel header and forwards the packet on the access link to the 250 mobile station. 252 The proxy mobile agent acts as a default router on the access link 253 and any packet that the mobile node sends to any corresponding node 254 is received by the proxy mobile agent and it forwards the packet to 255 the home agent through the tunnel. The home agent on the other end 256 of the tunnel, after receiving the packet removes the tunnel header 257 and routes the packet to the destination. 259 4. Proxy Mobile IPv6 Protocol Security 261 The signaling messages between the proxy mobile agent and the home 262 agent are protected using IPsec. Per-mobile node security 263 associations are not required between the proxy mobile agent and the 264 home agent to protect the Proxy Binding Update and Proxy Binding 265 Acknowledgment messages. 267 ESP in transport mode with mandatory integrity protection is used for 268 protecting the signaling messages. Confidentiality protection is not 269 required. 271 IKEv2 is used to setup security associations between the proxy mobile 272 agent and the home agent to protect the Proxy Binding Update and 273 Proxy Binding Acknowledgment messages. The proxy mobile agent and 274 the home agent can use any of the authentication mechanisms, as 275 specified in IKEv2, for mutual authentication. 277 Mobile IPv6 specification requires the home agent to prevent a mobile 278 node from creating security associations or creating binding cache 279 entries for another mobile node's home address. In the protocol 280 described in this document, the mobile node is not involved in 281 creating security associations for protecting the signaling messages 282 or sending binding updates. Therefore, this is not a concern. 283 However, the home agent MUST allow only authorized proxy mobile 284 agents to create binding cache entries on behalf of the mobile nodes. 285 The actual mechanism by which the home agent verifies if a proxy 286 mobile agent is authorized to send Proxy Binding Updates on behalf of 287 a mobile node is out of scope for this document. One possible 288 solution is for the home agent to check with the AAA infrastructure 289 if a particular proxy mobile agent is authorized to send Proxy 290 Binding Updates on behalf of a mobile node. 292 4.1. Peer Authorization Database Entries 294 The following describes PAD entries on the proxy mobile agent and the 295 home agent. The PAD entries are only example configurations. Note 296 that the PAD is a logical concept and a particular proxy mobile agent 297 or a home agent implementation can implement the PAD in an 298 implementation specific manner. The PAD state may also be 299 distributed across various databases in a specific implementation. 301 proxy mobile agent PAD: 302 - IF remote_identity = home_agent_identity_1 303 Then authenticate (shared secret/certificate/) 304 and authorize CHILD_SA for remote address home_agent_1 306 home agent PAD: 307 - IF remote_identity = pma_11 308 Then authenticate (shared secret/certificate/EAP) 309 and authorize CHILD_SAs for remote address pma_address_1 311 The list of authentication mechanisms in the above examples is not 312 exhaustive. There could be other credentials used for authentication 313 stored in the PAD. 315 4.2. Security Policy Database Entries 317 The following describes the security policy entries on the proxy 318 mobile agent and the home agent required to protect the Proxy Mobile 319 IPv6 signaling messages. The SPD entries are only example 320 configurations. A particular proxy mobile agent or a Home Agent 321 implementation could configure different SPD entries as long as they 322 provide the required security. 324 In the examples shown below, the identity of the proxy mobile agent 325 is assumed to be pma_1, the address of the proxy mobile agent is 326 assumed to be pma_address_1, and the IPv6 address of the Home Agent 327 is assumed to be home_agent_1. 329 mobile node SPD-S: 330 - IF local_address = pma_address_1 & 331 remote_address = home_agent_1 & 332 proto = MH & local_mh_type = BU & remote_mh_type = BAck 333 Then use SA ESP transport mode 334 Initiate using IDi = pma_1 to address home_agent_1 336 home agent SPD-S: 337 - IF local_address = home_agent_1 & 338 remote_address = pma_address_1 & 339 proto = MH & local_mh_type = BAck & remote_mh_type = BU 340 Then use SA ESP transport mode 342 5. Home Agent Considerations 344 For supporting the Proxy Mobile IPv6 scheme defined in this document, 345 the Mobile IPv6 home agent entity, defined in [RFC-3775], needs some 346 protocol enhancements. This section describes the required 347 enhancements and the protocol operation on the home agent for 348 supporting this scheme. 350 The base Mobile IPv6 specification [RFC-3775], defines the home agent 351 and the mobile node as the two key entities. The Proxy Mobile IPv6 352 scheme introduces a new entity, the Proxy Mobile Agent. This is the 353 entity that will participate in the mobility related signaling. From 354 the perspective of the home agent, the proxy mobile agent is a 355 special element in the network that has the privileges to send 356 mobility related signaling messages on behalf of the mobile node. 357 Typically, the home agent is provisioned with the list of proxy 358 mobile agents authorized to send proxy registrations. 360 When the home agent receives a (Proxy) Binding Update message, the 361 source address and the alternate care-of address in the message is 362 the address that is configured on the egress interface of the sending 363 proxy mobile agent and the message is protected by the Security 364 Association of the Proxy Mobile Agent identified with that address. 365 The home agent can distinguish between a Binding Update message 366 received from a proxy mobile agent from a Binding Update message 367 received directly from a mobile node. This distinction is important 368 for using the right security association for validating the Binding 369 Update and this is achieved by relaxing the MUST requirement for 370 having the Home Address Option presence in Destination Options header 371 and by introducing a new flag in the Binding Update message. The 372 home agent as a traditional IPSec peer can use the SPI in the IPSec 373 header [RFC-4306] of the received packet for locating the correct 374 security association and for processing the Binding Update in the 375 context of Proxy Mobile IP scheme. 377 To allow configuration flexibility, the Proxy Mobile IPv6 scheme 378 allows multiple address configuration models, Per-MN-Prefix and the 379 usual Shared-Prefix addressing model. In the Per-MN-Prefix model, 380 each mobile is allocated a exclusively unique home prefix and the 381 prefix is not hosted on the home link. The home agent in this 382 addressing model is just a topological anchor point and the prefix is 383 physically hosted on the interface of the proxy mobile agent, where 384 the mobile is attached. Thus the home agent is not required to 385 perform any proxy ND operations [RFC-2461] for defending the home 386 address on the home link. The home agent is required to manage a 387 binding cache entry for managing the session state and a routing 388 state for properly routing the packets destined to the mobile node. 390 5.1. Extensions to Binding Cache Conceptual Data Structure 392 The home agent maintains a Binding Cache entry for each currently 393 registered mobile node. The Binding Cache is a conceptual data 394 structure, described in Section 9.1 of [RFC3775]. For supporting 395 this specification, the conceptual Binding Cache entry needs to be 396 extended with the following new fields. 398 o A flag indicating whether or not this Binding Cache entry is 399 created due to a proxy registration. This flag is enabled for 400 Binding Cache entries that are proxy registrations and is turned 401 off for all other entries that are direct registrations. 403 o A mobile identifier, NAI, for tagging the Binding Cache entry with 404 a global identifier of the mobile. This field is set to the value 405 set in the NAI option [RFC-4285]. 407 o A flag indicating whether or not the Binding Cache entry has a 408 home address that is on virtual interface. This flag is enabled, 409 if the home prefix of the mobile is configured on a virtual 410 interface. When the configured home prefix of a mobile is on a 411 virtual interface, the home agent is not required to function as a 412 Neighbor Discovery proxy for the mobile node. 414 o The IPv4 Home Address of the mobile if the mobile is a dual-stack 415 node and if it has obtained a IPv4 home address as part of the 416 IPv4 address configuration. 418 5.2. Bi-Directional Tunnel Management 420 The bi-directional tunnel between the home agent and the proxy mobile 421 agent is used for routing the traffic to and from the mobile node. 422 The tunnel hides the topology and enables the mobile node to use an 423 address that is topologically anchored at the home agent. The base 424 Mobile IPv6 specification [RFC-3775], uses the tunneling mechanism 425 for routing traffic to and from the mobile using its home address. 426 However, there are subtle differences in the way Proxy Mobile IPv6 427 uses the tunneling scheme. 429 As in Mobile IPv4 [RFC-3344], the tunnel between the home agent and 430 the proxy mobile agent is typically a shared tunnel and MAY be used 431 for routing traffic streams for different mobiles attached to the 432 same proxy mobile agent. This specification modifies the 1:1 433 relation between the tunnel and a binding cache entry to 1:m 434 relation, reflecting the shared nature of the tunnel. 436 The source address of the tunnel MUST be the address that is used as 437 the destination address for the Binding Update messages sent by the 438 proxy mobile agent. 440 The home agent SHOULD use a Tunnel-Life timer for managing the tunnel 441 life time. The timer value should be set to the accepted binding 442 life time and must be updated after each periodic registration. The 443 tunnel should be deleted after the expiry of the timer. 445 The home agent SHOULD maintain a tunnel-user-count counter for each 446 managed tunnel and this counter should reflect the active mobiles 447 sharing the tunnel. When the tunnel is being used for routing 448 traffic to multiple mobiles attached to the same proxy mobile agent, 449 the home agent MUST set the Tunnel-Life timer value to the highest 450 binding life time across all the binding life time that is granted 451 for all the mobiles sharing that tunnel. 453 Some implementations MAY choose to statically pre-establish the 454 tunnels between the home agent and the proxy mobile agent and with 455 out having a need to create or tear down the tunnels dynamically on a 456 need basis. 458 5.3. Routing Considerations 460 This section describes how the data traffic to/from the mobile node 461 is handled at the home agent. The following entries explains the 462 routing state at the home agent when supporting 1.) Per-MN-Prefix 463 and 2.) Shared-Prefix addressing models. This section also covers 464 the routing states when supporting IPv4 home address allocation 465 support. 467 HAA - IPv6 global address that is configured on the home agent's 468 interface and is the address to where the proxy mobile agent 469 sent the binding update. This is one end-point of the tunnel. 471 CoA - IPv6 global address that is configured on the proxy mobile 472 agent's egress interface and is the registered care-of address 473 in the binding cache entry at the home agent. This is the 474 remote end point of the tunnel. 476 HoP - The IPv6 home prefix of the mobile. 478 HoA - The IPv6 home address of the mobile. This is the IPv6 global 479 address that the mobile obtained and configured on the remote 480 MN-AR link from its home prefix (HoP). 482 HoA_v4 - The IPv4 home address of the mobile. This is the IPv4 483 address that the mobile obtained, when functioning in the 484 dual-stack mode, and configured on the remote MN-AR link. 486 Per-MN-Prefix Addressing Model: 487 =============================== 488 HoP::/64 via tunnel0, next hop CoA 490 Shared-Prefix Addressing Model: 491 =============================== 492 HoA::/128 via tunnel0, next hop CoA 494 IPv4 Home Address support: 495 ========================== 496 HoA_v4/32 via tunnel0, next hop CoA 498 tunnel0: 499 ======== 500 Source: HAA 501 Destination: CoA 502 Tunnel Transport: IPv6 503 Tunnel Payload: IPv4, IPv6 505 The home agent functions as an anchor point for the mobile node's 506 home prefix. When the home agent receives a data packet from a 507 corresponding node, destined for the mobile node's home address, the 508 created routing state will forward the packet to the mobile node 509 through the bi-directional tunnel established between itself and the 510 serving proxy mobile agent. When the mobile is allocated a unique 511 and exclusive home prefix, the home agent will forward all packets 512 sent to that prefix through the tunnel to the proxy mobile agent, as 513 the prefix is hosted on the proxy mobile agent. 515 All the reverse tunneled packets that the home agent receives from 516 the tunnel, after removing the packet encapsulation will get routed 517 to the destination specified in the inner packet header. These 518 routed packets will have the source address field set to the mobile 519 node's home address. 521 5.4. Dynamic Home Agent Address Discovery Considerations 523 Dynamic Home Agent Address Discovery, as explained in Section 10.5 of 524 [RFC-3775], allows a mobile node to discover all the home agents on 525 its home link by sending ICMP Home Agent Address Discovery Request 526 message to the Mobile IPv6 Home-Agents anycast address, derived from 527 its home network prefix. 529 The Proxy Mobile IPv6 model assumes that the home agent address 530 information is pre-configured in the mobile's profile or it may 531 obtained through other means and all the network entities can obtain 532 this information. It is important to note that there is little value 533 in using DHAAD for discovering the home agent as the proxy mobile 534 agents at different access routers will not predictably be able to 535 locate the current serving home agent for a mobile. However, if 536 there is only one home agent on the home link, the proxy mobile agent 537 can use Dynamic Home Agent Address Discovery scheme for discovering 538 the home agent address. 540 When the mobile is configured with a shared Shared-Prefix addressing 541 model, the proxy mobile agent serving the mobile will be able to 542 discover the mobile's home agent by sending the ICMP Home Agent 543 Address Discovery Request message to the Mobile IPv6 Home-Agents 544 anycast address derived from its home prefix. The home agent on the 545 mobile's home link will receive these messages and will be able to 546 reply to this message. 548 When the mobile is configured with a unique Per-MN-Prefix addressing 549 model, the home agent is a topological anchor point for that prefix 550 and with the prefix being hosted on the link attached to the proxy 551 mobile agent. For the discovery scheme to work, the home agent MUST 552 be able to receive the ICMP discovery packets sent to the anycast 553 address derived from the mobile's home prefix. 555 5.5. Sequencing Number Considerations 557 Sequence number is typically used by two communication end points as 558 a means to establish order of the exchanged packets. Mobile IPv6 559 uses the Sequence Number field in the registrations messages. The 560 home agent and the mobile are required to manage this counter. 562 In Proxy Mobile IPv6, the Binding Update messages that the home agent 563 receives on behalf of a specific mobile, may not be from the same 564 proxy mobile agent and thus the sequence number value in these 565 messages will have little meaning and the home agent will not be 566 predictably order the messages and thus may end up processing an 567 older message while ignoring the latest binding update message. 569 In the Proxy Mobile IP model, where the ordering of packets have to 570 established when multiple senders are involved, sequence number 571 scheme in the absence of time context transfers will not work. A 572 global scale such as a time stamp is the right way to ensure order of 573 packets. This document proposes the use of time stamp in all the 574 Binding Update messages sent by proxy mobile agents. By leveraging 575 NTP [RFC-1305] service, all the entities in the Proxy Mobile IP 576 Network will be able to synchronize the clocks and a time stamp field 577 in the Binding Update message will enable the home agent to 578 predictable identify the latest messages from a list of messages 579 delivered in a out of order fashion. 581 The Proxy Mobile IP model, defined in this document requires the 582 Binding Update messages sent by the proxy mobile agent to have the 583 time stamp option. The home agent processing a proxy registration 584 MUST ignore the sequence number field and SHOULD use the value from 585 the Time Stamp option to establish ordering of the received Binding 586 Update messages. If the home agent receives a Binding Update message 587 with a invalid time stamp, the registration request MUST be rejected 588 and a Binding Acknowledgement must be sent with the status "Invalid 589 Time Stamp" and with the Time Stamp option. 591 5.6. IPv4 Home Address Mobility Support 593 The transition from IPv4 to IPv6 is a long process and during this 594 period of transition, both the protocols will be enabled over the 595 same infrastructure. It is reasonable to assume that the mobile node 596 and the home agent are IPv4 and IPv6 enabled and further it is also 597 reasonable to expect the same mobility infrastructure to provide IPv4 598 and IPv6 address mobility. The Proxy Mobile IPv6 scheme defined in 599 this document allows the mobile node to obtain a IPv4 address and to 600 roam in the network using the same address. 602 A mobile node attached to a proxy mobile agent, when it sends a DHCP 603 request, the network will ensure it gets a IPv4 address from its home 604 address prefix. The DHCP Relay Agent on the access router will tag 605 the DHCP request from the mobile node with its home prefix hint and 606 the DHCP server will allocate an address from that prefix. The proxy 607 mobile agent will send this information in the option, IPv4 Home 608 Network Prefix Option as part of the Binding Update message. Upon 609 accepting the registration for the mobile from the proxy mobile 610 agent, the home address will add IPv4 host route over the tunnel to 611 the proxy mobile agent. Any IPv4 packets that the home agent 612 receives from the corresponding node will be routed to the proxy 613 mobile agent over the IPv6/IPv6 tunnel and any IPv4 packets that it 614 receives over the tunnel will be routed after removing the tunnel 615 header. 617 5.7. Route Optimizations Considerations 619 Mobile IPv6 route optimization, as defined in [RFC-3775], enables a 620 mobile node to communicate with a corresponding node directly using 621 its care-of address and further the Return Routability procedure 622 enables the corresponding node to have reasonable trust that the 623 mobile node owns both the home address and care-of address. 625 In the Proxy Mobile IPv6 model, the mobile is not involved in any 626 mobility related signaling and also it does not operate in the dual- 627 address mode. Hence, the return routability procedure as defined in 628 RFC-3775 is not applicable for the proxy model. This document does 629 not address the Route Optimization problem and leaves this work item 630 for future enhancements. 632 This specification further recommends that the home agent MUST drop 633 all HoTI messages received from a home address that has corresponding 634 Binding Cache entry with the proxy registration flag set. 636 5.8. Mobile Prefix Discovery Considerations 638 The ICMP Mobile Prefix Advertisement message, described in Section 639 6.8 and Section 11.4.3 of [RFC-3775], allows a home agent to send a 640 Mobile Prefix Advertisement to the mobile node. 642 In Proxy Mobile IPv6 deployments, the mobile's home prefix 643 information would be typically configured in the mobile's profile and 644 so there is not much need for this dynamic nature of prefix 645 discovery. Thus, this specification does not support Mobile Prefix 646 Discovery. 648 5.9. Home Agent Operation Summary 650 After receiving a Proxy Binding Update request from a proxy mobile 651 agent on behalf of a mobile node, the home agent must process the 652 request as defined Section 10, of the base Mobile IPv6 specification 653 [RFC-3775], with one exception that this request is a proxy request 654 and proper authorization checks have to be enforced. 656 The home agent must use the NAI option present in the mobility header 657 of the Binding Update message for identifying the mobile and for 658 downloading the mobile's policy from the policy store. This policy 659 will contain the mobile's address configuration model, home prefix, 660 home address and other parameters. 662 The home agent has to verify the policy to ensure the proxy mobile 663 agent that is sending this request has the right to do so, else it 664 MUST reject the request and send a Proxy Binding Acknowledgment with 665 the proper status code. 667 The home agent MUST ignore the sequence number field in the Binding 668 Update for proxy registrations. 670 If the received Binding Update does not have a home network prefix 671 option and if there is no Binding Cache entry for that mobile node, 672 the home agent MUST reject the registration with 673 HOME_ADDRESS_REQUIRED status code. 675 Upon accepting this request, the home agent must create a Binding 676 Cache entry with the home address from the Home Network Prefix Option 677 in the Binding Update and must set up a tunnel to the proxy mobile 678 agent serving the mobile node. This bi-directional tunnel between 679 the home agent and the proxy mobile agent is used for routing the 680 mobile traffic. 682 For supporting this scheme, the home agent MUST satisfy all the 683 requirements listed in Section 8.4 of [1]. The key differences of 684 this scheme for the Per-MN-Prefix configuration mode, when compared 685 to the base protocol is as follows: 687 The mobile node is not anchored on any physical interface on the home 688 agent. Thus the home agent is not required to perform any proxy ND 689 operations for defending the home address on the home link. The home 690 agent is required to manage a binding cache entry for managing the 691 session state and a routing state for properly routing the packets 692 destined to the mobile node. 694 Each mobile node has a home address in a prefix that is created 695 exclusively for that mobile node and no other mobile node will share 696 its home address from this prefix. 698 The route entry specifying that the mobile node's home prefix is 699 reachable via the tunnel is created as supposed to creating an route 700 entry just for the mobile node's home address. 702 If multiple mobile stations are currently visiting the same proxy 703 mobile agent, all the binding updates will share the same care-of 704 address and possibly the same tunnel. 706 6. Proxy Mobile Agent Considerations 708 The Proxy Mobile IPv6 scheme introduces a new function, the Proxy 709 Mobile Agent (PMA). It is a function that runs on the access router 710 and is the entity that does the mobility related signaling on behalf 711 of the mobile node. 713 From the perspective of the home agent, the proxy mobile agent is a 714 special element in the network that sends Mobile IPv6 signaling 715 messages on behalf of a mobile station using its own identity. It is 716 the entity that binds the mobile node's home address to an address on 717 its own access interface. 719 The Proxy Mobile Agent has the following functional roles. It will 720 emulate the mobile node's home network on the access link, will 721 update the home agent about the current location of the mobile node 722 and sets up a data path for enabling the mobile node to use its home 723 address for communication from the access link. 725 This specification is independent of the underlying access technology 726 or the link model. The interface between the mobile and the access 727 router can be either: 729 o Point-to-Point Link 731 o Shared Link 733 This specification does not support split links. Also, it is to be 734 noted that from the current deployment perspective, Point-to-Point 735 link model appears to be the most common and required model. 737 6.1. Address Configuration Models 739 This specification supports the following address configuration 740 models: 742 o Per-MN-Prefix Model 744 o Shared-Prefix Model 746 In the Per-MN-Prefix model, there is a unique home prefix assigned 747 for each mobile node and that prefix is hosted on the access link. 748 The prefix just follows the mobile. In this addressing model, based 749 on the administrative policy, the mobile node can use either 750 Stateless Address Autoconfiguration or Statefull Address 751 Configuration using DHCP for obtaining the IPv6 address configuration 752 for its interface on the access link. Further, the mobile can also 753 generate interface identifiers with privacy considerations, as 754 specified in [RFC-3041]. 756 In the Shared-Prefix model, the prefix is a shared prefix and the 757 mobile is not the only node using an address from that prefix block. 758 In this addressing model, Stateless Address Autoconfiguration is not 759 supported by this specification. The mobile is allowed to use only 760 Statefull Address Configuration using DHCP for obtaining the address 761 configuration for its interface on the link. 763 The configured administrative policy for the mobile dictates the type 764 of addressing model that is supported for a mobile on the access 765 link. The proxy mobile agent on the access router will control this 766 by setting the relevant flags in the Router Advertisement 767 accordingly. 769 6.2. Access Authentication 771 Access authentication is outside scope of this document. This 772 specification does not deal with the access link security and further 773 assumes that there are proper authorization models in place for 774 ensuring only authorized nodes with their respective identities are 775 able to access the link. 777 Access authentication on any wireless access link, ensures a node 778 with a given MAC address and an Identifier such as NAI, is authorized 779 to use the link and the Layer-2 security ensures that. This 780 specification assumes such security mechanisms are in place. 782 6.3. Home Network Emulation 784 One of the key functions of the proxy mobile agent is to emulate the 785 mobile's home network on the access link. It has to ensure, the 786 mobile believes it is on its home link. After the access 787 authentication, the proxy mobile agent can obtain the mobile's 788 profile and from that it has to send the Router Advertisements to the 789 mobile advertising its home prefix and other parameters. Further if 790 the mobile uses statefull Address Configuration mode such as DHCP, 791 the proxy mobile agent or the DHCP Relay Agent [RFC-3315], MUST set 792 the link-address field of the DHCP request to the mobile's home 793 network prefix and the DHCP server will allocate an address from that 794 prefix block, as specified in Section 20.1.1 of [RFC-3315]. 796 If the access link is a point-to-point link, the advertisements from 797 the proxy mobile agent on that link are not seen by any other mobile 798 stations. However, if the access link is a shared link, the proxy 799 mobile agent has to ensure that each of the mobile node that is 800 attached to that link receive only their home prefixes as the on-link 801 prefixes. For this to happen, the proxy mobile agent MUST unicast 802 the Router Advertisement to the mobile node. The destination field 803 of the Layer-2 header in the Router Advertisement MUST be the 804 mobile's node's MAC address and however, the destination field in the 805 IPv6 header can be the all-nodes-multicast address. 807 6.4. Link-Local and Global Address Uniqueness 809 On a point-to-point link, when the mobile tries to establish a PPP 810 session [RFC-1661] with the access router, the PPP goes through the 811 Network layer Protocol phase and the IPv6 Control Protocol, IPCP6 812 [RFC-2472] gets triggered. Both the PPP peers negotiate a unique 813 identifier using Interface-Identifier option in IPV6CP and the 814 negotiated identifier is used for generating a unique link-local 815 address on that link. Now, if the mobile moves to a new access 816 router, the PPP session gets torn down and new PPP session with the 817 new access router will be established and the mobile obtains a new 818 link-local address. Now, even if the mobile is DNAv6 capable, as 819 specified in [draft-ietf-dna-protocol-03], the mobile still 820 configures a new link-local address when ever it moves to a new link. 822 However, if the link between the mobile node and the access router is 823 a shared link and if a DNAv6 capable mobile moves from access network 824 to the other, the mobile may not detect link change due to DNAv6 (how 825 ever this really depends on the wireless technology in use), 826 detecting the same link and there is a remote possibility for the 827 link local address collision on the new link. One of the work around 828 for this issue to the set following flag on the mobile, 829 DNASameLinkDADFlag to TRUE and that will force the mobile to redo DAD 830 operation even when the DNAv6 detected no link change. 832 For the global address or the home address uniqueness, the home agent 833 will not accept a Binding Update from a mobile, identified by a NAI, 834 for a home address that is already registered for some other mobile 835 station. Further, if the address configuration is based on statefull 836 Address Configuration using DHCP, the DHCP server will ensure the 837 uniqueness. 839 6.5. IPv4 Home Address Mobility Support 841 If the mobile node is permitted to roam using a IPv4 home address and 842 if the mobile has a dual-stack, the mobile can send a DHCP request 843 and can obtain the IPv4 address configuration for its interface. As 844 part of this configuration, the mobile node will obtain a IPv4 845 address, subnet address, subnet mask and default-router address. The 846 relay agent service on the access router will ensure the mobile node 847 is assigned an address from its home prefix, by marking the DHCP 848 request with the prefix hint. 850 However, the default-router address that is obtained from the DHCP 851 will be that of a router on its home link and the mobile node is on 852 the access link. In order for the mobile node to be able use the 853 default router for routing all IPv4 packets, the proxy mobile agent 854 on the access link must respond to the ARP requests from the mobile 855 node for the default-router's IPv4 address. Now, if the mobile roams 856 to a new link, the proxy mobile agent on that link must send a 857 gratuitous ARP for the mobile's default-router address. 859 In IPv6, the nodes on the link use the link-local address of the 860 default router for routing packets and it is not required that the 861 default router needs to have a configured address from the prefix 862 that the node uses. However, in IPv4, the default-router address on 863 the link must be from the same subnet as of the IP address of the 864 node. Since, the proxy mobile agent will not have an address on the 865 mobile's home prefix, it must act as a proxy for the mobile router's 866 IPv4 gateway address. 868 6.6. Tunnel Management 870 In the traditional Mobile IPv6 model, there is a separate tunnel from 871 the home agent to every mobile node that has a binding entry. The 872 tunnel end-point of each these tunnels is the respective mobile 873 node's care-of address and that is unique to that mobile node. In 874 the case of Proxy Mobile IPv6, the care-of address or the tunnel end- 875 point is the address of the proxy mobile agent and there could be 876 multiple mobile stations attached to the same proxy mobile agent and 877 hence the tunnel is a shared tunnel serving multiple mobile stations. 878 This is identical to the Mobile IPv4 model [RFC-3344], where a tunnel 879 between the foreign agent and the home agent is shared by many 880 visiting mobile nodes. 882 The life of the Proxy Mobile IP tunnel should not be based on a 883 single binding cache entry. The tunnel may get created as part of 884 creating a mobility binding for a mobile node and later the same 885 tunnel may be associated with other binding entries. So, the tearing 886 down logic of the tunnel must be based on the number of visitors over 887 that tunnel. Implementations are free to pre-establish tunnels 888 between every home agent and every proxy mobile node in the network 889 and with out creating and destroying the tunnels on a need basis. 891 6.7. Routing Considerations 893 This section describes how the data traffic to/from the mobile node 894 is handled at the proxy mobile agent. The following entries explains 895 the routing state at the proxy mobile agent. 897 HAA - IPv6 global address that is configured on the home agent's 898 interface and is the address to where the proxy mobile agent 899 sent the binding update. This is one end-point of the tunnel. 901 CoA - IPv6 global address that is configured on the proxy mobile 902 agent's egress interface and is the registered care-of address 903 in the binding cache entry at the home agent. This is the 904 remote end point of the tunnel. 906 HoP - The IPv6 home prefix of the mobile. 908 HoA - The IPv6 home address of the mobile. This is the IPv6 global 909 address that the mobile obtained and configured on the remote 910 MN-AR link from its home prefix (HoP). 912 HoA_v4 - The IPv4 home address of the mobile. This is the IPv4 913 address that the mobile obtained, when functioning in the 914 dual-stack mode, and configured on the remote MN-AR link. 916 Per-MN-Prefix Addressing Model: 917 =============================== 918 For all traffic from the source address HoA to 919 0::/0 route via tunnel0, next hop HAA 921 HoA::/64 is on the interface locally connected 923 Shared-Prefix Addressing Model: 924 =============================== 925 For all traffic from the source prefix HoA::/64 to 926 0::/0 route via tunnel0, next hop HAA 928 HoA::/128 is on the interface locally connected 930 IPv4 Home Address support: 931 ========================== 932 For all IPv4 traffic from the source address HoA_v4 to 933 0.0.0.0/0.0.0.0 route via tunnel0, next hop HAA 935 HoA_v4/32 is on the interface locally connected 937 tunnel0: 938 ======== 939 Source: CoA 940 Destination: HAA 941 Tunnel Transport: IPv6 942 Tunnel Payload: IPv4, IPv6 944 When the proxy mobile agent receives any packets from the mobile 945 station to any destination, the packet will be forwarded to the home 946 agent through the bi-directional tunnel established between itself 947 and the mobile's home agent. However, the packets that are sent with 948 link-local source address are not forwarded. 950 All the packets that the proxy mobile agent receives from the tunnel, 951 after removing the tunnel encapsulation, will get forwarded to the 952 mobile node on the connected interface. 954 6.8. Interaction with DHCP Relay Agent 956 If Statefull Address Configuration using DHCP is supported on the 957 access link, the DHCP Relay Agent [RFC-3315] needs to be configured 958 on the access router. When the mobile stations sends a DHCP Request, 959 the relay agent function on the access router must set the link- 960 address field in the DHCP message to the mobile node's home prefix, 961 so as to provide a prefix hint to the DHCP Server. On a point-to- 962 point link, this is just a normal DHCP relay agent configuration. 963 However, on the shared links supporting multiple mobile stations with 964 different home prefixes, there is some interaction required between 965 the relay agent and the proxy mobile agent, for setting the link- 966 address field to the requesting mobile node's home prefix. The proxy 967 mobile agent should also have the ability to learn the DHCP assigned 968 address to the mobile station. 970 If the mobile is permitted to roam using IPv4 home address, the 971 DHCPv4 relay agent service [RFC-2131] needs to be configured on that 972 link. Further, the giaddr field in the request packet must be set to 973 the mobile node's IPv4 home prefix. 975 6.9. Coexistence of CMIP & PMIP Nodes 977 In some operating environments, network operators may want to 978 provision a particular link attached to an access router running 979 proxy mobile agent for supporting nodes using Mobile IP signaling and 980 the nodes that depend on the network for doing the Mobile IP 981 signaling for achieving network mobility. This specification 982 supports links with such mixture of nodes. 984 Upon obtaining the mobile node's profile after a successful access 985 authentication and after a policy consideration, the proxy mobile 986 agent MUST determine if the network based mobility service should be 987 offered to that mobile node. If the mobile is entitled for such 988 service, then the network should ensure the mobile believes it is on 989 its home link, as explained in various sections of this document. 991 If the mobile is not entitled for the network based mobility service, 992 the proxy mobile agent MUST ensure the mobile can obtain an IPv6 993 care-of address using normal IPv6 address configuration mechanisms. 994 The obtained address should be from a local visitor network prefix. 995 In other words the mobile should be able to operate as a traditional 996 mobile node roaming in a visitor network and with the ability to 997 obtain a care-of address from the local visitor network prefix hosted 998 on that link. 1000 If the stateless address configuration mode is supported on that 1001 link, the prefix information option in the router advertisements 1002 should contain local visitor network prefix. If statefull address 1003 configuration mode is enforced on the link and if DHCP is in used, 1004 the mobile should obtain the IPv6 or IPv4 care-of address from the 1005 local visitor network prefix. 1007 If the link between the access router and the mobile node is a shared 1008 link, the Router Advertisement has to unicasted to the mobile station 1009 with the destination address in the layer-2 header set to the 1010 mobile's MAC address and the destination address in the IPv6 header 1011 set to the all-nodes multicast address. 1013 6.10. Proxy Mobile Agent Operation Summary 1015 After detecting a new mobile node on its access link and after a 1016 successful access authentication, the proxy mobile agent using the 1017 mobile's identifier will obtain the mobile's profiles from the policy 1018 store. The mobile's policy can also be pushed to the proxy mobile 1019 agent using context transfer procedure. Context Transfer is out of 1020 scope for this current specification. The mobile's profile contains 1021 the mobile node's home agent address, home prefix, addressing model, 1022 permitted address configuration mechanisms and other parameters that 1023 are needed to emulate the mobile's home network on the access 1024 network. 1026 The proxy mobile agent constructs a Router Advertisement containing 1027 the mobile's home prefix and it will send it to the mobile node. If 1028 the link between the mobile node and the access router is a shared 1029 link, then the Router Advertisement will be unicasted to the mobile 1030 station by setting the destination address in the layer-2 header to 1031 the mobile's MAC address and the destination address in the IPv6 1032 header set to the all-nodes multicast address. 1034 The proxy mobile agent sends a Proxy Binding Update to the home 1035 agent. The source address of this message will be the configured 1036 IPv6 address on the egress interface. The contents of the message 1037 include the Mobile Node NAI Option, Home Network Prefix Option, IPv4 1038 Home Address Option and Time Stamp Option. This message will be 1039 protected by using IPSec security association created between the 1040 proxy mobile agent and home agent. 1042 If the mobile is configured for the Per-MN-Prefix model, the proxy 1043 mobile agent will set the Home Network Prefix Option to the mobile's 1044 home network that is learnt from the mobile's profile. The home 1045 agent sets up a route for the whole prefix and there is no MUST 1046 requirement that the mobile's home address is associated in the BCE 1047 at the home agent. However, if the proxy mobile agent predictably 1048 learns the address that the mobile is using from its home prefix, it 1049 is recommended that the Home Network Prefix Option be set with the 1050 specific home address, so that the Binding Cache entry on the home 1051 agent will have a reachable address for the mobile. 1053 If the mobile is configured for Per-MN-Address model, the proxy 1054 mobile agent must set the Home Network Prefix Option to the DHCP 1055 assigned address for that mobile. It is possible, the mobile is 1056 DNAv6 capable and after attaching to a new link, it never initiates a 1057 DHCP request. In that situation, the proxy mobile agent must send 1058 the Binding Update with out the Home Network Prefix option and the 1059 home agent will send the mobile's home address in Binding 1060 Acknowledgement message, if there is a Binding Cache entry for that 1061 mobile, else it will reject the Binding Update and the proxy mobile 1062 agent must wait till the mobile triggers the DHCP for address 1063 configuration. 1065 After receiving a Proxy Binding Acknowledgment with the status code 1066 indicating the acceptance of the Binding Acknowledgment, the proxy 1067 mobile agent MUST setup a tunnel to the home agent, as explained in 1068 the above sections. 1070 If the home agent denies the Proxy Binding Update request, the proxy 1071 mobile agent MUST NOT advertise the mobile node's home prefix on the 1072 link and there by denying the mobility service to the mobile station. 1074 At any point, if the proxy mobile agent detects that the mobile node 1075 has roamed away from its home link, it MUST send a Binding Update to 1076 the home agent with the lifetime value of 0 and it must remove the 1077 route over the tunnel for that mobile and also delete the tunnel if 1078 no other mobile traffic route is setup over that tunnel. 1080 6.11. Conceptual Data Structures 1082 Every proxy mobile agent maintains a Binding Update List for each 1083 currently registered visitor. The Binding Update List is a 1084 conceptual data structure, described in Section 11.1 [RFC-3775]. For 1085 supporting this specification, the conceptual Binding Update List 1086 must be extended with the following new fields. 1088 o The Identifier of the mobile node in the form of NAI. This is 1089 obtained as part of the Access Authentication procedure. This 1090 identifier is required for downloading the mobile node's profile 1091 from the policy store. 1093 o A flag specifying whether or not the configured addressing model 1094 for the mobile is Per-MN-Prefix model. If the flag is not set, 1095 indicates the configured addressing model is a Shared-Prefix 1096 model. 1098 o The link-local address of the mobile node on the link. This 1099 address is learned through the Source Address of the Router 1100 Solicitation messages received from the mobile node on the link. 1102 o The IPv4 home address of the mobile, if IPv4 home address mobility 1103 is supported. 1105 o The IPv4 home network prefix length of the mobile, if IPv4 home 1106 address mobility is supported. 1108 o The IPv4 default router address of the mobile, if IPv4 home 1109 address mobility is supported. This is the address that is 1110 configured on the home agent. 1112 7. Mobile Node Considerations 1114 The Proxy Mobile IPv6 scheme, defined in this document, enables a 1115 mobile node to achieve network mobility with out requiring its 1116 participation in any mobility related signaling. The specification 1117 assumes the mobile node is a IPv6 host, and optionally IPv4 capable, 1118 if it is operating as a dual-stack node. 1120 Once the mobile enters a Proxy Mobile IPv6 domain and attaches to an 1121 access network, the network identifies the mobile as part of the 1122 access authentication procedure and ensures the mobile using any of 1123 the address configuration mechanisms permitted by the network for 1124 that mobile, will be able to obtain an address and move anywhere in 1125 that managed domain. From the perspective of the mobile, the entire 1126 Proxy Mobile IPv6 domain appears as a single link, the network 1127 ensures the mobile believes it is always on its home link. If the 1128 mobile is Mobile IPv6 client, as per [RFC-3775], the mobile will not 1129 detect movement and hence it will not trigger the Mobile IPv6 1130 registrations. 1132 7.1. Booting in the Proxy Mobile IPv6 Network 1134 When the mobile node attaches to a link on the access router running 1135 proxy mobile agent, it will present its identity to the network in 1136 the form of NAI as part of the access authentication procedure. 1137 After performing the required access authentication procedures, the 1138 network knows the mobile's home prefix, address configuration models 1139 and other parameters. 1141 After a successful access authentication, the mobile node will send a 1142 Router Solicitation message. The proxy mobile agent on the link will 1143 respond to the Router Solicitation message with a Router 1144 Advertisement. The Router Advertisement will have the mobile node's 1145 home prefix, default router and other address configuration 1146 parameters. The address configuration parameters such as Managed 1147 Address Configuration, statefull Configuration flag values will be 1148 consistent with the home link policy. 1150 If the Router Advertisement has the Managed Address Configuration 1151 flag set, the mobile node, as it would normally do, will send a DHCP 1152 Request and again the proxy mobile agent on that link will ensure, 1153 the mobile node gets its home address as a lease from the DHCP 1154 server. 1156 If the Router Advertisement does not have the Managed Address 1157 Configuration flag set, the mobile node can autoconfigure itself by 1158 appending its link-layer address (EUI-64 format) to the advertised 1159 local home network prefix or it can configure an address per [RFC- 1160 3041] specification. 1162 Once the address configuration is complete, the mobile node will 1163 always be able to use that IPv6/IPv4 address anywhere with in that 1164 managed network where proxy mobile agents are deployed. Further, the 1165 mobile node will always get the same Address even after a reboot. 1167 7.2. Roaming in the Proxy Mobile IPv6 Network 1169 After booting in the network and obtaining a IPv6 and possibly IPv4 1170 address as well (if the network supports dual-stack mode), the mobile 1171 when it moves from one access network to the other in that Proxy 1172 Mobile IP domain, will always detect its home link, home prefix and 1173 obtains the same IPv6/IPv4 address, if it uses DHCP for address 1174 configuration. However, the mobile always detects a new default- 1175 router on the new link advertising its home prefix and with a 1176 different link-local address. Any Router Solicitation messages from 1177 the mobile node will result in a Router Advertisement advertising its 1178 home prefix, default router and other configuration parameters 1179 consistent with the home link properties. 1181 7.3. IPv6 Host Protocol Parameters 1183 This specification assumes the mobile node to be a normal IPv6 host, 1184 with its protocol operation consistent with the base IPv6 1185 specification [RFC-2460]. All aspects of Neighbor Discovery 1186 Protocol, including Router Discovery, Neighbor Discovery, Address 1187 Configuration procedures will just remain consistent with the base 1188 IPv6 Neighbor Discovery Specification [RFC-2461]. However, the 1189 protocol RECOMMENDS the mobile station to adjust the following IPv6 1190 operating parameters to the below recommended values for protocol 1191 efficiency and for achieving faster hand-offs. 1193 Lower Default Router List Cache Time-out: 1195 As per the base IPv6 specification [RFC-2460], each IPv6 host will 1196 maintain certain host data structures including a Default Router 1197 list. This is the list of on-link routers that have sent Router 1198 Advertisement messages and are eligible to be a default routers on 1199 that link. The Router Lifetime field in the received Router 1200 Advertisement defines the life of this entry. 1202 In the Proxy IPv6 scenario, when the mobile node moves from one link 1203 to another, the received Router Advertisement messages advertising 1204 the mobile's home prefix on the new access link are from a different 1205 link-local address and thus making the mobile believe that there is a 1206 new default router on the link. It is important that the mobile node 1207 uses the newly learnt default router as supposed to the previous 1208 learnt default router. The mobile node must update its default- 1209 router list with the new default router entry and must age out the 1210 previously default router entry from its cache, just as specified in 1211 Section 6.3.5 of the base IPv6 ND specification [1]. This action is 1212 critical for minimizing packet losses during a hand off switch. 1214 On detecting a reachability problem, the mobile node will certainly 1215 detect the neighbor or the default router unreachability by 1216 performing a Neighbor Unreachability Detection procedure, but it is 1217 important that the mobile node times out the previous default router 1218 entry at the earliest. If a given IPv6 host implementation has the 1219 provision to adjust these flush timers, still conforming to the base 1220 IPv6 ND specification, it is desirable to keep the flush-timers to 1221 suit the above consideration. 1223 However, if the proxy mobile agent has the ability to with draw the 1224 previous router entry, by multicasting a Router Advertisement using 1225 the link-local address that of the previous mobility proxy agent and 1226 with the Router Lifetime field set to zero, then it is possible to 1227 force the flush out of the Previous Default Router entry from the 1228 mobile node's cache. This certainly requires the proxy mobile agent 1229 to notify its link-local address to the home agent as part of the 1230 binding update and the home agent to associate this opaque data with 1231 the binding cache entry so that a new proxy mobile agent can learn 1232 the link-local address of the previous router and send a Router 1233 Advertisement with that link-local address. 1235 There are other solutions possible for this problem, including the 1236 assignment of a unique link-local address for all the access routers 1237 in the Proxy Mobile IP Network. In either case, this is an 1238 implementation choice and has no bearing on the protocol 1239 interoperability. Implementations are free to adopt the best 1240 approach that suits their target deployments. 1242 8. Message Formats 1244 This section defines extensions to the Mobile IPv6 [RFC-3775] 1245 protocol messages. 1247 8.1. Proxy Binding Update 1249 0 1 2 3 1250 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 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | Sequence # | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 |A|H|L|K|M|R|P| Reserved | Lifetime | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | | 1257 | | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 Figure 8: Proxy Binding Update Message 1262 A new flag, the 'P' flag, is added to the Binding Update message 1263 [RFC-3775]. The 'P' flag indicates that the registration is a Proxy 1264 Registration. When a proxy mobile agent sends a registration to the 1265 home agent, the P flag MUST be set to value of 1, to indicate to the 1266 home agent that this registration is a proxy registration sent by a 1267 proxy mobile agent on behalf of a mobile node. 1269 For descriptions of other fields present in this message, refer to 1270 [RFC3775]. 1272 A Binding Update message that is sent by proxy mobile agent is also 1273 referred to as "Proxy Binding Update". 1275 8.2. Proxy Binding Acknowledgment 1277 0 1 2 3 1278 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 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 | Status |K|R|P|Reserved | 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 | Sequence # | Lifetime | 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 | | 1285 | | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 Figure 9: Proxy Binding Acknowledgment Message 1290 Proxy Registration Flag (P) 1292 A new flag, the 'P' flag, is added to the Binding Acknowledgement 1293 message [RFC-3775]. The Proxy Registration Flag is set to a value of 1294 1, to indicate that the home agent that processed the Proxy Binding 1295 Update supports Proxy Registration. This flag value is set only if 1296 the corresponding Proxy Binding Update had the Proxy Registration 1297 Flag set. 1299 For descriptions of other fields present in this message, refer to 1300 [RFC3775]. 1302 A Binding Acknowledgment message that is sent by proxy mobile agent 1303 is also referred to as "Proxy Binding Acknowledgement". 1305 8.3. Home Network Prefix Option 1307 A new option, Home Network Prefix Option is defined for using it in 1308 the Proxy Binding Update and Acknowledgment messages exchanged 1309 between the home agent to the proxy mobile agent. This option can be 1310 used for exchanging the mobile node's home prefix and home address 1311 information. 1313 The home network prefix Option has an alignment requirement of 8n+4. 1314 Its format is as follows: 1316 0 1 2 3 1317 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 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 | Type | Length | Reserved | Prefix Length | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 | | 1322 + + 1323 | | 1324 + Local Network Prefix + 1325 | | 1326 + + 1327 | | 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 Type 1331 1333 Length 1335 Eight-bit unsigned integer indicating the length in octets of 1336 the option, excluding the type and length fields. Set to 18. 1338 Reserved 1340 This field is unused for now. The value MUST be initialized 1341 to 0 by the sender and MUST be ignored by the receiver. 1343 Prefix Length 1345 Eight-bit unsigned integer indicating the prefix length of 1346 the IPv6 prefix contained in the option. If the prefix length 1347 is set to the value 128, indicates the presence of the 1348 mobile's home address. 1350 Home Network Prefix 1352 A sixteen-byte field containing the Home Network Prefix 1354 Figure 10: Home Network Prefix Option 1356 8.4. Time Stamp Option 1358 A new option, Time Stamp Option is defined for use in Proxy Binding 1359 Update and Acknowledgement messages. This option MUST be present in 1360 all Proxy Binding Update and Acknowledgement messages. 1362 0 1 2 3 1363 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 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | Option Type | Option Length | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | | 1368 + Timestamp + 1369 | | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 Type 1373 1375 Length 1377 Eight-bit unsigned integer indicating the length in octets of 1378 the option, excluding the type and length fields. Set to 18. 1380 Timestamp 1382 64bit time stamp 1384 Figure 11: Time Stamp Option 1386 8.5. Status Codes 1388 Binding Acknowledgment Status Values 1390 The following status code values are defined for using them in the 1391 Binding Acknowledgment message when using PMIPv6 protocol. 1393 145: Proxy Registration not supported by the home agent 1395 146: Proxy Registrations from this proxy mobile agent not allowed 1397 147: No home address for this NAI is configured and the Home Network 1398 Prefix Option not present in the Binding Update. 1400 148: Invalid Time Stamp Option in the Binding Update 1401 Status values less than 128 indicate that the Binding Update was 1402 processed successfully by the receiving nodes. Values greater than 1403 128 indicate that the Binding Update was rejected by the Home Agent. 1405 The value allocation for this usage needs to be approved by the IANA 1406 and must be updated in the IANA registry. 1408 9. IANA Considerations 1410 This document defines a new Mobility Header Option, the Mobile Home 1411 Network Prefix Option. This option is described in Section 8.3. The 1412 Type value for this option needs to be assigned from the same 1413 numbering space as allocated for the other mobility options defined 1414 in [RFC-3775]. 1416 This document defines a new Mobility Header Option, the Time Stamp 1417 Option. This option is described in Section 8.4. The type value for 1418 this option needs to be assigned from the same numbering space as 1419 allocated for the other mobility options defined in [RFC-3775]. 1421 This document also defines new Binding Acknowledgement status values 1422 as described in Section 8.5. The status values MUST be assigned from 1423 the same space used for Binding Acknowledgement status values in 1424 [RFC-3775]. 1426 10. Security Considerations 1428 The Mobile IPv6 base specification [RFC-3775] requires the signaling 1429 messages between the home agent and the mobile node to be secured by 1430 the use of IPsec extension headers. 1432 This document introduces a new functional entity, proxy mobile agent, 1433 a function that will be implemented in the access routers. This 1434 entity is responsible for performing the Mobile IPv6 signaling on 1435 behalf of the mobile node, also called as Proxy Mobile IPv6 1436 Signaling. 1438 All signaling messages between the Proxy Mobile Agent and the Home 1439 Agent MUST be authenticated by IPsec [RFC-4301]. The use of IPsec to 1440 protect Mobile IPv6 signaling messages is described in detail in the 1441 HA-MN IPsec specification [RFC-3776]. The signaling messages 1442 described in this document just extend Mobile IPv6 messages and just 1443 requires some subtle changes to what is described in the HA-MN IPSec 1444 specification. 1446 As described in the base Mobile IPv6 specification [RFC-3775], 1447 Section 5.1 both the mobile client (in this case, its the proxy 1448 mobile agent) and the home agent MUST support and SHOULD use the 1449 Encapsulating Security Payload (ESP) header in transport mode and 1450 MUST use a non-NULL payload authentication algorithm to provide data 1451 origin authentication, data integrity and optional anti-replay 1452 protection. 1454 This document does not cover the security requirements for 1455 authorizing the mobile node for the use of the access link. It is 1456 assumed that there are proper Layer-2 based authentication 1457 procedures, such as EAP, in place and will ensure the mobile node is 1458 properly identified and authorized before permitting it to access the 1459 network. It is further assumed that the same security mechanism will 1460 ensure the mobile session is not hijacked by malicious nodes on the 1461 access link. 1463 The proxy solution allows one device creating a routing state for 1464 some other device at the home agent. It is important that the home 1465 agent has proper authorization services in place to ensure a given 1466 proxy mobile agent is permitted to be a proxy for a specific mobile 1467 node. If proper security checks are not in place, a malicious node 1468 may be able to hijack a session or may do a denial-of-service 1469 attacks. 1471 11. Acknowledgements 1473 The authors would like to thank Julien Laganier, Alex Petrescu, Brian 1474 Haley, Ahmad Muhanna, Mohamed Khalil, Fred Templing, Nishida 1475 Katsutoshi, James Kempf, Vidya Narayanan, Henrik Levkowetz, Phil 1476 Roberts, Jari Arkko, Ashutosh Dutta, Hesham Soliman and many others 1477 for their passionate discussions in the working group mailing list on 1478 the topic of Proxy Mobile IPv6 and NETLMM. These discussions 1479 stimulated much of the thinking and shaped the draft to the current 1480 form. We acknowledge that ! The authors would also like to thank 1481 Ole Troan, Akiko Hattori and Perviz Yegani for their input on this 1482 document. 1484 12. References 1485 12.1. Normative References 1487 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1488 Specification, Implementation", RFC 1305, March 1992. 1490 [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1491 (IPv6) Specification", RFC 2460, December 1998. 1493 [RFC-2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 1494 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 1496 [RFC-2462] Thompson, S., Narten, T., "IPv6 Stateless Address 1497 Autoconfiguration", RFC 2462, December 1998. 1499 [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1500 IPv6 Specification", RFC 2473, December 1998. 1502 [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 1503 M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1504 RFC 3315, July 2003. 1506 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 1507 IPv6", Work in Progress. 1509 [RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1510 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", 1511 RFC 3776, June 2004. 1513 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1514 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, 1515 November 2005. 1517 [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the 1518 Internet Protocol", RFC 4301, December 2005. 1520 [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC 1521 2406, December 2005. 1523 [RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2) 1524 Protocol", RFC 4306, December 2005. 1526 [draft-ietf-netlmm-nohost-req-05.txt] Kempf, J., Leung, K., Roberts, 1527 P., Nishida, K., Giaretta, G., Liebsch, M., "Goals for Network-based 1528 Localized Mobility Management", October 2006. 1530 [draft-ietf-netlmm-nohost-ps-05.txt] Kempf, J., Leung, K., Roberts, 1531 P., Nishida, K., Giaretta, G., Liebsch, M., "Problem Statement for 1532 Network-based Localized Mobility Management", September 2006. 1534 [draft-ietf-netlmm-threats-04.txt] Vogt, C., Kempf, J., "Security 1535 Threats to Network-Based Localized Mobility Management", September 1536 2006. 1538 12.2. Informative References 1540 [RFC-1332] McGregor, G., "The PPP Internet Protocol Control Protocol 1541 (IPCP)", RFC 1332, May 1992. 1543 [RFC-1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 1544 51, RFC 1661, July 1994. 1546 [RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", RFC 1547 2472, December 1998. 1549 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1550 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1552 [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for 1553 Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1555 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1556 August 2002. 1558 [RFC-3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1559 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 1561 [draft-ietf-dna-protocol-03] Kempf, J., et al "Detecting Network 1562 Attachment in IPv6 Networks (DNAv6)", draft-ietf-dna-protocol-03, 1563 October 2006. 1565 [draft-ietf-mip6-ikev2-ipsec-08] Devarapalli, V. and F. Dupont, 1566 "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture" 1567 December 2006. 1569 Authors' Addresses 1571 Sri Gundavelli 1572 Cisco Systems 1573 170 West Tasman Drive 1574 San Jose, CA 95134 1575 USA 1577 Email: sgundave@cisco.com 1579 Kent Leung 1580 Cisco Systems 1581 170 West Tasman Drive 1582 San Jose, CA 95134 1583 USA 1585 Email: kleung@cisco.com 1587 Vijay Devarapalli 1588 Azaire Networks 1589 4800 Great America Pkwy 1590 Santa Clara, CA 95054 1591 USA 1593 Email: vijay.devarapalli@azairenet.com 1595 Kuntal Chowdhury 1596 Starent Networks 1597 30 International Place 1598 Tewksbury, MA 1600 Email: kchowdhury@starentnetworks.com 1602 Intellectual Property Statement 1604 The IETF takes no position regarding the validity or scope of any 1605 Intellectual Property Rights or other rights that might be claimed to 1606 pertain to the implementation or use of the technology described in 1607 this document or the extent to which any license under such rights 1608 might or might not be available; nor does it represent that it has 1609 made any independent effort to identify any such rights. Information 1610 on the procedures with respect to rights in RFC documents can be 1611 found in BCP 78 and BCP 79. 1613 Copies of IPR disclosures made to the IETF Secretariat and any 1614 assurances of licenses to be made available, or the result of an 1615 attempt made to obtain a general license or permission for the use of 1616 such proprietary rights by implementers or users of this 1617 specification can be obtained from the IETF on-line IPR repository at 1618 http://www.ietf.org/ipr. 1620 The IETF invites any interested party to bring to its attention any 1621 copyrights, patents or patent applications, or other proprietary 1622 rights that may cover technology that may be required to implement 1623 this standard. Please address the information to the IETF at 1624 ietf-ipr@ietf.org. 1626 Disclaimer of Validity 1628 This document and the information contained herein are provided on an 1629 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1630 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1631 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1632 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1633 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1634 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1636 Copyright Statement 1638 Copyright (C) The Internet Society (2007). This document is subject 1639 to the rights, licenses and restrictions contained in BCP 78, and 1640 except as set forth therein, the authors retain all their rights. 1642 Acknowledgment 1644 Funding for the RFC Editor function is currently provided by the 1645 Internet Society.