idnits 2.17.00 (12 Aug 2021) /tmp/idnits8036/draft-anipko-mif-mpvd-arch-00.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 (July 2013) is 3231 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-6man-addr-select-opt has been published as RFC 7078 Summary: 0 errors (**), 0 flaws (~~), 4 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 July 2013 5 Expires: December 31, 2013 7 Multiple Provisioning Domain Architecture 8 draft-anipko-mif-mpvd-arch-00 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 December 31, 2013. 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 and implicit PVDs . . . . . . . . . . . . . . . . 4 58 2.2. Relationship between PVDs and interfaces . . . . . . . . . 5 59 2.3. PVD identity/naming . . . . . . . . . . . . . . . . . . . 5 60 2.4. Relationship to dual-stack networks . . . . . . . . . . . 5 61 2.5. Elements of PVD . . . . . . . . . . . . . . . . . . . . . 6 62 3. Example network configurations and number of PVDs . . . . . . 6 63 4. Reference model of PVD-aware node . . . . . . . . . . . . . . 6 64 4.1. Constructions and maintenance of separate PVDs . . . . . . 6 65 4.2. Consistent use of PVDs for network connections . . . . . . 6 66 4.2.1. Name resolution . . . . . . . . . . . . . . . . . . . 6 67 4.2.2. Next-hop and source address selection . . . . . . . . 6 68 4.3. Connectivity tests . . . . . . . . . . . . . . . . . . . . 7 69 4.4. Relationship to interface management and connection manager 7 70 5. PVD support in APIs . . . . . . . . . . . . . . . . . . . . . 7 71 5.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 7 73 5.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 6. PVD-aware nodes trust to PVDs . . . . . . . . . . . . . . . . 7 75 6.1. Untrusted PVDs . . . . . . . . . . . . . . . . . . . . . . 7 76 6.2. Authenticated PVDs . . . . . . . . . . . . . . . . . . . . 8 77 6.3. Trusted PVDs . . . . . . . . . . . . . . . . . . . . . . . 8 78 6.3.1. Trust via strong ID . . . . . . . . . . . . . . . . . 8 79 6.3.2. Trust via attachment . . . . . . . . . . . . . . . . . 8 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 85 10.2. Informative References . . . . . . . . . . . . . . . . . 8 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 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 (RFC 6419 [RFC6419]) to tackle such 94 problems, in many cases the issues may still appear. The MIF problem 95 statement document RFC 6418 [RFC6418] describes the general landscape 96 as well as discusses many specific issues details. 98 Across the layers, problems enumerated in RFC 6418 [RFC6418] can be 99 grouped into 3 categories: 101 1. Lack of consistent and distinctive management of configuration 102 elements, associated with different networks. 104 2. Inappropriate mixed use of configuration elements, associated 105 with different networks, in the course of a particular network 106 activity / connection. 108 3. Use of a particular network, not consistent with the intent of 109 the scenario / involved parties, leading to connectivity failure 110 and / or other undesired consequences. 112 As an illustration: an example of (1) is a single node-scoped list of 113 DNS server IP addresses, learned from different networks, leading to 114 failures or delays in resolution of name from particular namespaces; 115 an example of (2) is use of an attempt to resolve a name of a HTTP 116 proxy server, learned from a network A, with a DNS server, learned 117 from a network B, likely to fail; an example of (3) is a use of 118 employer-sponsored VPN connection for peer-to-peer connections, 119 unrelated to employment activities. 121 This architecture describes a solution to these categories of 122 problems, respectively, by: 124 1. Introducing a formal notion of the PVD, including PVD identity, 125 and ways for nodes to learn the intended associations among 126 acquired network configuration information elements. 128 2. Introducing a reference model for a PVD-aware node, preventing 129 inadvertent mixed use of the configuration information, which may 130 belong to different PVDs. 132 3. Providing recommendations on PVD selection based on PVD identity 133 and connectivity tests for common scenarios. 135 1.1. Requirements Language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 2. Definitions and types of PVDs 143 Provisioning Domain: a consistent set of network configuration 144 information. Usually, the entire set available on a single interface 145 is provided by a single source, such as network administrator. 146 Typical examples of such information, learned from the network, are: 147 source address prefixes, used by the network, IP address of DNS 148 server, name of HTTP proxy server if available, DNS suffixes 149 associated with the network etc. 151 It is also possible for other sources, such as e.g. node local 152 policy, user input or other out of band mechanisms to either 153 construct a PVD entirely (analogously to static IP configuration of 154 an interface), or supplement with particular elements all or some 155 PVDs learned from the network. As an example, node administrator 156 could inject a not ISP-specific DNS server into PVDs for any of the 157 networks the node could become attached to. Such creation / 158 augmentation of PVD could be static or dynamic. The particular 159 implementation mechanisms are outside of the scope of this document. 161 PVD-aware node: a node that supports association of network 162 configuration information into PVDs, and using the resultant PVDs to 163 serve requests for network connections in a way, consistent with 164 recommendations of this architecture. 166 2.1. Explicit and implicit PVDs 168 A node may receive explicit information from the network and/or other 169 sources, about presence of PVDs and association of particular network 170 information with a particular PVD. PVDs, constructed based on such 171 information, are referred to in this document as "explicit". 173 Protocol changes/extensions will likely be required to support the 174 explicit PVDs. As an example, one could think of one or several DHCP 175 options, defining a PVD identity and elements. A different approach 176 could be to introduce a DHCP option, which only introduces identity 177 of a PVD, while the association of network information elements with 178 that identity, is implemented by the respective protocols - such as 179 e.g., with a Router Discovery [RFC4861] option declaring association 180 of an address range with a particular PVD. 182 Specific, existing or new, features of networking protocols to enable 183 delivery of PVD identity and association with various network 184 information elements will be defined in companion design documents. 186 It is likely that for a long time there may be networks which do not 187 advertise any explicit PVD information, since deployment of any new 188 features in networking protocols is a relatively slow process. When 189 connected to such networks, PVD-aware nodes may still provide 190 benefits to their users, compared to non-PVD aware nodes, by creating 191 separate PVDs for configuration received on different interfaces. 192 Such PVDs are referred to in this document as "implicit". This 193 allows the node to manage and use network information from different 194 interfaces separately and consistently use the configuration to serve 195 network connection requests. 197 In the mixed mode, where e.g. multiple networks are available on the 198 link the interface is attached to, and only some of the networks 199 advertize PVD information, the PVD-aware node shall create explicit 200 PVDs based on explicitly learned PVD information, and associate the 201 rest of the configuration with an implicit PVD created for that 202 interface. 204 It shall be possible for networks to communicate that some of their 205 configuration elements could be used within a context of other 206 networks/PVDs. Based on such declaration and their policies, PVD- 207 aware nodes may choose to inject such elements into some or all other 208 PVDs they connect to. 210 2.2. Relationship between PVDs and interfaces 212 Implicit PVDs are limited to network configuration information 213 received on a single interface. Explicit PVDs, in practice will 214 often also be scoped to a configuration related to a particular 215 interface, however per this architecture there is no such requirement 216 or limitation and as defined in this architecture, explicit PVDs may 217 include information related to more than one interfaces, if the node 218 learns presence of the same PVD on those interfaces and the 219 authentication of the PVD ID meets the level required by the node 220 policy. 222 2.3. PVD identity/naming 224 For explicit PVDs, PVD ID (globally unique ID, that possibly is 225 human-readable) is received as part of that information. For 226 implicit PVDs, the node assigns a locally generated globally unique 227 ID to each implicit PVD. 229 PVD-aware node may use these IDs to choose a PVD with matching ID for 230 special-purpose connection requests, in accordance with node policy 231 or choice by advanced applications, and/or to present human-readable 232 IDs to the end-user for selection of Internet-connected PVDs. 234 2.4. Relationship to dual-stack networks 236 When applied to dual-stack networks, the PVD definition allows for 237 multiple PVDs to be created, where each PVD contain information for 238 only one address family, or for a single PVD that contains 239 information about multiple address families. This architecture 240 requires that accompanying design documents for accompanying protocol 241 changes must support PVDs containing information from multiple 242 address families. PVD-aware nodes must be capable of dealing with 243 both single-family and multi-family PVDs. 245 Nevertheless, for explicit PVDs, the choice of either of the 246 approaches is a policy decision of a network administrator and/or 247 node user/administrator. Since some of the IP configuration 248 information that can be learned from the network can be applicable to 249 multiple address families (for instance DHCP address selection option 250 [I-D.ietf-6man-addr-select-opt]), it is likely that dual-stack 251 networks will deploy single PVDs for both address families. 253 For implicit PVDs, by default PVD-aware nodes shall including 254 multiple IP families into single implicit PVD created for an 255 interface. 257 A PVD-aware node that provides API to use / enumerate / inspect PVDs 258 and/or their properties shall provide ability to filter PVDs and/or 259 their properties by address family. 261 2.5. Elements of PVD 263 3. Example network configurations and number of PVDs 265 4. Reference model of PVD-aware node 267 4.1. Constructions and maintenance of separate PVDs 269 4.2. Consistent use of PVDs for network connections 271 PVDs enable PVD-aware nodes to use consistently a correct set of 272 configuration elements to serve the specific network requests from 273 beginning to end. This section describes specific examples of such 274 consistent use. 276 4.2.1. Name resolution 278 When PVD-aware node needs to resolve a name of the destination used 279 by a connection request, the node could decide to use one, or 280 multiple PVDs for a given name lookup. 282 The node shall chose one PVD, if e.g., the node policy required to 283 use a particular PVD for a particular purpose (e.g. to download an 284 MMS using a specific APN over a cellular connection). To make the 285 choice, the node could use a match of the PVD DNS suffix or other 286 form of PVD ID, as determined by the node policy. 288 The node may pick multiple PVDs, if e.g., they are general purpose 289 PVDs providing connectivity to the Internet, and the node desires to 290 maximize chances for connectivity in Happy Eyeballs style. In this 291 case, the node could do the lookups in parallel, or in sequence. 292 Alternatively, the node may use for the lookup only one PVD, based on 293 the PVD connectivity properties, user choice of the preferred 294 Internet PVD, etc. 296 In either case, by default the node shall use for the following 297 connection request the PVD, where the lookup results were obtained. 299 4.2.2. Next-hop and source address selection 300 For the purpose of this discussion, let's assume the preceding name 301 lookup succeeded in a particular PVD. For each obtained destination 302 address, the node shall perform a next-hop lookup among routers, 303 associated with that PVD. As an example, such association could be 304 determined by the node via matching the source address prefixes/ 305 specific routes advertized by the router against known PVDs, or 306 receiving explicit PVD affiliation advertized through a new Router 307 Discovery [RFC4861] option. 309 For each destination, once the best next-hop is found, the node 310 selects best source address according to the RFC 6724 [RFC6724] 311 rules, but with a constraint that the source address must belong to a 312 range associated with the used PVD. If needed, the node would use the 313 prefix policy from the same PVD for the best source address selection 314 among multiple candidates. 316 When destination/source pairs are identified, then they are sorted 317 using the RFC 6724 [RFC6724] destination sorting rules and the prefix 318 policy table from the used PVD. 320 4.3. Connectivity tests 322 4.4. Relationship to interface management and connection managers 324 5. PVD support in APIs 326 In all cases changes in available PVDs must be somehow exposed, 327 appropriately for each of the approaches. 329 5.1. Basic 331 Applications are not PVD-aware in any manner, and only submit 332 connection requests. The node performs PVD selection implicitly, 333 without any otherwise applications participation, and based purely on 334 policies and/or user choice. 336 5.2. Intermediate 338 Applications indirectly participate in selection of PVD by specifying 339 hard requirements and soft preferences. The node performs PVD 340 selection, based on applications inputs and policies and/or user 341 preferences. Some / all properties of the resultant PVD may be 342 exposed to applications. 344 5.3. Advanced 346 PVDs are directly exposed to applications, for enumeration and 347 selection, within limits allowed by the node policies and / or user 348 preferences. 350 6. PVD-aware nodes trust to PVDs 352 6.1. Untrusted PVDs 353 6.2. Authenticated PVDs 355 6.3. Trusted PVDs 357 6.3.1. Trust via strong ID 359 6.3.2. Trust via attachment 361 7. Acknowledgements 363 8. IANA Considerations 365 This memo includes no request to IANA. 367 9. Security Considerations 369 All drafts are required to have a security considerations section. 371 10. References 373 10.1. Normative References 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, March 1997. 378 10.2. Informative References 380 [I-D.ietf-6man-addr-select-opt] 381 Matsumoto, A., Fujisaki, T. and T. Chown, "Distributing 382 Address Selection Policy using DHCPv6", Internet-Draft 383 draft-ietf-6man-addr-select-opt-10, April 2013. 385 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 386 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 387 September 2007. 389 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 390 Provisioning Domains Problem Statement", RFC 6418, 391 November 2011. 393 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 394 Multiple-Interface Hosts", RFC 6419, November 2011. 396 [RFC6724] Thaler, D., Draves, R., Matsumoto, A. and T. Chown, 397 "Default Address Selection for Internet Protocol Version 6 398 (IPv6)", RFC 6724, September 2012. 400 Author's Address 401 Dmitry Anipko 402 Microsoft Corporation 403 One Microsoft Way 404 Redmond, WA 98052 405 USA 407 Phone: +1 425 703 7070 408 Email: dmitry.anipko@microsoft.com