idnits 2.17.1 draft-ietf-mif-problem-statement-03.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 4, 2010) is 5100 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-09 == Outdated reference: A later version (-12) exists of draft-ietf-mif-current-practices-00 == 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-02 -- 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) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 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: November 5, 2010 France Telecom - Orange 6 May 4, 2010 8 Multiple Interfaces Problem Statement 9 draft-ietf-mif-problem-statement-03.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 November 5, 2010. 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 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Scope and Existing Work . . . . . . . . . . . . . . . . . . . 4 70 3.1. Below IP Interaction . . . . . . . . . . . . . . . . . . . 4 71 3.2. Hosts Requirements . . . . . . . . . . . . . . . . . . . . 4 72 3.3. Mobility and other IP protocols . . . . . . . . . . . . . 5 73 3.4. Address Selection . . . . . . . . . . . . . . . . . . . . 5 74 3.5. Finding and Sharing IP Addresses with Peers . . . . . . . 6 75 3.6. Socket API . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.7. Above IP Layers . . . . . . . . . . . . . . . . . . . . . 7 77 4. Symptoms . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 4.1. DNS resolution issues . . . . . . . . . . . . . . . . . . 7 79 4.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 4.3. Address Selection Policy . . . . . . . . . . . . . . . . . 9 81 4.4. Single Interface on Multiple Provisioning Domains . . . . 9 82 5. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 88 11. Informative References . . . . . . . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 A multihomed host have multiple provisioning domains (via physical 94 and/or virtual interfaces). For example, a node may be 95 simultaneously connected to a wired Ethernet LAN, a 802.11 LAN, a 3G 96 cell network, one or multiple VPN connections or one or multiple 97 automatic or manual tunnels. Current laptops and smartphones 98 typically have multiple access network interfaces and, thus, may be 99 simultaneously connected to different provisioning domains. 101 A multihomed host receives node configuration information from each 102 of its access networks, through various mechanims such as DHCPv4 103 [RFC2131], DHCPv6 [RFC3315], PPP [RFC1661] and IPv6 Router 104 Advertisements [RFC4861]. Some received configuration objects are 105 specific to an interface such as the IP address and the link prefix. 106 Others are typically considered by implementations as being global to 107 the node, such as the routing information (e.g. default gateway), DNS 108 servers IP addresses and address selection policies. 110 When the received node-scoped configuration objects have different 111 values from each provisioning domains, such as different DNS servers 112 IP addresses, different default gateways or different address 113 selection policies, the node has to decide which it will use or how 114 it will merge them. 116 Several issues regarding how the node-scoped configuration objects 117 are used in a multihomed node environment have been raised. The 118 following sections define the MIF host and the scope of this 119 document, describe related work, list the symptoms and then the 120 underlying problems. 122 A companion document [I-D.ietf-mif-current-practices] discusses 123 current practices. 125 2. Terminology 127 Administrative domain 129 A group of hosts, routers, and networks operated and managed by a 130 single organization [RFC1136]. 132 Provisioning domain 134 A set of consistent configuration information (e.g. Default 135 router, Network prefixes, DNS,...). 0ne administrative domain can 136 contain multiple provisioning domains. 138 A MIF host is defined as: 140 o A [RFC1122] IPv4 and/or [RFC4294] IPv6 compliant host 141 o Configured with more than one IP addresses (excluding loopback, 142 link-local) 143 o On one or more provisioning domains, as presented to the IP stack. 144 o The interfaces may be logical, virtual or physical. 145 o The IP addresses come from more than one administrative domains. 146 o The IP addresses may be from the same or from different address 147 families, such as IPv4 and IPv6. 148 o Communications using these IP addresses may happen simultaneously 149 and independently. 150 o Communications using these IP addresses may be tied on all the 151 possible provisioning domains, or, at least, on a limited number 152 of provisioning domains. 153 o While the MIF host may forward packets between its interfaces, 154 forwarding packets is not taken into account in this definition. 156 Reference to IP version 158 When a protocol keyword such as IP, PPP, DHCP is used without any 159 reference to a specific IP version, then it implies both IPv4 and 160 IPv6. A specific IP version keyword such as DHCPv4 or DHCPv6 is 161 specific to that IP version. 163 3. Scope and Existing Work 165 This section describes existing related work and defines the scope of 166 the problem. 168 3.1. Below IP Interaction 170 Network discovery and selection on lower layers as defined by 171 [RFC5113] is out of scope of this document. Moreover, lower layer 172 interaction such as IEEE 802.21 is also out of scope. 174 Proxy MIP allows sharing a single IP address across multiple interfac 175 es (e.g., WiMAX and CDMA, LTE and HSPA, etc.) to disparate networks. 176 From the IP stack view on the node, there is only a single interface 177 and single IP address. Therefore, this situation is out of scope. 178 Furthermore, link aggregation done under IP where a single interface 179 is shown to the IP stack is also out of scope. 181 3.2. Hosts Requirements 183 The requirements for Internet Hosts [RFC1122] describe the multihomed 184 host as if it has multiple IP addresses, which may be associated with 185 one or more physical interfaces connected to the same or different 186 networks. 188 The host maintains a route cache table where each entry contains the 189 local IP address, the destination IP address, Type-of-Service and 190 Next-hop gateway IP address. The route cache entry would have data 191 about the properties of the path, such as the average round-trip 192 delay measured by a transport protocol. 194 As per [RFC1122], two models are defined: 195 o The "Strong" host model defines a multihomed host as a set of 196 logical hosts within the same physical host. In this model a 197 packet must be sent on an interface that corresponds to the source 198 address of that packet. 199 o The "Weak" host model describes a host that has some embedded 200 gateway functionality. In the weak host model, the host can send 201 and receive packets on any interface. 203 The multihomed host computes routes for outgoing datagrams 204 differently depending on the model. Under the strong model, the 205 route is computed based on the source IP address, the destination IP 206 address and the Type-of-Service. Under the weak model, the source IP 207 address is not used, but only the destination IP address and the 208 Type-of-Service. 210 3.3. Mobility and other IP protocols 212 This document assumes hosts only implementing [RFC1122] for IPv4 and 213 [RFC4294] for IPv6, and not using any kind of new transport 214 protocols. It is not required for the host to support additional IP 215 mobility or multihoming protocols, such as SHIM6, SCTP, Mobile IP, 216 HIP, RRG, LISP or else. Moreover, the peer of the connection is also 217 not required to use these mechanisms. 219 3.4. Address Selection 221 The Default Address Selection specification [RFC3484] defines 222 algorithms for source and destination IP address selections. It is 223 mandatory to be implemented in IPv6 nodes, which also means dual- 224 stack nodes. A node-scoped policy table managed by the IP stack is 225 defined. Provisions are made to change or update the policy table, 226 however, no mechanism is defined. 228 Issues on using the Default Address Selection were found [RFC5220] in 229 the context of multiple prefixes on the same link. New work 230 [I-D.chown-addr-select-considerations] discusses the multiple 231 attached networks scenarios and how to update the policy table. 233 3.5. Finding and Sharing IP Addresses with Peers 235 Interactive Connectivity Establishment (ICE [I-D.ietf-mmusic-ice]) is 236 a technique for NAT traversal for UDP-based (and TCP) media streams 237 established by the offer/answer model. The multiplicity of IP 238 addresses and ports in SDP offers are tested for connectivity by 239 peer-to-peer connectivity checks. The result is candidate IP 240 addresses and ports for establishing a connection with the other 241 peer. ICE does not solve the MIF issues, such as the incompatible 242 configuration objects received on different interfaces. However, ICE 243 may be of use for address selection if the application is ICE- 244 enabled. 246 Some application protocols do referrals (i.e. provides reachability 247 information to itself or to a third-part) of IP addresses and port 248 numbers for further exchanges. Grobj 249 [I-D.carpenter-behave-referral-object] defines the problem with 250 referrals in today's IP networks. While referrals feature does not 251 solve the MIF issues, it is related since, in a multiple provisioning 252 domain context, referrals must provide consistent information 253 depending on which provisioning domain is used. 255 3.6. Socket API 257 Application Programming Interface (API) may expose objects that user 258 applications may use for the MIF purpose. For example, [RFC3542] 259 shows how an application using the Advanced sockets API can specify 260 the interface or the source IP address, through simple bind() 261 operation or IPV6_PKTINFO socket option. 263 There are other examples of API dealing with similar issues to MIF. 264 For instance, [RFC5014] defines API to influence the default address 265 selection mechanism by specifying attributes of the source addresses 266 it prefers. [I-D.ietf-shim6-multihome-shim-api] gives another 267 example in a multihoming context, by defining a socket API enabling 268 interactions between applications and the multihoming shim layer for 269 advanced locator management, and access to information about failure 270 detection and path exploration. 272 In the MIF context, some implementations, specially in the mobile 273 world, rely on higher-level connection managers to deal with issues 274 brought by multiple provisioning domains. Typically, the connection 275 manager can select the provisioning domain when application is domain 276 scoped. Connection managers usually leverage on API to gather 277 information and/or for control purpose. If examples exist, as 278 reminded above, there is no set of high level API to provide all 279 required services for a connection manager expected to address IP 280 configuration issues in a context of multiple provisioning domains. 282 Moreover, various operation system implementations deliver different 283 sets of high level API. In addition, these mechanisms do not 284 necessarily behave the same way across different platform and OS in 285 the presence of the MIF problems [I-D.ietf-mif-current-practices]. 286 This lack of harmonization is an issue since it may lead to multiple 287 instantiation of a cross platform/OS connection manager or 288 application. 290 3.7. Above IP Layers 292 The MIF issues discussed in this document assume no changes in 293 transport protocols or applications. However, fixing the issues 294 might involve these layers. For instance, an application may 295 implement the connection management function (as decribed in 296 preceding section). 298 4. Symptoms 300 This section describes the various symptoms found using a MIF host 301 that has already received configuration objects from its various 302 provisioning domains. 304 These situations are also described in 305 [I-D.savolainen-mif-dns-server-selection], [I-D.yang-mif-req] and 306 [RFC4477]. They occur, for example, when: 307 1. one interface is on the Internet and one is on a corporate 308 private network. The latter may be through VPN. 309 2. one interface is on one access network (i.e. wifi) and the other 310 one is on another access network (3G) with specific services. 312 4.1. DNS resolution issues 314 A MIF host (H1) has an active interface(I1) connected to a network 315 (N1) which has its DNS server (S1) and another active interface (I2) 316 connected to a network (N2) which has its DNS server (S2). S1 serves 317 with some private namespace "private.example.com". The user or the 318 application uses a name "a.private.example.com" which is within the 319 private namespace of S1 and only resolvable by S1. Any of the 320 following situations may occur: 321 1. H1 stack, based on its routing table, uses I2 to reach S1 to 322 resolve "a.private.example.com". H1 never reaches S1. The name 323 is not resolved. 324 2. H1 keeps only one set of DNS server addresses from the received 325 configuration objects and kept S2 address. H1 sends the DNS A 326 query for a.private.example.com to S2. S2 responds with an error 327 for an non-existant domain (NXDOMAIN). The name is not resolved. 329 3. H1 keeps only one set of DNS server addresses from the received 330 configuration objects and kept S2 address. H1 sends the DNS A 331 query for a.private.example.com to S2. S2 asks its upstream DNS 332 and gets an IP address for a.private.example.com. However, the 333 IP address is not the same one S1 would have given. Therefore, 334 the application tries to connect to the wrong destination host, 335 or to the wrong interface of the latter, which may imply security 336 issues or result in lack of service. 337 4. S1 or S2 has been used to resolve "a.private.example.com" to an 338 [RFC1918] address. Both N1 and N2 are [RFC1918] addressed 339 networks. IPv4 source address selection may face challenges, as 340 due address overlapping the source/destination IP addresses do 341 not necessarily provide enough information for making proper 342 address selection decisions. 343 5. H1 has resolved an FQDN to locally valid IP address when 344 connected to N1. After movement from N1 to N2, the host tries to 345 connect to the same IP address as earlier, but as the address was 346 only locally valid, connection setup fails. 347 6. H1 requests AAAA record from a DNS server on a network that uses 348 protocol translators and DNS64 [I-D.ietf-behave-dns64]. If the 349 H1 receives synthesized AAAA record, it is guaranteed to be valid 350 only on the network it was learned from. If the H1 uses 351 synthesized AAAA on an network interface it is not valid on, the 352 packets will be dropped by the network. 354 4.2. Routing 356 A MIF host (H1) has an active interface(I1) connected to a network 357 (N1) and another active interface (I2) connected to a network (N2). 358 The user or the application is trying to reach an IP address (IP1). 359 Any of the following situations may occur: 360 1. For IP1 , H1 has one default route (R1) via network (N1). So, 361 trying to reach IP1, H1 stack uses R1 and sends through I1. If 362 IP1 is only reachable by N2, IP1 is never reached or is not the 363 right target. 364 2. For the IP1 address family, H1 has one default route (R1, R2) per 365 network (N1, N2). IP1 is reachable by both networks, but N2 path 366 has better characterictics, such as better round-trip time, least 367 cost, better bandwidth, etc.... These preferences could be 368 defined by user, by the provider, by discovery or else. H1 stack 369 uses R1 and tries to send through I1. IP1 is reached but the 370 service would be better by I2. 371 3. For the IP1 address family, H1 has a default route (R1), a 372 specific X.0.0.0/8 route R1B (eg. RFC1918 prefix) to N1 and a 373 default route (R2) to N2. IP1 is reachable by N2 only, but the 374 prefix (X.0.0.0/8) is used in both networks. Because of the most 375 specific route R1B, H1 stack sends through I2 and never reach the 376 target. 378 A MIF host may have multiple routes to a destination. However, by 379 default, it does not have any hint concerning which interface would 380 be the best to use for that destination. For example, as discussed 381 in [I-D.savolainen-mif-dns-server-selection], 382 [I-D.hui-ip-multiple-connections-ps] and [I-D.yang-mif-req], a 383 service provider might want to influence the routing table of the 384 host connecting to its network. 386 A host usually has a node-scoped routing table. Therefore, when a 387 MIF host is connected to multiple provisioning domains where each 388 service provider wants to influence the routing table of the host, 389 then conflicts might arise from the multiple routing information 390 being pushed to the host. 392 A user on such multihomed host might want a local policy to influence 393 which interface will be used based on various conditions. 395 On a MIF host, some source addresses are not valid if used on some 396 interfaces. For example, an RFC1918 source address might be 397 appropriate on the VPN interface but not on the public interface of 398 the MIF host. If the source address is not chosen appropriately, 399 then sent packets might be filtered in the path if source address 400 filtering is in place ([RFC2827],[RFC3704]) and reply packets might 401 never come back to the source. 403 4.3. Address Selection Policy 405 A MIF host (H1) has an active interface(I1) connected to a network 406 (N1) and another active interface (I2) connected to a network (N2). 407 When the user or the application is trying to reach an IP address 408 (IP1), the following situations may occur: 409 H1 receives from both networks (N1 and N2) an update of its 410 default address selection policy. However, the policies are 411 specific to each network. The policies are merged by H1 stack. 412 Based on the merged policy, the chosen source address is from N1 413 but packets are sent to N2. The source address is not reachable 414 from N2, therefore the return packet is lost. 416 Merging address selection policies may have important impacts on 417 routing. 419 4.4. Single Interface on Multiple Provisioning Domains 421 When a MIF host using a single interface is connected to multiple 422 networks with different default routers, similar issues as described 423 above happen. Even with a single interface, a node may wish to 424 connect to more than one configuration domain: that node may use more 425 than one IP source address and may have more than one default router. 427 The node may want to access services that can only be reached using 428 one of the provisioning domain, so it needs to use the right outgoing 429 source address and default gateway to reach that service. In this 430 situation, that node may also need to use different DNS servers to 431 get domain names in those different provisioning domains. 433 5. Problems 435 This section tries to list the underlying problems corresponding to 436 the issues discussed in the previous section. The problems can be 437 divided into five categories: 1) Configuration 2) DNS resolution 3) 438 Routing 4) Address selection and 5) connection management. They are 439 shown as below: 441 1. Configuration 442 1. Configuration objects (e.g. DNS servers, NTP servers, ...) 443 are usually node-scoped. 444 2. Same configuration objects (e.g. DNS server addresses, NTP 445 server addresses, ..) received from multiple provisioning 446 domains are usually overwritten. 447 3. Host implementations usually do not keep separate network 448 configuration (such as DNS server addresses) per provisioning 449 domain. 450 4. Referrals must provide consistent information depending on 451 which provisioning domain is concerned. 452 2. DNS resolution 453 1. DNS server addresses are usually node-scoped. 454 2. DNS answers are usually not kept with the interface from 455 which the answer comes from. 456 3. Routing 457 1. Routing tables are usually node-scoped. 458 2. Host implementations usually do not implement the [RFC1122] 459 models where the Type-of-Service are in the routing table. 460 3. Host implementations usually do not keep path 461 characteristics, user or provider preferences in the routing 462 table. 463 4. Address selection 464 1. Default Address Selection policies are usually node-scoped. 465 2. Default Address Selection policies may differ when received 466 on different provisioning domains. 467 3. Host implementations usually do not implement the strong host 468 model [RFC1122] where the source address is in the routing 469 table. 470 4. Applications usually do not use advanced APIs to specify the 471 source IP address or to set preferences on the address 472 selection policies. 474 5. Connection management 475 1. Some implementations, specially in the mobile world, have 476 higher-level API and/or connection manager to address MIF 477 issues. These mechanisms are not standardized and do not 478 necessarily behave the same way across different OS, and/or 479 platorms, in the presence of the MIF problems. 480 2. Provisioning domain selection is a feature of connection 481 management. Domain selection can be tricky due to lot of 482 different situations and selection criteria: some 483 applications are domain-scoped, or may have a preferred 484 provisioning domain (e.g. according to avalaible QoS). Each 485 actor (end-user, operator, service provider, etc.) may also 486 have their preferred provisioning domains (e.g. single out 487 lower cost domain), possibly per application. 488 3. The different actors may provide different, and sometimes 489 contradictory, domain selection policies to the connection 490 management function. The connection manager can typically 491 address the issue, but not all connection managers are able 492 to. 493 4. A MIF host can support different connection managers, which 494 may have contradictory ways to solve the MIF issues. For 495 instance, because of different selection algorithms, two 496 different connection managers could select different domains 497 in a same context. Or, when dealing with different domain 498 selection policies, a connection manager may give precedence 499 to user policy while another could favour mobile operator 500 policy. 502 6. Summary 504 A MIF host receives node configuration information from each of its 505 provisioning domains. Some configuration objects are global to the 506 node, some are local to the interface. Various issues arise when 507 multiple conflicting node-scoped configuration objects are received 508 via multiple provisioning domains. Similar situations also happen 509 with single interface host connected to multiple networks. 510 Therefore, there is a need to define the appropriate behavior of an 511 IP stack and possibly define protocols to manage these cases. 513 7. Security Considerations 515 The problems discussed in this document have security implications, 516 such as when the packets sent on the wrong interface might be leaking 517 some confidential information. Moreover, the undetermined behavior 518 of IP stacks in the multihomed context bring additional threats where 519 an interface on a multihomed host might be used to conduct attacks 520 targeted to the networks connected by the other interfaces. 522 8. IANA Considerations 524 This document has no actions for IANA. 526 9. Authors 528 This document is a joint effort with authors of the MIF requirements 529 draft [I-D.yang-mif-req]. The authors of this document, in 530 alphabetical order, include: Marc Blanchet, Jacqni Qin, Pierrick 531 Seite, Carl Williams and Peny Yang. 533 10. Acknowledgements 535 The initial Internet-Drafts prior to the MIF working group and the 536 discussions during the MIF BOF meeting and on the mailing list around 537 the MIF charter scope on the mailing list brought very good input to 538 the problem statement. This draft steals a lot of text from these 539 discussions and the initial drafts. Therefore, the editor would like 540 to acknowledge the following people (in no specific order), from 541 which some text has been taken from: Jari Arkko, Keith Moore, Sam 542 Hartman, George Tsirtsis, Scott Brim, Ted Lemon, Bernie Volz, Giyeong 543 Son, Gabriel Montenegro, Julien Laganier, Teemu Savolainen, Christian 544 Vogt, Lars Eggert, Margaret Wasserman, Hui Deng, Ralph Droms, Ted 545 Hardie, Christian Huitema, Remi Denis-Courmont, Alexandru Petrescu, 546 Zhen Cao. Sorry if some contributors have not been named. 548 11. Informative References 550 [I-D.carpenter-behave-referral-object] 551 Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and 552 K. Moore, "A Generic Referral Object for Internet 553 Entities", draft-carpenter-behave-referral-object-01 (work 554 in progress), October 2009. 556 [I-D.chown-addr-select-considerations] 557 Chown, T., "Considerations for IPv6 Address Selection 558 Policy Changes", draft-chown-addr-select-considerations-03 559 (work in progress), July 2009. 561 [I-D.hui-ip-multiple-connections-ps] 562 Hui, M. and H. Deng, "Problem Statement and Requirement of 563 Simple IP Multi-homing of the Host", 564 draft-hui-ip-multiple-connections-ps-02 (work in 565 progress), March 2009. 567 [I-D.ietf-behave-dns64] 568 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 569 "DNS64: DNS extensions for Network Address Translation 570 from IPv6 Clients to IPv4 Servers", 571 draft-ietf-behave-dns64-09 (work in progress), March 2010. 573 [I-D.ietf-mif-current-practices] 574 Wasserman, M., "Current Practices for Multiple Interface 575 Hosts", draft-ietf-mif-current-practices-00 (work in 576 progress), October 2009. 578 [I-D.ietf-mmusic-ice] 579 Rosenberg, J., "Interactive Connectivity Establishment 580 (ICE): A Protocol for Network Address Translator (NAT) 581 Traversal for Offer/Answer Protocols", 582 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 584 [I-D.ietf-shim6-multihome-shim-api] 585 Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, 586 "Socket Application Program Interface (API) for 587 Multihoming Shim", draft-ietf-shim6-multihome-shim-api-13 588 (work in progress), February 2010. 590 [I-D.savolainen-mif-dns-server-selection] 591 Savolainen, T., "DNS Server Selection on Multi-Homed 592 Hosts", draft-savolainen-mif-dns-server-selection-02 (work 593 in progress), February 2010. 595 [I-D.yang-mif-req] 596 Yang, P., Seite, P., Williams, C., and J. Qin, 597 "Requirements on multiple Interface (MIF) of simple IP", 598 draft-yang-mif-req-00 (work in progress), March 2009. 600 [RFC1122] Braden, R., "Requirements for Internet Hosts - 601 Communication Layers", STD 3, RFC 1122, October 1989. 603 [RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing 604 Domains: A model for routing in the Internet", RFC 1136, 605 December 1989. 607 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 608 RFC 1661, July 1994. 610 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 611 E. Lear, "Address Allocation for Private Internets", 612 BCP 5, RFC 1918, February 1996. 614 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 615 RFC 2131, March 1997. 617 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 618 Defeating Denial of Service Attacks which employ IP Source 619 Address Spoofing", BCP 38, RFC 2827, May 2000. 621 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 622 and M. Carney, "Dynamic Host Configuration Protocol for 623 IPv6 (DHCPv6)", RFC 3315, July 2003. 625 [RFC3484] Draves, R., "Default Address Selection for Internet 626 Protocol version 6 (IPv6)", RFC 3484, February 2003. 628 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 629 "Advanced Sockets Application Program Interface (API) for 630 IPv6", RFC 3542, May 2003. 632 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 633 Networks", BCP 84, RFC 3704, March 2004. 635 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 636 April 2006. 638 [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host 639 Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack 640 Issues", RFC 4477, May 2006. 642 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 643 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 644 September 2007. 646 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 647 Socket API for Source Address Selection", RFC 5014, 648 September 2007. 650 [RFC5113] Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network 651 Discovery and Selection Problem", RFC 5113, January 2008. 653 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 654 "Problem Statement for Default Address Selection in Multi- 655 Prefix Environments: Operational Issues of RFC 3484 656 Default Rules", RFC 5220, July 2008. 658 Authors' Addresses 660 Marc Blanchet 661 Viagenie 662 2600 boul. Laurier, suite 625 663 Quebec, QC G1V 4W1 664 Canada 666 Email: Marc.Blanchet@viagenie.ca 667 URI: http://www.viagenie.ca 669 Pierrick Seite 670 France Telecom - Orange 671 4, rue du Clos Courtel, BP 91226 672 Cesson-Sevigne 35512 673 France 675 Email: pierrick.seite@orange-ftgroup.com