idnits 2.17.1 draft-devarapalli-netlmm-multihoming-03.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, updated by RFC 4748 on line 598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 622. 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 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 (August 22, 2008) is 5726 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) -- Possible downref: Normative reference to a draft: ref. '3' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM Working Group V. Devarapalli 3 Internet-Draft WiChorus 4 Intended status: Standards Track N. Kant 5 Expires: February 23, 2009 H. Lim 6 Stoke 7 C. Vogt 8 Ericsson 9 August 22, 2008 11 Multiple Interface Support with Proxy Mobile IPv6 12 draft-devarapalli-netlmm-multihoming-03.txt 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 February 23, 2009. 39 Abstract 41 Proxy Mobile IPv6 enables network-based mobility for a regular IPv6 42 mobile node with no mobility management protocol. It makes it appear 43 to the mobile node that its IP address does not change as the mobile 44 node moves across the Proxy Mobile IPv6 domain. There have been some 45 issues identified with supporting a host with multiple interfaces 46 attaching to the Proxy Mobile IPv6 domain. This document describes 47 and analyzes some of the scenarios associated with this. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Multiple Interface Scenarios . . . . . . . . . . . . . . . . . 4 54 3.1. Unique Prefix per Interface . . . . . . . . . . . . . . . 4 55 3.2. Unique Address per Interface . . . . . . . . . . . . . . . 5 56 3.3. Shared Address across Interfaces . . . . . . . . . . . . . 6 57 4. Handovers across Interfaces . . . . . . . . . . . . . . . . . 8 58 4.1. Requirements for a PMIPv6 Handover across Interfaces . . . 8 59 4.1.1. Removal of IP Address/Prefix from Old Interface . . . 8 60 4.1.2. Configuration of Same IP Address/Prefix on New 61 Interface . . . . . . . . . . . . . . . . . . . . . . 9 62 4.1.3. Update of Active Socket Structures . . . . . . . . . . 9 63 4.2. Handover across Interfaces using a PMIPv6 virtual 64 interface . . . . . . . . . . . . . . . . . . . . . . . . 9 65 4.3. Inter-Access Technology Handovers . . . . . . . . . . . . 9 66 4.4. Mobile node with three or more interfaces . . . . . . . . 11 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 74 Intellectual Property and Copyright Statements . . . . . . . . . . 15 76 1. Introduction 78 Proxy Mobile IPv6 [2] provides network-based mobility for a regular 79 IPv6 mobile node with no mobility management protocol. It is quite 80 straight forward to provide mobility for a mobile node with one 81 interface. There are some issues identified with supporting a host 82 with multiple interfaces attaching to the Proxy Mobile IPv6 domain. 84 The multiple interfaces on the mobile node could be of the same or 85 different access technology types. If the mobile node has multiple 86 interfaces attached to the Proxy Mobile IPv6 domain, and wishes to 87 use both interfaces simultaneously, the LMA and the MAGs in the Proxy 88 Mobile IPv6 domain must allow this. 90 The mobile node may also decide to handoff sessions from one 91 interface to another. The two interfaces involved in the handover 92 could be of the same or different access technology types. 94 In some cases, the mobile node may be assigned the same prefix across 95 two interfaces when both interfaces are attached to the Proxy Mobile 96 IPv6 domain. The mobile node may be a regular IPv6 host which cannot 97 handle the same prefix across two different interfaces. Some mobile 98 nodes have multi-homing support in the sense that they can connect to 99 the same subnet via two interfaces and still able to send and receive 100 packets on both interfaces. 102 This document analyzes three different scenarios with respect to a 103 mobile node with multiple interfaces attaching to a Proxy Mobile IPv6 104 domain. 106 o Assigning a unique prefix per interface of the mobile node. 107 o Assigning the same prefix across interfaces but a unique address 108 per interface. 109 o Shared address across interfaces. 111 In all three scenarios the mobile node is able to use the multiple 112 interfaces simultaneously to send and receive packets. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [1]. 120 3. Multiple Interface Scenarios 122 Three different scenarios are considered in this document. The 123 following sections describe and analyze the three scenarios. 125 3.1. Unique Prefix per Interface 127 In this scenario, each interface on the mobile node is assigned a 128 unique prefix. The LMA maintains multiple binding cache entries, one 129 entry per interface on the mobile node. The binding cache entries 130 may contain the Layer 2 interface identifier and the access 131 technology type of the corresponding interface on the mobile node. 132 The LMA also maintains two separate routes for prefix1 and prefix2. 134 LMA Binding Cache 135 +----+ ----------------- 136 |LMA | MN:if1 [prefix1] --> MAG1 137 +----+ MN:if2 [prefix2] --> MAG2 138 //\\ 139 +---------//--\\-------------+ 140 ( // \\ ) PMIPv6 domain 141 ( // \\ ) 142 +------//--------\\----------+ 143 // \\ 144 // \\ 145 +----+ +----+ 146 |MAG1| |MAG2| 147 +----+ +----+ 148 | | 149 | | 150 | if1 if2 | 151 +------[MN]------+ 153 Figure 1: Unique Prefix per Interface 155 The mobile node is able to use both interfaces simultaneously for 156 sending and receiving packets. Since the LMA maintains separate 157 route entries for prefix1 and prefix2, it encapsulates and forwards 158 the packets via the appropriate MAG. 160 When the mobile node moves and attaches to another MAG in the same 161 Proxy Mobile IPv6 domain, session continuity is maintained by 162 assigning the same prefix to the interface. If the mobile node moves 163 and attaches to MAG3 with if1, the MAG3 sends a Proxy Binding Update 164 message to the LMA with the access technology type and interface 165 identifier of if1. The LMA checks if there is an existing binding 166 cache entry for the mobile node for if1. If there is an existing 167 binding cache entry, the LMA assigns the same prefix previously 168 assigned and responds to MAG3. 170 If there is no L2 interface identifier that MAG3 could identify for 171 if1 and did not include the interface identifier in the Proxy Binding 172 Update, then the LMA does not know if this is a handover for if1 or 173 if the mobile node is attaching via a new interface to MAG3. The 174 LMA's decision is then based on what the Handoff Indicator field in 175 the Handoff Indicator option is set to. If MAG3 knows that the 176 mobile node was attached to another MAG in the same Proxy Mobile IPv6 177 domain using if1, then it must indicate to the LMA that it is a 178 handover. This would ensure that the mobile node sees the same 179 prefix for if1. Otherwise the mobile node ends up with a new prefix 180 for if1. 182 The Proxy Mobile IPv6 specification [2] does not specify any 183 mechanism for MAG3 to figure out if the mobile node is performing a 184 handover for if1 or if it is attaching to the Proxy Mobile IPv6 185 domain for the first time via if1. One option is for MAG3 to obtain 186 this information via context transfer from MAG1. This solution 187 requires a context transfer interface between MAG1 and MAG3. Another 188 option is for MAG3 to be told by the AAA infrastructure as part of 189 access authentication that the mobile node was previously attached to 190 the Proxy Mobile IPv6 domain via if1. However, this solution may not 191 work in case the AAA infrastructure does not store interface related 192 information or if the AAA infrastructure is not being used. One 193 solution that may work in most cases is for the mobile node to 194 indicate to MAG3 that it already has sessions on top of the prefix 195 assigned to if1 and it is performing a handover. The mobile node 196 conveys this information as part of Layer 2 setup. When MAG3 gets 197 this information, it sets the Handoff Indicator field in the Handoff 198 Indicator option to indicate a handover for if1. 200 Section 4 discusses handovers between interfaces using Proxy Mobile 201 IPv6 in more detail. 203 3.2. Unique Address per Interface 205 In this scenario, the mobile node is assigned the same prefix across 206 multiple interfaces, but with a unique address per interface. The 207 LMA maintains separate binding cache entries per address of the 208 mobile node. The LMA may also maintain a single binding cache entry, 209 but must have separate host route entries per address assigned to the 210 mobile node. This scenario illustrated in Figure 2 creates a multi- 211 homing scenario where the mobile node has connectivity via two 212 interfaces to the same subnet. 214 LMA Binding Cache 215 +----+ ----------------- 216 |LMA | MN:if1 [addr1] --> MAG1 217 +----+ MN:if2 [addr2] --> MAG2 218 //\\ 219 +---------//--\\-------------+ 220 ( // \\ ) PMIPv6 domain 222 ( // \\ ) 223 +------//--------\\----------+ 224 // \\ 225 // \\ 226 +----+ +----+ 227 |MAG1| |MAG2| 228 +----+ +----+ 229 | | 230 | | 231 | if1 if2 | 232 +------[MN]------+ 234 Figure 2: Unique Address per Interface 236 The mobile node is able to use both interfaces simultaneously for 237 sending and receiving packets. Since the LMA maintains separate host 238 route entries for addr1 and addr2, it encapsulates and forwards the 239 packets via the appropriate MAG. 241 This scenario however creates a multi-link subnet since the same 242 prefix is advertised over two different point-to-point links. 243 Neighbor discovery is not run across the two point-to-point links 244 even though the same prefix is used across the links. Please refer 245 to [5] for more information on issues regarding multi-link subnets. 247 3.3. Shared Address across Interfaces 249 In this scenario, the mobile node is assigned the same address across 250 multiple interfaces. This scenario enables a mobile node to use 251 different links, but make only one IP address visible to the 252 applications. The mobile node can send and receive packets for one 253 particular application flow over if1 and for another application flow 254 over if2. This scenario also enables a mobile node to combine two 255 low bandwidth links into a high bandwidth link. Figure 3 illustrates 256 this scenario. 258 LMA State 259 +----+ --------- 260 |LMA | MN:if1 [addr1, flow1] --> MAG1 261 +----+ MN:if2 [addr2, flow2] --> MAG2 262 //\\ 263 +---------//--\\-------------+ 264 ( // \\ ) PMIPv6 domain 265 ( // \\ ) 266 +------//--------\\----------+ 267 // \\ 268 // \\ 269 +----+ +----+ 270 |MAG1| |MAG2| 271 +----+ +----+ 272 | | 273 | | 274 | if1 if2 | 275 +------[MN]------+ 277 Figure 3: Shared Address across Interfaces 279 The LMA maintains only one binding cache entry per mobile node in 280 this scenario. However, the LMA maintains flow filters that indicate 281 routing to a particular MAG. For example, lets assume that the 282 mobile node has two separate flows, flow1 and flow2 and wants to run 283 flow1 over if1 and flow2 over if2. When the LMA receives a packet 284 for the mobile node, it checks the flow filters stored in the binding 285 cache entry. If the packets match filter1, the LMA tunnels the 286 packets to MAG1. 288 For this scenario to work, the mobile node must be able to indicate 289 to the attached MAG which flow will be sent over the attachment to 290 the MAG. It may do this by indicating the service identifier during 291 the layer 2 attachment to the MAG. The service identifier is 292 described in [4]. The MAG, in turn must include the flow information 293 in the Proxy Binding Update sent to the LMA. The MAG may use the 294 Service Selection option [4] in the Proxy Binding Update to indicate 295 the flow information. The MAG may also construct a flow filter and 296 convey the information in the Proxy Binding Update. See [3] for more 297 information on carrying flow filters in the proxy binding update. 299 The LMA processes the Proxy Binding Update from the MAG and creates a 300 filter based on the flow information. The flow filters may be stored 301 in the binding cache entry for the mobile node. 303 4. Handovers across Interfaces 305 The followings describe handovers across multitple interfaces on a 306 mobile node using Proxy Mobile IPv6. 308 4.1. Requirements for a PMIPv6 Handover across Interfaces 310 Using Proxy Mobile IPv6 for handovers across interfaces requires the 311 following at the minimum on the mobile node. 313 o Removal of the IP address/prefix from the old interface. 314 o Configuration of the same IP address/prefix on the new interface. 315 o Update of active socket structures to the new interface. 317 The following describes the requirements for a handover across 318 interface in more detail. 320 4.1.1. Removal of IP Address/Prefix from Old Interface 322 An IP address can be removed from the old interface through a tear- 323 down of the link-layer connection, provided the IP address was auto- 324 configured. Standard host stack implementations remove auto- 325 configured IP addresses from interfaces that have lost link-layer 326 connectivity. The advantage of this mechanism is that it is network- 327 controlled and does not require special host functionality. A 328 disadvantage of the mechanism is its coarse granularity: A link-layer 329 connectivity tear-down leads to the removal of all IP addresses on an 330 interface. So if an interface has multiple IP addresses, all of them 331 are removed, yet a handover may be desired for only one of them. 333 Link-layer connectivity tear-down is the only means by which a 334 network can control the removal of an IP address from an old 335 interface. Standard host stack implementations generally do not 336 accept IP layer control messages as a trigger for IP address removal. 337 For example, zero-lifetime advertisements for an IP address prefix in 338 Router Advertisement messages [6] are ignored in an effort to protect 339 against denial-of-service attacks. 341 Alternative mechanisms to remove an IP address from the old interface 342 therefore require new functionality on mobile nodes. The handover 343 may be indicated by the network, such as through a zero-lifetime 344 advertisement for an IP address prefix in Router Advertisement 345 messages. But it is the mobile node which must correctly interpret 346 such indication and remove the corresponding IP address. 348 4.1.2. Configuration of Same IP Address/Prefix on New Interface 350 A successful handover across interfaces requires a mobile node to 351 configure the new interface with the same IP address that was 352 previously used on the old interface. The standard mechanism for 353 autonomous address auto-configuration in IPv6, Stateless Address 354 Autoconfiguration [7], does not support this. It derives IP 355 addresses from the respective interface identifiers, and thus 356 generates different IP addresses on different interfaces. 358 Configuration of the same IP address on a new interface therefore 359 requires either network-controlled IP address configuration through 360 DHCPv6, L2 address assignment mechanisms or new functionality on the 361 mobile nodes. 363 4.1.3. Update of Active Socket Structures 365 Typically, sockets structures are opened based on the address 366 assigned to an interface. As long as the address is available on one 367 of the interfaces on the mobile node, the active sockets should not 368 get affected. However, many implementations today include a pointer 369 to the interface in socket structures. This makes handovers between 370 different interfaces impossible. Handovers across interfaces may 371 therefore require modifications to such implementations to make 372 socket structures interface-independent. 374 4.2. Handover across Interfaces using a PMIPv6 virtual interface 376 The mobile node may also implement a virtual interface that hides the 377 multiple physical interfaces involved in the handover. The address 378 that the mobile node configures, when it is attached to the Proxy 379 Mobile IPv6 domain, is assigned to the virtual interface. Only the 380 virtual interface and the address configured on the virtual interface 381 are visible to the applications on the mobile node. 383 If only one interface is active at a time, then the mobile node maps 384 the virtual interface to the active physical interface. When a 385 handover happens, the mobile node maps the virtual interface to the 386 new active physical interface. The implementation of this virtual 387 interface can be done in a manner similar to the Linux Port Bonding 388 [8]. The actual implementation details are out of scope of this 389 document. 391 4.3. Inter-Access Technology Handovers 393 This section considers a handover scenario where the mobile node 394 performs a handover between interfaces that belong to different 395 access technologies. 397 The mobile node is initially attached to the Proxy Mobile IPv6 domain 398 via MAG1 using if1 as show in Figure 4. 400 LMA Binding Cache 401 +----+ ----------------- 402 |LMA | MN:if1 [prefix1] --> MAG1 403 +----+ 404 //\\ 405 +---------//--\\-------------+ 406 ( // \\ ) PMIPv6 domain 407 ( // \\ ) 408 +------//--------\\----------+ 409 // \\ 410 // \\ 411 +----+ +----+ 412 |MAG1| |MAG2| 413 +----+ +----+ 414 | 415 | 416 | if1 if2 417 +------[MN]------ 419 Figure 4: Mobile Node attached via if1 421 The mobile node moves and attaches to the same Proxy Mobile IPv6 422 domain via MAG2 using if2. The mobile node may not have connectivity 423 on if1 anymore. The LMA assigns the same prefix for if2 and updates 424 its binding cache entry. This is illustrated in Figure 5. 426 LMA Binding Cache 427 +----+ ----------------- 428 |LMA | MN:if2 [prefix1] --> MAG2 429 +----+ 430 //\\ 431 +---------//--\\-------------+ 432 ( // \\ ) PMIPv6 domain 433 ( // \\ ) 434 +------//--------\\----------+ 435 // \\ 436 // \\ 437 +----+ +----+ 438 |MAG1| |MAG2| 439 +----+ +----+ 440 | 441 | 442 if1 if2 | 443 ------[MN]------+ 445 Figure 5: Mobile Node Performs Handover to if2 447 For the above inter-access technology handover to work, the LMA must 448 know that this is a handover involving two different interfaces of 449 the mobile node. The Interface Identifier option if present in the 450 Proxy Binding Update from MAG2 will have a different identifier from 451 what is stored in the binding cache entry on the LMA. So this might 452 appear to the LMA as if the mobile node is attaching via a different 453 interface. The Proxy Binding Update from MAG2 MUST have the Handoff 454 Indicator field in the Handoff Indicator option set to "2" or "3" to 455 indicate that it is a handover. See Section 3.1 for a detailed 456 description of how MAG2 determines when to indicate in the Proxy 457 Binding Update that it is a handover. 459 The mobile node must also be able to move the prefix from if1 to if2 460 during the handover for the inter-access technology handover to work. 461 The mobile node should satisfy the requirements listed in Section 4.1 462 for the handover to work. 464 4.4. Mobile node with three or more interfaces 466 This section considers a handover scenario for a mobile node with 467 three or more interfaces and performing a handover from if1 to if3 468 while staying connected over if2. It is assumed that the mobile node 469 is attached to MAG1 using if1, MAG2 using if2 and MAG3 using if3. In 470 this scenario, even if MAG3 knows that it is a handover, it does not 471 which two interfaces are involved in the handover. The AAA 472 infrastructure does not help here since the AAA does not know which 473 interface is being handed off to which one. The only possible 474 solution here is for the mobile node to tell MAG3 more information 475 about if1 or the home network prefix assigned to if1 or information 476 about MAG1. MAG3 may indicate in the Proxy Binding Update 477 information about if1 or the prefix assigned to if1 in the Proxy 478 Binding Update sent to the LMA. The LMA uses this information to 479 assign the prefix that was assigned to if1 to if3 also. In case the 480 mobile node provides information about MAG1, then MAG3 can contact 481 MAG1 over a context transfer interface and obtain more information 482 about if1 or the home network prefix assigned to if1. In all cases, 483 MAG3 indicates that it is a handover in the Proxy Binding Update. 485 Yet another handover scenario is where the mobile is attached to MAG1 486 via if1 and MAG2 via if2, decides to attach to MAG2 via if3 and 487 perform a handover from the if1 to if3. In this scenario, the mobile 488 node must indicate to MAG2 that it is performing a handover from if1 489 by providing information about if1 when attaching to MAG2 using if3. 490 MAG2 would then treat the attachment over if3 as a handover from if1 491 and will indicate this in this Proxy Binding Update to the LMA. The 492 LMA would then assign the same prefix that was previously assigned 493 for if1. MAG would further treat existing attachment over if2 494 separately and cause no modifications to the sessions over if2. 496 5. Security Considerations 498 This document mainly analyzes some of the scenarios arising out of a 499 mobile node with multiple interfaces attaching to a Proxy Mobile IPv6 500 domain. It does not introduce any new security concerns on top of 501 what is described in the Security Considerations section of [2]. 503 6. IANA Considerations 505 This document does not request any assignments from IANA. 507 7. Acknowledgements 509 Many of the issues related to using Proxy Mobile IPv6 with a mobile 510 node with multiple interfaces were discussed on the NETLMM mailing 511 list. This document tries to capture those issues. Therefore the 512 authors would like to thank all the folks involved in those 513 discussions. 515 The authors would also like to think Sri Gundavelli, Kuntal 516 Chowdhury, Basavaraj Patil, Vidya Narayanan, and George Tsirtsis for 517 some interesting discussions in this space. 519 8. References 521 8.1. Normative References 523 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 524 Levels", BCP 14, RFC 2119, March 1997. 526 [2] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and 527 B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-18 528 (work in progress), May 2008. 530 [3] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi, 531 "Flow Bindings in Mobile IPv6 and Nemo Basic Support", 532 draft-soliman-monami6-flow-binding-05 (work in progress), 533 November 2007. 535 8.2. Informative References 537 [4] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service 538 Selection for Mobile IPv6", RFC 5149, February 2008. 540 [5] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007. 542 [6] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor 543 Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. 545 [7] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address 546 Autoconfiguration", RFC 4862, September 2007. 548 [8] "Linux Port Bonding", 549 http://linux-ip.net/html/ether-bonding.html . 551 Authors' Addresses 553 Vijay Devarapalli 554 WiChorus 555 3950 North First Street 556 San Jose, CA 95134 557 USA 559 Email: vijay@wichorus.com 560 Nishi Kant 561 Stoke 562 5403 Betsy Ross Drive 563 Santa Clara, CA 95054 564 USA 566 Email: nishi@stoke.com 568 Heeseon Lim 569 Stoke 570 5403 Betsy Ross Drve 571 Santa Clara, CA 95054 572 USA 574 Email: hlim@stoke.com 576 Christian Vogt 577 Ericsson Research, NomadicLab 578 Hirsalantie 11 579 02420 Jorvas 580 Finland 582 Email: christian.vogt@ericsson.com 584 Full Copyright Statement 586 Copyright (C) The IETF Trust (2008). 588 This document is subject to the rights, licenses and restrictions 589 contained in BCP 78, and except as set forth therein, the authors 590 retain all their rights. 592 This document and the information contained herein are provided on an 593 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 594 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 595 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 596 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 597 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 598 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 600 Intellectual Property 602 The IETF takes no position regarding the validity or scope of any 603 Intellectual Property Rights or other rights that might be claimed to 604 pertain to the implementation or use of the technology described in 605 this document or the extent to which any license under such rights 606 might or might not be available; nor does it represent that it has 607 made any independent effort to identify any such rights. Information 608 on the procedures with respect to rights in RFC documents can be 609 found in BCP 78 and BCP 79. 611 Copies of IPR disclosures made to the IETF Secretariat and any 612 assurances of licenses to be made available, or the result of an 613 attempt made to obtain a general license or permission for the use of 614 such proprietary rights by implementers or users of this 615 specification can be obtained from the IETF on-line IPR repository at 616 http://www.ietf.org/ipr. 618 The IETF invites any interested party to bring to its attention any 619 copyrights, patents or patent applications, or other proprietary 620 rights that may cover technology that may be required to implement 621 this standard. Please address the information to the IETF at 622 ietf-ipr@ietf.org.