idnits 2.17.1 draft-devarapalli-netext-multi-interface-support-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 date (March 3, 2009) is 5530 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) == Outdated reference: A later version (-11) exists of draft-ietf-mext-flow-binding-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT Working Group V. Devarapalli 3 Internet-Draft WiChorus 4 Intended status: Standards Track N. Kant 5 Expires: September 4, 2009 H. Lim 6 Stoke 7 C. Vogt 8 Ericsson 9 March 3, 2009 11 Multiple Interface Support with Proxy Mobile IPv6 12 draft-devarapalli-netext-multi-interface-support-00.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may not be modified, 18 and derivative works of it may not be created, except to format it 19 for publication as an RFC or to translate it into languages other 20 than English. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 4, 2009. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 Proxy Mobile IPv6 enables network-based mobility for a regular IPv6 54 mobile node with no mobility management protocol. It makes it appear 55 to the mobile node that its IP address does not change as the mobile 56 node moves across the Proxy Mobile IPv6 domain. There have been some 57 issues identified with supporting a host with multiple interfaces 58 attaching to the Proxy Mobile IPv6 domain. This document describes 59 and analyzes some of the scenarios associated with this. It also 60 describes the requirements for a handover across interfaces using 61 Proxy Mobile IPv6. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Multiple Interface Scenarios . . . . . . . . . . . . . . . . . 4 68 3.1. Unique Prefix per Interface . . . . . . . . . . . . . . . 4 69 3.2. Unique Address per Interface . . . . . . . . . . . . . . . 5 70 3.3. Shared Address across Interfaces . . . . . . . . . . . . . 6 71 4. Handovers across Interfaces . . . . . . . . . . . . . . . . . 8 72 4.1. Requirements for a PMIPv6 Handover across Interfaces . . . 8 73 4.1.1. Removal of IP Address/Prefix from Old Interface . . . 8 74 4.1.2. Configuration of Same IP Address/Prefix on New 75 Interface . . . . . . . . . . . . . . . . . . . . . . 9 76 4.1.3. Update of Active Socket Structures . . . . . . . . . . 9 77 4.2. Handover across Interfaces using a PMIPv6 virtual 78 interface . . . . . . . . . . . . . . . . . . . . . . . . 9 79 4.3. Inter-Access Technology Handovers . . . . . . . . . . . . 9 80 4.4. Mobile node with three or more interfaces . . . . . . . . 11 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 86 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Introduction 91 Proxy Mobile IPv6 [2] provides network-based mobility for a regular 92 IPv6 mobile node with no mobility management protocol. It is quite 93 straight forward to provide mobility for a mobile node with one 94 interface. There are some issues identified with supporting a host 95 with multiple interfaces attaching to the Proxy Mobile IPv6 domain. 97 The multiple interfaces on the mobile node could be of the same or 98 different access technology types. If the mobile node has multiple 99 interfaces attached to the Proxy Mobile IPv6 domain, and wishes to 100 use both interfaces simultaneously, the LMA and the MAGs in the Proxy 101 Mobile IPv6 domain must allow this. 103 The mobile node may also decide to handoff sessions from one 104 interface to another. The two interfaces involved in the handover 105 could be of the same or different access technology types. 107 In some cases, the mobile node may be assigned the same prefix across 108 two interfaces when both interfaces are attached to the Proxy Mobile 109 IPv6 domain. The mobile node may be a regular IPv6 host which cannot 110 handle the same prefix across two different interfaces. Some mobile 111 nodes have multi-homing support in the sense that they can connect to 112 the same subnet via two interfaces and still able to send and receive 113 packets on both interfaces. 115 This document analyzes three different scenarios with respect to a 116 mobile node with multiple interfaces attaching to a Proxy Mobile IPv6 117 domain. 119 o Assigning a unique prefix per interface of the mobile node. 120 o Assigning the same prefix across interfaces but a unique address 121 per interface. 122 o Shared address across interfaces. 124 In all three scenarios the mobile node is able to use the multiple 125 interfaces simultaneously to send and receive packets. 127 This document also analyzes the requirements on a IPv6 host to 128 support a handover across interfaces when Proxy Mobile IPv6 is used 129 in Section 4.1. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [1]. 137 3. Multiple Interface Scenarios 139 Three different scenarios are considered in this document. The 140 following sections describe and analyze the three scenarios. 142 3.1. Unique Prefix per Interface 144 In this scenario, each interface on the mobile node is assigned a 145 unique prefix. The LMA maintains multiple binding cache entries, one 146 entry per interface on the mobile node. The binding cache entries 147 may contain the Layer 2 interface identifier and the access 148 technology type of the corresponding interface on the mobile node. 149 The LMA also maintains two separate routes for prefix1 and prefix2. 151 LMA Binding Cache 152 +----+ ----------------- 153 |LMA | MN:if1 [prefix1] --> MAG1 154 +----+ MN:if2 [prefix2] --> MAG2 155 //\\ 156 +---------//--\\-------------+ 157 ( // \\ ) PMIPv6 domain 158 ( // \\ ) 159 +------//--------\\----------+ 160 // \\ 161 // \\ 162 +----+ +----+ 163 |MAG1| |MAG2| 164 +----+ +----+ 165 | | 166 | | 167 | if1 if2 | 168 +------[MN]------+ 170 Figure 1: Unique Prefix per Interface 172 The mobile node is able to use both interfaces simultaneously for 173 sending and receiving packets. Since the LMA maintains separate 174 route entries for prefix1 and prefix2, it encapsulates and forwards 175 the packets via the appropriate MAG. 177 When the mobile node moves and attaches to another MAG in the same 178 Proxy Mobile IPv6 domain, session continuity is maintained by 179 assigning the same prefix to the interface. If the mobile node moves 180 and attaches to MAG3 with if1, the MAG3 sends a Proxy Binding Update 181 message to the LMA with the access technology type and interface 182 identifier of if1. The LMA checks if there is an existing binding 183 cache entry for the mobile node for if1. If there is an existing 184 binding cache entry, the LMA assigns the same prefix previously 185 assigned and responds to MAG3. 187 If there is no L2 interface identifier that MAG3 could identify for 188 if1 and did not include the interface identifier in the Proxy Binding 189 Update, then the LMA does not know if this is a handover for if1 or 190 if the mobile node is attaching via a new interface to MAG3. The 191 LMA's decision is then based on what the Handoff Indicator field in 192 the Handoff Indicator option is set to. If MAG3 knows that the 193 mobile node was attached to another MAG in the same Proxy Mobile IPv6 194 domain using if1, then it must indicate to the LMA that it is a 195 handover. This would ensure that the mobile node sees the same 196 prefix for if1. Otherwise the mobile node ends up with a new prefix 197 for if1. 199 The Proxy Mobile IPv6 specification [2] does not specify any 200 mechanism for MAG3 to figure out if the mobile node is performing a 201 handover for if1 or if it is attaching to the Proxy Mobile IPv6 202 domain for the first time via if1. One option is for MAG3 to obtain 203 this information via context transfer from MAG1. This solution 204 requires a context transfer interface between MAG1 and MAG3. Another 205 option is for MAG3 to be told by the AAA infrastructure as part of 206 access authentication that the mobile node was previously attached to 207 the Proxy Mobile IPv6 domain via if1. However, this solution may not 208 work in case the AAA infrastructure does not store interface related 209 information or if the AAA infrastructure is not being used. One 210 solution that may work in most cases is for the mobile node to 211 indicate to MAG3 that it already has sessions on top of the prefix 212 assigned to if1 and it is performing a handover. The mobile node 213 conveys this information as part of Layer 2 setup. When MAG3 gets 214 this information, it sets the Handoff Indicator field in the Handoff 215 Indicator option to indicate a handover for if1. 217 Section 4 discusses handovers between interfaces using Proxy Mobile 218 IPv6 in more detail. 220 3.2. Unique Address per Interface 222 In this scenario, the mobile node is assigned the same prefix across 223 multiple interfaces, but with a unique address per interface. The 224 LMA maintains separate binding cache entries per address of the 225 mobile node. The LMA may also maintain a single binding cache entry, 226 but must have separate host route entries per address assigned to the 227 mobile node. This scenario illustrated in Figure 2 creates a multi- 228 homing scenario where the mobile node has connectivity via two 229 interfaces to the same subnet. 231 LMA Binding Cache 232 +----+ ----------------- 233 |LMA | MN:if1 [addr1] --> MAG1 234 +----+ MN:if2 [addr2] --> MAG2 235 //\\ 236 +---------//--\\-------------+ 237 ( // \\ ) PMIPv6 domain 239 ( // \\ ) 240 +------//--------\\----------+ 241 // \\ 242 // \\ 243 +----+ +----+ 244 |MAG1| |MAG2| 245 +----+ +----+ 246 | | 247 | | 248 | if1 if2 | 249 +------[MN]------+ 251 Figure 2: Unique Address per Interface 253 The mobile node is able to use both interfaces simultaneously for 254 sending and receiving packets. Since the LMA maintains separate host 255 route entries for addr1 and addr2, it encapsulates and forwards the 256 packets via the appropriate MAG. 258 This scenario however creates a multi-link subnet since the same 259 prefix is advertised over two different point-to-point links. 260 Neighbor discovery is not run across the two point-to-point links 261 even though the same prefix is used across the links. Please refer 262 to [5] for more information on issues regarding multi-link subnets. 264 3.3. Shared Address across Interfaces 266 In this scenario, the mobile node is assigned the same address across 267 multiple interfaces. This scenario enables a mobile node to use 268 different links, but make only one IP address visible to the 269 applications. The mobile node can send and receive packets for one 270 particular application flow over if1 and for another application flow 271 over if2. This scenario also enables a mobile node to combine two 272 low bandwidth links into a high bandwidth link. Figure 3 illustrates 273 this scenario. 275 LMA State 276 +----+ --------- 277 |LMA | MN:if1 [addr, flow1] --> MAG1 278 +----+ MN:if2 [addr, flow2] --> MAG2 279 //\\ 280 +---------//--\\-------------+ 281 ( // \\ ) PMIPv6 domain 282 ( // \\ ) 283 +------//--------\\----------+ 284 // \\ 285 // \\ 286 +----+ +----+ 287 |MAG1| |MAG2| 288 +----+ +----+ 289 | | 290 | | 291 | if1 if2 | 292 +------[MN]------+ 294 Figure 3: Shared Address across Interfaces 296 The LMA maintains only one binding cache entry per mobile node in 297 this scenario. However, the LMA maintains flow filters that indicate 298 routing to a particular MAG. For example, lets assume that the 299 mobile node has two separate flows, flow1 and flow2 and wants to run 300 flow1 over if1 and flow2 over if2. When the LMA receives a packet 301 for the mobile node, it checks the flow filters stored in the binding 302 cache entry. If the packets match filter1, the LMA tunnels the 303 packets to MAG1. 305 For this scenario to work, the mobile node must be able to indicate 306 to the attached MAG which flow will be sent over the attachment to 307 the MAG. It may do this by indicating the service identifier during 308 the layer 2 attachment to the MAG. The service identifier is 309 described in [4]. The MAG, in turn must include the flow information 310 in the Proxy Binding Update sent to the LMA. The MAG may use the 311 Service Selection option [4] in the Proxy Binding Update to indicate 312 the flow information. The MAG may also construct a flow filter and 313 convey the information in the Proxy Binding Update. See [3] for more 314 information on carrying flow filters in the proxy binding update. 316 The LMA processes the Proxy Binding Update from the MAG and creates a 317 filter based on the flow information. The flow filters may be stored 318 in the binding cache entry for the mobile node. 320 4. Handovers across Interfaces 322 The followings describe handovers across multiple interfaces on a 323 mobile node using Proxy Mobile IPv6. 325 4.1. Requirements for a PMIPv6 Handover across Interfaces 327 Using Proxy Mobile IPv6 for handovers across interfaces requires the 328 following at the minimum on the mobile node. 330 o Removal of the IP address/prefix from the old interface. 331 o Configuration of the same IP address/prefix on the new interface. 332 o Update of active socket structures to the new interface. 334 The following describes the requirements for a handover across 335 interface in more detail. 337 4.1.1. Removal of IP Address/Prefix from Old Interface 339 An IP address can be removed from the old interface through a tear- 340 down of the link-layer connection, provided the IP address was auto- 341 configured. Standard host stack implementations remove auto- 342 configured IP addresses from interfaces that have lost link-layer 343 connectivity. The advantage of this mechanism is that it is network- 344 controlled and does not require special host functionality. A 345 disadvantage of the mechanism is its coarse granularity: A link-layer 346 connectivity tear-down leads to the removal of all IP addresses on an 347 interface. So if an interface has multiple IP addresses, all of them 348 are removed, yet a handover may be desired for only one of them. 350 Link-layer connectivity tear-down is the only means by which a 351 network can control the removal of an IP address from an old 352 interface. Standard host stack implementations generally do not 353 accept IP layer control messages as a trigger for IP address removal. 354 For example, zero-lifetime advertisements for an IP address prefix in 355 Router Advertisement messages [6] are ignored in an effort to protect 356 against denial-of-service attacks. 358 Alternative mechanisms to remove an IP address from the old interface 359 therefore require new functionality on mobile nodes. The handover 360 may be indicated by the network, such as through a zero-lifetime 361 advertisement for an IP address prefix in Router Advertisement 362 messages. But it is the mobile node which must correctly interpret 363 such indication and remove the corresponding IP address. 365 4.1.2. Configuration of Same IP Address/Prefix on New Interface 367 A successful handover across interfaces requires a mobile node to 368 configure the new interface with the same IP address that was 369 previously used on the old interface. The standard mechanism for 370 autonomous address auto-configuration in IPv6, Stateless Address 371 Autoconfiguration [7], does not support this. It derives IP 372 addresses from the respective interface identifiers, and thus 373 generates different IP addresses on different interfaces. 375 Configuration of the same IP address on a new interface therefore 376 requires either network-controlled IP address configuration through 377 DHCPv6, L2 address assignment mechanisms or new functionality on the 378 mobile nodes. 380 4.1.3. Update of Active Socket Structures 382 Typically, sockets structures are opened based on the address 383 assigned to an interface. As long as the address is available on one 384 of the interfaces on the mobile node, the active sockets should not 385 get affected. However, many implementations today include a pointer 386 to the interface in socket structures. This makes handovers between 387 different interfaces impossible. Handovers across interfaces may 388 therefore require modifications to such implementations to make 389 socket structures interface-independent. 391 4.2. Handover across Interfaces using a PMIPv6 virtual interface 393 The mobile node may also implement a virtual interface that hides the 394 multiple physical interfaces involved in the handover. The address 395 that the mobile node configures, when it is attached to the Proxy 396 Mobile IPv6 domain, is assigned to the virtual interface. Only the 397 virtual interface and the address configured on the virtual interface 398 are visible to the applications on the mobile node. 400 If only one interface is active at a time, then the mobile node maps 401 the virtual interface to the active physical interface. When a 402 handover happens, the mobile node maps the virtual interface to the 403 new active physical interface. The implementation of this virtual 404 interface can be done in a manner similar to the Linux Port Bonding 405 [8]. The actual implementation details are out of scope of this 406 document. 408 4.3. Inter-Access Technology Handovers 410 This section considers a handover scenario where the mobile node 411 performs a handover between interfaces that belong to different 412 access technologies. 414 The mobile node is initially attached to the Proxy Mobile IPv6 domain 415 via MAG1 using if1 as show in Figure 4. 417 LMA Binding Cache 418 +----+ ----------------- 419 |LMA | MN:if1 [prefix1] --> MAG1 420 +----+ 421 //\\ 422 +---------//--\\-------------+ 423 ( // \\ ) PMIPv6 domain 424 ( // \\ ) 425 +------//--------\\----------+ 426 // \\ 427 // \\ 428 +----+ +----+ 429 |MAG1| |MAG2| 430 +----+ +----+ 431 | 432 | 433 | if1 if2 434 +------[MN]------ 436 Figure 4: Mobile Node attached via if1 438 The mobile node moves and attaches to the same Proxy Mobile IPv6 439 domain via MAG2 using if2. The mobile node may not have connectivity 440 on if1 anymore. The LMA assigns the same prefix for if2 and updates 441 its binding cache entry. This is illustrated in Figure 5. 443 LMA Binding Cache 444 +----+ ----------------- 445 |LMA | MN:if2 [prefix1] --> MAG2 446 +----+ 447 //\\ 448 +---------//--\\-------------+ 449 ( // \\ ) PMIPv6 domain 450 ( // \\ ) 451 +------//--------\\----------+ 452 // \\ 453 // \\ 454 +----+ +----+ 455 |MAG1| |MAG2| 456 +----+ +----+ 457 | 458 | 459 if1 if2 | 460 ------[MN]------+ 462 Figure 5: Mobile Node Performs Handover to if2 464 For the above inter-access technology handover to work, the LMA must 465 know that this is a handover involving two different interfaces of 466 the mobile node. The Interface Identifier option if present in the 467 Proxy Binding Update from MAG2 will have a different identifier from 468 what is stored in the binding cache entry on the LMA. So this might 469 appear to the LMA as if the mobile node is attaching via a different 470 interface. The Proxy Binding Update from MAG2 MUST have the Handoff 471 Indicator field in the Handoff Indicator option set to "2" or "3" to 472 indicate that it is a handover. See Section 3.1 for a detailed 473 description of how MAG2 determines when to indicate in the Proxy 474 Binding Update that it is a handover. 476 The mobile node must also be able to move the prefix from if1 to if2 477 during the handover for the inter-access technology handover to work. 478 The mobile node should satisfy the requirements listed in Section 4.1 479 for the handover to work. 481 4.4. Mobile node with three or more interfaces 483 This section considers a handover scenario for a mobile node with 484 three or more interfaces and performing a handover from if1 to if3 485 while staying connected over if2. It is assumed that the mobile node 486 is attached to MAG1 using if1, MAG2 using if2 and MAG3 using if3. In 487 this scenario, even if MAG3 knows that it is a handover, it does not 488 which two interfaces are involved in the handover. The AAA 489 infrastructure does not help here since the AAA does not know which 490 interface is being handed off to which one. The only possible 491 solution here is for the mobile node to tell MAG3 more information 492 about if1 or the home network prefix assigned to if1 or information 493 about MAG1. MAG3 may indicate in the Proxy Binding Update 494 information about if1 or the prefix assigned to if1 in the Proxy 495 Binding Update sent to the LMA. The LMA uses this information to 496 assign the prefix that was assigned to if1 to if3 also. In case the 497 mobile node provides information about MAG1, then MAG3 can contact 498 MAG1 over a context transfer interface and obtain more information 499 about if1 or the home network prefix assigned to if1. In all cases, 500 MAG3 indicates that it is a handover in the Proxy Binding Update. 502 Yet another handover scenario is where the mobile is attached to MAG1 503 via if1 and MAG2 via if2, decides to attach to MAG2 via if3 and 504 perform a handover from the if1 to if3. In this scenario, the mobile 505 node must indicate to MAG2 that it is performing a handover from if1 506 by providing information about if1 when attaching to MAG2 using if3. 507 MAG2 would then treat the attachment over if3 as a handover from if1 508 and will indicate this in this Proxy Binding Update to the LMA. The 509 LMA would then assign the same prefix that was previously assigned 510 for if1. MAG would further treat existing attachment over if2 511 separately and cause no modifications to the sessions over if2. 513 5. Security Considerations 515 This document mainly analyzes some of the scenarios arising out of a 516 mobile node with multiple interfaces attaching to a Proxy Mobile IPv6 517 domain. It does not introduce any new security concerns on top of 518 what is described in the Security Considerations section of [2]. 520 6. IANA Considerations 522 This document does not request any assignments from IANA. 524 7. Acknowledgements 526 Many of the issues related to using Proxy Mobile IPv6 with a mobile 527 node with multiple interfaces were discussed on the NETLMM mailing 528 list. This document tries to capture those issues. Therefore the 529 authors would like to thank all the folks involved in those 530 discussions. 532 The authors would also like to think Sri Gundavelli, Kuntal 533 Chowdhury, Basavaraj Patil, Vidya Narayanan, and George Tsirtsis for 534 some interesting discussions in this space. 536 8. References 538 8.1. Normative References 540 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 541 Levels", BCP 14, RFC 2119, March 1997. 543 [2] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and 544 B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 546 [3] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi, 547 "Flow Bindings in Mobile IPv6 and Nemo Basic Support", 548 draft-ietf-mext-flow-binding-00 (work in progress), May 2008. 550 8.2. Informative References 552 [4] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service 553 Selection for Mobile IPv6", RFC 5149, February 2008. 555 [5] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007. 557 [6] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor 558 Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. 560 [7] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address 561 Autoconfiguration", RFC 4862, September 2007. 563 [8] "Linux Port Bonding", 564 http://linux-ip.net/html/ether-bonding.html . 566 Authors' Addresses 568 Vijay Devarapalli 569 WiChorus 570 3950 North First Street 571 San Jose, CA 95134 572 USA 574 Email: vijay@wichorus.com 575 Nishi Kant 576 Stoke 577 5403 Betsy Ross Drive 578 Santa Clara, CA 95054 579 USA 581 Email: nishi@stoke.com 583 Heeseon Lim 584 Stoke 585 5403 Betsy Ross Drve 586 Santa Clara, CA 95054 587 USA 589 Email: hlim@stoke.com 591 Christian Vogt 592 Ericsson Research, NomadicLab 593 Hirsalantie 11 594 02420 Jorvas 595 Finland 597 Email: christian.vogt@ericsson.com