idnits 2.17.1 draft-yang-mif-req-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/.) 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 : ---------------------------------------------------------------------------- ** 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 396: '... R1 - MIF MUST cover IPv4 only, IPv6...' RFC 2119 keyword, line 482: '...rce address for the response SHOULD be...' RFC 2119 keyword, line 565: '...xchange policies MUST support security...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 27, 2009) is 5536 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'Nordmark09' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'OMA-DM' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 598, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 608, but no explicit reference was found in the text == Unused Reference: 'RFC4191' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'RFC5113' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'RFC5213' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'Wakikawa09' is defined on line 626, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-blanchet-mif-problem-statement-00 ** Downref: Normative reference to an Informational draft: draft-blanchet-mif-problem-statement (ref. 'Blanchet08') -- Possible downref: Non-RFC (?) normative reference: ref. 'OMA-DM' ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Downref: Normative reference to an Informational RFC: RFC 5113 ** Downref: Normative reference to an Experimental draft: draft-savolainen-6man-fqdn-based-if-selection (ref. 'Savolainen08') == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-11 Summary: 7 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Yang 3 Internet-Draft Hitachi (China) R&D Corp 4 Intended status: Standards Track P. Seite 5 Expires: August 31, 2009 France Telecom 6 C. Williams 7 J. Qin 8 ZTE 9 February 27, 2009 11 Requirements on multiple Interface (MIF) of simple IP 12 draft-yang-mif-req-00 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. 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 August 31, 2009. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This draft makes a summary on the requirements of supporting multiple 51 interfaces (MIF) in hosts with simple IP. These requirements result 52 from examining scenarios for multiple interface host usages. The 53 differentiation between MIF and other related IETF works are 54 interpreted as well. 56 Table of Contents 58 1. introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Challenges for multi-homed simple IP support . . . . . . . 6 60 2. Scenarios of service sets for Multi-interfaced Hosts . . . . . 7 61 2.1. Sets of services are the same . . . . . . . . . . . . . . 7 62 2.2. Set of services are different . . . . . . . . . . . . . . 7 63 2.3. Set of services are partially overlapping . . . . . . . . 8 64 2.4. Inclusion of a set of services . . . . . . . . . . . . . . 8 65 2.5. Combination of services . . . . . . . . . . . . . . . . . 9 66 3. Requirements of MIF . . . . . . . . . . . . . . . . . . . . . 10 67 3.1. General Requirements . . . . . . . . . . . . . . . . . . . 10 68 3.2. Requirements on MIF routing . . . . . . . . . . . . . . . 10 69 3.3. Requirements on merging of IP layer autoconfiguration . . 11 70 3.4. split DNS . . . . . . . . . . . . . . . . . . . . . . . . 11 71 4. Related IETF works . . . . . . . . . . . . . . . . . . . . . . 13 72 4.1. relationship with current internet hosts (RFC1122) . . . . 13 73 4.2. Network Discovery and Selection Problem (RFC5113) . . . . 13 74 4.3. PMIPv6 & Monami6 . . . . . . . . . . . . . . . . . . . . . 13 75 4.4. Default address selection (RFC3484) . . . . . . . . . . . 14 76 4.5. Site Multi-homing of IPv6 (SHIM6) . . . . . . . . . . . . 14 77 4.6. Default Router Preferences (RFC4191) . . . . . . . . . . . 14 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 8. Normative References . . . . . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 84 1. introduction 86 Currently most of the network hosts (such as mobile phones, note PCs, 87 etc) are equiped with multiple interfaces physically or virtually. 88 The interfaces may connect with same or different network domains. 89 Such scenarios result in connectivity issues as configuration 90 information may be local to the interface or gobal to the node. 91 Various challenges arise when multiple configuration objects that are 92 global to the node are received on the many interfaces the multi- 93 homed host has. for example, as figure 1 shows, a mobile phone may 94 connect with multiple access networks at the same time. 96 Another example is given by figure 2. A notePC could reach the 97 Internet via If1 for web browsing, while maintaining a VPN connection 98 to the remote private 100 Multi-homing problem in Monami6/MEXT has been discussed for issues 101 related to simultaneous use of multiple addresses for either mobile 102 hosts using Mobile IPv6 or mobile routers using NEMO Basic Support 103 and their variants (FMIPv6, HMIPv6,etc). NETLMM WG also has the work 104 to support the mobile nodes with multiple interfaces in proxy mobile 105 IPv6. However, the solutions of both multihoming support in MEXT and 106 PMIPv6 leverage on a mobility anchor (Home Agent (HA) or Local 107 Mobility Anchor (LMA)). 109 +-------------+ 110 | Destination | 111 | Peers | 112 +-------------+ 113 | 114 *** *** *** *** 115 * ** ** ** * 116 * * 117 * Internet * 118 //* *\\ 119 // * ** ** ** * \\ 120 // *** *** *** *** \\ 121 // // \\ \\ \\ 122 +----+ +----+ +----+ +------+ +----+ 123 | GW | |GGSN| | GW | |ASN-GW| | AR | 124 +----+ +----+ +----+ +------+ +----+ 125 | | | | | 126 | | | | | 127 +----+ +----+ +----+ +-----+ +-----+ 128 |WiFi| |HSPA| |LTE | + 16e | |Wired| 129 |AP | |NB | |eNB | + BS | |CPE | 130 +----+ +----+ +----+ +-----+ +-----+ 131 \ \ | / | 132 \ \ | / / 133 + + + + / 134 | | | | | 135 +---+--------------+------+------+-----+----+ 136 | | | | | | | 137 | +-+-+ +-----+ +---+ +---+ +---+ +---+ | 138 | |if0| | if2 If3| |If4| |If5| |Ifn| | 139 | +---+ |(VPN)| +---+ +---+ +---+ +---+ | 140 | | +-----+ | | | | | 141 | | | | | | | 142 | ++-----+-------+------+------+-----+-+ | 143 | | MIF | | 144 | | (Interface monitoring and control) | | 145 | +--.---------------------------------+ | 146 | | | 147 | | +......................+ | 148 | | : Mobility management : | 149 | | : protocols (MIP,...): | 150 | | : (not in MIF Scope) : | 151 | | +......................+ | 152 | | | 153 | +--'---------------------------------+ | 154 | | MIF | | 155 | | (address selection, policies | | 156 | | management, .... | | 157 | +------------+------------------- ---+ | 158 | | | 159 | +--------'---------+ | 160 | | Applications | | 161 | +------------------+ | 162 +-------------------------------------------+ 163 Mobile Terminal 165 Figure 1: Mobile Terminals connected to multiple networks 167 ** *** ** 168 * * * * 169 * Private * 170 * Network * 171 * * * * 172 +-------------+ ** *** ** 173 | Destination | \\ 174 | Peers | +-----+ 175 +-------------+ | VPN | 176 \ +-----+ 177 \ // 178 \ *** *** *** *** 179 * ** ** ** * 180 * * 181 * Internet * 182 * * 183 * ** ** ** * 184 *** *** *** *** 185 || \\ 186 +-----+ +-----+ 187 | NW2 | | NW1 | 188 +-----+ +-----+ 189 / | 190 | | 191 | | 192 +----+----------------------+----------+ 193 | | | | 194 | +--+----+ +--------+ --+---+ | 195 | | if0 | | if2 | If1 | | 196 | +--.----+ | (VPN) | ---.--+ | 197 | | +--------+ | | 198 | | | | 199 | ++-----------------------+---+ | 200 | | MIF | | 201 | | (Interface monitoring and | | 202 | | control) | | 203 | +--.-------------------------+ | 204 | | | 205 | | +......................+ | 206 | | : Mobility management : | 207 | | : protocols (MIP,...): | 208 | | : (not in MIF Scope) : | 209 | | +......................+ | 210 | | | 211 | +--'---------------------------+ | 212 | | MIF | | 213 | | (address selection, policies | | 214 | | management, .... | | 215 | +------------+-----------------+ | 216 | | | 217 | | | 218 | +--------'---------+ | 219 | | Applications | | 220 | | | | 221 | +------------------+ | 222 +--------------------------------------+ 223 VPN client 225 Figure 2: clients interconnect with Internet and VPN server 227 Some problem statements ([hui08] and [Blanchet08]) have been proposed 228 for MIF problems as well. In MIF framework, different interfaces of 229 MIF node will have different addresses, which may be allocated from 230 different networks. 232 1.1. Challenges for multi-homed simple IP support 234 Several issues below are considered for multi-homed simple IP host. 236 o selection of access networks: which network(s) to attach to using 237 the physical interface(s) that the host has. Already covered in RFC 238 5113. 240 o Flow-based Routing: access networks may be different in bandwidth, 241 delay, pricing, etc. if a host is attached to a number of different 242 point of attachment, there should have the way to help decide the 243 right interfaces and source addresses for specific flows of 244 application. 246 o Configuration reconciliation: A multi-homed host receives node 247 configuration information from each of its access networks. Some 248 configuration objects are global to the node, some are local to the 249 interface. Various issues arise when multiple configuration objects 250 that are global to the node are received on the many interfaces the 251 multi-homed host has. 253 o Split DNS: If a host is attached to a number of different 254 interfaces, how does it resolve a FQDN if more than one interface has 255 provided a DNS server address? [Savolainen08] gives an example on 256 solving this issue. 258 o Protocols for Policy delivery: the MN and the network should 259 support mechanisms, e.g. [802.21], to communicate about interface 260 management policies. 262 2. Scenarios of service sets for Multi-interfaced Hosts 264 The MIF work is looking at a multi-homed host whereby it receives 265 node configuration information from each of its access networks. 266 This section enumerates scnearios of service sets for multi-homed 267 hosts so that analysis can be made to the problem goals of the IETF 268 work. 270 Combinations of the above - configurations with both multiple network 271 interfaces and multiple IP addresses assigned to some or all of these 272 interfaces - are also possible. 274 2.1. Sets of services are the same 276 Here the host has two or more unlimited Internet Connections. The 277 sets of services for these connections are the same. 279 A and B are Internet connections both having the same set of 280 services. 282 ___________ 283 / \ 284 / \ 285 ( A, B ) 286 ( ) 287 \ / 288 \___________/ 290 Case I: Same set of services 292 Figure 1 294 2.2. Set of services are different 296 Next on the list of complexity is the scenario case a host has 297 multiple Internet connections but the set of services for these are 298 different. Here the host for example may have a physical and/or 299 logical VPN connection to different private networks and services. 300 Another example is connecting a host to 2 logically separate but 301 physically connected networks. Here a host has one Internet 302 connection and one VPN connection through which only private network 303 and services can be reached. 305 In the diagram A and B are the Internet Connections of a host each 306 having a different set of services associated with them. 308 ______ ______ 309 / \ / \ 310 / \ / \ 311 ( A ) ( B ) 312 ( ) ( ) 313 \ / \ / 314 \______/ \______/ 316 Case II: Different set of services 318 Figure 2 320 2.3. Set of services are partially overlapping 322 Here the multi-connected host networking services are partially 323 overlapping. 325 Connection A and B having overlapping services. 327 _____ _____ 328 / \/ \ 329 / / \ \ 330 ( A ( ) B ) 331 ( ( ) ) 332 \ \ / / 333 \______/_____/ 335 Case III: Partially overlapping set of services 337 Figure 3 339 2.4. Inclusion of a set of services 341 In this usage scenario services provided by one network the host 342 connects to are completely included by the provision of another. For 343 example, the host has one Internet connection and one VPN connection, 344 while it can also access the Internet services through NATs and 345 proxies provided in the VPN besides some private services. 347 _______ 348 / B \ 349 / ____ \ 350 ( / \ ) 351 ( ( A ) ) 352 \ \____/ / 353 \_______/ 355 Case IV: Inclusion 357 Figure 4 359 2.5. Combination of services 361 A realistic scenario is the combination of the above mentioned 362 scenarios. A multi-homed host has multiple network interfaces both 363 physical and logical. If the host has all physical connections, the 364 host may be connected to different networks through various ways, for 365 instance, wired LAN, 802.11 LAN or a 3G cellular network. For the 366 case that multiple interfaces on the same network, connection issues 367 should be handled by lower-layer protocols, the MIF focuses on upper- 368 layer routing and service reachability. If there is one logical 369 connection the host may have logical connections built on its 370 physical connection, this may be handled by some third-party tools. 371 While the data forwarding process needs to be defined further such as 372 in a BCP document. 374 3. Requirements of MIF 376 In accord with the considerations in section 1, new requirements 377 arise for MIF from the following aspects: 379 o Packet routing in MIF 381 o Merging of autoconfigurations in MIF 383 o Split DNS 385 o the way to communicate the policies between MIF node and network. 386 DHCP ([rfc2131] and [rfc3315]) may be a possible way to do it. 388 3.1. General Requirements 390 Note: the items in this sub-section are applicable for all the 391 scenarios in section 2. 393 R0 - MIF nodes must have at least two physical/virtual interfaces, 394 which may be interconnecting with same/different domains 396 R1 - MIF MUST cover IPv4 only, IPv6 only, and dual-stack MIF node. 398 R2 - MIF solution must compatible with existing IPv4, IPv6 399 architecture and protocols. 401 R3 - MIF covers routing issues with multihomed nodes. This includes 402 multicast routing, knowing that multicast mobility is not in the 403 scope (see R4). 405 R4 - MIF does not require to support IP mobily management protocols 406 (e.g. MIPv6, MIPv4). 408 3.2. Requirements on MIF routing 410 Note: the items in this sub-section are applicable for all the 411 scenarios in section 2. 413 R5 - MIF must decide the interface for a specific outgoing IP flow, 414 before the default route is applied, if applications are agnostic of 415 MIF functions. 417 R6 - MIF should provide support for interface selection according 418 different applications needs (in term of QoS required, etc.), if 419 applications have interfaces with MIF. 421 R7 - MIF must not remove the default route mechanism as defined by 422 RFC1122. 424 R8 - MIF must provide applications/users the inforamtion related to 425 the interfaces. 427 R9 - MIF must have the protocols to communicate the routing policies 428 between MIF node and network. 430 R10 - MIF must be able to get information from interfaces in order to 431 feed the access selection process. 433 R11 - MIF nodes may start, stop and dynamically change flows and 434 connection status. 436 3.3. Requirements on merging of IP layer autoconfiguration 438 Note: the items in this sub-section are applicable for all the 439 scenarios in section 2. 441 R12 - MIF must be capable of collecting the global/local 442 configuration objects from different interfaces 444 R13 - MIF must support specific policies to merge the configuration 445 objects when they are conflicting 447 R14 - MIF must provide the way to users/network to exchange the 448 policies for merging of configurations. 450 R15 - MIF node must provide the way to update the configurations. 452 3.4. split DNS 454 Note: the items in this sub-section are not necessary for the 455 scenario in section 2.1, wherein the service sets of different 456 interfaces are same. The other scenarios in section 2 have the 457 requirements in this sub-section 459 R16 - MIF must be able to get DNS services from different networks. 461 R17 - MIF must be configured with policies for DNS service access. 463 R18 - MIF must provide the way to users/network to change the 464 policies for DNS access. 466 R19 - MIF must provide the way to update the policies of DNS service 467 access. 469 R20 - MIF must have the protocols to communicate the DNS access 470 policies between MIF node and network. 472 4. Related IETF works 474 4.1. relationship with current internet hosts (RFC1122) 476 RFC1122 specified the requirements on the internet host softwares 477 related to link layer, IP layer, and transport layer. MIF will not 478 change the basic routing policies of outbound packets in RFC1122. On 479 the contrary, MIF will add new ways to decide the route of outbound 480 packets before the default route is applied. As for multihoming 481 support, if the datagram is sent in response to a received datagram, 482 MIF will also select the source address for the response SHOULD be 483 the specific-destination address of the request, which is the same as 484 the definition of RFC1122. Otherwise, more rules will be provided by 485 MIF besides the specified rules to select the source addresses. The 486 rules of MIF are applicable for both strong and weak end systems 487 (ES). In MIF, An application is not required to explicitly specify 488 the source address for initiating a connection or a request. 490 4.2. Network Discovery and Selection Problem (RFC5113) 492 RFC5113 defines the ways to help users to select which network to 493 connect to and how to authenticate with that network, when multiple 494 access networks are available. Basically, it divides the problems of 495 network discovery and selection into multiple sub- problems, 496 including Discovery of Points of Attachment, Identity Selection, AAA 497 Routing, Network Capabilities Discovery, etc. Some constraints on 498 potential solutions are outlined, and the limitations of several 499 solutions (including existing ones) are discussed as well. In RFC 500 5113, the routing of data packets, in the situation where mechanisms 501 more advanced than destination-based routing are thought to be 502 necessary. But, it explicitly specified that payload routingis not 503 discussed further in RFC5113. MIF will have solution for this issue. 505 MIF will rely on RFC5113 for network discovery and selection. Before 506 the MIF works for routing/configuration/split DNS, the network 507 discrovery and attachment must be finished beforehand by ways of 508 RFC5113. In this sense, MIF will not cover the network selection and 509 discovery at all. 511 4.3. PMIPv6 & Monami6 513 As discussed in section 1, the solutions of both multihoming support 514 in MEXT and NetLMM need the support from Home Agent (HA) or Local 515 Mobility Anchor (LMA). MIF will work on multiple interface solutions 516 of generic simple IP model. Anyhow, some experiences in these WG 517 will be good references in MIF as well. 519 4.4. Default address selection (RFC3484) 521 RFC 3484 proposed default address selection and destination address 522 for IPv6 could be a refernce to MIF work. 524 4.5. Site Multi-homing of IPv6 (SHIM6) 526 SHIM6 provides multi-homed site with a new sub-layer (shim) into the 527 IP stack of end-system hosts, for the purposes of redundancy, load 528 sharing, operational policy or cost. It will enable hosts on multi- 529 homed sites to use a set of provider-assigned IP address prefixes and 530 switch between them without upsetting transport protocols or 531 applications. It's different from MIF in the following two items: 533 o MIF will handling the routing of multiple flows via multiple 534 interfaces based on the MIF policies. SHIM6 only schedules the 535 interfaces for the purposes of redundancy, load sharing, etc. o SHIM6 536 is more on swtiching the prefixes without the invovlement of 537 transport protocols or applications. 539 o SHIM6 assumes the configuration of multiple interfaces has been 540 done beforehand. MIF will work on the reconciliation of these 541 configuration objects. 543 4.6. Default Router Preferences (RFC4191) 545 RFC 4191 already specify to extend RA to communicate the prefernce 546 and specific routing prefix. However, considering the requirements 547 of MIF, it doesn't cover a full fledges information for a routing and 548 also not include for DHCP support. 550 5. Security Considerations 552 MIF must have the security capabilities to protect MIF node from any 553 malicious attempts caused by security holes such as denial of service 554 attacks. 556 - The MIF solution must not compromise the security architecture of 557 the basic IPv4/IPv6 networks. 559 - MIF is required to provide an admission control mechanism to 560 regulate any MIF events. 562 - MIF could rely on the security mechanism of each interface on MIF 563 node. 565 - Mechanisms used by MIF to exchange policies MUST support security 566 feature to protect this flow of information. 568 6. Conclusion 570 This draft is basically about the requirements on MIF. The related 571 considerations are given firstly, followed by the requirements of MIF 572 on different aspect. Lastly, the relationship and differentiation 573 are made between perspective work of MIF and the related IETF work. 575 7. IANA Considerations 577 This document makes no requests to IANA. 579 8. Normative References 581 [802.21] "IEEE 802.21 Standard for Local and Metropolitan Area 582 Networks: Media Independent Handover Services". 584 [Blanchet08] 585 Blanchet, M., "Multiple Interfaces Problem Statement", 586 draft-blanchet-mif-problem-statement-00.txt (work in 587 progress), December 2008. 589 [Nordmark09] 590 Nordmark, E., "Shim6: Level 3 Multihoming Shim Protocol 591 for IPv6", draft-ietf-shim6-proto-12.txt (work in 592 progress), February 2009. 594 [OMA-DM] "Enabler Test Specification for Device Management v1.2", 595 Open Mobile Alliance OMA-ETS-DM-V1_2-20080718-C, 596 July 2008. 598 [RFC1122] Braden, R., "Requirements for Internet Hosts - 599 Communication Layers", STD 3, RFC 1122, October 1989. 601 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 602 RFC 2131, March 1997. 604 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 605 and M. Carney, "Dynamic Host Configuration Protocol for 606 IPv6 (DHCPv6)", RFC 3315, July 2003. 608 [RFC3484] Draves, R., "Default Address Selection for Internet 609 Protocol version 6 (IPv6)", RFC 3484, February 2003. 611 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 612 More-Specific Routes", RFC 4191, November 2005. 614 [RFC5113] Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network 615 Discovery and Selection Problem", RFC 5113, January 2008. 617 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 618 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 620 [Savolainen08] 621 Savolainen , T., "Domain name based network interface 622 selection", IETF Internet-draft 623 draft-savolainen-6man-fqdn-based-if-selection-00.txt, 624 October 2008. 626 [Wakikawa09] 627 Wakikawa , R., "Multiple Care-of Addresses Registration", 628 draft-ietf-monami6-multiplecoa-11 (work in progress), 629 January 2009. 631 [hui08] Hui, M., "Problem Statement and Requirement of Simple IP 632 Multi-homing of the Host", 633 draft-hui-ip-multiple-connections-ps-01 (work in 634 progress), November 2008. 636 Authors' Addresses 638 Peng Yang 639 Hitachi (China) R&D Corp 641 Email: peng.yang.chn@gmail.com 643 Pierrick Seite 644 France Telecom 646 Email: pierrick.seite@orange-ftgroup.com 648 Carl Williams 649 ZTE 650 Consultant 651 Palo Alto 652 United States 654 Email: carl.williams@mcsr-labs.org 656 Jacni Qin 657 ZTE 658 Shanghai 659 China 661 Email: jacniq@gmail.com