idnits 2.17.1 draft-ietf-mif-problem-statement-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- 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 (March 8, 2010) is 5162 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-07 == 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 -- 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: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet Ed. 3 Internet-Draft Viagenie 4 Intended status: Informational P. Seite 5 Expires: September 9, 2010 France Telecom 6 March 8, 2010 8 Multiple Interfaces Problem Statement 9 draft-ietf-mif-problem-statement-02.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 to IETF 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), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 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 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 9, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. Scope and Existing Work . . . . . . . . . . . . . . . . . . . 5 76 3.1. Below IP Interaction . . . . . . . . . . . . . . . . . . . 5 77 3.2. Hosts Requirements . . . . . . . . . . . . . . . . . . . . 5 78 3.3. Mobility and other IP protocols . . . . . . . . . . . . . 6 79 3.4. Address Selection . . . . . . . . . . . . . . . . . . . . 6 80 3.5. Finding and Sharing IP Addresses with Peers . . . . . . . 6 81 3.6. Socket API . . . . . . . . . . . . . . . . . . . . . . . . 7 82 3.7. Above IP Layers . . . . . . . . . . . . . . . . . . . . . 8 83 4. Symptoms . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 4.1. DNS resolution issues . . . . . . . . . . . . . . . . . . 8 85 4.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 4.3. Address Selection Policy . . . . . . . . . . . . . . . . . 10 87 4.4. Single Interface on Multiple Networks . . . . . . . . . . 10 88 5. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 89 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 92 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 94 11. Discussion home for this draft . . . . . . . . . . . . . . . . 12 95 12. Informative References . . . . . . . . . . . . . . . . . . . . 13 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 98 1. Introduction 100 A multihomed host have multiple provisioning domains (via physical 101 and/or virtual interfaces). For example, a node may be 102 simultaneously connected to a wired Ethernet LAN, a 802.11 LAN, a 3G 103 cell network, one or multiple VPN connections or one or multiple 104 automatic or manual tunnels. Current laptops and smartphones 105 typically have multiple access network interfaces and, thus, may be 106 simultaneously connected to different provisioning domains. 108 A multihomed host receives node configuration information from each 109 of its access networks, through various mechanims such as DHCPv4 110 [RFC2131], DHCPv6 [RFC3315], PPP [RFC1661] and IPv6 Router 111 Advertisements [RFC4861]. Some received configuration objects are 112 specific to an interface such as the IP address and the link prefix. 113 Others are typically considered by implementations as being global to 114 the node, such as the routing information (e.g. default gateway), DNS 115 servers IP addresses and address selection policies. 117 When the received node-scoped configuration objects have different 118 values from each provisioning domains, such as different DNS servers 119 IP addresses, different default gateways or different address 120 selection policies, the node has to decide which it will use or how 121 it will merge them. 123 Several issues regarding how the node-scoped configuration objects 124 are used in a multihomed node environment have been raised. The 125 following sections define the MIF host and the scope of this 126 document, describe related work, list the symptoms and then the 127 underlying problems. 129 A companion document [I-D.ietf-mif-current-practices] discusses 130 current practices. 132 2. Terminology 134 A MIF host is defined as: 135 o A [RFC1122] IPv4 and/or [RFC4294] IPv6 compliant host 136 o Configured with more than one IP addresses (excluding loopback, 137 link-local) 138 o On one or more provisioning domains, as presented to the IP stack. 139 o The interfaces may be logical, virtual or physical. 140 o The IP addresses come from more than one administrative domains. 141 o The IP addresses may be from the same or from different address 142 families, such as IPv4 and IPv6. 144 o Communications using these IP addresses may happen simultaneously 145 and independently. 146 o Communications using these IP addresses may be tied on all the 147 possible provisioning domains, or, at least, on a limited number 148 of provisioning domains. 149 o While the MIF host may forward packets between its interfaces, 150 forwarding packets is not taken into account in this definition. 152 When a protocol keyword such as IP, PPP, DHCP is used without any 153 reference to a specific IP version, then it implies both IPv4 and 154 IPv6. A specific IP version keyword such as DHCPv4 or DHCPv6 is 155 specific to that IP version. 157 3. Scope and Existing Work 159 This section describes existing related work and defines the scope of 160 the problem. 162 3.1. Below IP Interaction 164 Network discovery and selection on lower layers as defined by 165 [RFC5113] is out of scope of this document. Moreover, lower layer 166 interaction such as IEEE 802.21 is also out of scope. 168 Proxy MIP allows sharing a single IP address across multiple interfac 169 es (e.g., WiMAX and CDMA, LTE and HSPA, etc) to disparate networks. 170 From the IP stack view on the node, there is only a single interface 171 and single IP address. Therefore, this situation is out of scope. 172 Furthermore, link aggregation done under IP where a single interace 173 is shown to the IP stack is also out of scope. 175 3.2. Hosts Requirements 177 The requirements for Internet Hosts [RFC1122] describe the multihomed 178 host as if it has multiple IP addresses, which may be associated with 179 one or more physical interfaces connected to the same or different 180 networks. 182 The host maintains a route cache table where each entry contains the 183 local IP address, the destination IP address, Type-of-Service and 184 Next-hop gateway IP address. The route cache entry would have data 185 about the properties of the path, such as the average round-trip 186 delay measured by a transport protocol. 188 As per [RFC1122], two models are defined: 190 o The "Strong" host model defines a multihomed host as a set of 191 logical hosts within the same physical host. In this model a 192 packet must be sent on an interface that corresponds to the source 193 address of that packet. 194 o The "Weak" host model describes a host that has some embedded 195 gateway functionality. In the weak host model, the host can send 196 and receive packets on any interface. 198 The multihomed host computes routes for outgoing datagrams 199 differently depending on the model. Under the strong model, the 200 route is computed based on the source IP address, the destination IP 201 address and the Type-of-Service. Under the weak model, the source IP 202 address is not used, but only the destination IP address and the 203 Type-of-Service. 205 3.3. Mobility and other IP protocols 207 This document assumes hosts only implementing [RFC1122] for IPv4 and 208 [RFC4294] for IPv6, and not using any kind of new transport 209 protocols. It is not required for the host to support additional IP 210 mobility or multihoming protocols, such as SHIM6, SCTP, Mobile IP, 211 HIP, RRG, LISP or else. Moreover, the peer of the connection is also 212 not required to use these mechanisms. 214 3.4. Address Selection 216 The Default Address Selection [RFC3484] defines algorithms for source 217 and destination IP address selections. It is mandatory to be 218 implemented in IPv6 nodes, which also means dual-stack nodes. A 219 node-scoped policy table managed by the IP stack is defined. 220 Provisions are made to change or update the policy table, however, no 221 mechanism is defined. 223 Issues on using the Default Address Selection were found [RFC5220] in 224 the context of multiple prefixes on the same link. New work 225 [I-D.chown-addr-select-considerations] discusses the multiple 226 attached networks scenarios and how to update the policy table. 228 3.5. Finding and Sharing IP Addresses with Peers 230 Interactive Connectivity Establishment (ICE [I-D.ietf-mmusic-ice]) is 231 a technique for NAT traversal for UDP-based (and TCP) media streams 232 established by the offer/answer model. The multiplicity of IP 233 addresses and ports in SDP offers are tested for connectivity by 234 peer-to-peer connectivity checks. The result is candidate IP 235 addresses and ports for establishing a connection with the other 236 peer. ICE does not solve the MIF issues, such as the incompatible 237 configuration objects received on different interfaces. However, ICE 238 may be of use for address selection if the application is ICE- 239 enabled. 241 Some application protocols do referrals (i.e. provides reachability 242 information to itself or to a third-part) of IP addresses and port 243 numbers for further exchanges. Grobj 244 [I-D.carpenter-behave-referral-object] defines the problem with 245 referrals in today's IP networks. While referrals feature does not 246 solve the MIF issues, it is related since, in a multiple provisioning 247 domain context, referrals must provide consistent information 248 depending on which provisioning domain is used. 250 3.6. Socket API 252 Application Programming Interface (API) may expose objects that user 253 applications may use for the MIF purpose. For example, [RFC3542] 254 shows how an application using the Advanced sockets API can specify 255 the interface or the source IP address, through simple bind() 256 operation or IPV6_PKTINFO socket option. 258 There are other examples of API dealing with MIF similar issues. For 259 instance, [RFC5014] defines API to influence the default address 260 selection mechanism by specifying attributes of the source addresses 261 it prefers. [I-D.ietf-shim6-multihome-shim-api] gives another 262 example in a multihoming context, by defining a socket API enabling 263 interactions between applications and the multihoming shim layer for 264 advanced locator management, and access to information about failure 265 detection and path exploration. 267 In the MIF context, some implementations, specially in the mobile 268 world, rely on higher-level connection managers to deal with issues 269 brought by multiple provisioning domains. For instance, the 270 connection manager may select the provisioning domain when 271 application is domain scoped. Connection managers usually leverage 272 on API to gather information and/or for control purpose. If examples 273 exist, as reminded above, there is no set of high level API to 274 provide all required services for a connection manager expected to 275 address IP configuration issues in a context of multiple provisioning 276 domains. Moreover, various operation system implementations deliver 277 different sets of high level API. These mechanisms do not 278 necessarily behave the same way in the presence of the MIF problems 279 [I-D.ietf-mif-current-practices]. Therefore, in order to avoid 280 multiple instantiation of a same connection manager and for an 281 harmonized behaviour across different platform and OS, 282 standardization of such an API would bring more consistency in 283 application development. 285 3.7. Above IP Layers 287 The MIF issues discussed in this document assume no changes in 288 transport protocols or applications. However, fixing the issues 289 might involve these layers. For instance, an application may 290 implement the connection management function (as decribed in 291 preceding section). 293 4. Symptoms 295 This section describes the various symptoms found using a MIF host 296 that has already received configuration objects from its various 297 provisioning domains. 299 These situations are also described in 300 [I-D.savolainen-6man-fqdn-based-if-selection], [I-D.yang-mif-req] and 301 [RFC4477]. They occur, for example, when: 302 1. one interface is on the Internet and one is on a corporate 303 private network. The latter may be through VPN. 304 2. one interface is on one access network (i.e. wifi) and the other 305 one is on another access network (3G) with specific services. 307 4.1. DNS resolution issues 309 A MIF host (H1) has an active interface(I1) connected to a network 310 (N1) which has its DNS server (S1) and another active interface (I2) 311 connected to a network (N2) which has its DNS server (S2). S1 serves 312 with some private namespace "private.example.com". The user or the 313 application uses a name "a.private.example.com" which is within the 314 private namespace of S1 and only resolvable by S1. Any of the 315 following situations may occur: 316 1. H1 stack, based on its routing table, uses I2 to reach S1 to 317 resolve "a.private.example.com". H1 never reaches S1. The name 318 is not resolved. 319 2. H1 keeps only one set of DNS server addresses from the received 320 configuration objects and kept S2 address. H1 sends the DNS A 321 query for a.private.example.com to S2. S2 responds with an error 322 for an non-existant domain (NXDOMAIN). The name is not resolved. 323 3. H1 keeps only one set of DNS server addresses from the received 324 configuration objects and kept S2 address. H1 sends the DNS A 325 query for a.private.example.com to S2. S2 asks its upstream DNS 326 and gets an IP address for a.private.example.com. However, the 327 IP address is not the right one S1 would have given. Therefore, 328 the application tries to connect to the wrong destination host, 329 which may imply security issues. 331 4. S1 or S2 has been used to resolve "a.private.example.com" to an 332 [RFC1918] address. Both N1 and N2 are [RFC1918] addressed 333 networks. IPv4 source address selection may face challenges, as 334 due address overlapping the source/destination IP addresses do 335 not necessarily provide enough information for making proper 336 address selection decisions. 337 5. H1 has resolved an FQDN to locally valid IP address when 338 connected to N1. After movement from N1 to N2, the host tries to 339 connect to the same IP address as earlier, but as the address was 340 only locally valid, connection setup fails. 341 6. H1 requests AAAA record from a DNS server on a network that uses 342 protocol translators and DNS64 [I-D.ietf-behave-dns64]. If the 343 H1 receives synthesized AAAA record, it is quaranteed to be valid 344 only on the network it was learned from. If the H1 uses 345 synthesized AAAA on an network interface it is not valid on, the 346 packets will be dropped by the network. 348 4.2. Routing 350 A MIF host (H1) has an active interface(I1) connected to a network 351 (N1) and another active interface (I2) connected to a network (N2). 352 The user or the application is trying to reach an IP address (IP1). 353 Any of the following situations may occur: 354 1. For the IP1 address family, H1 has one default route (R1, R2) per 355 network (N1, N2). IP1 is only reachable by N2. H1 stack uses R1 356 and tries to send through I1. IP1 is never reached or is not the 357 right target. 358 2. For the IP1 address family, H1 has one default route (R1, R2) per 359 network (N1, N2). IP1 is reachable by both networks, but N2 path 360 has better characterictics, such as better round-trip time, least 361 cost, better bandwidth, etc.... These preferences could be 362 defined by user, by the provider, by discovery or else. H1 stack 363 uses R1 and tries to send through I1. IP1 is reached but the 364 service would be better by I2. 365 3. For the IP1 address family, H1 has a default route (R1), a 366 specific X.0.0.0/8 route R1B (eg. RFC1918 prefix) to N1 and a 367 default route (R2) to N2. IP1 is reachable by N2 only, but the 368 prefix (X.0.0.0/8) is used in both networks. Because of the most 369 specific route R1B, H1 stack sends through I2 and never reach the 370 target. 372 A MIF host may have multiple routes to a destination. However, by 373 default, it does not have any hint concerning which interface would 374 be the best to use for that destination. For example, as discussed 375 in [I-D.savolainen-6man-fqdn-based-if-selection], 376 [I-D.hui-ip-multiple-connections-ps] and [I-D.yang-mif-req], a 377 service provider might want to influence the routing table of the 378 host connecting to its network. 380 A host usually has a node-scoped routing table. Therefore, when a 381 MIF host is connected to multiple provisioning domains where each 382 service provider wants to influence the routing table of the host, 383 then conflicts might arise from the multiple routing information 384 being pushed to the host. 386 A user on such multihomed host might want a local policy to influence 387 which interface will be used based on various conditions. 389 On a MIF host, some source addresses are not valid if used on some 390 interfaces. For example, an RFC1918 source address might be 391 appropriate on the VPN interface but not on the public interface of 392 the MIF host. If the source address is not chosen appropriately, 393 then sent packets might be filtered in the path if source address 394 filtering is in place ([RFC2827],[RFC3704]) and reply packets might 395 never come back to the source. 397 4.3. Address Selection Policy 399 A MIF host (H1) has an active interface(I1) connected to a network 400 (N1) and another active interface (I2) connected to a network (N2). 401 The user or the application is trying to reach an IP address (IP1). 402 Any of the following situations may occur: 403 1. H1 receives from both networks (N1 and N2) an update of its 404 default address selection policy. However, the policies are 405 specific to each network. The policies are merged by H1 stack. 406 Based on the merged policy, the chosen source address is from N1 407 but packets are sent to N2. The source address is not reachable 408 from N2, therefore the return packet is lost. 410 Merging address selection policies may have important impacts on 411 routing. 413 4.4. Single Interface on Multiple Networks 415 When a MIF host using a single interface is connected to multiple 416 networks with different default routers, similar issues as described 417 above happen. 419 5. Problems 421 This section tries to list the underlying problems corresponding to 422 the issues discussed in the previous section. The problems can be 423 divided into five categories: 1) Configuration 2) DNS resolution 3) 424 Routing 4) Address selectiona and 5) connexion management. They are 425 shown as below: 427 o Configuration 428 1. Configuration objects (e.g. DNS servers, NTP servers, ...) 429 are usually node-scoped. 430 2. Same configuration objects (e.g. DNS server addresses, NTP 431 server addresses, ..) received from multiple provisioning 432 domains are usually overwritten. 433 3. Host implementations usually do not keep separate network 434 configuration (such as DNS server addresses) per provisioning 435 domain. 436 4. Referrals must provide consistent information depending on 437 which provisioning domain is concerned. 438 o DNS resolution 439 1. DNS server addresses are usually node-scoped. 440 2. DNS answers are usually not kept with the interface from which 441 the answer comes from. 442 o Routing 443 1. Routing tables are usually node-scoped. 444 2. Host implementations usually do not implement the [RFC1122] 445 models where the Type-of-Service are in the routing table. 446 3. Host implementations usually do not keep path characteristics, 447 user or provider preferences in the routing table. 448 o Address selection 449 1. Default Address Selection policies are usually node-scoped. 450 2. Default Address Selection policies may differ when received on 451 different provisioning domains. 452 3. Host implementations usually do not implement the [RFC1122] 453 strong model where the source address is in the routing table. 454 4. Applications usually do not use advanced APIs to specify the 455 source IP address or to set preferences on the address 456 selection policies. 457 o Connexion management 458 1. Some implementations, specially in the mobile world, have 459 higher-level API and/or connection manager. These mechanisms 460 are not standardized and do not necessarily behave the same 461 way across different OS, and/or platorms, in the presence of 462 the MIF problems. So, clearly, standardization could bring 463 harmonization, e.g. a standard API could be considered. 465 6. Summary 467 A MIF host receives node configuration information from each of its 468 provisioning domains. Some configuration objects are global to the 469 node, some are local to the interface. Various issues arise when 470 multiple conflicting node-scoped configuration objects are received 471 via multiple provisioning domains. Similar situations also happen 472 with single interface host connected to multiple networks. 473 Therefore, there is a need to define the appropriate behavior of an 474 IP stack and possibly define protocols to manage these cases. 476 7. Security Considerations 478 The problems discussed in this document have security implications, 479 such as when the packets sent on the wrong interface might be leaking 480 some confidential information. Moreover, the undetermined behavior 481 of IP stacks in the multihomed context bring additional threats where 482 an interface on a multihomed host might be used to conduct attacks 483 targeted to the networks connected by the other interfaces. 485 8. IANA Considerations 487 This document has no actions for IANA. 489 9. Authors 491 This document is a joint effort with authors of the MIF requirements 492 draft [I-D.yang-mif-req]. The authors of this document, in 493 alphabetical order, include: Marc Blanchet, Jacqni Qin, Pierrick 494 Seite, Carl Williams and Peny Yang. 496 10. Acknowledgements 498 The initial Internet-Drafts prior to the MIF working group and the 499 discussions during the MIF BOF meeting and on the mailing list around 500 the MIF charter scope on the mailing list brought very good input to 501 the problem statement. This draft steals a lot of text from these 502 discussions and the initial drafts. Therefore, the editor would like 503 to acknowledge the following people (in no specific order), from 504 which some text has been taken from: Jari Arkko, Keith Moore, Sam 505 Hartman, George Tsirtsis, Scott Brim, Ted Lemon, Bernie Volz, Giyeong 506 Son, Gabriel Montenegro, Teemu Savolainen, Christian Vogt, Lars 507 Eggert, Margaret Wasserman, Hui Deng, Ralph Droms, Ted Hardie, 508 Christian Huitema, Remi Denis-Courmont, Zhen Cao. Sorry if some 509 contributors have not been named. 511 11. Discussion home for this draft 513 This document is intended to define the problem space discussed in 514 the mif@ietf.org mailing list. 516 12. Informative References 518 [I-D.carpenter-behave-referral-object] 519 Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and 520 K. Moore, "A Generic Referral Object for Internet 521 Entities", draft-carpenter-behave-referral-object-01 (work 522 in progress), October 2009. 524 [I-D.chown-addr-select-considerations] 525 Chown, T., "Considerations for IPv6 Address Selection 526 Policy Changes", draft-chown-addr-select-considerations-03 527 (work in progress), July 2009. 529 [I-D.hui-ip-multiple-connections-ps] 530 Hui, M. and H. Deng, "Problem Statement and Requirement of 531 Simple IP Multi-homing of the Host", 532 draft-hui-ip-multiple-connections-ps-02 (work in 533 progress), March 2009. 535 [I-D.ietf-behave-dns64] 536 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 537 "DNS64: DNS extensions for Network Address Translation 538 from IPv6 Clients to IPv4 Servers", 539 draft-ietf-behave-dns64-07 (work in progress), March 2010. 541 [I-D.ietf-mif-current-practices] 542 Wasserman, M., "Current Practices for Multiple Interface 543 Hosts", draft-ietf-mif-current-practices-00 (work in 544 progress), October 2009. 546 [I-D.ietf-mmusic-ice] 547 Rosenberg, J., "Interactive Connectivity Establishment 548 (ICE): A Protocol for Network Address Translator (NAT) 549 Traversal for Offer/Answer Protocols", 550 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 552 [I-D.ietf-shim6-multihome-shim-api] 553 Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, 554 "Socket Application Program Interface (API) for 555 Multihoming Shim", draft-ietf-shim6-multihome-shim-api-13 556 (work in progress), February 2010. 558 [I-D.savolainen-6man-fqdn-based-if-selection] 559 Savolainen, T., "Domain name based network interface 560 selection", 561 draft-savolainen-6man-fqdn-based-if-selection-00 (work in 562 progress), October 2008. 564 [I-D.yang-mif-req] 565 Yang, P., Seite, P., Williams, C., and J. Qin, 566 "Requirements on multiple Interface (MIF) of simple IP", 567 draft-yang-mif-req-00 (work in progress), March 2009. 569 [RFC1122] Braden, R., "Requirements for Internet Hosts - 570 Communication Layers", STD 3, RFC 1122, October 1989. 572 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 573 RFC 1661, July 1994. 575 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 576 E. Lear, "Address Allocation for Private Internets", 577 BCP 5, RFC 1918, February 1996. 579 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 580 RFC 2131, March 1997. 582 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 583 Defeating Denial of Service Attacks which employ IP Source 584 Address Spoofing", BCP 38, RFC 2827, May 2000. 586 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 587 and M. Carney, "Dynamic Host Configuration Protocol for 588 IPv6 (DHCPv6)", RFC 3315, July 2003. 590 [RFC3484] Draves, R., "Default Address Selection for Internet 591 Protocol version 6 (IPv6)", RFC 3484, February 2003. 593 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 594 "Advanced Sockets Application Program Interface (API) for 595 IPv6", RFC 3542, May 2003. 597 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 598 Networks", BCP 84, RFC 3704, March 2004. 600 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 601 April 2006. 603 [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host 604 Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack 605 Issues", RFC 4477, May 2006. 607 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 608 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 609 September 2007. 611 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 612 Socket API for Source Address Selection", RFC 5014, 613 September 2007. 615 [RFC5113] Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network 616 Discovery and Selection Problem", RFC 5113, January 2008. 618 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 619 "Problem Statement for Default Address Selection in Multi- 620 Prefix Environments: Operational Issues of RFC 3484 621 Default Rules", RFC 5220, July 2008. 623 Authors' Addresses 625 Marc Blanchet 626 Viagenie 627 2600 boul. Laurier, suite 625 628 Quebec, QC G1V 4W1 629 Canada 631 Email: Marc.Blanchet@viagenie.ca 632 URI: http://www.viagenie.ca 634 Pierrick Seite 635 France Telecom 636 4, rue du Clos Courtel, BP 91226 637 Cesson-Sevigne 35512 638 France 640 Email: pierrick.seite@orange-ftgroup.com