idnits 2.17.1 draft-ietf-mif-problem-statement-08.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 (October 25, 2010) is 4925 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3775' is mentioned on line 241, but not defined ** Obsolete undefined reference: RFC 3775 (Obsoleted by RFC 6275) == Unused Reference: 'RFC4477' is defined on line 741, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-mif-current-practices-04 == Outdated reference: A later version (-05) exists of draft-ietf-mptcp-architecture-02 == Outdated reference: A later version (-17) exists of draft-ietf-shim6-multihome-shim-api-14 == Outdated reference: A later version (-06) exists of draft-savolainen-mif-dns-server-selection-04 -- 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: 1 error (**), 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: April 28, 2011 France Telecom - Orange 6 October 25, 2010 8 Multiple Interfaces and Provisioning Domains Problem Statement 9 draft-ietf-mif-problem-statement-08.txt 11 Abstract 13 This document describes issues encountered by a node attached to 14 multiple provisioning domains. This node receives configuration 15 information from each of its provisioning domains where some 16 configuration objects are global to the node, others are local to the 17 interface. Issues such as selecting the wrong interface to send 18 trafic happen when conflicting node-scoped configuration objects are 19 received and inappropriately used. Moreover, other issues are the 20 result of simulatenous attachment to multiple networks, such as 21 domain selection or addressing and naming space overlaps, regardless 22 of the provisioning mechanism. While multiple provisioning domains 23 are typically seen on nodes with multiple interfaces, this document 24 also discusses single interface nodes situation. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 28, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Scope and Existing Work . . . . . . . . . . . . . . . . . . . 4 63 3.1. Below IP Interaction . . . . . . . . . . . . . . . . . . . 4 64 3.2. MIF node Characterization . . . . . . . . . . . . . . . . 4 65 3.3. Hosts Requirements . . . . . . . . . . . . . . . . . . . . 5 66 3.4. Mobility and other IP protocols . . . . . . . . . . . . . 6 67 3.5. Address Selection . . . . . . . . . . . . . . . . . . . . 6 68 3.6. Finding and Sharing IP Addresses with Peers . . . . . . . 6 69 3.7. Interface and Provisioning domain selection . . . . . . . 7 70 3.8. Connection manager . . . . . . . . . . . . . . . . . . . . 7 71 3.9. Socket API . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4. MIF Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 4.1. DNS resolution issues . . . . . . . . . . . . . . . . . . 8 74 4.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.3. Address Selection Policy . . . . . . . . . . . . . . . . . 10 76 4.4. Single Interface on Multiple Provisioning Domains . . . . 11 77 5. Underlying problems and causes . . . . . . . . . . . . . . . . 11 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 8. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 82 10. Informative References . . . . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 A multihomed node may have multiple provisioning domains (via 88 physical and/or virtual interfaces). For example, a node may be 89 simultaneously connected to a wired Ethernet LAN, a 802.11 LAN, a 3G 90 cell network, one or multiple VPN connections or one or multiple 91 tunnels(automatic or manual). Current laptops and smartphones 92 typically have multiple access network interfaces and, thus, are 93 often connected to different provisioning domains. 95 A multihomed node receives configuration information from each of its 96 attached networks, through various mechanisms such as DHCPv4 97 [RFC2131], DHCPv6 [RFC3315], PPP [RFC1661] and IPv6 Router 98 Advertisements [RFC4861]. Some received configuration objects are 99 specific to an interface such as the IP address and the link prefix. 100 Others are typically considered by implementations as being global to 101 the node, such as the routing information (e.g. default gateway), DNS 102 servers IP addresses, and address selection policies, herein named 103 "node-scoped". 105 When the received node-scoped configuration objects have different 106 values from each provisioning domains, such as different DNS servers 107 IP addresses, different default gateways or different address 108 selection policies, the node has to decidewhich one to use or how it 109 will merge them. 111 Other issues are the result of simulatenous attachment to multiple 112 networks, such as addressing and naming space overlaps, regardless of 113 the provisioning mechanism. 115 The following sections define the multiple interfaces (MIF) node, the 116 scope of this work, describe related work, list issues and then 117 summarize the underlying problems. 119 A companion document [I-D.ietf-mif-current-practices] discusses some 120 current practices of various implementations dealing with MIF. 122 2. Terminology 124 Administrative domain 126 A group of hosts, routers, and networks operated and managed by a 127 single organization [RFC1136]. 129 Provisioning domain 130 A set of consistent configuration information (e.g. Default 131 router, Network prefixes, DNS,...). One administrative domain may 132 have multiple provisioning domains. 134 Reference to IP version 136 When a protocol keyword such as IP, PPP, DHCP is used in this 137 document without any reference to a specific IP version, then it 138 implies both IPv4 and IPv6. A specific IP version keyword such as 139 DHCPv4 or DHCPv6 is meant to be specific to that IP version. 141 3. Scope and Existing Work 143 This section describes existing related work and defines the scope of 144 the problem. 146 3.1. Below IP Interaction 148 Some types of interfaces have link layer characteristics which may be 149 used in determining how multiple provisioning domain issues will be 150 dealt with. For instance, link layers may have authentication and 151 encryption characteristics which could be used as criteria for 152 interface selection. However, network discovery and selection on 153 lower layers as defined by [RFC5113] is out of scope of this 154 document. Moreover, interoperability with lower layer mechanisms 155 such as services defined in IEEE 802.21, which aims at facilitating 156 handover between heterogeneous networks [802.21], is also out of 157 scope. 159 Some mechanisms (e.g., based on a logical IP interface) 160 allow sharing a single IP address over multiple 161 interfaces to networks with disparate access techologies. From the 162 IP stack view on the node, there is only a single interface and 163 single IP address. Therefore, this situation is out of scope of this 164 current problem statement. Furthermore, link aggregation done under 165 IP where a single interface is shown to the IP stack is also out of 166 scope. 168 3.2. MIF node Characterization 170 A MIF node has the following characteristics: 172 o A [RFC1122] IPv4 and/or [RFC4294] IPv6 compliant node 173 o A MIF node is configured with more than one IP addresses 174 (excluding loopback and link-local) 176 o A MIF node can attach to more than one provisioning domains, as 177 presented to the IP stack. 178 o The interfaces may be logical, virtual or physical. 179 o Configuration objects come from one or more administrative 180 domains. 181 o The IP addresses may be from the same or from different address 182 families, such as IPv4 and IPv6. 183 o Communications using these IP addresses may happen simultaneously 184 and independently. 185 o Some communications using these IP addresses are possible on all 186 the provisioning domains, while some are only possible on a 187 smaller set of the provisioning domains. 188 o While the MIF node may forward packets between its interfaces, 189 forwarding packets is not taken into account in this definition 190 and is out of scope for this document. 192 3.3. Hosts Requirements 194 The requirements for Internet Hosts [RFC1122] describe the multihomed 195 node as if it has multiple IP addresses, which may be associated with 196 one or more physical interfaces connected to the same or different 197 networks. 199 The requirements states that The node maintains a route cache table 200 where each entry contains the local IP address, the destination IP 201 address, Type-of-Service and Next-hop gateway IP address. The route 202 cache entry would have data about the properties of the path, such as 203 the average round-trip delay measured by a transport protocol. 204 Nowadays, implementations are not caching these informations. 206 [RFC1122] defines two host models: 207 o The "Strong" host model defines a multihomed host as a set of 208 logical hosts within the same physical host. In this model a 209 packet must be sent on an interface that corresponds to the source 210 address of that packet. 211 o The "Weak" host model describes a host that has some embedded 212 gateway functionality. In the weak host model, the host can send 213 and receive packets on any interface. 215 The multihomed node computes routes for outgoing datagrams 216 differently depending on the model. Under the strong model, the 217 route is computed based on the source IP address, the destination IP 218 address and the Type-of-Service. Under the weak model, the source IP 219 address is not used, but only the destination IP address and the 220 Type-of-Service. 222 3.4. Mobility and other IP protocols 224 The scope of this document is only about nodes implementing [RFC1122] 225 for IPv4 and [RFC4294] for IPv6 without additional features or 226 special-purpose support for transport layers, mobility, multi-homing, 227 or identifier-locator split mechanisms. Dealing with multiple 228 interfaces with such mechanisms is related but considered as a 229 separate problem and is under active study elsewhere in the IETF 230 [RFC4960], [RFC5206], [RFC5533], [RFC5648], 231 [I-D.ietf-mptcp-architecture]. 233 When an application is using one interface while another interface 234 with better characteristics becomes available, the ongoing 235 application session could be transferred to the newly enabled 236 interface. However, in some cases, the ongoing session shall be kept 237 on the current interface while initiating the new sessions on the new 238 interface. The problem of the interface selection is within the MIF 239 scope and may leverage specific node functions (Section 3.8). 240 However, if transfer of IP session is required, IP mobility 241 mechanisms, such as [RFC3775], shall be used. 243 3.5. Address Selection 245 The Default Address Selection specification [RFC3484] defines 246 algorithms for source and destination IP address selections. It is 247 mandatory to be implemented in IPv6 nodes, which also means dual- 248 stack nodes. A node-scoped policy table managed by the IP stack is 249 defined. Mechanisms to update the policy table are being defined 250 [I-D.ietf-6man-addr-select-sol] to update the policy table. 252 Issues on using the Default Address Selection were found in [RFC5220] 253 and [RFC5221] in the context of multiple prefixes on the same link. 255 3.6. Finding and Sharing IP Addresses with Peers 257 Interactive Connectivity Establishment (ICE [RFC5245]) is a technique 258 for NAT traversal for UDP-based (and TCP) media streams established 259 by the offer/answer model. The multiplicity of IP addresses, ports 260 and transport in SDP offers are tested for connectivity by peer-to- 261 peer connectivity checks. The result is candidate IP addresses and 262 ports for establishing a connection with the other peer. However, 263 ICE does not solve issues when incompatible configuration objects are 264 received on different interfaces. 266 Some application protocols do referrals of IP addresses, port numbers 267 and transport for further exchanges. For instance, applications can 268 provide reachability information to itself or to a third party. The 269 general problem of referrals is related to the multiple interface 270 problem, since, in this context, referrals must provide consistent 271 information depending on which provisioning domain is used. 272 Referrals are discussed in [I-D.carpenter-behave-referral-object] and 273 [I-D.ietf-shim6-app-refer]. 275 3.7. Interface and Provisioning domain selection 277 In a MIF context, the node may handle simultaneously multiple domains 278 with disparate characteristics, especially when supporting multiple 279 access technologies. Selection is simple if the application is 280 restricted to one specific provisioning domain: the application must 281 start on the default provisioning domain if available, otherwise the 282 application does not start. However, if the application can be run 283 on several provisioning domains, the selection problem is difficult. 285 For example, the interface selection mechanism defined in [TS23.234] 286 uses the following information: 288 o preferences provided by the user, 289 o policies provided by network operator, 290 o quality of the radio link, 291 o network resource considerations (e.g. available QoS, IP 292 connectivity check,...), 293 o the application QoS requirements in order to map applications to 294 the best interface 295 o and so on... 297 However, [TS23.234] is designed for a specific multiple-interfaces 298 use-case. A generic way to handle these characteristics is yet to be 299 defined. 301 3.8. Connection manager 303 Some implementations, specially in the mobile world, rely on higher- 304 level connection managers to deal with issues brought by multiple 305 provisioning domains. Typically, the connection manager manages the 306 interface and provisioning domain selection on behalf of 307 applications. As discussed previously in Section 3.7, the connection 308 manager has the same issues to making decisions in the general way in 309 front of multiple and diverse criteria. 311 Connection managers usually leverage the link-layer interface to 312 gather information and/or for control purpose. Such link-layer 313 interface may not provide all required services to make a proper 314 decision (e.g. interface selection). Some connection managers use 315 specific MIF socket API (Section 3.9) available in some vendor- 316 specific platforms. The connection manager generic architecture and 317 requirements are not currently standardized. Known connection 318 managers behaviors have been documented in 319 [I-D.ietf-mif-current-practices]. 321 3.9. Socket API 323 An Application Programming Interface (API) may expose objects that 324 user applications, or connection managers, use for dealing with 325 multiple interfaces. For example, [RFC3542] defines how an 326 application using the Advanced sockets API specifies the interface or 327 the source IP address, through a simple bind() operation or with the 328 IPV6_PKTINFO socket option. 330 Other APIs have been defined to solve similar issues to MIF.[RFC5014] 331 defines an API to influence the default address selection mechanism 332 by specifying attributes of the source addresses it prefers. 333 [I-D.ietf-shim6-multihome-shim-api] gives another example in a 334 multihoming context, by defining a socket API enabling interactions 335 between applications and the multihoming shim layer for advanced 336 locator management, and access to information about failure detection 337 and path exploration. 339 4. MIF Issues 341 This section describes the various issues when using a MIF node that 342 has already received configuration objects from its various 343 provisioning domains or when multiple interfaces are used and results 344 in addressing or naming space overlaps. They occur, for example, 345 when: 347 1. one interface is on the Internet and one is on a corporate 348 private network. The latter may be through VPN. 349 2. one interface is on one access network (i.e. wifi) and the other 350 one is on another access network (3G) with specific services. 352 4.1. DNS resolution issues 354 A MIF node (M1) has an active interface(I1) connected to a network 355 (N1) which has its DNS server (S1) and another active interface (I2) 356 connected to a network (N2) which has its DNS server (S2). S1 serves 357 with some private namespace "private.example.com". The user or the 358 application uses a name "a.private.example.com" which is within the 359 private namespace of S1 and only resolvable by S1. Any of the 360 following situations may occur: 362 1. M1 stack, based on its routing table, uses I2 to reach S1 to 363 resolve "a.private.example.com". M1 never reaches S1. The name 364 is not resolved. 366 2. M1 keeps only one set of DNS server addresses from the received 367 configuration objects and kept S2 address. M1 sends the forward 368 DNS query for a.private.example.com to S2. S2 responds with an 369 error for an non-existent domain (NXDOMAIN). The name is not 370 resolved. This issue also arises when performing reverse DNS 371 lookup. In the same situation, the reverse DNS query fails. 372 3. M1 keeps only one set of DNS server addresses from the received 373 configuration objects and kept S2 address. M1 sends the DNS 374 query for a.private.example.com to S2. S2 asks its upstream DNS 375 and gets an IP address for a.private.example.com. However, the 376 IP address is not the same one S1 would have given. Therefore, 377 the application tries to connect to the wrong destination node, 378 or to the wrong interface of the latter, which may imply security 379 issues or result in lack of service. 380 4. S1 or S2 has been used to resolve "a.private.example.com" to an 381 [RFC1918] address. Both N1 and N2 are [RFC1918] addressed 382 networks. Traffic may be sent using the wrong interface. This 383 issue is not related to receiving multiple configuration objects, 384 but to an address overlap between interfaces or attaching 385 networks. 386 5. M1 has resolved an FQDN to locally valid IP address when 387 connected to N1. If the node looses connection to N1, the node 388 may try to connect, via N2, to the same IP address as earlier, 389 but as the address was only locally valid, connection setup 390 fails. Similarly, M1 may have received NXDOMAIN for an FQDN when 391 connected to N1. After detachment from N1, the node should not 392 assume the FQDN continues to be nonexistent on N2. 393 6. M1 requests AAAA record from a DNS server on a network that uses 394 protocol translators and DNS64 [I-D.ietf-behave-dns64]. If the 395 M1 receives synthesized AAAA record, it is guaranteed to be valid 396 only on the network it was learned from. If the M1 uses 397 synthesized AAAA on any other network interface, traffic may be 398 lost, dropped or forwarded to the wrong network. 400 4.2. Routing 402 A MIF node (M1) has an active interface(I1) connected to a network 403 (N1) and another active interface (I2) connected to a network (N2). 404 The user or the application is trying to reach an IP address (IP1). 405 Any of the following situations may occur: 407 1. For IP1, M1 has one default route (R1) via network (N1). To 408 reach IP1, M1 stack uses R1 and sends through I1. If IP1 is only 409 reachable by N2, IP1 is never reached or is not the right target. 410 2. For the IP1 address family, M1 has one default route (R1, R2) per 411 network (N1, N2). IP1 is reachable by both networks, but N2 path 412 has better characteristics, such as better round-trip time, least 413 cost, better bandwidth, etc.... These preferences could be 414 defined by user, provisioned by the network operator, or else. 415 M1 stack uses R1 and tries to send through I1. IP1 is reached 416 but the service would be better by I2. 417 3. For the IP1 address family, M1 has a default route (R1), a 418 specific X.0.0.0/8 route R1B (eg. RFC1918 prefix) to N1 and a 419 default route (R2) to N2. IP1 is reachable by N2 only, but the 420 prefix (X.0.0.0/8) is used in both networks. Because of the most 421 specific route R1B, M1 stack sends through I2 and never reach the 422 target. 424 A MIF node may have multiple routes to a destination. However, by 425 default, it does not have any hint concerning which interface would 426 be the best to use for that destination. The first-hop selection may 427 leverage on local routing policy, allowing some actors (e.g. network 428 operator or service provider) to influence the routing table, i.e. 429 make decision regarding which interface to use. For instance, a user 430 on such multihomed node might want a local policy to influence which 431 interface will be used based on various conditions. Some SDOs have 432 defined policy-based selection mechanisms, for instance the Access 433 Network Discovery and Selection Function (ANDSF) [TS23.402] allows to 434 provide selection policies to terminals with both a 3GPP and non-3GPP 435 interfaces. However, as pointed out in Section 3.8, the selection 436 may be a tricky problem requiring sophisticated mechanisms (e.g. 437 connection manager), due to lot of criteria to consider. Moreover, 438 information required to make a decision may be not available. For 439 instance, interfaces to lower layer may not provide all required 440 hints to the selection (e.g. information on interface quality). 442 Another problem is that a node usually has a node-scoped routing 443 table. Therefore, when a MIF node is connected to multiple 444 provisioning domains, different actors may want to influence the 445 routing table of the node, then conflicts might arise from the 446 multiple routing information being pushed to the node. 448 On a MIF node, some source addresses are not valid if used on some 449 interfaces. For example, an RFC1918 source address might be 450 appropriate on the VPN interface but not on the public interface of 451 the MIF node. If the source address is not chosen appropriately, 452 then sent packets might be filtered in the path if source address 453 filtering is in place ([RFC2827],[RFC3704]) and reply packets might 454 never come back to the source. 456 4.3. Address Selection Policy 458 Even if not yet specified, the distribution of address selection 459 policy is sometimes evoked. If deployed, such a mechanism could 460 bring specific issue in a multiple provisioning domain context. Lets 461 consider a MIF node(M1) with an active interface(I1) connected to a 462 network (N1) and another active interface (I2) connected to a network 463 (N2). When the user or the application is trying to reach an IP 464 address (IP1), the following situations may occur: 465 M1 receives from both networks (N1 and N2) an update of its 466 default address selection policy. However, the policies are 467 specific to each network. The policies are merged by M1 stack. 468 Based on the merged policy, the chosen source address is from N1 469 but packets are sent to N2. The source address is not reachable 470 from N2, therefore the return packet is lost. 472 Merging address selection policies may have important impacts on 473 routing. 475 4.4. Single Interface on Multiple Provisioning Domains 477 When a node using a single interface is connected to multiple 478 networks, i.e. different default routers, similar issues as described 479 above happen. Even with a single interface, a node may wish to 480 connect to more than one configuration domain: that node may use more 481 than one IP source address and may have more than one default router. 482 The node may want to access services that can only be reached using 483 one of the provisioning domain, so it needs to use the right outgoing 484 source address and default gateway to reach that service. In this 485 situation, that node may also need to use different DNS servers to 486 get domain names in those different provisioning domains. 488 5. Underlying problems and causes 490 This section lists the underlying problems, and their causes, which 491 lead to the issues discussed in the previous section. The problems 492 can be divided into five categories: 1) Configuration 2) DNS 493 resolution 3) Routing 4) Address selection and 5) connection 494 management and API. They are shown as below: 496 1. Configuration. In a MIF context, configuration information 497 specific to a provisioning domain may be ignored because: 498 1. Configuration objects (e.g. DNS servers, NTP servers, ...) 499 are node-scoped. So the IP stack is not able to maintain the 500 mapping between information and corresponding provisioning 501 domain. 502 2. Same configuration objects (e.g. DNS server addresses, NTP 503 server addresses, ..) received from multiple provisioning 504 domains may be overwritten. 505 3. Host implementations usually do not keep separate network 506 configuration (such as DNS server addresses) per provisioning 507 domain. 509 2. DNS resolution 510 1. Some FQDN can be resolvable only by sending queries to the 511 right server (e.g. intranet services). However, DNS query 512 could be sent to the wrong interface because DNS server 513 addresses may be node-scoped. 514 2. A DNS answer can be valid only on a specific provisioning 515 domain but applications may be not aware of that mapping 516 because DNS answers may be not kept with the provisioning 517 from which the answer comes from. 518 3. Routing 519 1. In the MIF context, routing information could be specific to 520 each interface. This could lead to routing issue because, in 521 current node implementations, routing tables are node-scoped. 522 2. Interfaces and provisioning domains of a MIF node can provide 523 different characteristics (e.g. round-trip time, least cost, 524 better bandwidth, etc....). So, user, applications or 525 network provider may wish to influence routing (i.e. first- 526 hop router selection) to take benefit of this heterogeneity. 527 The first-hop selection could be based on policy taking into 528 account various criteria such as path characteristics and 529 application requirements. However, with current node 530 implementations, neither the Type-of-Service nor path 531 characteristics can be taken into account in the routing 532 table. Such a requirement, would thus lead the interface and 533 provisioning domain selection to leverage on dedicated 534 mechanisms (e.g. high-level function, such as connection 535 manager). However, selection may be tricky due to lot of 536 different situations and selection criteria: some 537 applications are domain-scoped, or may have a preferred 538 provisioning domain (e.g. according to available QoS); each 539 actor (user, operator, service provider, etc.) may also have 540 their preferred provisioning domains (e.g. single out lower 541 cost domain), possibly per type of application. 542 3. a node attached to multiple provisioning domain could be 543 provided with disparate selection policies. If the different 544 actors (e.g. user and network operator) are allowed to 545 provide their own policies, there is a risk for the node to 546 receive contradictory selection policies. It may lead the 547 node to make wrong selection. 548 4. The problem of first hop selection could not be solved via 549 configuration (Section 3.7), and may leverage on 550 sophisticated and specific mechanisms (Section 3.8). 551 4. Address selection 552 1. Default Address Selection policies may be specific to their 553 corresponding provisioning domain. However, a MIF node may 554 not be able to manage per-provisioning domain address 555 selection policies because default Address Selection policy 556 is node-scoped. 558 2. On a MIF node, some source addresses are not valid if used on 559 some interfaces or even on some default routers on the same 560 interface. In this situation, the source address should be 561 taken into account in the routing table; but current node 562 implementations do not support such a feature. 563 3. Source address or address selection policies could be 564 specified by applications. However, there is no advanced 565 APIs to allow applications realizing such operations. 566 5. Connection management and API 567 1. Some implementations, specially in the mobile world, have 568 higher-level API and/or connection manager to address MIF 569 issues. These mechanisms are not standardized and do not 570 necessarily behave the same way across different OS, and/or 571 platforms, in the presence of the MIF problems. This lack of 572 consistency is an issue for user and operator who could 573 experience different connection manager behaviors depending 574 on the terminal. 575 2. Connection managers usually leverage on interface to link 576 layer to gather information and/or for control purpose. 577 However, such link layer interface may not provide all 578 required services (e.g. may not provide all information 579 allowing to make a proper interface selection). 580 3. A MIF node can support different connection managers, which 581 may have contradictory ways to solve the MIF issues. For 582 instance, because of different selection algorithms, two 583 different connection managers could select different domains 584 in a same context. Or, when dealing with different domain 585 selection policies, a connection manager may give precedence 586 to user policy while another could favor mobile operator 587 policy. 589 6. Security Considerations 591 The problems discussed in this document have security implications, 592 such as when the packets sent on the wrong interface might be leaking 593 some confidential information. Configuration parameters from one 594 provisioning domain could cause a denial of service on another 595 provisioning domain (e.g. DNS issues). Moreover, the undetermined 596 behavior of IP stacks in the multihomed context bring additional 597 threats where an interface on a multihomed node might be used to 598 conduct attacks targeted to the networks connected by the other 599 interfaces.corrupted provisioning domain selection policy may induce 600 a node to make decisions causing certain traffic to be forwarded to 601 the attacker. 603 Additional security concerns are raised by possible future mechanisms 604 that provide additional information to the node so that it can make a 605 more intelligent decision with regards to the issues discussed in 606 this document. Such future mechanisms may themselves be vulnerable 607 and may not be easy to protect in the general case. 609 7. IANA Considerations 611 This document has no actions for IANA. 613 8. Authors 615 This document is a joint effort with authors of the MIF requirements 616 draft [I-D.yang-mif-req]. The authors of this document, in 617 alphabetical order, include: Marc Blanchet, Jacqni Qin, Pierrick 618 Seite, Carl Williams and Peny Yang. 620 9. Acknowledgements 622 The initial Internet-Drafts prior to the MIF working group and the 623 discussions during the MIF BOF meeting and on the mailing list around 624 the MIF charter scope on the mailing list brought very good input to 625 the problem statement. This draft steals a lot of text from these 626 discussions and initial drafts (e.g. [I-D.yang-mif-req], 627 [I-D.hui-ip-multiple-connections-ps], 628 [I-D.savolainen-mif-dns-server-selection]). Therefore, the editor 629 would like to acknowledge the following people (in no specific 630 order), from which some text has been taken from: Jari Arkko, Keith 631 Moore, Sam Hartman, George Tsirtsis, Scott Brim, Ted Lemon, Bernie 632 Volz, Giyeong Son, Gabriel Montenegro, Julien Laganier, Teemu 633 Savolainen, Christian Vogt, Lars Eggert, Margaret Wasserman, Hui 634 Deng, Ralph Droms, Ted Hardie, Christian Huitema, Remi Denis- 635 Courmont, Alexandru Petrescu, Zhen Cao. Sorry if some contributors 636 have not been named. 638 10. Informative References 640 [802.21] IEEE, "IEEE Standard for Local and Metropolitan Area 641 Networks - Part 21: Media Independent Handover Services, 642 IEEE LAN/MAN Std 802.21-2008, January 2009.", 2010. 644 [I-D.carpenter-behave-referral-object] 645 Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and 646 K. Moore, "A Generic Referral Object for Internet 647 Entities", draft-carpenter-behave-referral-object-01 (work 648 in progress), October 2009. 650 [I-D.hui-ip-multiple-connections-ps] 651 Hui, M. and H. Deng, "Problem Statement and Requirement of 652 Simple IP Multi-homing of the Host", 653 draft-hui-ip-multiple-connections-ps-02 (work in 654 progress), March 2009. 656 [I-D.ietf-6man-addr-select-sol] 657 Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution 658 approaches for address-selection problems", 659 draft-ietf-6man-addr-select-sol-03 (work in progress), 660 March 2010. 662 [I-D.ietf-behave-dns64] 663 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 664 "DNS64: DNS extensions for Network Address Translation 665 from IPv6 Clients to IPv4 Servers", 666 draft-ietf-behave-dns64-11 (work in progress), 667 October 2010. 669 [I-D.ietf-mif-current-practices] 670 Wasserman, M. and P. Seite, "Current Practices for 671 Multiple Interface Hosts", 672 draft-ietf-mif-current-practices-04 (work in progress), 673 October 2010. 675 [I-D.ietf-mptcp-architecture] 676 Ford, A., Raiciu, C., Handley, M., and J. Iyengar, 677 "Architectural Guidelines for Multipath TCP Development", 678 draft-ietf-mptcp-architecture-02 (work in progress), 679 October 2010. 681 [I-D.ietf-shim6-app-refer] 682 Nordmark, E., "Shim6 Application Referral Issues", 683 draft-ietf-shim6-app-refer-00 (work in progress), 684 July 2005. 686 [I-D.ietf-shim6-multihome-shim-api] 687 Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, 688 "Socket Application Program Interface (API) for 689 Multihoming Shim", draft-ietf-shim6-multihome-shim-api-14 690 (work in progress), August 2010. 692 [I-D.savolainen-mif-dns-server-selection] 693 Savolainen, T. and J. Kato, "Improved DNS Server Selection 694 for Multi-Homed Nodes", 695 draft-savolainen-mif-dns-server-selection-04 (work in 696 progress), September 2010. 698 [I-D.yang-mif-req] 699 Yang, P., Seite, P., Williams, C., and J. Qin, 700 "Requirements on multiple Interface (MIF) of simple IP", 701 draft-yang-mif-req-00 (work in progress), March 2009. 703 [RFC1122] Braden, R., "Requirements for Internet Hosts - 704 Communication Layers", STD 3, RFC 1122, October 1989. 706 [RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing 707 Domains: A model for routing in the Internet", RFC 1136, 708 December 1989. 710 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 711 RFC 1661, July 1994. 713 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 714 E. Lear, "Address Allocation for Private Internets", 715 BCP 5, RFC 1918, February 1996. 717 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 718 RFC 2131, March 1997. 720 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 721 Defeating Denial of Service Attacks which employ IP Source 722 Address Spoofing", BCP 38, RFC 2827, May 2000. 724 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 725 and M. Carney, "Dynamic Host Configuration Protocol for 726 IPv6 (DHCPv6)", RFC 3315, July 2003. 728 [RFC3484] Draves, R., "Default Address Selection for Internet 729 Protocol version 6 (IPv6)", RFC 3484, February 2003. 731 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 732 "Advanced Sockets Application Program Interface (API) for 733 IPv6", RFC 3542, May 2003. 735 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 736 Networks", BCP 84, RFC 3704, March 2004. 738 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 739 April 2006. 741 [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host 742 Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack 743 Issues", RFC 4477, May 2006. 745 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 746 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 747 September 2007. 749 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 750 RFC 4960, September 2007. 752 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 753 Socket API for Source Address Selection", RFC 5014, 754 September 2007. 756 [RFC5113] Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network 757 Discovery and Selection Problem", RFC 5113, January 2008. 759 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 760 Host Mobility and Multihoming with the Host Identity 761 Protocol", RFC 5206, April 2008. 763 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 764 "Problem Statement for Default Address Selection in Multi- 765 Prefix Environments: Operational Issues of RFC 3484 766 Default Rules", RFC 5220, July 2008. 768 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 769 "Requirements for Address Selection Mechanisms", RFC 5221, 770 July 2008. 772 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 773 (ICE): A Protocol for Network Address Translator (NAT) 774 Traversal for Offer/Answer Protocols", RFC 5245, 775 April 2010. 777 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 778 Shim Protocol for IPv6", RFC 5533, June 2009. 780 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 781 and K. Nagami, "Multiple Care-of Addresses Registration", 782 RFC 5648, October 2009. 784 [TS23.234] 785 3GPP, "3GPP system to Wireless Local Area Network (WLAN) 786 interworking; TS 23.234", 2009. 788 [TS23.402] 789 3GPP, "Architecture enhancements for non- 3GPP accesses; 790 TS 23.402", 2010. 792 Authors' Addresses 794 Marc Blanchet 795 Viagenie 796 2875 boul. Laurier, suite D2-630 797 Quebec, QC G1V 2M2 798 Canada 800 Email: Marc.Blanchet@viagenie.ca 801 URI: http://viagenie.ca 803 Pierrick Seite 804 France Telecom - Orange 805 4, rue du Clos Courtel, BP 91226 806 Cesson-Sevigne 35512 807 France 809 Email: pierrick.seite@orange-ftgroup.com