idnits 2.17.1 draft-montavont-mip6-mmi-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 798. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 775. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 782. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 788. ** 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 Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 331: '...o use. To do so, the MN SHOULD keep a...' RFC 2119 keyword, line 393: '...CN. Then the MN MUST choose which pol...' RFC 2119 keyword, line 400: '... A MN MUST carefully choose which Co...' RFC 2119 keyword, line 401: '...e same CN, all flows MUST use the same...' RFC 2119 keyword, line 426: '...nterface, the MN MUST check its Bindin...' (12 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 (July 15, 2005) is 6857 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) == Unused Reference: '10' is defined on line 758, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 762, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) == Outdated reference: A later version (-02) exists of draft-ernst-generic-goals-and-benefits-01 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-05) exists of draft-montavont-mobileip-multihoming-pb-statement-04 -- Possible downref: Normative reference to a draft: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '4') -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-03) exists of draft-nomadv6-mobileip-filters-00 -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-05) exists of draft-wakikawa-mobileip-multiplecoa-03 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-03 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '11') Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF MIP6 Working Group N. Montavont 3 Internet-Draft T. Noel 4 Expires: January 16, 2006 LSIIT 5 M. Kassi-Lahlou 6 France Telecom R&D 7 July 15, 2005 9 Mobile IPv6 for multiple interfaces (MMI) 10 draft-montavont-mip6-mmi-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 16, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 Mobile IPv6 [1] allows a MN to maintain its IPv6 communications while 44 moving between subnets. This document presents the problematic for a 45 MN that has multiple network interfaces. It discusses how to perform 46 vertical handovers (flow redirection between interfaces) and propose 47 MMI (Mobile IPv6 for Multiple Interfaces) which describes the use of 48 Mobile IPv6 to support multiple interfaces. One one hand, these 49 extensions focus on the MN ability to use a backup interface for 50 communications and on the other hand to spread flows between the MN 51 own interfaces. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology related to multiple interfaces . . . . . . . . . . 4 57 3. Motivations: Why a MN may want to redirect a flow . . . . . . 6 58 4. Multiple interfaces management . . . . . . . . . . . . . . . . 7 59 4.1 One home address per interface . . . . . . . . . . . . . . 7 60 4.2 Mechanism for redirection between interfaces . . . . . . . 7 61 4.3 Receiving new communications . . . . . . . . . . . . . . . 9 62 4.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5. Per-correspondant node mobility . . . . . . . . . . . . . . . 11 64 5.1 Spreading flows on interfaces . . . . . . . . . . . . . . 11 65 5.2 Create a new binding on a remote CN . . . . . . . . . . . 11 66 5.3 Several flows with the same CN . . . . . . . . . . . . . . 12 67 6. Per-flow Mobility . . . . . . . . . . . . . . . . . . . . . . 14 68 7. Load balancing Mobility . . . . . . . . . . . . . . . . . . . 16 69 7.1 Options of Binding Update . . . . . . . . . . . . . . . . 16 70 7.2 Binding Management . . . . . . . . . . . . . . . . . . . . 17 71 7.3 MN operations . . . . . . . . . . . . . . . . . . . . . . 17 72 7.3.1 Source careof address . . . . . . . . . . . . . . . . 18 73 7.3.2 Destination careof address . . . . . . . . . . . . . . 19 74 7.3.3 Security issues . . . . . . . . . . . . . . . . . . . 19 75 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 79 Intellectual Property and Copyright Statements . . . . . . . . 23 81 1. Introduction 83 Future MNs will probably have multiple interfaces to be connected to 84 different access technologies. Thus a MN can benefit of the pros of 85 each access technology to be connected everywhere at any time[2]. 86 Each technology has its specific characteristics in terms of coverage 87 area, bandwidth, reliability, etc. While Mobile IPv6 [1] allows a MN 88 to handover between subnets, there are no requirements to manage 89 mobility into the MN, i.e. between several interfaces. The document 90 [3] lists the issues of Mobile IPv6 that prevent the use of multiple 91 interfaces. This document presents the problematic of having 92 multiple interfaces and proposes some simple extensions to Mobile 93 IPv6, called MMI (Mobile IPv6 for Multiple Interfaces) to optimize 94 the use of multiple interfaces. 96 Assume a MN with two interfaces. At first, the MN can be connected 97 to the network with only one interface. Then the MN moves away from 98 the coverage area of its current point of attachment and looses its 99 network connection through this interface. At the same time, it 100 connects to the network with the other interface. Subsequently the 101 MN may want all the flows using the first interface to be 102 automatically redirected on the other available interface. In this 103 case, the MN takes advantage of having multiple interfaces by using a 104 backup interface. Another scenario would be a MN moving across 105 different subnets, and use an alternative interface for its flows 106 while it performs Mobile IPv6 operations. This would minimize the 107 impact of the handover on the applications. 109 In this document, the specific operations needed to perform vertical 110 handovers are described. In the next section, some definitions 111 related to multiple interfaces management are given. The section 3 112 explains why a MN may want to redirect flows between its interfaces. 113 Then, MMI operations are described for a generic network 114 configuration. These operations describe the use of Mobile IPv6 to 115 perform vertical handovers. Then a per-correspondant node mobility 116 is described, which is the ability for the MN to spread its flows on 117 several interfaces with different CNs. Then we detail the per-flow 118 mobility, the operations for the MN to independently manage each 119 flow. Finally we describe the load balancing mobility, which allows 120 the MN to use several CoAs and thus interfaces, for the same flow. 121 We then conclude the document. 123 2. Terminology related to multiple interfaces 125 The following terms are introduced in the document. Some definitions 126 are taken from [4]. Other definitions can be found in [2]. 128 Available interface 130 An interface that offers to the MN connectivity to the network. 131 The interface is configured and attached to an AR. The MN can 132 initiate and receive flows through this interface. 134 L2 handover 136 The change of point of attachement (link layer). 138 L3 handover 140 The change of IP subnet. 142 Horizontal handover 144 From the IP point of view, a horizontal handover happens if the MN 145 changes of subnet it is connected to 147 Vertical Handover (from [4]) 149 In a vertical handover the MN's network interface to the access 150 network changes. A vertical handover is typically an inter- 151 technology handover. 153 Previous interface 155 During a vertical handover, the previous interface is the 156 interface from which flow will be redirected. 158 New interface 160 During a vertical handover, the new interface is the interface to 161 which flow will be redirected. 163 Per-correspondant node mobility 165 Per-CN mobility is the ability for the MN to indenpendatly manage 166 flows from different CNs. Each CN is independently managed by the 167 MN but all flows from a single CN are exchange via the same 168 interface on the MN. 170 Per-flow mobility 172 The per-flow mobility is the ability for the MN to manage each 173 flow independently. Each flow can be mapped to any interface, 174 without disturbing other existing mappings between flows and 175 interfaces. 177 Per-flow Load balancing 179 The per-flow load balancing is the ability for the MN to 180 simultaneously use several interfaces with the same CN, even for 181 the same flow. 183 3. Motivations: Why a MN may want to redirect a flow 185 When a MN has multiple interfaces, it may use its interfaces in many 186 ways. It can keep a backup interface or uses them simultaneously. A 187 MN may want to redirect its flows between its available interfaces 188 for many reasons: 190 o An interface in use comes down and thus does not offer network 191 connectivity anymore. 193 o The MN can take advantage of having multiple interfaces and 194 redirects some or all flows from the down interface to another 195 available interface 197 o An interface comes up. The MN may decide that the interface which 198 comes up is most suitable for its current flows currently using 199 another interface 201 o The MN performs a handover on an interface in use for flows. When 202 a MN performs a horizontal handover, the handover latency (the 203 time during which the MN can not send nor receive packets) can be 204 long and then the quality of the flows can suffer. If the MN 205 wants to minimize such perturbation, it can redirect some or all 206 the flows on another available interface. This redirection can be 207 done in advance of the handover if the L2 triggers are considered 208 [5]. 210 o The network capabilities change. The MN can observe a degradation 211 of service on one of its interface, or conversely an improvement 212 of capacity on an interface. The MN may then decide to redirect 213 some or all flows on another interface that it considers most 214 suitable for the target flows. 216 o A new flow is initiated between the MN and a CN. According to 217 internal policies, the MN may want to redirect this flow on a most 218 suitable interface. 220 4. Multiple interfaces management 222 4.1 One home address per interface 224 In the following, we assume a MN with two interfaces I1 and I2 of 225 different access technologies. Each interface is configured with a 226 global IPv6 address, respectively IP1 and IP2. These two global IPv6 227 addresses are assigned to the MN in such a way that both addresses 228 can be used to reach the MN. 230 The MN uses Mobile IPv6 on each of its interfaces when it moves 231 between subnets. The MN has a home link for each of its interfaces 232 and there is a router acting as a home agent on each home link. The 233 use of Mobile IPv6 to redirect flows between interfaces are 234 highlighted for a generic network configuration. So IP1 and IP2 can 235 be either home address or current CoA. 237 4.2 Mechanism for redirection between interfaces 239 The mechanism for a MN to redirect flows from one of its interfaces 240 (the previous interface) to another one (the new interface) is to 241 perform a redirection between the IP address (previous IP address) 242 allocated to the previous interface to the IP address (new IP 243 address) allocated to the new interface. To do so, the MN sends a 244 Binding Update through the new interface to register the IP address 245 allocated to the new interface as new CoA for the redirected flows. 247 To make things as clear as possible, this section discusses the flow 248 redirection from (I1, IP1) to (I2, IP2), as illustrated in Figure 1. 249 We also use HA1 to refer to the home agent used by the MN for its IP 250 address IP1 and HA2 for the HA used by the MN for its IP address IP2. 251 The operations are the same if IP1 (resp. IP2) is the home address or 252 the current CoA allocated to I1 (resp. I2). 254 Same or different access networks 255 Home link or not. 256 _________________......__________________ 257 | | 258 _| _| 259 |_| AP1 |_| AP2 260 _____________ 261 | | 262 | \|/ 264 Interface 1 (I1) \|/ \|/ Interface 2 (I2) 265 IP1 | | IP2 266 |______| 267 | | 268 | MN | 269 |______| 271 To perform a vertical handover from the previous interface I1 to the 272 new interface I2, the MN has to send a Binding Update to HA1 (and 273 eventually to its CNs). The Binding Update must be sent as follow: 275 o The home address field set to the IP address bound to the previous 276 interface (IP1) 278 o The CoA field set to the IP address bound to the new interface 279 (IP2) 281 This Binding Update must be sent through the new interface I2. This 282 operation does not disturb the initial communications on the new 283 interface I2 using IP2. But this may have an impact on the available 284 bandwidth on I2. Thus, this mechanism allows a MN to send a binding 285 information for a previous interface by using another interface, the 286 new interface. 288 Afterwards, if the MN moves to a new subnet through the new interface 289 I2 (horizontal handover on I2), it obtains a new CoA (IP3). Besides 290 the operations required in Mobile IPv6 when a MN changes its point of 291 attachment, the MN has to send a Binding Update to HA2 (and 292 eventually to CNs of its current flows which have a binding between 293 IP1 and IP2 in their binding cache) to update its location. Now, the 294 binding cache of HA1 records, among others, a binding between the 295 home address IP1 and the CoA IP3. Thus, the movement detected on I2 296 is indicated to I1. 298 Later, if the MN wants to use the previous interface I1 again and had 299 registered an association on HA1 between IP1 and IP2, it needs to 300 update the entry in the binding cache of HA1. If the MN is connected 301 to a foreign network through the previous interface I1 (different 302 from the home link), it sends a Binding Update with the new IPv6 303 address got on the current link as the new CoA. If the MN is 304 connected to its home link through I1, it has to send a Binding 305 Update to its home agent to make it invalid the binding cache for it 306 (see returning home in [1]). 308 4.3 Receiving new communications 310 No new mechanisms are required to receive a new communication once a 311 redirection between interfaces was done. Consider a MN which has 312 redirected flows from a previous interface (I1, IP1) to a new 313 interface (I2, IP2) as described in this document (section 4.2). If 314 the MN receives a new flow forwarded by HA1, the MN has several 315 possibilities: it might reject the flow (e.g. the flow needs are not 316 adapted to the network capacities provided to the MN); Or if the MN 317 does not reject the flow, it might decide to inform the CN of the 318 flow that its current address is IP2 and that it needs to use routing 319 header [1]. 321 4.4 Discussion 323 The use of multiple home addresses can be a solution to manage and 324 optimize the use of several interfaces. If a MN can bind at least 325 one home address per interface and can register a binding for each 326 home address with a home agent (not necessarly the same), the use of 327 Mobile IPv6 as described above allows a MN to spread its flows on 328 several interfaces. 330 When a MN initiates a new flow with a CN, it has to choose which 331 (interface, home address) to use. To do so, the MN SHOULD keep a 332 preference table indicating the prefered interface per type of flow 333 and a default prefered interface (such as tables illustrated in 334 Figure 2). Then, the choice of the interface determines the home 335 address and thus the home agent to use for that flow. If the MN is 336 connected to its home link through the chosen interface, then no 337 mobile IPv6 operations are required. Otherwise, if the MN is away 338 from its home link for this interface, it must have a binding on its 339 home agent serving the target home address. If its home agent has 340 not a binding for this home address, it must create one as defined in 341 [1]. Then the MN may initiate a correspondant registration to 342 perform route optimzation. 344 If at any time, the MN wants to redirect a flow for which the MN uses 345 the home address HoA1 to another interface, it has to send a Binding 346 Update as described in section 4.2, with the current address of the 347 new interface as CoA in the Binding Update. If all packets from CNs 348 are encapsulated to the home agent (the CN has not a binding for the 349 MN), all flows using the home address HoA1 will be redirected to the 350 new interface. Otherwise, if the CN has a binding for the home 351 address HoA1, the MN can send the Binding Update directly to the CN 352 (after a return routability procedure). 354 Therefore all flows with a single CN using the same home address and 355 route optimization will use the same interface. The per-CN mobility 356 is further detailed in next section. If the MN wants to use several 357 interfaces with the same CN, it can initiate the flow with different 358 home addresses. 360 5. Per-correspondant node mobility 362 While the previous section describes how a MN may use Mobile IPv6 363 when it has several interfaces, we will see in this section how a MN 364 can use Mobile IPv6 to register different CoAs with different CNs to 365 spread its flows from different CNs on different interfaces. 367 5.1 Spreading flows on interfaces 369 When a CN exchanges data packets with a MN, it first uses the home 370 address of the MN as source address in packets. Also, packets from 371 CN are sent to the home address of the MN when it has no binding for 372 the home address. If the MN is away from its home network for this 373 home address and if the MN has already registered a primary CoA on 374 the home agent (as defined in section 11.7.1 of [1]), the bi- 375 directional tunnel between the home agent and the MN is used for all 376 packets. Packets finally reach the interface on which the primary 377 CoA of the MN is bound. 379 In this situation, the MN may initiate a correspondant registration 380 (return routability procedure and Binding Update / Binding 381 Acknowledgment exchange) with that CN. The MN may register as well 382 its primary CoA, as any other IPv6 address bound to one of its 383 interfaces (even another home address). 385 In order to manage the flow spreading on several interfaces, the MN 386 may have a policy table to decide which interface(s) is (are) 387 preferred for which type of flow. This policy table indicates for 388 example that flow of type 1 should use interface 1 and flow of type 2 389 should use interface 2. But this policy table is made on the MN, and 390 the MN can not know all its future CNs. So some policies can be not 391 valid when the two flows are exchanged with the same CN; Current 392 Mobile IPv6 specification does not allow to independently manage two 393 flows with the same CN. Then the MN MUST choose which policy is the 394 most important and redirect one of the two flows. This is what is 395 called per-CN mobility. The choice of the interface will determine 396 the choice of the CoA to register with the CN. 398 5.2 Create a new binding on a remote CN 400 A MN MUST carefully choose which CoA to register with its CN. If the 401 MN has several flows with the same CN, all flows MUST use the same 402 CoA, i.e. the same interface. Therefore the MN has to maintain a 403 policy table that do not generate conflicts. Figure 2 is an example 404 of such a policy table. 406 | Flow Disciminant | List of preferred interfaces | Priority 407 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|-+-+-+-+-+-+-+-+-+ 408 |Default |if1 | x 409 |1 |if3, if4 | 5 410 |5 |if2, if3 | 8 412 Figure 2. Interface preference 414 This policy table shows preferences on interfaces according to a flow 415 discriminant. The flow discriminant can be one, several or all 416 fields of the source/destination ports numbers, source/destination 417 address and protocol number. For example, it can be just a 418 destination port, or the (source port, destination port, CN address) 419 tuple. The priority field is used to set a priority on the different 420 entries and helps in case of conflict (two different mappings with 421 the same CN). 423 When the MN wants to use route optimization with a CN, it first 424 checks a policy table such as the one presented in Figure 2. This 425 table gives to the MN the preferred interface for the flow. After 426 having chosen the preferred interface, the MN MUST check its Binding 427 Update List to find if the destination address of this flow has 428 already an association between the MN home address and a CoA. If the 429 destination address does not appear in the Binding Update List, the 430 MN can initiate a correspondant registration with one of the address 431 bound to the chosen interface. If the destination address is already 432 in the Binding Update List, it means that the CN has already a 433 binding for this home address. This case is discussed in the next 434 subsection. 436 5.3 Several flows with the same CN 438 The MN may also want to change a binding on a distant CN at any point 439 of time, even if it does not get a new CoA. For example, its 440 internal policies may change, or a new flow is initiated between the 441 MN and the CN. We further detail the second case in this subsection. 443 When a CN has a binding for a MN, all packets sent to the home 444 address will be encapsulated to the registered CoA. If the CN 445 initiates a new flow with the home address of the MN, packets will be 446 tunneled to the registered CoA of the MN. This means that this new 447 flow will reach the same interface as the previous flow of this CN. 448 However, the internal preference of the MN may indicate that this 449 flow would be better mapped to another interface of the MN, i.e. to 450 another IPv6 address in most cases. In this case, the MN MUST be 451 able to choose which rule to follow and then which CoA to register. 452 The priority field of the table illustrated in Figure 2 can be used 453 for this purpose. The most important flow determines the most 454 prefered interface for the CN. The flow which has the higher 455 priority will be picked to choose the new interface to use with that 456 CN. If the most important flow indicates another interface than the 457 one currently used with this CN, then the MN has to initiate a return 458 routability procedure. Otherwise, nothing needs to be done, and the 459 new flow will not use the prefered interface. 461 6. Per-flow Mobility 463 The per-flow mobility is a step more in the multiple interfaces 464 management. The aim of this solution is to independently manage each 465 flow, whatever the CN. Each flow can be uniquely identified and 466 redirected between interfaces without modifying binding of other 467 flows. Especially, flows exchanged with a single CN can be 468 independently managed by registering a different CoA for each flow. 469 To reach this goal, new options in Binding Update have to be defined 470 in order to identify a flow and an entry in the binding cache since 471 several CoAs would be bound to the same home address. 473 On one hand, an ongoing flow between two hosts can be uniquely 474 identified with the source/destination port numbers/addresses and the 475 protocol number quintuplet. On the other hand, some types of flow 476 use well-known port number(s). Also, for some application, the 477 destination address is known, especially when it is a server, or the 478 port number can be known, etc. A per-flow mobility should allow a MN 479 to register different CoAs as well for established flows (where the 480 quintuplet is known) as for future potential flows by using one or 481 several fields of the quintuplet. 483 Such solutions were already proposed at the IETF. The per-flow 484 movement [6] proposes to use either the source/destination port 485 numbers, source/destination addresses and protocol number quintuplet 486 or the IPv6 flow label to identify a flow. In this solution, the 487 full identifier of a flow must be included in the Binding Update sent 488 by the MN to redirect a flow between two CoAs. However, it can be 489 useful for the MN to set policies only for a subset of the quintuplet 490 identifier, especially when the flow is not started yet. References 491 [7] and [8] also propose new options to manage a per-flow mobility. 492 Each option defined in these documents is used to identify a subset 493 of a flow identifier such as a port number. 495 When a MN sends a Binding Update with per-flow mobility option(s), 496 the receiving CN may have several CoAs bound to the same home 497 address. But in Mobile IPv6, the home address is the identifier of a 498 binding. If the CN has several CoAs bound to the same home address, 499 a new identifier is needed in the binding cache. Currently, two 500 solutions are proposed to identify an entry in the binding cache: 501 Reference [9] proposes a new field in Binding Update which is called 502 Binding ID (BID). When the MN sends a Binding Update to a CN, it MAY 503 includes a BID to uniquely identify this entry in the binding cache 504 of the CN. So, when the MN wants to update an entry, it can identify 505 which one with this BID. But, in the context of a per-flow mobility, 506 the per-flow mobility option [6] already uniquely identifies an entry 507 in the Binding cache. So it can be used to uniquely identify an 508 entry in the CN binding cache. In this case, a Binding Update can 509 include several per-flow mobility options. 511 7. Load balancing Mobility 513 The load balancing mobility is the finnest granular mobility that can 514 be achieved on a multiple interfaces MN. This mechanism aims to 515 allow a multiple interfaces MN to perform load balacing on several 516 interfaces. The options defined in this section allow to use 517 different interfaces to send and receive packets from one CN. 518 Furthermore, this option can be used in addition of a per-flow 519 mobility option (see previous section) to use several interfaces for 520 the same flow. To do so, the MN can register different CoAs 521 allocated to different interfaces for a single flow. 523 7.1 Options of Binding Update 525 The following sub-option is proposed to register a CoA with policies 526 for load balancing mobility. 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Option Type | Option Len | S | D | CoA ID | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | | 534 + + 535 | | 536 + Alternate Care-of address + 537 | | 538 + + 539 | | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 Figure 3. Load balancing mobility option 544 Option Type 546 TBD 548 Option Len 550 Length of option 552 S 554 Source address flag. When the Source address flag is set, the 555 alternate advertised CoA will be one of the source CoA of packets 556 sent to the CN. 558 D 560 Destination address flag. When the Destination address flag is set 561 (different from 0), it means that the advertised CoA will be one of 562 the destination address that the CN MUST use. When the flag is 563 different from 1, it indicates the proportion of packets the CN has 564 to send to the advetised CoA. Values for this field are to be 565 defined, according to the authorized percentage. 567 CoA ID 569 Identifier of the CoA to be used in the binding cache in the 570 receiving node. 0 is a reserved value that can be used for the source 571 CoA of Binding Update (see next section). 573 Alternate CoA 575 The CoA to be registered on the receiving node. 577 7.2 Binding Management 579 The binding cache in both HA and CN MUST be modified to support load 580 balancing mobility. Binding cache MUST be extended to associate 581 several CoAs to the same home address, in the same entry. Each CoA 582 is identified by the CoA ID, received in load balancing mobility 583 option. To choose between several CoAs in one entry, we also propose 584 to associate two fields to each registered CoA: 586 o Destination field: indicates if the corresponding CoA in the 587 binding cache is used as destination address for the corresponding 588 home address. A value different from 0 indicates the proportion 589 of packets to be set with this CoA. 591 o Source field: indicates that packets can be received with this CoA 592 as source address. 594 7.3 MN operations 596 A MN can use the load balacing mobility option in Binding Update sent 597 to both its HA(s) and CN(s). A MN must take care which policy it 598 assigns to a CoA that it registers with distant nodes, in order to 599 keep distant node's binding cache coherent. 601 When a MN is away from its home network and a distant node (HA of the 602 MN or CN) has not yet a binding cache for this MN, the MN may send a 603 Binding Update with the following content: 605 o The MN may include more than one load balancing mobility option in 606 the same Binding Update. 608 o If the MN includes at least one load balancing mobility option, 609 the source address of the Binding Update will also be registered 610 by the distant node. The CoA ID of the source address of this 611 Binding Update will be 0 (both in the Binding Cache of the 612 receiving node and in the Binding Update list). 614 o If the MN includes load balancing mobility option(s) only with the 615 Destination flag set, the MN requests the distant node to send 616 packets to a different CoA than the one(s) that the MN uses to 617 send packets. The source address of the Binding Update will be 618 registered as source CoA by the distant node. The CoA in the load 619 balancing mobility option(s) must be registered as destination 620 CoA, with the associated percentage. The CoA identifier is given 621 by the CoA ID field of the option. 623 o If the MN includes load balancing mobility option(s) only with the 624 Source flag set, the MN requests the distant node to accept 625 packets from the CoA(s) included in the load balancing mobility 626 option(s). The source address of the Binding Update will be 627 registered as destination CoA by the distant node. The CoA 628 identifier is given by the CoA ID field of the option. 630 o When a Binding Update includes different load balancing mobility 631 options (some with the destination flag set and other(s) with the 632 source address flag set), the source address of the Binding Update 633 must be taken as a source CoA to register. 635 When a MN is away from its home network and wants to update an 636 existing entry in the Binding Cache of a distant node (HA of the MN 637 or CN), the source address of the Binding Update will replace the 638 source address with the CoA ID 0. If the MN had registered only one 639 CoA without any load balancing mobility option, the source address of 640 the Binding Update will replace the current registered CoA and will 641 have the CoA ID 0. 643 7.3.1 Source careof address 645 If the MN wants to use a specific CoA as source address in its 646 outgoing packets, different from the CoA(s) that a distant node uses 647 to send packets, it SHOULD send Binding Update with a load balancing 648 mobility option with the source address flag set. The load balancing 649 mobility option must be set as follows: 651 o S = 1: Option indicates source CoA 652 o D = 0 | integer (TBD): see subsection Section 7.3.2 654 o CoA ID = Identifier of the CoA set in the alternate CoA field. If 655 this option updates an existing entry, this field must be set with 656 the CoA ID that this option updates. 658 o Alternate careof address: the new CoA the MN MAY use as source 659 address to send data packets. 661 7.3.2 Destination careof address 663 If the MN wants a distant node to send packets to a specific set of 664 CoAs, the MN SHOULD send a Binding Update with a load balancing 665 mobility option with the destination flag set. The option of the 666 Binding Update MUST be filled as follows: 668 o S = 0 | 1: see subsection Section 7.3.1 670 o D = integer (TBD) different from 0: indicates the proportion of 671 packets sent by CN to the advertised alternate CoA. 673 o CoA ID = identifier of the CoA set in the alternate CoA field. If 674 this option updates an existing entry, this field must be set with 675 the CoA ID that this option updates. 677 o Alternate CoA: the new CoA the receiving node MUST use as 678 destination address in packets sent to the corresponding home 679 address. 681 When a MN includes a destination load balancing mobility option in a 682 Binding Update, care must be taken to register as much as CoA than 683 those needed by the proportion. Upon reception of a Binding Update, 684 the receiving node MUST have the right number of CoAs in order to 685 respect the requested proportion. 687 7.3.3 Security issues 689 The same security mechanisms as described in Mobile IPv6 MUST be 690 performed when a MN sends a binding Update with a load balancing 691 mobility option. When a MN sends a Binding Update with a load 692 balancing mobility option to a CN, it has to initiate a return 693 routability procedure for every CoAs the MN wants to register in the 694 Binding Update (including the source address of the Binding Update). 696 8. Conclusion 698 Multihoming of MN is an important issue as described in [2]. When a 699 MN has multiple interfaces, it is multihomed. We shown in this 700 document that a multiple interfaces MN can be managed in different 701 ways, through different granulary levels: per-CN mobility, per-flow 702 mobility and load balancing mobility. Each solution brings different 703 advantages to the MN and in some of them extensions to Mobile IPv6 704 are needed. The per-CN mobility allows a MN to use a different 705 interface with different CNs. The advantage of this solution is that 706 it only requires minor extensions to Mobile IPv6. The main drawback 707 is when a MN has two flows with the same CN, the same interface has 708 to be used. The per-flow mobility is the ability for the MN to 709 manage each flow independently. This topic is already deeply 710 investigated in individual propositions. The load balancing mobility 711 allows a MN to use several interfaces with one CN or for one flow. A 712 new option is introduced in this document to allow a MN to register 713 several CoAs as source CoA or as destination CoA. 715 9. Acknowledgements 717 The authors would like to thank the members of the French RNRT 718 Cyberte project (France Telecom RD, Cisco System, ENST Bretagne, 719 IRISA, and LSIIT) for their valuable feedback. 721 10. References 723 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 724 IPv6", RFC 3775, June 2004. 726 [2] Ernst, T., Montavont, N., Wakikawa, R., Paik, E., and K. 727 Kuladinithi, "Goals and Benefits of Multihoming", 728 I-D draft-ernst-generic-goals-and-benefits-01, February 2005. 730 [3] Montavont, N., Wakikawa, R., Ernst, T., Ng, C-W., and K. 731 Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 732 draft-montavont-mobileip-multihoming-pb-statement-04 (work in 733 progress), June 2005. 735 [4] Manner, J. and M. Kojo, "Mobility Related Terminology", 736 RFC 3753, June 2004. 738 [5] Kempf, J., "Supporting Optimized Handover for IP Mobility - 739 Requirements for Underlying Systems", 740 I-D draft-manyfolks-l2-mobilereq-02.txt, June 2002. 742 [6] Soliman, H., ElMalki, K., and C. Castelluccia, "Per-flow 743 movement in MIPv6", 744 I-D draft-soliman-mobileip-flow-move-03.txt, June 2003. 746 [7] Montavont, N. and T. Noel, "Home Agent Filtering For Mobile 747 IPv6", I-D draft-montavont-mobileip-ha-filtering-v6-00.txt, 748 July 2003. 750 [8] Koojana, K., Fikouras, N., Koensgen, A., and C. Goerg, "Filters 751 for Mobile IPv6 Bindings (NOMADv6)", 752 I-D draft-nomadv6-mobileip-filters-00.txt, July 2003. 754 [9] Wakikawa, R., Uehara, K., Ernst, T., and K. Nagami, "Multiple 755 careof address Registration on Mobile IPv6", 756 I-D draft-wakikawa-mobileip-multiplecoa-03.txt, June 2005. 758 [10] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 759 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 760 Agents", RFC 3776, June 2004. 762 [11] Ernst, T. and H-Y. Lach, "Network Mobility Support 763 Terminology", I-D draft-ietf-nemo-terminology-03, 764 February 2005. 766 Intellectual Property Statement 768 The IETF takes no position regarding the validity or scope of any 769 Intellectual Property Rights or other rights that might be claimed to 770 pertain to the implementation or use of the technology described in 771 this document or the extent to which any license under such rights 772 might or might not be available; nor does it represent that it has 773 made any independent effort to identify any such rights. Information 774 on the procedures with respect to rights in RFC documents can be 775 found in BCP 78 and BCP 79. 777 Copies of IPR disclosures made to the IETF Secretariat and any 778 assurances of licenses to be made available, or the result of an 779 attempt made to obtain a general license or permission for the use of 780 such proprietary rights by implementers or users of this 781 specification can be obtained from the IETF on-line IPR repository at 782 http://www.ietf.org/ipr. 784 The IETF invites any interested party to bring to its attention any 785 copyrights, patents or patent applications, or other proprietary 786 rights that may cover technology that may be required to implement 787 this standard. Please address the information to the IETF at 788 ietf-ipr@ietf.org. 790 Disclaimer of Validity 792 This document and the information contained herein are provided on an 793 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 794 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 795 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 796 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 797 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 798 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 800 Copyright Statement 802 Copyright (C) The Internet Society (2005). This document is subject 803 to the rights, licenses and restrictions contained in BCP 78, and 804 except as set forth therein, the authors retain all their rights. 806 Acknowledgment 808 Funding for the RFC Editor function is currently provided by the 809 Internet Society.