idnits 2.17.1 draft-seite-netext-dma-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 19, 2010) is 5088 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-liu-distributed-mobility-01 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Seite 3 Internet-Draft P. Bertin 4 Intended status: Informational France Telecom - Orange 5 Expires: November 20, 2010 May 19, 2010 7 Dynamic Mobility Anchoring 8 draft-seite-netext-dma-00.txt 10 Abstract 12 Most existing IP mobility solutions are derived from Mobile IP 13 principles where a given mobility anchor maintains Mobile Nodes (MNs) 14 binding up-to-date. Data traffic is then encapsulated between the 15 mobility anchor and the MN or its Access Router. These approaches 16 are usually implemented on a centralised architectures where both MN 17 context and traffic encapsulation need to be processed at a central 18 network entity, i.e. the mobility anchor. However, one of the trend 19 in mobile network evolution is to "flatten" mobility architecture by 20 confining mobility support in the access network, e.g. at the access 21 routers level, keeping the rest of the network unaware of the 22 mobility events and their support. This document discusses the 23 deployment of a Proxy Mobile IP approach in such a flat architecture. 24 The solution allows to dynamically distribute mobility functions 25 among access routers. The goal is also to dynamically adapt the 26 mobility support of the MN's needs by applying traffic redirection 27 only to MNs' flows when an IP handover occurs. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 20, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Use-case and requirements . . . . . . . . . . . . . . . . . . 5 78 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 7 79 4.1. Dynamic Mobility Anchoring . . . . . . . . . . . . . . . . 7 80 4.2. Protocol sequence for handover management . . . . . . . . 8 81 4.3. Difference with Proxy Mobile IPv6 . . . . . . . . . . . . 10 82 4.4. IP flow mobility support . . . . . . . . . . . . . . . . . 11 83 5. Implementation feedback . . . . . . . . . . . . . . . . . . . 13 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 92 1. Terminology 94 Proxy Mobile IPv6 inherited terminology 96 The following terms used in this document are to be interpreted as 97 defined in the Proxy Mobile IPv6 specification [RFC5213]; Mobile 98 Node (MN), Home Network Prefix (HNP), Mobile Node Identifier (MN- 99 Identifier), Proxy Binding Update (PBU), and Proxy Binding 100 Acknowledgement (PBA). 102 Mobility capable Access Router (MAR) 104 The Mobility capable Access Router is an access router which 105 provides mobility management functions. It has both mobility 106 anchoring and location update functional capabilities. A Mobility 107 capable Access Router can act as a Home or as a Visited Mobility 108 capable Access Router (respectively H-MAR and V-MAR). Any given 109 MAR could act both as H-MAR and V-MAR for a given mobile node 110 having different HNPs, either allocated by this MAR (H-MAR role) 111 or another MAR on which the mobile node was previously attached 112 (V-MAR role). 114 * H-MAR: it allocates HNP for mobile nodes. Similarly to 115 [RFC5213], the H-MAR is the topological anchor point for the 116 mobile node's home network prefix(es) it has allocated. The 117 H-MAR acts as a regular IPv6 router for HNPs it has allocated, 118 and when a mobile node has moved away and attached to a V-MAR, 119 the H-MAR is responsible for: tracking the mobile node location 120 (i.e. the V-MAR where the mobile node is currently attached), 121 and forwarding packets to the V-MAR where the mobile node is 122 attached. 123 * V-MAR: it manages the mobility-related signaling for a mobile 124 node, using a HNP allocated by a MAR previously visited by the 125 mobile node, that is attached to its access link. 127 2. Introduction 129 Most existing IP mobility solutions are derived from Mobile IP 130 [RFC3775] principles where a given mobility agent (e.g. the Home 131 Agent (HA) in Mobile IP or the Local Mobility Agent (LMA) in Proxy 132 Mobile IPv6 [RFC5213]) maintains Mobile Nodes (MNs) bindings. Data 133 traffic is then encapsulated between the MN or its Access Router 134 (e.g. the Mobile Access Gateway (MAG) in PMIPv6) and its mobility 135 agent. These approaches lead to the implementation of centralised 136 architectures where both MN context and traffic encapsulation need to 137 be maintained at a central network entity, the mobility agent. Thus, 138 when hundreds of thousands of MNs are communicating in a given 139 cellular network, such a centralised network entity causes well-known 140 bottlenecks and single point of failure issues, which requires costly 141 network dimensioning and engineering to be fixed. In addition, 142 tunnelling encapsulations impact the overall network efficiency since 143 they require the maintenance of MN's specific contexts in each tunnel 144 end nodes and they incur delays in packet processing and transport 145 functions. Such centralised approach provides the ability to route 146 MN traffic whatever its localisation is, as well as to support 147 handovers when it moves from access router to access router. 149 It is however well established that a huge amount of mobile 150 communications are set up while the user is not physically moving, 151 i.e. its MN stays in the same radio cell. For example, the user is 152 being communicating at home, in his office, at a cafe... Applying 153 the aforementioned centralised principles leads then to aggregate 154 user's contexts and traffic at a central node in the network for the 155 sake of mobility support whereas the MN remains motionless. As this 156 leads to the introduced scalability and performances issues, 157 alternative approaches may consider a way to better adapt mobility 158 support in the network to cope with MN's movements and its ongoing 159 traffic flows' requirements. Typically, one of the trend in the 160 evolution of mobile networks is to go on flat architecture with the 161 distribution of network functions, including mobility functions 162 [I-D.liu-distributed-mobility]. According to this principle, 163 [I-D.chan-netext-distributed-lma] proposes a deployment of Proxy 164 Mobile IPv6 in a flat architecture by splitting the location 165 management and routing functions of the LMA. 167 In this document, we propose a slightly different approach by 168 dynamically distributing mobility handling among terminals and access 169 routers. This document inherits from concepts introduced in 170 [NTMS2008]. Our goal is twofold: 171 o dynamically adapting mobility support to each of the MN's needs by 172 applying traffic redirection only to MNs' flows that are already 173 established when an IP handover occurs; 174 o confining the mobility support at the access routers level, 175 keeping the rest of the network unaware of mobility events and 176 their support. 178 3. Use-case and requirements 180 In a standard IPv6 network without specific mobility support, any 181 host is able to set up communications flows using a global IPv6 182 address acquired with the support of its current access router 183 [RFC4862]. When the host moves from this access router to a new one, 184 its ongoing IP sessions cannot be maintained without leveraging on IP 185 mobility mechanisms. 187 However, once attached to the new access router, the host can again 188 acquire a routable global IPv6 address to be used for any new 189 communication flow it sets up. Hence, a flow based mobility support 190 may be restricted to provide traffic indirection to host's flows that 191 are already ongoing during host's handovers between access routers. 192 Any new flow being set up uses the new host's global address acquired 193 on the new link available after the handover. 195 When a multiple-interface host moves between access routers of 196 different access technologies, such a simple approach can also be 197 applied, considering that each network interface provides dynamically 198 global IPv6 addresses acquired on current access routers. Flows 199 mobility is then required only to support the necessary traffic 200 indirection from the access router on which the flow has been 201 initially set up to the access router the host is currently attached. 202 Such IP based indirection can even be made independent from access 203 technologies types, providing thus inherent inter-access mobility 204 facilities. 206 Based on these considerations, IP flow mobility relies on the dynamic 207 provision of flow based traffic indirection between access routers. 208 Hence, any given IP flow can be considered as implicitly anchored on 209 the current MN's access router when being set up. While the MN is 210 attached to its initial access router, the IP flow is delivered as 211 for any standard IPv6 node. The anchoring function at the access 212 router is thus needed only to manage traffic indirection if the MN 213 moves to a new access router (and for subsequent movements while the 214 IP flow remains active), maintaining the flow communication until it 215 ends up. 217 Any flow's incoming packet toward the MN is routed in a standard way 218 to the access router anchoring the flow as the packet contains the 219 destination IP address issued from router prefix. Then, if the MN is 220 currently attached to the initial anchor access router, the incoming 221 packet is directly delivered over the access link. Otherwise, the 222 anchoring access router needs to redirect the packet to the current 223 (or one of the currents) MN's access router(s). 225 Any flow's outgoing packet from the MN is sent over either the 226 initial anchor access router link or another access router link it is 227 currently using. In the first case, the packet can be routed in a 228 standard way, i.e., without requiring networks mobility support 229 functions. In the second case, we consider its redirection to the 230 initial flows' anchor router, but it may be noticed that direct 231 routing by the current access router may be also allowed (yet this 232 may lead to more stringent security and policy considerations). 234 4. Solution Overview 236 4.1. Dynamic Mobility Anchoring 238 The basic idea is to distribute mobility traffic management with 239 dynamic user's traffic anchoring in access network nodes. The 240 solution relies on a very simple flat architecture outlined in 241 Figure 1 where the Mobility capable Access Router (MAR) supports both 242 traffic anchoring and MN's location management functionalities. The 243 idea is that regular IPv6 routing applies when an IP communication is 244 initiated. For instance, if the mobile node (e.g. MN1), being 245 attached to MAR1, initiates a communication with CN1, the traffic 246 will be routed through MAR1 without requiring any specific mobility 247 operation. When MN1 moves away from MAR1 and attaches to MAR3, the 248 traffic remains anchored to MAR1 and is tunneled between MAR1 and 249 MAR3. MAR1 becomes the mobility anchor, but only for traffic 250 initiated by MN1 when it was attached to MAR1. 252 Communications newly initiated, e.g. to CN2, while the mobile node is 253 attached to MAR3 will be routed in a standard way via MAR3. So, MAR3 254 is both the mobility anchor, i.e. the H-MAR, for traffic newly 255 initiated (i.e. when the mobile node is attached to MAR3) and the 256 V-MAR for traffic initiated while being attached to MAR1. If the 257 mobile node moves away from MAR3, while maintaining communications 258 with both CN1 and CN2, two mobility anchors come into play: the data 259 traffic will be anchored in MAR1 for communication with CN1 and in 260 MAR3 for communication with CN2. 262 Summarizing the above mechanism, it is proposed to locate mobility 263 anchoring for the same mobile node depending on where the flow is 264 initially created. Accordingly, communications are expected to be 265 initiated without requiring mobility anchoring and tunneling. 267 With this solution, even if a mobile node is moving across several 268 MARs, the tunnel endpoints are always on the initial H-MAR and on the 269 current V-MAR. In the case the mobile node moves from MAR1 to MAR2 270 then to MAR3, a tunnel will be firstly established between MAR1 and 271 MAR2 to forward HNP1; then a tunnel between MAR1 and MAR3 will be 272 established. 274 However such an architecture leads to new requirement on the HNP 275 prefix model. Actually, because the HNP is anchored to its mobility 276 anchor (i.e. H-MAR), a dynamic mobility anchoring requires that each 277 MAR must advertise different per-MN prefixes set. For example, if 278 MN1 is anchored to both MAR1 and MAR3, these two mobility capable 279 access routers would advertise respectively HNP1 and HNP3 for MN1. 281 _______ _______ 282 | | | | 283 | CN1 | | CN2 | 284 |_______| |_______| 285 '. Flow#2 . 286 Flow#1 ' '. | Flow#3 287 ' '...'''''''''''''.... . 288 ..''' '. '''.. 289 .' ' '.IP network . '. 290 : ' '. | : 291 '..' +-------+ . ..' 292 '''... | | ....''' 293 ' | MAR2 | \ . 294 MAR1 Forwarding Table ' | | \ | 295 +=====================+ ' | |'. \ . 296 HNP-1::/64 -> MAR3 ' +-------+\'. \ | 297 +-------+ \ '+ ------+ 298 | | \ | | 299 | MAR1 |-----------------| MAR3 | 300 | |'''''''''''''''''| | 301 | |-----------------| | 302 +-------+ +-------+ 303 ' ' | 304 Flow#1 ' . . Flow#3 305 ' ' | 306 +-----+ Flow#2 +-----+ 307 | MN1 | -----move-------> | MN1 | 308 +-----+ +-----+ 309 (single interface, IF1) 311 Figure 1: Distributed Mobility Anchoring 313 4.2. Protocol sequence for handover management 315 An example of handover management for a single interface mobile node 316 is depicted on Figure 2. The mobile node, MN1, is assumed to move 317 from MAR1 to MAR2. Following are the main steps of the handover 318 management process: 320 1. The mobile node, MN1, attaches to MAR1 which is responsible for 321 allocating the MN-HNP, e.g. HNP1 for MN1. 322 2. Hence, the mobile node can initiate and maintain data transport 323 sessions (with CN1 in the picture), using IP addresses derived 324 from HNP1, in a standard way while it remains attached to MAR1, 325 i.e. mobility functions do not come into play. 326 3. The MN handoffs to MAR2 which will thus act as V-MAR for HNP1: 327 MAR2 retrieves the ongoing mobility sessions (e.g. from a policy 328 store, as per [RFC5213]) for MN, then it proceeds to location 329 update for HNP1 with MAR1 (H-MAR role), i.e., PBU/PBA exchange 330 between MAR2 and MAR1. 331 4. MAR2 also allocates new HNPs for MN1; these HNPs are meant to be 332 used by application flows initiated after the handoff. 333 5. MAR1, playing the H-MAR role for HNP1, encapsulates MN1's traffic 334 and tunnels it to the V-MAR, i.e. MAR2, where packets are 335 decapsulated and delivered to the MN. 336 6. The mobile node can initiate and maintain new data transport 337 sessions, e.g. with CN2, using IP addresses derived from HNP2. 338 This traffic is routed in a standard way while the mobile node 339 remains attached to MAR2. 341 MN1 MAR2 MAR1 CN1 CN2 342 | | | | | 343 | | | | | 344 L2 Attach | | | | 345 | | | | | 346 |----------------RS---------->| | | 347 | | | MAR1 allocates | 348 | | | and advertises | 349 |<---------------RA-----------| HNP1 | | 350 | | | | | 351 comm. to CN1 using HNP1 | | | 352 |<----------------data-flow#1--------->| | 353 | | | | | 354 handover | | | | 355 to MA2 | | | | 356 |-----RS----->| MAR2 allocates| | | 357 | | HNP2 for new communications | 358 | | | | | 359 | |----pBU------->| | | 360 | | | | | 361 | |<---pBA--------| | | 362 |<---RA-------| | | | 363 | | | | | 364 handover | | | | 365 completed | | | | 366 | | | | | 367 |<---flow#1 --|<===tunnel====>|------->| | 368 | | | | | 369 comm. to CN2 using HNP2 | | | 370 | | | | | 371 |<-----------------data-flow#2----------------->| 372 | | | | | 373 | | | | | 375 Figure 2: Handover management with Distributed Mobility Anchoring 377 4.3. Difference with Proxy Mobile IPv6 379 A V-MAR is required to advertise new per-MN HNP set for new IP 380 communications to be initiated, while Proxy Mobile IPv6 advertises 381 the same HNPs when roaming from MAG to MAG. So, while Proxy Mobile 382 IPv6 is based on the per-MN prefix model, this proposal leverages on 383 a per-MN and per-MAR prefix model. It is not required to statically 384 allocate different set of HNPs per MAR. Actually, at a given time, 385 only active MARs for an MN (i.e. access routers on which the mobile 386 node is currently attached to) need to share the per-MN HNPs set. 388 So, for the sake of scalability, per-MN HNPs should be dynamically 389 shared out among MN's active MARs. 391 A mobile node may be served simultaneously by more than one mobility 392 anchor at the same time. Each MAR anchors the IP traffic initiated 393 when the mobile node was attached to it. 395 4.4. IP flow mobility support 397 The distribution of mobility functions can also apply in the context 398 of multiple-interfaces terminals and IP flow mobility. In such a 399 case, any given IP flow can be considered as implicitly anchored on 400 the current host's access router when set up. Until the host does 401 not move from the initial access router (H-MAR), the IP flow is 402 delivered as for any standard IPv6 node. The anchoring function at 403 the H-MAR is thus managing traffic indirection only if one, or 404 several, IP flow(s) are moved to another interface, and for 405 subsequent movements while the initial anchored flows remain active. 406 This anchoring is performed on a per-flow basis and each H-MAR needs 407 to track all possible V-MARs for a given host on the move. The H-MAR 408 must also manage different tunnels for a given mobile node providing 409 that the node is multihomed and it simultaneously processes different 410 IP flows on its interfaces. 412 In the following, it is assumed that flow mobility consists in 413 transferring a subset of prefixes from one access to another (i.e. a 414 given prefix is associated to a given IP flow). This scenario is 415 described in [I-D.jeyatharan-netext-multihoming-ps] and implemented 416 in [I-D.yokota-netlmm-pmipv6-mn-itho-support]. However, providing 417 specific extensions to mobility signalling (extensions to be 418 defined), the solution could also matches the scenario where a same 419 prefix is shared across multiple interfaces (scenario described in 420 [I-D.jeyatharan-netext-multihoming-ps] ). In this case, a prefix is 421 still anchored to one MAR but redirected IP flows are routed by the 422 H-MAR using flow filtering mechanism. 424 Lets consider a simple example to illustrate the dynamic per-flow 425 mobility anchoring. Figure 3 depicts the IP flow mobility management 426 for a mobile node with two interfaces. The IP data flows, Flow#1 and 427 Flow#2, have been initiated on if1. Thus, Flow#1 and Flow#2, using 428 respecively prefixes HNP1 and HNP2, are anchored to MAR1. Referring 429 to the picture, Flow#1 has not been moved; so Flow#1 is delivered in 430 a standard IPv6 way. Flow#2 has been transferred from If1 to If2, so 431 the the Flow#2 packets, corresponding to HNP2, are tunneled from MAR1 432 to MAR2. In other words, MAR1 and MAR2 are respectively the H-MAR 433 anchor and the V-MAR for flow#2. 435 _______ _______ 436 | | | | 437 | CN1 | | CN2 | 438 |_______| |_______| 439 ' . 440 Flow#1 ' | Flow#2 441 ' ...'''''''''''''.... . 442 ..''' '''.. 443 .' ' IP network . '. 444 : ' | : 445 '..' . ..' 446 '''.....................'|' 447 ' . 448 ' | 449 ' .- . - . - . - . - . - . 450 ' | 451 +-------+ Flow#2 + ------+ 452 | | tunneled | | 453 | MAR1 |-----------------| MAR2 | 454 |(H-MAR)| -.-.-.-.-.-.-.-.|(V-MAR)| 455 | |-----------------| | 456 +-------+ +----|--+ 457 ' . 458 Flow#1 ' | Flow#2 459 ' . 460 ' If1 +-----+ If2 | 461 ''''''''''| MN | - . - . 462 +-----+ 464 Figure 3: Distributed IF flow Mobility Anchoring 466 In case of the handover of an IP flow, initially adressed to one 467 interface, the mobile node must be able to process that traffic also 468 on the target interface. In order to meet that requirement, the 469 mobile node could support the weak host model, as per [RFC1122], 470 [I-D.bernardos-mif-pmip]. By supporting the weak host model, the 471 mobile node can accept traffic, addressed to one IP address, on any 472 of its interfaces. 474 Another solution for the host to support the handover from one 475 interface to another, is to hide the inter-access handover to layers 476 above IP. The mobile node can support this scenario by using a 477 virtual IP interface. The applicability of that approach is 478 discussed on [I-D.bernardos-netext-ll-statement] and 479 [I-D.yokota-netlmm-pmipv6-mn-itho-support] describes a solution. 481 5. Implementation feedback 483 The solution proposed in this document has been implemented and 484 tested on a Linux based testbed and for a single interface terminal. 485 When several IPv6 addresses are available, Linux (at least the 486 distribution we use) leverages on [RFC3484] default rules to select 487 the source address. The problem is that, on a single interface host 488 and when several global addresses are available, any of the [RFC3484] 489 source address selection rules applies. So, in this case, Linux 490 selects the more recent address registered among the list of 491 potential source address. In our context, it leads to the following 492 situation: 494 A mobile node (MN1) attaches to a mobility capable access router 495 (MAR1) advertising the prefix HNP1; so MN1 generates the IP 496 address IP1. If MN1 attaches to a new mobility capable access 497 router (MAR2) advertising the prefix HNP2, MN1 generates a new IP 498 address IP2. At this stage, MN1 has two IP addresses: IP1 and 499 IP2. If the mobile node comes back to MAR1, the more recent IP 500 address, IP2, will be used to start new application. This 501 behaviour brings issue with regards to the expected prefix 502 management (described in Section 4.1); actually applications are 503 meant to use prefixes advertised on the current access link to 504 start new data flow. In this example, MN1 must use IP1, and not 505 IP2, to start new applications when coming back to MAR1. 507 In order to address the above issue, we have modified Linux source 508 address selection algorithm. The modification overtake Linux 509 mechanism and consists in always selecting the source address 510 corresponding to the prefix advertised on the current access. 512 6. Security Considerations 514 TBD. 516 7. IANA Considerations 518 This document has no actions for IANA. 520 8. Acknowledgements 522 The authors would like to acknowledge Philippe Quenard and Carole 523 Bonan who have implemented the solution decribed here. The authors 524 would also like to express their gratitude to Lucian Suciu, Servane 525 Bonjour and Karine Guillouard for their suggestions and reviews of 526 this document. 528 Last but not least, the authors would like to acknowledge Dapeng Liu, 529 Anthony Chan and Julien Laganier for having shared thoughts on the 530 concept of distributed mobility. 532 9. References 534 9.1. Normative References 536 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 537 Address Autoconfiguration", RFC 4862, September 2007. 539 9.2. Informative References 541 [I-D.bernardos-mif-pmip] 542 Bernardos, C., Melia, T., Seite, P., and J. Korhonen, 543 "Multihoming extensions for Proxy Mobile IPv6", 544 draft-bernardos-mif-pmip-02 (work in progress), 545 March 2010. 547 [I-D.bernardos-netext-ll-statement] 548 Bernardos, C., Zuniga, J., and T. Melia, "Applicability 549 Statement on Link Layer implementation/Logical Interface 550 over Multiple Physical Interfaces", 551 draft-bernardos-netext-ll-statement-01 (work in progress), 552 March 2010. 554 [I-D.chan-netext-distributed-lma] 555 Chan, H., Xia, F., Xiang, J., and H. Ahmed, "Distributed 556 Local Mobility Anchors", 557 draft-chan-netext-distributed-lma-03 (work in progress), 558 March 2010. 560 [I-D.jeyatharan-netext-multihoming-ps] 561 Jeyatharan, M. and C. Ng, "Multihoming Problem Statement 562 in NetLMM", draft-jeyatharan-netext-multihoming-ps-02 563 (work in progress), March 2010. 565 [I-D.liu-distributed-mobility] 566 Liu, D. and Z. Cao, "Distributed mobility management 567 Problem Statement", draft-liu-distributed-mobility-01 568 (work in progress), March 2010. 570 [I-D.yokota-netlmm-pmipv6-mn-itho-support] 571 Yokota, H., Gundavelli, S., Trung, T., Hong, Y., and K. 572 Leung, "Virtual Interface Support for IP Hosts", 573 draft-yokota-netlmm-pmipv6-mn-itho-support-03 (work in 574 progress), March 2010. 576 [NTMS2008] 577 Bertin, P., "A Distributed Dynamic Mobility Management 578 Scheme designed for Flat IP Architectures.", NTMS'2008 , 579 November 2008. 581 [RFC1122] Braden, R., "Requirements for Internet Hosts - 582 Communication Layers", STD 3, RFC 1122, October 1989. 584 [RFC3484] Draves, R., "Default Address Selection for Internet 585 Protocol version 6 (IPv6)", RFC 3484, February 2003. 587 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 588 in IPv6", RFC 3775, June 2004. 590 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 591 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 593 Authors' Addresses 595 Pierrick Seite 596 France Telecom - Orange 597 4, rue du Clos Courtel, BP 91226 598 Cesson-Sevigne 35512 599 France 601 Email: pierrick.seite@orange-ftgroup.com 603 Philippe Bertin 604 France Telecom - Orange 605 4, rue du Clos Courtel, BP 91226 606 Cesson-Sevigne 35512 607 France 609 Email: philippe.bertin@orange-ftgroup.com