idnits 2.17.1 draft-ietf-mif-happy-eyeballs-extension-11.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 (November 13, 2016) is 2720 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Chen 3 Internet-Draft China Mobile 4 Intended status: Informational C. Williams 5 Expires: May 17, 2017 Consultant 6 D. Wing 7 A. Yourtchenko 8 Cisco Systems, Inc. 9 November 13, 2016 11 Happy Eyeballs Extension for Multiple Interfaces 12 draft-ietf-mif-happy-eyeballs-extension-11 14 Abstract 16 This memo proposes extensions to the Happy Eyeball's algorithm 17 requirements defined in RFC6555 for use with the multiple 18 provisioning domain architecture. The Happy Eyeballs in MIF would 19 make the selection process smoother by using connectivity tests over 20 pre-filtered interfaces according to defined policy. This would 21 choose the best interface with an automatic fallback mechanism. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 17, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. WiFi is broken . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Policy Conflict . . . . . . . . . . . . . . . . . . . . . 4 62 4. Happiness Parameters . . . . . . . . . . . . . . . . . . . . 4 63 4.1. Hard Set . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1.1. Operator Policy . . . . . . . . . . . . . . . . . . . 5 65 4.1.2. User Preference . . . . . . . . . . . . . . . . . . . 5 66 4.2. Soft Set . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.2.1. Provisioning Domain Identity . . . . . . . . . . . . 6 68 4.2.2. DNS Selection . . . . . . . . . . . . . . . . . . . . 6 69 4.2.3. Next Hop . . . . . . . . . . . . . . . . . . . . . . 6 70 4.2.4. Source Address Selection . . . . . . . . . . . . . . 6 71 4.2.5. Common Practice . . . . . . . . . . . . . . . . . . . 6 72 5. HE-MIF Process Requirements . . . . . . . . . . . . . . . . . 7 73 5.1. First Step, Filter . . . . . . . . . . . . . . . . . . . 7 74 5.2. Second Step, Sort . . . . . . . . . . . . . . . . . . . . 8 75 5.2.1. Interface Validation . . . . . . . . . . . . . . . . 8 76 5.2.2. Name Resolution . . . . . . . . . . . . . . . . . . . 8 77 5.2.3. Connection Establishment . . . . . . . . . . . . . . 8 78 6. Implementation Framework . . . . . . . . . . . . . . . . . . 9 79 7. Additional Considerations . . . . . . . . . . . . . . . . . . 9 80 7.1. Usage Scope . . . . . . . . . . . . . . . . . . . . . . . 9 81 7.2. Fallback Timeout . . . . . . . . . . . . . . . . . . . . 9 82 7.3. DNS Selections . . . . . . . . . . . . . . . . . . . . . 10 83 7.4. Flow Continuity . . . . . . . . . . . . . . . . . . . . . 11 84 7.5. Interworking with Happy Eyeball . . . . . . . . . . . . . 11 85 7.6. Multipath Applicability . . . . . . . . . . . . . . . . . 11 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 91 11.2. Informative References . . . . . . . . . . . . . . . . . 13 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 94 1. Introduction 96 The MIF problem statement [RFC6418] describes problems specific for 97 nodes attached to multiple provisioning domains. Specifically, there 98 is a issue description that a node has selected an interface and 99 obtained a valid IP address from the network, but Internet 100 connectivity is not available. This memo intends to address the 101 issue and elaborate more in Section 3.1. 103 [RFC7556] describes the multiple provisioning domain architecture. 104 It refers to using connectivity tests to validate a Provisioning 105 Domain (PvD). Given a number of implicit/explicit PvDs, plus 106 preferences/policy, what is the process to follow to select the best 107 PvD to use for any given connection. In the event that two or more 108 are deemed to be best, how are the Happy Eyeballs (HE) techniques 109 applied to find the best and deal with resilience. This memo also 110 proposes process requirements using Happy Eyeballs (HE) extensions. 112 There are a variety of algorithms that can be envisioned. This 113 document describes additional parameters and processes that need to 114 be considered in addition to the HE algorithm requirements defined in 115 [RFC6555] necessary to support multiple interfaces, so that a node 116 with multiple interfaces can select the best path for a particular 117 connection-oriented flow (e.g., TCP, SCTP). 119 2. Terminology 121 This document makes use of following terms: 123 o Happy Eyeballs (HE): specifies requirements for an algorithm that 124 reduces the user-visible connection delay for dual-stack hosts 125 with a single interface per-protocol. 127 o Happy Eyeballs - Multi-Interface (HE-MIF): Extends the Happy 128 Eyeballs concept to the multiple provisioning domain architecture. 129 It describes additional requirements for algorithms that offer 130 connectivity tests on PVD-aware or non-PVD-aware nodes [RFC7556] 131 to select the best interface for a specific connection request. 133 3. Use Cases 135 The section describes scenarios the HE-MIF targeted to use. 137 3.1. WiFi is broken 139 Assuming a MIF node has both a 3GPP mobile network interface and a 140 WiFi interface, a common practice would be to always prefer the WiFi 141 connection when the node enters an area with WiFi available. In this 142 situation, a node might assume that because a valid IP address has 143 been allocated, the WiFi link provides connectivity to destinations 144 through the Internet. However, this might not be the case for 145 several reasons: 147 o WiFi access-point authentication requirements 149 o WiFi has no global Internet connectivity 151 o Instability at layer 2 153 In order to resolve this problem, the user would need to disable the 154 device's interface preferences, e.g. by disabling the WiFi interface. 155 HE-MIF offers users the possibility of configuring their preferences 156 for the choice of the most suitable network interface to use, such as 157 via setting on their mobile phone. 159 In this case, users may prefer to wait an appropriate time period for 160 connections to be established over a WiFi path. If no connection can 161 be made it will fall back to attempting the connection over a 3GPP 162 mobile network path. 164 3.2. Policy Conflict 166 A node has network access via both WiFi and 3GPP networks. In a 167 mobile network, IPv6-only may be preferable since IPv6 has the 168 potential to be simpler than dual-stack. The WiFi access offers IPv4 169 only. In this scenario, the combination of source address selection 170 [RFC6724] and preferring the WiFi interface may cause a problem. The 171 transition to IPv6 may mean that IPv6 is the preferred protocol, so 172 the 3GPP interface should be chosen even though it could be 173 considered a suboptimal selection e.g. the WiFi interface likely is 174 less expensive. 176 4. Happiness Parameters 178 This section provides input parameter proposal that HE-MIF should 179 catch. Two sets of "Happiness" parameters have been defined. It 180 serves applications and initiates HE-MIF connection tests 181 subsequently. By following the process described below, MIF nodes 182 can select an appropriate interface that best meets the configuration 183 parameters defined by the user. The two sets of "Happiness" 184 parameters are called Hard Set and Soft Set respectively. 186 4.1. Hard Set 188 Hard set contains parameters which should be complied with. It helps 189 to select candidate interfaces through which a particular flow should 190 be directed. These should be seen as constraints on the choice, such 191 as provider policies, support for IPv4 or IPv6, and other parameters 192 which would prevent a particular interface and transport from being 193 used by a particular flow. Parameters in the hard set should be easy 194 to use and understand. When several parameters in the hard set are 195 in conflict, the user's preference should be prioritized. 197 4.1.1. Operator Policy 199 Operators may deliver the customized policies for a particular 200 network environment because of geo-location or service regulation 201 considerations. One example relevant for 3GPP networks is an 202 operator delivering policies from an Access Network Discovery and 203 Selection function (ANDSF) [TS23.402]. 205 The ANDSF provides a node with policies and network selection 206 information to influence the selection between different access 207 technologies, such as 3GPP mobile networks, WiFi access. The ANDSF 208 can provide the node with three types of information[TS24.302]. 210 o Access network discovery and selection information: it includes a 211 list of access networks available in the vicinity of the node. 212 The information may include the access technology types (e.g. 213 WiFi), network identifiers (e.g. SSID in the case of WiFi) as 214 well as validity conditions (e.g. where and when). 216 o Inter-System Mobility Policies (ISMPs): they are a set of 217 operator-defined rules and preferences that affect the inter- 218 system mobility decisions, e.g. decisions about whether to use 219 3GPP mobile network or a WiFi network. 221 o Inter-System Routing Policies (ISRPs): the node uses ISRPs when it 222 can route IP traffic simultaneously over multiple radio access 223 networks. It could provide routing policies in an IP flow 224 granularity. 226 4.1.2. User Preference 228 User's preference: users may express preferences which likely not 229 have a formally technical language , like "No 3/4G while roaming", 230 "Only download applications larger than 20Mb over WiFi", etc. Those 231 information are normally input from User Interface (UI). 233 4.2. Soft Set 235 Soft set contains factors which impact the selection of the path 236 across which a particular flow should be transmitted among the 237 available interfaces and transports which meet the hard set 238 requirements described above. 240 4.2.1. Provisioning Domain Identity 242 A PVD-aware node uses PvD Identity(PvD-ID) to select a PvD with a 243 matching ID for special-purpose connection requests. The PvD-ID may 244 be generated by the node implicitly or received from the network 245 explicitly. for explicit PvDs, the node could take the parameter from 246 PvD ID Option [I-D.ietf-mif-mpvd-id] via the configuration protocols 247 ([I-D.ietf-mif-mpvd-dhcp-support] or 248 [I-D.ietf-mif-mpvd-ndp-support]). A PVD-aware node may decide to use 249 one preferred PVD or allow the use of multiple PVDs simultaneously 250 for applications. The node behavior should be consistent with MPVD 251 architecture [RFC7556]. 253 4.2.2. DNS Selection 255 At the name service lookup step, the node has to choose a recursive 256 DNS server to use. A HE-MIF node should take the parameter of RDNSS 257 Selection DHCP Option [RFC6731] to select an interface for a 258 particular namespace. 260 4.2.3. Next Hop 262 [RFC4191] allows the configuration of specific routes to a 263 destination. A HE-MIF node should take the parameters of router 264 preference and route information to identify the next hop. 266 4.2.4. Source Address Selection 268 For each destination, once the best next hop is found, the node 269 should consider IP prefix and precedence parameter in policy table to 270 select the best source address according to the rule defined in 271 [RFC6724]. 273 4.2.5. Common Practice 275 There is relevant common practice related to interface selection, 276 e.g. Prefer WiFi over a 3GPP interface, if available. Such 277 conventions should also be considered. 279 5. HE-MIF Process Requirements 281 An HE-MIF node may use the two sets of parameters as two steps in the 282 interface selection process. The first step is to use the Hard Set 283 to synthesize policies from different actors (e.g., users or network 284 operators). These hard set parameters will provide a filter which 285 will exclude not qualifying interfaces from any further 286 consideration. 288 The second step is to influence how a node makes a connection when 289 multiple interfaces still remain in the candidate list after first 290 step. This is essentially sorting behavior. In the multiple 291 provisioning domain architecture, a PVD aware node makes connectivity 292 tests as described in Section 5.3 of [RFC7556]. A PVD agnostic node 293 take other parameters apart from PVD-ID in the Soft Set to proceed 294 the sort process. 296 The two steps are described in more details in the following sub- 297 sections. It should be noted that HE-MIF does not prescribe such 298 two-step model. It will be very specific to particular cases and 299 implementations. The two step model mainly describes requirements 300 for how to use the hard/soft set. 302 5.1. First Step, Filter 304 One goal of the filter is to reconcile multiple selection policies 305 from users or operators. Afterwards, merged demands would be mapped 306 to a set of candidate interfaces, which are judged as qualified. 308 Decision on the reconciliation of different policies will depend very 309 much on the deployment scenario. An implementation may not be able 310 to determine priority for each policies without explicit 311 configuration provided by users or administrator. For example, an 312 implementation may by default always prefer the WiFi because of cost 313 saving consideration. Whereas, other users may turn off a device's 314 WiFi interface to guarantee use of a 3GPP network interface to assure 315 higher reliability or security. 317 The decision on mergence of policies may be made by implementations, 318 or by node administrators. However, it's worth to note that a demand 319 from users should be normally considered higher priority than from 320 other actors. 322 The merged policies serve as a filter which is iterated across the 323 list of available interfaces. Qualified interfaces are selected and 324 the proceed to the second step. 326 5.2. Second Step, Sort 328 5.2.1. Interface Validation 330 The Sort process aims to select the best interface and provide 331 fallback capacities. As stated in [RFC7556], a PVD-aware node shall 332 perform connectivity tests and, only after validation of the PVD, 333 consider using it to serve application connections requests. In 334 current implementations, some nodes already implement this, e.g., by 335 trying to reach a dedicated web server (see Section 3.1.2 [RFC6419] 336 ). If anything is abnormal, it assumes there is a proxy on the path. 337 This status detection is recommended to be used in HE-MIF to detect 338 DNS interception or an HTTP proxy that forces a login or a click- 339 through. Unexamined PVDs or interfaces should be accounted as 340 "unconnected". It should not join the sort process. 342 5.2.2. Name Resolution 344 Name resolution is executed on the validated interfaces. Before the 345 requests are initiated, it should check if there is a matching PVD ID 346 for the destination name. A PVD agnostic node may request DNS server 347 selection DHCP option [RFC6731] for interface selection guidance. 348 Those information may weight a particular interface to be preferred 349 to others sending resolving requests. If the node can't find useful 350 information in the Soft Set, DNS queries would be sent out on 351 multiple interfaces in parallel to maximize chances for connectivity. 352 Some additional discussions of DNS selection consideration of HE-MIF 353 are described in Section 7.3. 355 5.2.3. Connection Establishment 357 Once a destination address was resolved, a connection is to be setup. 358 For the given destination address, a PVD-aware node selects a next- 359 hop and source address associated with that PVD in the name 360 resolution process. A PVD agnostic node may receive certain next hop 361 in a RA message [RFC4191], the node selects best source address 362 according to the rules [RFC6724]. 364 The interface identified by the source address should be treated to 365 initiate the connection prior to others. This could avoid thrashing 366 the network, by not making simultaneous connection attempts on 367 multiple interfaces. After making a connection attempt on the 368 preferred pairs and failing to establish a connection within a 369 certain time period (see Section 7.2), a HE-MIF implementation will 370 decide to initiate connection attempt using rest of interfaces in 371 parallel. This fallback consideration will make subsequent 372 connection attempts successful on non-preferable interfaces. 374 The node would cache information regarding the outcome of each 375 connection attempt. Cache entries would be flushed periodically. A 376 system-defined timeout may take place to age the state. Maximum on 377 the order of 10 minutes defined in [RFC6555] is recommended to keep 378 the interface state changes synchronizing with IP family states. 380 If there is no specific Soft Set provided, all selected interfaces 381 should be treated equally. for a node implementing multipath 382 transports (for example, Multipath TCP (MPTCP) [RFC6182]), the 383 interfaces could be treated as valid to perform subsequent multipath 384 process, such as starting subflow. A node only supporting single 385 physical transport would initiate on several interface 386 simultaneously. The goal here is to provide the most fast connection 387 for users, by quickly attempting to connect using each candidate 388 interface. Afterwards, the node would do the same caching and 389 flushing process as described above. 391 6. Implementation Framework 393 The simplest way to implement the processes described in this 394 document is within the application itself. This would not require 395 any specific support from the operating system beyond the commonly 396 available APIs that provide transport service. It could also be 397 implemented using a high-level API approach, linking to the MIF-API 398 [I-D.ietf-mif-api-extension]. 400 7. Additional Considerations 402 7.1. Usage Scope 404 Connection-oriented transports (e.g., TCP, SCTP) are directly applied 405 as scoped in [RFC6555]. For connectionless transport protocols 406 (e.g., UDP), a similar mechanism can be used if the application has 407 request/response semantics. Further investigations are out of the 408 document scope. 410 7.2. Fallback Timeout 412 When the preferred interface was failed, HE-MIF would trigger a 413 fallback process to start connection initiation on several candidate 414 interfaces. A period of time should be set to invalidate the 415 interface and fallback to others. Aggressive timeouts may achieve 416 quick interface handover, but at the cost of traffic that may be 417 chargeable on certain networks, e.g. the handover from WiFi to 3GPP 418 networks brings a charge to customers. Considering the reasons, it 419 is recommended to prioritize the input from users (e.g., real 420 customers or applications) through user interface. For default- 421 setting on a system, a hard error [RFC1122] in replied ICMP could 422 serve as a trigger for the fallback process. When the ICMP soft 423 error is present or non-response was received, it's recommended that 424 the timeout should be large enough to allow connection 425 retransmission. [RFC1122] states that such timer must be at least 3 426 minutes to provide TCP retransmission. However, several minutes 427 delay may not inappropriate for user experiences. A widespread 428 practice [RFC5461] sets 75 seconds to optimize connection process. 430 More optimal timer may be expected. The particular setting will be 431 very specific to implementations and cases. The memo didn't try to 432 provide a concrete value because of following concerns. 434 o RTT (Round-Trip Time) on different interfaces may vary quite a 435 lot. A particular value of timeout may not accurately help to 436 make a decision that this interface doesn't work at all. On the 437 contrary, it may cause a misjudgment on a interface, which is not 438 very fast. In order to compensate the issues, the timeout setting 439 based on past experiences of a particular interface may help to 440 make a fair decision. Whereas, it's going beyond the capability 441 of Happy Eyeballs [RFC6555]. Therefore, it leaves a particular 442 implementation. 444 o In some cases, fast interface may not be treated as "best". For 445 example, a interface could be evaluated in the principle of 446 bandwidth-delay, termed "Bandwidth-Delay-Product ". Happy 447 Eyeballs measures only connection speed. That is, how quickly a 448 TCP connection is established . It does not measure bandwidth. If 449 the fallback has to take various factors into account and make 450 balanced decision, it's better to resort to a specific context and 451 implementation. 453 7.3. DNS Selections 455 During the Sort process, HE-MIF prioritizes PVD-ID match or [RFC6731] 456 inputs to select a proper server. It could help to address following 457 two cases. 459 o A DNS answer may be only valid for a specific provisioning domain, 460 but the DNS resolver may not be aware of that because the DNS 461 reply is not kept with the provisioning from which the answer 462 comes. The situation may become worse if asking internal name 463 with public address response or asking public name with private 464 address answers. 466 o Some FQDNs can be resolvable only by sending queries to the right 467 server (e.g., intranet services). Otherwise, a response with 468 NXDOMAIN is replied. Fast response is treated as optimal only if 469 the record is valid. That may cause messy for data connections, 470 since NXDOMAIN doesn't provide useful information. 472 HE-MIF can help to solve the issues of DNS interception with captive 473 portal. The DNS server modified and replied the answer with the IP 474 address of captive portal rather than the intended destination 475 address. In those cases, TCP connection may succeed, but Internet 476 connectivity is not available. It results in lack of service unless 477 user has authenticated. HE-MIF recommended using network 478 connectivity status probes to examine a pre-configured URL for 479 detecting DNS interception on the path (see more in Section 5.2). 480 The node will be able to automatically rely upon other interfaces to 481 select right DNS servers by excluding the unexamined interfaces. 483 7.4. Flow Continuity 485 [I-D.deng-mif-api-session-continuity-guide] describes session 486 continuity guidance for application developers. The flow continuity 487 topic is beyond this document scope. 489 7.5. Interworking with Happy Eyeball 491 HE-MIF process could cooperate with HE [RFC6555]. HE is executed on 492 an interface which is selected to make connection establishment (see 493 Section 5.2.3). for example, a node following PvD policy to pick a 494 interface and make both IPv4/IPv6 connection attempts in consistent 495 with HE requirements. The interface state management in HE-MIF is 496 designed to synchronize with IP family states. It could facilitate 497 the HE executions. 499 7.6. Multipath Applicability 501 Some nodes may support transports that provide an abstraction of a 502 single connection, aggregating multiple underlying connections. 503 Multipath TCP (MPTCP) [RFC6182] is an example of such a transport 504 protocol. For connections provided by such transports, a node may 505 leverage the "happiness" parameters and process on the underlying 506 connections. Following the HE-MIF requirements, each connection 507 could be performed consistently with user/operator's preference and 508 corresponding provisioning domain information. 510 8. IANA Considerations 512 This memo does not include any IANA requests. 514 9. Security Considerations 516 The security consideration is following the statement in [RFC6555] 517 and [RFC6418]. 519 10. Acknowledgements 521 The authors would like to thank Margaret Wasserman, Hui Deng, Erik 522 Kline, Stuart Cheshire, Teemu Savolainen, Jonne Soininen, Simon 523 Perreault, Zhen Cao, Dmitry Anipko, Ted Lemon, Daniel Migault, Russ 524 White and Bing Liu for their helpful comments. 526 Many thanks to Ralph Droms, Ian Farrer, Jouni Korhonen, Mirja 527 Khlewind and Suresh Krishnan for their detailed reviews. 529 11. References 531 11.1. Normative References 533 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 534 Communication Layers", STD 3, RFC 1122, 535 DOI 10.17487/RFC1122, October 1989, 536 . 538 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 539 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 540 November 2005, . 542 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 543 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 544 2012, . 546 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 547 "Default Address Selection for Internet Protocol Version 6 548 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 549 . 551 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 552 Recursive DNS Server Selection for Multi-Interfaced 553 Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, 554 . 556 [TS23.402] 557 3rd Generation Partnership Project, 3GPP., "Architecture 558 enhancements for non-3GPP accesses v8.8.0", December 2009. 560 [TS24.302] 561 3rd Generation Partnership Project, 3GPP., "Access to the 562 3GPP Evolved Packet Core (EPC) via non-3GPP access 563 networks v14.0.0", June 2016. 565 11.2. Informative References 567 [I-D.deng-mif-api-session-continuity-guide] 568 Deng, H., Krishnan, S., Lemon, T., and M. Wasserman, 569 "Guide for application developers on session continuity by 570 using MIF API", draft-deng-mif-api-session-continuity- 571 guide-04 (work in progress), July 2014. 573 [I-D.ietf-mif-api-extension] 574 Liu, D., Lemon, T., Ismailov, Y., and Z. Cao, "MIF API 575 consideration", draft-ietf-mif-api-extension-05 (work in 576 progress), February 2014. 578 [I-D.ietf-mif-mpvd-dhcp-support] 579 Krishnan, S., Korhonen, J., and S. Bhandari, "Support for 580 multiple provisioning domains in DHCPv6", draft-ietf-mif- 581 mpvd-dhcp-support-02 (work in progress), October 2015. 583 [I-D.ietf-mif-mpvd-id] 584 Krishnan, S., Korhonen, J., Bhandari, S., and S. 585 Gundavelli, "Identification of provisioning domains", 586 draft-ietf-mif-mpvd-id-02 (work in progress), October 587 2015. 589 [I-D.ietf-mif-mpvd-ndp-support] 590 Korhonen, J., Krishnan, S., and S. Gundavelli, "Support 591 for multiple provisioning domains in IPv6 Neighbor 592 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-03 593 (work in progress), February 2016. 595 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 596 DOI 10.17487/RFC5461, February 2009, 597 . 599 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 600 Iyengar, "Architectural Guidelines for Multipath TCP 601 Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, 602 . 604 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 605 Provisioning Domains Problem Statement", RFC 6418, 606 DOI 10.17487/RFC6418, November 2011, 607 . 609 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 610 Multiple-Interface Hosts", RFC 6419, DOI 10.17487/RFC6419, 611 November 2011, . 613 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 614 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 615 . 617 Authors' Addresses 619 Gang Chen 620 China Mobile 621 29, Jinrong Avenue 622 Xicheng District, 623 Beijing 100033 624 China 626 Email: phdgang@gmail.com, chengang@chinamobile.com 628 Carl Williams 629 Consultant 630 El Camino Real 631 Palo Alto, CA 94306 632 USA 634 Email: carlw@mcsr-labs.org 636 Dan Wing 637 Cisco Systems, Inc. 638 170 West Tasman Drive 639 San Jose, CA 95134 640 USA 642 Email: dwing@cisco.com 644 Andrew Yourtchenko 645 Cisco Systems, Inc. 646 De Kleetlaan, 7 647 Diegem B-1831 648 Belgium 650 Email: ayourtch@cisco.com