idnits 2.17.1 draft-ietf-mif-problem-statement-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 11, 2010) is 5005 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4477' is defined on line 655, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-10 == Outdated reference: A later version (-12) exists of draft-ietf-mif-current-practices-02 == Outdated reference: A later version (-05) exists of draft-ietf-mptcp-architecture-01 == Outdated reference: A later version (-17) exists of draft-ietf-shim6-multihome-shim-api-13 == Outdated reference: A later version (-06) exists of draft-savolainen-mif-dns-server-selection-03 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 4294 (Obsoleted by RFC 6434) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5206 (Obsoleted by RFC 8046) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet 3 Internet-Draft Viagenie 4 Intended status: Informational P. Seite 5 Expires: February 12, 2011 France Telecom - Orange 6 August 11, 2010 8 Multiple Interfaces Problem Statement 9 draft-ietf-mif-problem-statement-06.txt 11 Abstract 13 A multihomed host receives node configuration information from each 14 of its provisioning domain. Some configuration objects are global to 15 the node, some are local to the interface. Various issues arise when 16 multiple conflicting node-scoped configuration objects are received 17 on multiple interfaces. Similar situations also happen with single 18 interface host connected to multiple networks. This document 19 describes these issues. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 12, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Scope and Existing Work . . . . . . . . . . . . . . . . . . . 4 58 3.1. Below IP Interaction . . . . . . . . . . . . . . . . . . . 4 59 3.2. Hosts Requirements . . . . . . . . . . . . . . . . . . . . 5 60 3.3. Mobility and other IP protocols . . . . . . . . . . . . . 5 61 3.4. Address Selection . . . . . . . . . . . . . . . . . . . . 5 62 3.5. Finding and Sharing IP Addresses with Peers . . . . . . . 6 63 3.6. Socket API and connection manager . . . . . . . . . . . . 6 64 4. Symptoms . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1. DNS resolution issues . . . . . . . . . . . . . . . . . . 7 66 4.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.3. Address Selection Policy . . . . . . . . . . . . . . . . . 9 68 4.4. Single Interface on Multiple Provisioning Domains . . . . 9 69 5. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 75 11. Informative References . . . . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 78 1. Introduction 80 A multihomed host have multiple provisioning domains (via physical 81 and/or virtual interfaces). For example, a node may be 82 simultaneously connected to a wired Ethernet LAN, a 802.11 LAN, a 3G 83 cell network, one or multiple VPN connections or one or multiple 84 automatic or manual tunnels. Current laptops and smartphones 85 typically have multiple access network interfaces and, thus, may be 86 simultaneously connected to different provisioning domains. 88 A multihomed host receives node configuration information from each 89 of its access networks, through various mechanisms such as DHCPv4 90 [RFC2131], DHCPv6 [RFC3315], PPP [RFC1661] and IPv6 Router 91 Advertisements [RFC4861]. Some received configuration objects are 92 specific to an interface such as the IP address and the link prefix. 93 Others are typically considered by implementations as being global to 94 the node, such as the routing information (e.g. default gateway), DNS 95 servers IP addresses and address selection policies. 97 When the received node-scoped configuration objects have different 98 values from each provisioning domains, such as different DNS servers 99 IP addresses, different default gateways or different address 100 selection policies, the node has to decide which it will use or how 101 it will merge them. 103 Several issues regarding how the node-scoped configuration objects 104 are used in a multihomed node environment have been raised. The 105 following sections define the MIF host and the scope of this 106 document, describe related work, list the symptoms and then the 107 underlying problems. 109 A companion document [I-D.ietf-mif-current-practices] discusses 110 current practices. 112 2. Terminology 114 Administrative domain 116 A group of hosts, routers, and networks operated and managed by a 117 single organization [RFC1136]. 119 Provisioning domain 121 A set of consistent configuration information (e.g. Default 122 router, Network prefixes, DNS,...). One administrative domain can 123 contain multiple provisioning domains. 125 A MIF (Multiple InterFaces) host has the following characteristics: 127 o A [RFC1122] IPv4 and/or [RFC4294] IPv6 compliant host 128 o A MIF host is configured with more than one IP addresses 129 (excluding loopback, link-local) 130 o A MIF host can attach to more than one provisioning domains, as 131 presented to the IP stack. 132 o The interfaces may be logical, virtual or physical. 133 o Configuration objects come from one or more administrative 134 domains. 135 o The IP addresses may be from the same or from different address 136 families, such as IPv4 and IPv6. 137 o Communications using these IP addresses may happen simultaneously 138 and independently. 139 o Some communications using these IP addresses are possible on all 140 the provisioning domains, while some are only possible on a 141 smaller set of the provisioning domains. 142 o While the MIF host may forward packets between its interfaces, 143 forwarding packets is not taken into account in this definition. 145 Reference to IP version 147 When a protocol keyword such as IP, PPP, DHCP is used without any 148 reference to a specific IP version, then it implies both IPv4 and 149 IPv6. A specific IP version keyword such as DHCPv4 or DHCPv6 is 150 specific to that IP version. 152 3. Scope and Existing Work 154 This section describes existing related work and defines the scope of 155 the problem. 157 3.1. Below IP Interaction 159 Network discovery and selection on lower layers as defined by 160 [RFC5113] is out of scope of this document. Moreover, lower layer 161 interaction such as IEEE 802.21 is also out of scope. 163 Some mechanisms (e.g., based on a logical IP interface) 164 allow sharing a single IP address across multiple interfaces 165 (e.g., WiMAX and CDMA, LTE and HSPA, etc.) to disparate networks. 166 From the IP stack view on the node, there is only a single interface 167 and single IP address. Therefore, this situation is out of scope of 168 this current problem statement. Furthermore, link aggregation done 169 under IP where a single interface is shown to the IP stack is also 170 out of scope. 172 3.2. Hosts Requirements 174 The requirements for Internet Hosts [RFC1122] describe the multihomed 175 host as if it has multiple IP addresses, which may be associated with 176 one or more physical interfaces connected to the same or different 177 networks. 179 The host maintains a route cache table where each entry contains the 180 local IP address, the destination IP address, Type-of-Service and 181 Next-hop gateway IP address. The route cache entry would have data 182 about the properties of the path, such as the average round-trip 183 delay measured by a transport protocol. 185 As per [RFC1122], two models are defined: 186 o The "Strong" host model defines a multihomed host as a set of 187 logical hosts within the same physical host. In this model a 188 packet must be sent on an interface that corresponds to the source 189 address of that packet. 190 o The "Weak" host model describes a host that has some embedded 191 gateway functionality. In the weak host model, the host can send 192 and receive packets on any interface. 194 The multihomed host computes routes for outgoing datagrams 195 differently depending on the model. Under the strong model, the 196 route is computed based on the source IP address, the destination IP 197 address and the Type-of-Service. Under the weak model, the source IP 198 address is not used, but only the destination IP address and the 199 Type-of-Service. 201 3.3. Mobility and other IP protocols 203 This document is only concerned with the situation where the hosts 204 implement [RFC1122] for IPv4 and [RFC4294] for IPv6 and not special- 205 purpose support for transport layers, mobility, multi-homing, or 206 identifier-locator split mechanisms. Dealing with multiple 207 interfaces with such mechanisms is somewhat separate problem and 208 under active study elsewhere in the IETF [RFC4960], [RFC5206], 209 [RFC5533], [RFC5648], [I-D.ietf-mptcp-architecture]. 211 3.4. Address Selection 213 The Default Address Selection specification [RFC3484] defines 214 algorithms for source and destination IP address selections. It is 215 mandatory to be implemented in IPv6 nodes, which also means dual- 216 stack nodes. A node-scoped policy table managed by the IP stack is 217 defined. Provisions are made to change or update the policy table, 218 however, no mechanism is defined. 220 Issues on using the Default Address Selection were found in [RFC5220] 221 and [RFC5221] in the context of multiple prefixes on the same link. 222 New work [I-D.ietf-6man-addr-select-sol] discusses the multiple 223 attached networks scenarios and how to update the policy table. 225 3.5. Finding and Sharing IP Addresses with Peers 227 Interactive Connectivity Establishment (ICE [RFC5245]) is a technique 228 for NAT traversal for UDP-based (and TCP) media streams established 229 by the offer/answer model. The multiplicity of IP addresses and 230 ports in SDP offers are tested for connectivity by peer-to-peer 231 connectivity checks. The result is candidate IP addresses and ports 232 for establishing a connection with the other peer. However, ICE does 233 not solve issues when incompatible configuration objects are received 234 on different interfaces. 236 Some application protocols do referrals of IP addresses and port 237 numbers for further exchanges. For instance, applications can 238 provide reachability information to itself or to a third party. The 239 general problem of referrals is related to the multiple interface 240 problem, since, in this context, referrals must provide consistent 241 information depending on which provisioning domain is used. The 242 general referral problem has been studied in 243 [I-D.carpenter-behave-referral-object] and 244 [I-D.ietf-shim6-app-refer], but no solutions exist today. 246 3.6. Socket API and connection manager 248 Application Programming Interface (API) may expose objects that user 249 applications may use for dealing with multiple interfaces. For 250 example, [RFC3542] shows how an application using the Advanced 251 sockets API can specify the interface or the source IP address, 252 through simple bind() operation or IPV6_PKTINFO socket option. 254 There are other examples of API dealing with similar issues to MIF. 255 For instance, [RFC5014] defines API to influence the default address 256 selection mechanism by specifying attributes of the source addresses 257 it prefers. [I-D.ietf-shim6-multihome-shim-api] gives another 258 example in a multihoming context, by defining a socket API enabling 259 interactions between applications and the multihoming shim layer for 260 advanced locator management, and access to information about failure 261 detection and path exploration. 263 In the MIF context, some implementations, specially in the mobile 264 world, rely on higher-level connection managers to deal with issues 265 brought by multiple provisioning domains. Typically, the connection 266 manager can select the provisioning domain when application is domain 267 scoped. Connection managers usually leverage on API to gather 268 information and/or for control purpose. However, there is no 269 standardized high level API, and implementations differ also in the 270 functionality that they provide. In addition, these mechanisms do 271 not necessarily behave the same way across different platform and OS 272 in the presence of the MIF problems [I-D.ietf-mif-current-practices]. 273 This lack of harmonization is an issue since it may lead to multiple 274 instantiation of a cross platform/OS connection manager or 275 application. 277 4. Symptoms 279 This section describes the various symptoms found using a MIF host 280 that has already received configuration objects from its various 281 provisioning domains. They occur, for example, when: 283 1. one interface is on the Internet and one is on a corporate 284 private network. The latter may be through VPN. 285 2. one interface is on one access network (i.e. wifi) and the other 286 one is on another access network (3G) with specific services. 288 4.1. DNS resolution issues 290 A MIF host (H1) has an active interface(I1) connected to a network 291 (N1) which has its DNS server (S1) and another active interface (I2) 292 connected to a network (N2) which has its DNS server (S2). S1 serves 293 with some private namespace "private.example.com". The user or the 294 application uses a name "a.private.example.com" which is within the 295 private namespace of S1 and only resolvable by S1. Any of the 296 following situations may occur: 298 1. H1 stack, based on its routing table, uses I2 to reach S1 to 299 resolve "a.private.example.com". H1 never reaches S1. The name 300 is not resolved. 301 2. H1 keeps only one set of DNS server addresses from the received 302 configuration objects and kept S2 address. H1 sends the DNS A 303 query for a.private.example.com to S2. S2 responds with an error 304 for an non-existent domain (NXDOMAIN). The name is not resolved. 305 3. H1 keeps only one set of DNS server addresses from the received 306 configuration objects and kept S2 address. H1 sends the DNS A 307 query for a.private.example.com to S2. S2 asks its upstream DNS 308 and gets an IP address for a.private.example.com. However, the 309 IP address is not the same one S1 would have given. Therefore, 310 the application tries to connect to the wrong destination host, 311 or to the wrong interface of the latter, which may imply security 312 issues or result in lack of service. 314 4. S1 or S2 has been used to resolve "a.private.example.com" to an 315 [RFC1918] address. Both N1 and N2 are [RFC1918] addressed 316 networks. IPv4 source address selection may face challenges, as 317 due address overlapping the source/destination IP addresses do 318 not necessarily provide enough information for making proper 319 address selection decisions. 320 5. H1 has resolved an FQDN to locally valid IP address when 321 connected to N1. After movement from N1 to N2, the host tries to 322 connect to the same IP address as earlier, but as the address was 323 only locally valid, connection setup fails. 324 6. H1 requests AAAA record from a DNS server on a network that uses 325 protocol translators and DNS64 [I-D.ietf-behave-dns64]. If the 326 H1 receives synthesized AAAA record, it is guaranteed to be valid 327 only on the network it was learned from. If the H1 uses 328 synthesized AAAA on an network interface it is not valid on, the 329 packets will be dropped by the network. 331 A MIF host may also be provisioned with a Interface-specific suffix 332 search list ([I-D.ietf-mif-current-practices]). In this situation, 333 if H1 sends DNS query on I1 using the search list tied to I2, the 334 namespace could be not valid on I1 and the name could be not 335 resolved. 337 4.2. Routing 339 A MIF host (H1) has an active interface(I1) connected to a network 340 (N1) and another active interface (I2) connected to a network (N2). 341 The user or the application is trying to reach an IP address (IP1). 342 Any of the following situations may occur: 344 1. For IP1 , H1 has one default route (R1) via network (N1). So, 345 trying to reach IP1, H1 stack uses R1 and sends through I1. If 346 IP1 is only reachable by N2, IP1 is never reached or is not the 347 right target. 348 2. For the IP1 address family, H1 has one default route (R1, R2) per 349 network (N1, N2). IP1 is reachable by both networks, but N2 path 350 has better characteristics, such as better round-trip time, least 351 cost, better bandwidth, etc.... These preferences could be 352 defined by user, by the provider, by discovery or else. H1 stack 353 uses R1 and tries to send through I1. IP1 is reached but the 354 service would be better by I2. 355 3. For the IP1 address family, H1 has a default route (R1), a 356 specific X.0.0.0/8 route R1B (eg. RFC1918 prefix) to N1 and a 357 default route (R2) to N2. IP1 is reachable by N2 only, but the 358 prefix (X.0.0.0/8) is used in both networks. Because of the most 359 specific route R1B, H1 stack sends through I2 and never reach the 360 target. 362 A MIF host may have multiple routes to a destination. However, by 363 default, it does not have any hint concerning which interface would 364 be the best to use for that destination. For example, a service 365 provider might want to influence the routing table of the host 366 connecting to its network. 368 A host usually has a node-scoped routing table. Therefore, when a 369 MIF host is connected to multiple provisioning domains where each 370 service provider wants to influence the routing table of the host, 371 then conflicts might arise from the multiple routing information 372 being pushed to the host. 374 A user on such multihomed host might want a local policy to influence 375 which interface will be used based on various conditions. 377 On a MIF host, some source addresses are not valid if used on some 378 interfaces. For example, an RFC1918 source address might be 379 appropriate on the VPN interface but not on the public interface of 380 the MIF host. If the source address is not chosen appropriately, 381 then sent packets might be filtered in the path if source address 382 filtering is in place ([RFC2827],[RFC3704]) and reply packets might 383 never come back to the source. 385 4.3. Address Selection Policy 387 Even if not yet specified, the distribution of address selection 388 policy is sometimes evoked. If deployed, such a mechanism could 389 bring specific issue in a multiple provisioning domain context. Lets 390 consider a MIF host(H1) with an active interface(I1) connected to a 391 network (N1) and another active interface (I2) connected to a network 392 (N2). When the user or the application is trying to reach an IP 393 address (IP1), the following situations may occur: 394 H1 receives from both networks (N1 and N2) an update of its 395 default address selection policy. However, the policies are 396 specific to each network. The policies are merged by H1 stack. 397 Based on the merged policy, the chosen source address is from N1 398 but packets are sent to N2. The source address is not reachable 399 from N2, therefore the return packet is lost. 401 Merging address selection policies may have important impacts on 402 routing. 404 4.4. Single Interface on Multiple Provisioning Domains 406 When a MIF host using a single interface is connected to multiple 407 networks with different default routers, similar issues as described 408 above happen. Even with a single interface, a node may wish to 409 connect to more than one configuration domain: that node may use more 410 than one IP source address and may have more than one default router. 411 The node may want to access services that can only be reached using 412 one of the provisioning domain, so it needs to use the right outgoing 413 source address and default gateway to reach that service. In this 414 situation, that node may also need to use different DNS servers to 415 get domain names in those different provisioning domains. 417 5. Problems 419 This section lists the underlying problems leading to the issues 420 discussed in the previous section. The problems can be divided into 421 five categories: 1) Configuration 2) DNS resolution 3) Routing 4) 422 Address selection and 5) connection management and API. They are 423 shown as below: 425 1. Configuration. In a MIF context, configuration information 426 specific to a provisioning domain may be ignored because: 427 1. Configuration objects (e.g. DNS servers, NTP servers, ...) 428 are node-scoped. So the IP stack is not able to maintain the 429 mapping between information and corresponding provisioning 430 domain. 431 2. Same configuration objects (e.g. DNS server addresses, NTP 432 server addresses, ..) received from multiple provisioning 433 domains may be overwritten. 434 3. Host implementations usually do not keep separate network 435 configuration (such as DNS server addresses) per provisioning 436 domain. 437 2. DNS resolution 438 1. Some FQDN can be resolvable only via a specific interface 439 (e.g. intranet services). However, DNS query could be send 440 to the wrong interface because DNS server addresses may be 441 node-scoped. 442 2. A DNS answer can be valid only on a specific interface but 443 applications may be not aware of that mapping because DNS 444 answers may be not kept with the interface from which the 445 answer comes from. 446 3. Routing 447 1. In the MIF context, routing information could be specific to 448 each interface. This could lead to routing issue because, in 449 current host implementations, routing tables are node-scoped. 450 2. Interfaces of a MIF host can provide different 451 characteristics (e.g. round-trip time, least cost, better 452 bandwidth, etc....). So, user, applications or network 453 provider may wish to influence routing to take benefit of 454 this heterogeneity. However, with current host 455 implementations, neither the Type-of-Service nor path 456 characteristics can be taken into account in the routing 457 table. 458 4. Address selection 459 1. Default Address Selection policies may be specific to their 460 corresponding provisioning domain. However, a MIF host may 461 not be able to manage per-provisioning domain address 462 selection policies because default Address Selection policy 463 is node-scoped. 464 2. On a MIF host, some source addresses are not valid if used on 465 some interfaces or even on some default routers on the same 466 interface. In this situation, the source address should be 467 taken into account in the routing table; but current host 468 implementations do not support such a feature. 469 3. Source address or address selection policies could be 470 specified by applications. However, there is no advanced 471 APIs to allow applications realizing such operations. 472 5. Connection management and API 473 1. Some implementations, specially in the mobile world, have 474 higher-level API and/or connection manager to address MIF 475 issues. These mechanisms are not standardized and do not 476 necessarily behave the same way across different OS, and/or 477 platforms, in the presence of the MIF problems. This lack of 478 consistency is an issue for user and operator who could 479 experience different connection manager behaviors depending 480 on the terminal. 481 2. Provisioning domain selection is a feature of connection 482 management. Domain selection can be tricky due to lot of 483 different situations and selection criteria: some 484 applications are domain-scoped, or may have a preferred 485 provisioning domain (e.g. according to available QoS). Each 486 actor (end-user, operator, service provider, etc.) may also 487 have their preferred provisioning domains (e.g. single out 488 lower cost domain), possibly per application. 489 3. The different actors may provide different, and sometimes 490 contradictory, domain selection policies to the connection 491 management function. The connection manager can typically 492 address the issue, but not all connection managers are able 493 to. 494 4. A MIF host can support different connection managers, which 495 may have contradictory ways to solve the MIF issues. For 496 instance, because of different selection algorithms, two 497 different connection managers could select different domains 498 in a same context. Or, when dealing with different domain 499 selection policies, a connection manager may give precedence 500 to user policy while another could favor mobile operator 501 policy. 503 6. Summary 505 A MIF host receives node configuration information from each of its 506 provisioning domains. Some configuration objects are global to the 507 node, some are local to the interface. Various issues arise when 508 multiple conflicting node-scoped configuration objects are received 509 via multiple provisioning domains. Similar situations also happen 510 with single interface host connected to multiple networks. 511 Therefore, there is a need to define the appropriate behavior of an 512 IP stack and possibly define protocols to manage these cases. 514 7. Security Considerations 516 The problems discussed in this document have security implications, 517 such as when the packets sent on the wrong interface might be leaking 518 some confidential information. Moreover, the undetermined behavior 519 of IP stacks in the multihomed context bring additional threats where 520 an interface on a multihomed host might be used to conduct attacks 521 targeted to the networks connected by the other interfaces. 523 Additional security concerns raise up when information is provided to 524 the host so that it could make a more intelligent decision (e.g. 525 provide selection policies to the connection manager). This 526 additional information should be protected in some manner. 528 8. IANA Considerations 530 This document has no actions for IANA. 532 9. Authors 534 This document is a joint effort with authors of the MIF requirements 535 draft [I-D.yang-mif-req]. The authors of this document, in 536 alphabetical order, include: Marc Blanchet, Jacqni Qin, Pierrick 537 Seite, Carl Williams and Peny Yang. 539 10. Acknowledgements 541 The initial Internet-Drafts prior to the MIF working group and the 542 discussions during the MIF BOF meeting and on the mailing list around 543 the MIF charter scope on the mailing list brought very good input to 544 the problem statement. This draft steals a lot of text from these 545 discussions and initial drafts (e.g. [I-D.yang-mif-req], 546 [I-D.hui-ip-multiple-connections-ps], 548 [I-D.savolainen-mif-dns-server-selection]). Therefore, the editor 549 would like to acknowledge the following people (in no specific 550 order), from which some text has been taken from: Jari Arkko, Keith 551 Moore, Sam Hartman, George Tsirtsis, Scott Brim, Ted Lemon, Bernie 552 Volz, Giyeong Son, Gabriel Montenegro, Julien Laganier, Teemu 553 Savolainen, Christian Vogt, Lars Eggert, Margaret Wasserman, Hui 554 Deng, Ralph Droms, Ted Hardie, Christian Huitema, Remi Denis- 555 Courmont, Alexandru Petrescu, Zhen Cao. Sorry if some contributors 556 have not been named. 558 11. Informative References 560 [I-D.carpenter-behave-referral-object] 561 Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and 562 K. Moore, "A Generic Referral Object for Internet 563 Entities", draft-carpenter-behave-referral-object-01 (work 564 in progress), October 2009. 566 [I-D.hui-ip-multiple-connections-ps] 567 Hui, M. and H. Deng, "Problem Statement and Requirement of 568 Simple IP Multi-homing of the Host", 569 draft-hui-ip-multiple-connections-ps-02 (work in 570 progress), March 2009. 572 [I-D.ietf-6man-addr-select-sol] 573 Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution 574 approaches for address-selection problems", 575 draft-ietf-6man-addr-select-sol-03 (work in progress), 576 March 2010. 578 [I-D.ietf-behave-dns64] 579 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 580 "DNS64: DNS extensions for Network Address Translation 581 from IPv6 Clients to IPv4 Servers", 582 draft-ietf-behave-dns64-10 (work in progress), July 2010. 584 [I-D.ietf-mif-current-practices] 585 Wasserman, M. and P. Seite, "Current Practices for 586 Multiple Interface Hosts", 587 draft-ietf-mif-current-practices-02 (work in progress), 588 June 2010. 590 [I-D.ietf-mptcp-architecture] 591 Ford, A., Raiciu, C., Barre, S., and J. Iyengar, 592 "Architectural Guidelines for Multipath TCP Development", 593 draft-ietf-mptcp-architecture-01 (work in progress), 594 June 2010. 596 [I-D.ietf-shim6-app-refer] 597 Nordmark, E., "Shim6 Application Referral Issues", 598 draft-ietf-shim6-app-refer-00 (work in progress), 599 July 2005. 601 [I-D.ietf-shim6-multihome-shim-api] 602 Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, 603 "Socket Application Program Interface (API) for 604 Multihoming Shim", draft-ietf-shim6-multihome-shim-api-13 605 (work in progress), February 2010. 607 [I-D.savolainen-mif-dns-server-selection] 608 Savolainen, T., "Improved DNS Server Selection for Multi- 609 Homed Hosts", draft-savolainen-mif-dns-server-selection-03 610 (work in progress), June 2010. 612 [I-D.yang-mif-req] 613 Yang, P., Seite, P., Williams, C., and J. Qin, 614 "Requirements on multiple Interface (MIF) of simple IP", 615 draft-yang-mif-req-00 (work in progress), March 2009. 617 [RFC1122] Braden, R., "Requirements for Internet Hosts - 618 Communication Layers", STD 3, RFC 1122, October 1989. 620 [RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing 621 Domains: A model for routing in the Internet", RFC 1136, 622 December 1989. 624 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 625 RFC 1661, July 1994. 627 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 628 E. Lear, "Address Allocation for Private Internets", 629 BCP 5, RFC 1918, February 1996. 631 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 632 RFC 2131, March 1997. 634 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 635 Defeating Denial of Service Attacks which employ IP Source 636 Address Spoofing", BCP 38, RFC 2827, May 2000. 638 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 639 and M. Carney, "Dynamic Host Configuration Protocol for 640 IPv6 (DHCPv6)", RFC 3315, July 2003. 642 [RFC3484] Draves, R., "Default Address Selection for Internet 643 Protocol version 6 (IPv6)", RFC 3484, February 2003. 645 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 646 "Advanced Sockets Application Program Interface (API) for 647 IPv6", RFC 3542, May 2003. 649 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 650 Networks", BCP 84, RFC 3704, March 2004. 652 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 653 April 2006. 655 [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host 656 Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack 657 Issues", RFC 4477, May 2006. 659 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 660 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 661 September 2007. 663 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 664 RFC 4960, September 2007. 666 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 667 Socket API for Source Address Selection", RFC 5014, 668 September 2007. 670 [RFC5113] Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network 671 Discovery and Selection Problem", RFC 5113, January 2008. 673 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 674 Host Mobility and Multihoming with the Host Identity 675 Protocol", RFC 5206, April 2008. 677 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 678 "Problem Statement for Default Address Selection in Multi- 679 Prefix Environments: Operational Issues of RFC 3484 680 Default Rules", RFC 5220, July 2008. 682 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 683 "Requirements for Address Selection Mechanisms", RFC 5221, 684 July 2008. 686 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 687 (ICE): A Protocol for Network Address Translator (NAT) 688 Traversal for Offer/Answer Protocols", RFC 5245, 689 April 2010. 691 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 692 Shim Protocol for IPv6", RFC 5533, June 2009. 694 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 695 and K. Nagami, "Multiple Care-of Addresses Registration", 696 RFC 5648, October 2009. 698 Authors' Addresses 700 Marc Blanchet 701 Viagenie 702 2600 boul. Laurier, suite 625 703 Quebec, QC G1V 4W1 704 Canada 706 Email: Marc.Blanchet@viagenie.ca 707 URI: http://www.viagenie.ca 709 Pierrick Seite 710 France Telecom - Orange 711 4, rue du Clos Courtel, BP 91226 712 Cesson-Sevigne 35512 713 France 715 Email: pierrick.seite@orange-ftgroup.com