idnits 2.17.1 draft-anipko-mif-mpvd-arch-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 91 has weird spacing: '...uration and/o...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 22, 2013) is 3863 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'REF ANDSF' is mentioned on line 440, but not defined == Unused Reference: 'I-D.ietf-6man-addr-select-opt' is defined on line 580, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-6man-addr-select-opt-10 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIF Working Group D. Anipko 3 Internet-Draft Microsoft Corporation 4 Intended status: Informational September 22, 2013 5 Expires: March 24, 2014 7 Multiple Provisioning Domain Architecture 8 draft-anipko-mif-mpvd-arch-03 10 Abstract 12 This document is a product of the work of MIF architecture design 13 team. It outlines a solution framework for some of the issues, 14 experienced by nodes that can be attached to multiple networks. The 15 framework defines the notion of a Provisioning Domain (PVD) - a 16 consistent set of network configuration information, and PVD-aware 17 nodes - nodes which learn PVDs from the attached network(s) and/or 18 other sources and manage and use multiple PVDs for connectivity 19 separately and consistently. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 24, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Definitions and types of PVDs . . . . . . . . . . . . . . . . 3 57 2.1. Explicit PVDs . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Implicit PVDs and incremental adoption of the explicit PVDs 5 59 2.3. Relationship between PVDs and interfaces . . . . . . . . . 5 60 2.4. PVD identity/naming . . . . . . . . . . . . . . . . . . . 5 61 2.5. Relationship to dual-stack networks . . . . . . . . . . . 6 62 2.6. Elements of PVD . . . . . . . . . . . . . . . . . . . . . 7 63 3. Example network configurations and number of PVDs . . . . . . 7 64 4. Reference model of PVD-aware node . . . . . . . . . . . . . . 7 65 4.1. Constructions and maintenance of separate PVDs . . . . . . 7 66 4.2. Consistent use of PVDs for network connections . . . . . . 7 67 4.2.1. Name resolution . . . . . . . . . . . . . . . . . . . 7 68 4.2.2. Next-hop and source address selection . . . . . . . . 8 69 4.3. Connectivity tests . . . . . . . . . . . . . . . . . . . . 9 70 4.4. Relationship to interface management and connection manager 9 71 5. PVD support in APIs . . . . . . . . . . . . . . . . . . . . . 9 72 5.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 10 74 5.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6. PVD-aware nodes trust to PVDs . . . . . . . . . . . . . . . . 10 76 6.1. Untrusted PVDs . . . . . . . . . . . . . . . . . . . . . . 10 77 6.2. Trusted PVDs . . . . . . . . . . . . . . . . . . . . . . . 11 78 6.2.1. Authenticated PVDs . . . . . . . . . . . . . . . . . . 11 79 6.2.2. PVDs trusted by attachment . . . . . . . . . . . . . . 11 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 10.2. Informative References . . . . . . . . . . . . . . . . . 12 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 1. Introduction 90 Nodes attached to multiple networks may encounter problems due to 91 conflict of the networks configuration and/or simultaneous use of 92 the multiple available networks. While existing implementations 93 apply various techniques ([RFC6419]) to tackle such problems, in many 94 cases the issues may still appear. The MIF problem statement 95 document [RFC6418] describes the general landscape as well as 96 discusses many specific issues and scenarios details, and are not 97 listed in this document. 99 Across the layers, problems enumerated in [RFC6418] can be grouped 100 into 3 categories: 102 1. Lack of consistent and distinctive management of configuration 103 elements, associated with different networks. 105 2. Inappropriate mixed use of configuration elements, associated 106 with different networks, in the course of a particular network 107 activity / connection. 109 3. Use of a particular network, not consistent with the intent of 110 the scenario / involved parties, leading to connectivity failure 111 and / or other undesired consequences. 113 As an illustration: an example of (1) is a single node-scoped list of 114 DNS server IP addresses, learned from different networks, leading to 115 failures or delays in resolution of name from particular namespaces; 116 an example of (2) is use of an attempt to resolve a name of a HTTP 117 proxy server, learned from a network A, with a DNS server, learned 118 from a network B, likely to fail; an example of (3) is a use of 119 employer-sponsored VPN connection for peer-to-peer connections, 120 unrelated to employment activities. 122 This architecture describes a solution to these categories of 123 problems, respectively, by: 125 1. Introducing a formal notion of the PVD, including PVD identity, 126 and ways for nodes to learn the intended associations among 127 acquired network configuration information elements. 129 2. Introducing a reference model for a PVD-aware node, preventing 130 inadvertent mixed use of the configuration information, which may 131 belong to different PVDs. 133 3. Providing recommendations on PVD selection based on PVD identity 134 and connectivity tests for common scenarios. 136 1.1. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 2. Definitions and types of PVDs 144 Provisioning Domain: a consistent set of network configuration 145 information. Classically, the entire set available on a single 146 interface is provided by a single source, such as network 147 administrator, and can therefore be treated as a single provisioning 148 domain. In modern IPv6 networks, multihoming can result in more than 149 one provisioning domain being present on a single link. In some 150 scenarios, it is also possible for elements of the same domain to be 151 present on multiple links. 153 Typical examples of information in a provisioning domain, learned 154 from the network, are: source address prefixes, to be used by 155 connections within the provisioning domain, IP address of DNS server, 156 name of HTTP proxy server if available, DNS suffixes associated with 157 the network etc. 159 PVD-aware node: a node that supports association of network 160 configuration information into PVDs, and using the resultant PVDs to 161 serve requests for network connections in ways, consistent with 162 recommendations of this architecture. 164 2.1. Explicit PVDs 166 A node may receive explicit information from the network and/or other 167 sources, about presence of PVDs and association of particular network 168 information with a particular PVD. PVDs, constructed based on such 169 information, are referred to in this document as "explicit". 171 Protocol changes/extensions will likely be required to support the 172 explicit PVDs by IETF-defined mechanisms. As an example, one could 173 think of one or several DHCP options, carrying PVD identity and / or 174 its elements. A different approach could be to introduce a DHCP 175 option, which only carries identity of a PVD, while the association 176 of network information elements with that identity, is implemented by 177 the respective protocols - such as e.g., with a Router Discovery 178 [RFC4861] option associating an address range with a PVD. 180 Specific, existing or new, features of networking protocols to enable 181 delivery of PVD identity and association with various network 182 information elements will be defined in companion design documents. 184 Link-specific and/or vendor-proprietary mechanisms for discovery of 185 PVD information, different from the IETF-defined mechanisms, can be 186 used by the nodes separately from or together with IETF-defined 187 mechanisms, as long as they allow to discover necessary elements of 188 the PVD(s). In all cases, by default nodes must ensure that the 189 lifetime of all dynamically discovered PVD configuration is 190 appropriately limited by the relevant events - for example, if an 191 interface media state change was indicated, the previously discovered 192 information may no longer be valid and needs to be re-discovered or 193 confirmed. 195 It shall be possible for networks to communicate that some of their 196 configuration elements could be used within a context of other 197 networks/PVDs. Based on such declaration and their policies, PVD- 198 aware nodes may choose to inject such elements into some or all other 199 PVDs they connect to. 201 In some network topologies, the network infrastructure elements may 202 need to advertise multiple PVDs. The details of how this is done 203 generally will be defined in the individual companion design 204 documents. However, where different design choices are possible, the 205 choice that requires smaller number of packets shall be preferred for 206 efficiency. 208 2.2. Implicit PVDs and incremental adoption of the explicit PVDs 210 It is likely that for a long time there may be networks which do not 211 advertise explicit PVD information, since deployment of any new 212 features in networking protocols is a relatively slow process. 214 When connected to networks, which don't advertise explicit PVD 215 information, PVD-aware shall automatically create separate PVDs for 216 configuration received on multiple interfaces. Such PVDs are 217 referred to in this document as "implicit". 219 With implicit PVDs,PVD-aware nodes may still provide benefits to 220 their users, compared to non-PVD aware nodes, by using network 221 information from different interfaces separately and consistently to 222 serve network connection requests, following best practices described 223 in Section 4. 225 In the mixed mode, where e.g., multiple networks are available on the 226 link the interface is attached to, and only some of the networks 227 advertise PVD information, the PVD-aware node shall create explicit 228 PVDs based on explicitly learned PVD information, and associate the 229 rest of the configuration with an implicit PVD created for that 230 interface. 232 2.3. Relationship between PVDs and interfaces 234 Implicit PVDs are limited to network configuration information 235 received on a single interface. Explicit PVDs, in practice will 236 often also be scoped to a configuration related to a particular 237 interface, however per this architecture there is no such requirement 238 or limitation and as defined in this architecture, explicit PVDs may 239 include information related to more than one interfaces, if the node 240 learns presence of the same PVD on those interfaces and the 241 authentication of the PVD ID meets the level required by the node 242 policy. 244 It is an intent of this architecture to support such scenarios among 245 others. Hence, it shall be noted that no hierarchical relationship 246 exists between interfaces and PVDs: it is possible for multiple PVDs 247 to be simultaneously accessible over one interface, as well as single 248 PVD to be simultaneously accessible over multiple interfaces. 250 2.4. PVD identity/naming 252 For explicit PVDs, PVD ID (globally unique ID, that possibly is 253 human-readable) is received as part of that information. For 254 implicit PVDs, the node assigns a locally generated globally unique 255 ID to each implicit PVD. 257 PVD-aware node may use these IDs to choose a PVD with matching ID for 258 special-purpose connection requests, in accordance with node policy 259 or choice by advanced applications, and/or to present human-readable 260 IDs to the end-user for selection of Internet-connected PVDs. 262 A single network provider may operate multiple networks, including 263 networks at different locations. In such cases, the provider may 264 chose whether to advertise single or multiple PVD identities at all 265 or some of those networks, as it suits their business needs. This 266 architecture doesn't impose specific requirements in this regard. 268 When multiple nodes are connected to the same link, where one or more 269 explicit PVDs are available, this architecture assumes that the 270 information about all available PVDs is advertized by the networks to 271 all the connected nodes. At the same time, the connected nodes may 272 have different heuristics, policies and/or other settings, including 273 configured set of their trusted PVDs, which may lead to different 274 PVDs actually being used by different nodes for their connections. 276 Possible extensions, where different sets of PVDs may be advertised 277 by the networks to different connected nodes, are out of scope for 278 this document. 280 2.5. Relationship to dual-stack networks 282 When applied to dual-stack networks, the PVD definition allows for 283 multiple PVDs to be created, where each PVD contain information for 284 only one address family, or for a single PVD that contains 285 information about multiple address families. This architecture 286 requires that accompanying design documents for accompanying protocol 287 changes must support PVDs containing information from multiple 288 address families. PVD-aware nodes must be capable of dealing with 289 both single-family and multi-family PVDs. 291 For explicit PVDs, the choice of either of the approaches is a policy 292 decision of a network administrator and/or node user/administrator. 293 Since some of the IP configuration information that can be learned 294 from the network can be applicable to multiple address families (for 295 instance DHCP address selection option [I-D.ietf-6man-addr-select- 296 opt]), it is likely that dual-stack networks will deploy single PVDs 297 for both address families. 299 For implicit PVDs, by default PVD-aware nodes shall including 300 multiple IP families into single implicit PVD created for an 301 interface. At the time of writing of this document in dual-stack 302 networks it appears to be a common practice for configuration of both 303 address families to be provided by a single source. 305 A PVD-aware node that provides API to use / enumerate / inspect PVDs 306 and/or their properties shall provide ability to filter PVDs and/or 307 their properties by address family. 309 2.6. Elements of PVD 311 3. Example network configurations and number of PVDs 313 4. Reference model of PVD-aware node 315 4.1. Constructions and maintenance of separate PVDs 317 It is assumed that normally, configuration information contained in a 318 single PVD, shall be sufficient for a node to fulfill a network 319 connection request by an application, and hence there should be no 320 need to attempt to merge information across different PVDs. 322 Nevertheless, even when a PVD lack some parts of the configuration, 323 merging of information from different PVD(s) shall not be done 324 automatically, since typically it would lead to issues described in 325 [RFC6418]. 327 A node may use other sources, such as e.g., node local policy, user 328 input or other mechanisms, not defined by IETF, to either construct a 329 PVD entirely (analogously to static IP configuration of an 330 interface), or supplement with particular elements all or some PVDs 331 learned from the network, or potentially merge information from 332 different PVDs, if such merge is known to the node to be safe, based 333 on explicit policies. 335 As an example, node administrator could inject a not ISP-specific DNS 336 server into PVDs for any of the networks the node could become 337 attached to. Such creation / augmentation of PVD(s) could be static 338 or dynamic. The particular implementation mechanisms are outside of 339 the scope of this document. 341 4.2. Consistent use of PVDs for network connections 343 PVDs enable PVD-aware nodes to use consistently a correct set of 344 configuration elements to serve the specific network requests from 345 beginning to end. This section describes specific examples of such 346 consistent use. 348 4.2.1. Name resolution 349 When PVD-aware node needs to resolve a name of the destination used 350 by a connection request, the node could decide to use one, or 351 multiple PVDs for a given name lookup. 353 The node shall chose one PVD, if e.g., the node policy required to 354 use a particular PVD for a particular purpose (e.g. to download an 355 MMS using a specific APN over a cellular connection). To make the 356 choice, the node could use a match of the PVD DNS suffix or other 357 form of PVD ID, as determined by the node policy. 359 The node may pick multiple PVDs, if e.g., they are general purpose 360 PVDs providing connectivity to the Internet, and the node desires to 361 maximize chances for connectivity in Happy Eyeballs style. In this 362 case, the node could do the lookups in parallel, or in sequence. 363 Alternatively, the node may use for the lookup only one PVD, based on 364 the PVD connectivity properties, user choice of the preferred 365 Internet PVD, etc. 367 In either case, by default the node uses information obtained in a 368 name service lookup to establish connections only within the same PVD 369 from which the lookup results were obtained. 371 For simplicity, when we say that name service lookup results were 372 obtained from a PVD, what we mean is that the name service query was 373 issued against a name service the configuration of which is present 374 in a particular PVD. In that sense, the results are "from" that 375 particular PVD. 377 Some nodes may support transports and/or APIs, which provide an 378 abstraction of a single connection, aggregating multiple underlying 379 connections. MPTCP [RFC6182] is an example of such transport 380 protocol. For the connections provided by such transports/APIs, a 381 PVD-aware node may use different PVDs for servicing of that logical 382 connection, provided that all operations on the underlying 383 connections are done consistently within their corresponding PVD(s). 385 4.2.2. Next-hop and source address selection 387 For the purpose of this discussion, let's assume the preceding name 388 lookup succeeded in a particular PVD. For each obtained destination 389 address, the node shall perform a next-hop lookup among routers, 390 associated with that PVD. As an example, such association could be 391 determined by the node via matching the source address prefixes/ 392 specific routes advertized by the router against known PVDs, or 393 receiving explicit PVD affiliation advertized through a new Router 394 Discovery [RFC4861] option. 396 For each destination, once the best next-hop is found, the node 397 selects best source address according to the [RFC6724] rules, but 398 with a constraint that the source address must belong to a range 399 associated with the used PVD. If needed, the node would use the 400 prefix policy from the same PVD for the best source address selection 401 among multiple candidates. 403 When destination/source pairs are identified, then they are sorted 404 using the [RFC6724] destination sorting rules and the prefix policy 405 table from the used PVD. 407 4.3. Connectivity tests 409 Although some PVDs may appear as valid candidates for PVD selection 410 (e.g. good link quality, consistent connection parameters, etc.), 411 they may provide limited or no connectivity to the desired network or 412 the Internet. For example, some PVDs provide limited IP connectivity 413 (e.g., scoped to the link or to the access network), but require the 414 node to authenticate through a web portal to get full access to the 415 Internet. This may be more likely to happen for PVDs, which are not 416 trusted by the given PVD-aware node. 418 An attempt to use such PVD may lead to limited network connectivity 419 or connection failures for applications. To prevent the latter, a 420 PVD-aware node may perform connectivity test for the PVD, before 421 using it to serve network connection requests of the applications. 422 In current implementations, some nodes do that, for instance, by 423 trying to reach a dedicated web server (e.g., see [RFC6419]). 425 Per Section 4.2, a PVD-aware node shall maintain and use multiple 426 PVDs separately. The PVD-aware node shall perform connectivity test 427 and, only after validation of the PVD, consider using it to serve 428 application connections requests. Ongoing connectivity tests are 429 also required, since during the IP session, the end-to-end 430 connectivity could be disrupted for various reasons (e.g. poor L2, 431 IP QoS issues); hence a connectivity monitoring function is needed to 432 check the connectivity status and remove the PVD from the set of 433 usable PVDs if necessary. 435 There may be cases where a connectivity test for PVD selection may be 436 not appropriate and should be complemented, or replaced, by PVD 437 selection based on other factors. This could be realized e.g., by 438 leveraging some 3GPP and IEEE mechanisms, which would allow to expose 439 some PVD characteristics to the node (e.g. 3GPP Access Network 440 Discovery and Selection Function (ANDSF) [REF ANDSF], IEEE 802.11u/ 441 ANQP [REF 802.11u]). 443 4.4. Relationship to interface management and connection managers 445 5. PVD support in APIs 447 In all cases changes in available PVDs must be somehow exposed, 448 appropriately for each of the approaches. 450 5.1. Basic 451 Applications are not PVD-aware in any manner, and only submit 452 connection requests. The node performs PVD selection implicitly, 453 without any otherwise applications participation, and based purely on 454 node-specific administrative policies and/or choices made by the user 455 in a user interface provided by the operating environment, not by the 456 application. 458 As an example, such PVD selection can be done at the name service 459 lookup step, by using the relevant configuration elements, such as 460 e.g., those described in [RFC6731]. As another example, the PVD 461 selection could be done based on application identity or type (i.e., 462 a node could always use a particular PVD for a VOIP application). 464 5.2. Intermediate 466 Applications indirectly participate in selection of PVD by specifying 467 hard requirements and soft preferences. The node performs PVD 468 selection, based on applications inputs and policies and/or user 469 preferences. Some / all properties of the resultant PVD may be 470 exposed to applications. 472 5.3. Advanced 474 PVDs are directly exposed to applications, for enumeration and 475 selection. Node polices and/or user choices, may still override the 476 application preferences and limit which PVD(s) can be enumerated and/ 477 or used by the application, irrespectively of any preferences which 478 application may have specified. Depending on the implementation, 479 such restrictions, imposed per node policy and/or user choice, may or 480 may not be visible to the application. 482 6. PVD-aware nodes trust to PVDs 484 6.1. Untrusted PVDs 486 Implicit and explicit PVDs for which no trust relationship exists are 487 considered untrusted. Only PVDs, which meet the requirements in 488 Section 6.2, are trusted; any other PVD is untrusted. 490 In order to avoid various forms of misinformation that can be 491 asserted when PVDs are untrusted, nodes that implement PVD separation 492 cannot assume that two explicit PVDs with the same identifier are 493 actually the same PVD. A node that did make this assumption would be 494 vulnerable to attacks where for example an open Wifi hotspot might 495 assert that it was part of another PVD, and thereby might draw 496 traffic intended for that PVD onto its own network. 498 Since implicit PVD identifiers are synthesized by the node, this 499 issue cannot arise with implicit PVDs. 501 Mechanisms exist (for example, [RFC6731]) whereby a PVD can provide 502 configuration information that asserts special knowledge about the 503 reachability of resources through that PVD. Such assertions cannot 504 be validated unless the node has a trust relationship with the PVD; 505 assertions of this type therefore must be ignored by nodes that 506 receive them from untrusted PVDs. Failure to ignore such assertions 507 could result in traffic being diverted from legitimate destinations 508 to spoofed destinations. 510 6.2. Trusted PVDs 512 Trusted PVDs are PVDs for which two conditions apply. First, a 513 trust relationship must exist between the node that is using the PVD 514 configuration and the source that provided that configuration; this 515 is the authorization portion of the trust relationship. Second, 516 there must be some way to validate the trust relationship. This is 517 the authentication portion of the trust relationship. Two 518 mechanisms for validating the trust relationship are defined. 520 It shall be possible to validate the trust relationship for all 521 advertised elements of a trusted PVD, irrespectively of whether the 522 PVD elements are communicated as a whole, e.g. in a single DHCP 523 option, or separately, e.g. in supplementary RA options. Whether or 524 not this is feasible to provide mechanisms to implement trust 525 relationship for all PVD elements, will be determined in the 526 respective companion design documents. 528 6.2.1. Authenticated PVDs 530 One way to validate the trust relationship between a node and the 531 source of a PVD is through the combination of cryptographic 532 authentication and an identifier configured on the node. In some 533 cases, the two could be the same; for example, if authentication is 534 done with a shared secret, the secret would have to be associated 535 with the PVD identifier. Without a (PVD Identifier, shared key) 536 tuple, authentication would be impossible, and hence authentication 537 and authorization are combined. 539 However, if authentication is done using some public key mechanism 540 such as a TLS cert or DANE, authentication by itself isn't enough, 541 since theoretically any PVD could be authenticated in this way. In 542 addition to authentication, the node would need to be configured to 543 trust the identifier being authenticated. Validating the 544 authenticated PVD name against a list of PVD names configured as 545 trusted on the node would constitute the authorization step in this 546 case. 548 6.2.2. PVDs trusted by attachment 549 In some cases a trust relationship may be validated by some means 550 other than described in Section 6.2.1, simply by virtue of the 551 connection through which the PVD was obtained. For instance, a 552 handset connected to a mobile network may know through the mobile 553 network infrastructure that it is connected to a trusted PVD, and 554 whatever mechanism was used to validate that connection constitutes 555 the authentication portion of the PVD trust relationship. 556 Presumably such a handset would be configured from the factory, or 557 else through mobile operator or user preference settings, to trust 558 the PVD, and this would constitute the authorization portion of this 559 type of trust relationship. 561 7. Acknowledgements 563 8. IANA Considerations 565 This memo includes no request to IANA. 567 9. Security Considerations 569 All drafts are required to have a security considerations section. 571 10. References 573 10.1. Normative References 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, March 1997. 578 10.2. Informative References 580 [I-D.ietf-6man-addr-select-opt] 581 Matsumoto, A., Fujisaki, T. and T. Chown, "Distributing 582 Address Selection Policy using DHCPv6", Internet-Draft 583 draft-ietf-6man-addr-select-opt-10, April 2013. 585 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 586 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 587 September 2007. 589 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S. and J. 590 Iyengar, "Architectural Guidelines for Multipath TCP 591 Development", RFC 6182, March 2011. 593 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 594 Provisioning Domains Problem Statement", RFC 6418, 595 November 2011. 597 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 598 Multiple-Interface Hosts", RFC 6419, November 2011. 600 [RFC6724] Thaler, D., Draves, R., Matsumoto, A. and T. Chown, 601 "Default Address Selection for Internet Protocol Version 6 602 (IPv6)", RFC 6724, September 2012. 604 [RFC6731] Savolainen, T., Kato, J. and T. Lemon, "Improved Recursive 605 DNS Server Selection for Multi-Interfaced Nodes", RFC 606 6731, December 2012. 608 Author's Address 610 Dmitry Anipko 611 Microsoft Corporation 612 One Microsoft Way 613 Redmond, WA 98052 614 USA 616 Phone: +1 425 703 7070 617 Email: dmitry.anipko@microsoft.com