idnits 2.17.1 draft-kline-mif-mpvd-api-reqs-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [RFC7556], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 01, 2015) is 3100 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 15 -- Looks like a reference, but probably isn't: '2' on line 16 -- Looks like a reference, but probably isn't: '3' on line 16 -- Looks like a reference, but probably isn't: '4' on line 92 -- Looks like a reference, but probably isn't: '5' on line 93 -- Looks like a reference, but probably isn't: '6' on line 93 -- Looks like a reference, but probably isn't: '7' on line 108 -- Looks like a reference, but probably isn't: '8' on line 134 -- Looks like a reference, but probably isn't: '9' on line 159 -- Looks like a reference, but probably isn't: '10' on line 181 -- Looks like a reference, but probably isn't: '11' on line 193 -- Looks like a reference, but probably isn't: '12' on line 204 -- Looks like a reference, but probably isn't: '13' on line 212 -- Looks like a reference, but probably isn't: '14' on line 239 -- Looks like a reference, but probably isn't: '15' on line 243 -- Looks like a reference, but probably isn't: '16' on line 259 -- Looks like a reference, but probably isn't: '17' on line 314 -- Looks like a reference, but probably isn't: '18' on line 386 -- Looks like a reference, but probably isn't: '19' on line 387 -- Looks like a reference, but probably isn't: '20' on line 488 -- Looks like a reference, but probably isn't: '21' on line 544 -- Looks like a reference, but probably isn't: '22' on line 544 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 23 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Kline 3 Internet-Draft Google Japan KK 4 Intended status: Informational November 01, 2015 5 Expires: May 04, 2016 7 Multiple Provisioning Domains API Requirements 8 draft-kline-mif-mpvd-api-reqs-00 10 Abstract 12 RFC 7556 [RFC7556] provides the essential conceptual guidance an API 13 designer would need to support use of PvDs. This document aims to 14 capture the requirements for an API that can be used by applications 15 that would be considered "advanced", according to section 6.3 [1] of 16 RFC 7556 [RFC7556]. The "basic" [2] and "intermediate" [3] API 17 support levels can in principle be implemented by means of layers 18 wrapping the advanced API. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 04, 2016. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. High level requirements . . . . . . . . . . . . . . . . . . . 3 57 2.1. Requirements for an API . . . . . . . . . . . . . . . . . 3 58 2.2. Requirements for supporting operating systems . . . . . . 5 59 2.2.1. Source address selection . . . . . . . . . . . . . . 5 60 2.2.2. Route isolation . . . . . . . . . . . . . . . . . . . 6 61 2.2.3. Automatic PvD metadata marking . . . . . . . . . . . 6 62 2.2.4. Additional system and library support . . . . . . . . 7 63 3. Conceptual PvDs . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.1. The 'default' PvD . . . . . . . . . . . . . . . . . . . . 7 65 3.2. The 'unspecified' PvD . . . . . . . . . . . . . . . . . . 8 66 3.3. The 'null' PvD . . . . . . . . . . . . . . . . . . . . . 8 67 3.4. The 'loopback' PvD . . . . . . . . . . . . . . . . . . . 8 68 4. Requirements for new API functionality . . . . . . . . . . . 9 69 4.1. Learning PvD availability . . . . . . . . . . . . . . . . 9 70 4.2. Learning network configuration information comprising a 71 PvD . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.3. Scoping functionality to a specific PvD . . . . . . . . . 10 73 4.4. Explicit versus Implicit PvDs . . . . . . . . . . . . . . 10 74 4.5. Policy restrictions . . . . . . . . . . . . . . . . . . . 11 75 4.6. Programmatic reference implementation considerations . . 11 76 5. Existing networking APIs . . . . . . . . . . . . . . . . . . 12 77 5.1. Updating existing APIs . . . . . . . . . . . . . . . . . 12 78 5.2. Requirements for name resolution APIs . . . . . . . . . . 12 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 84 9.2. Informative References . . . . . . . . . . . . . . . . . 14 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 RFC 7556 [RFC7556] provides the essential conceptual guidance an API 90 designer would need to support use of PvDs. This document aims to 91 capture the requirements for an API that can be used by applications 92 that would be considered "advanced", according to section 6.3 [4] of 93 RFC 7556 [RFC7556]. The "basic" [5] and "intermediate" [6] API 94 support levels can in principle be implemented by means of layers 95 wrapping the advanced API. 97 This document also attempts to make some of the API implementation 98 requirements more concrete by discussion and example. 100 1.1. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 2. High level requirements 108 As described in section 2 [7] of RFC 7556 [RFC7556], a Provisioning 109 Domain ("PvD") is fundamentally a "consistent set of network 110 configuration information." This includes information like: 112 o the list of participating interfaces 114 o IPv4 and IPv6 addresses 116 o IPv4 and IPv6 routes: both default routes and more specifics (such 117 as may be learned via RFC 4191 [RFC4191] Route Information Options 118 ("RIOs")) 120 o DNS nameservers, search path, et cetera 122 o HTTP proxy configuration 124 and undoubtedly many more configuration elements yet to be specified 125 (like metering hints, transmission medium and speed, captive portal 126 URL, et cetera). 128 This configuration information as a whole may not be able to be 129 learned atomically, may need to be synthesized from multiple sources 130 including administrative provisioning, and cannot be presumed to be 131 unchanging over the lifetime of a node's association with a given 132 PvD. 134 In order for an application to make consistent use [8] of a given 135 PvD's network configuration several requirements are placed upon the 136 API itself and the host operating system providing the API. 138 2.1. Requirements for an API 140 At the highest level, the requirements for an API that enables 141 applications to make sophisticated use of multiple PvDs amount to 142 providing mechanisms by which they can: 144 R1 observe accessible PvDs 145 It MUST be possible for an application to be informed of the set 146 of all PvDs it can currently access, and to be informed of 147 changes to this set. 149 R2 observe configuration elements of an accessible PvD 151 It MUST be possible to learn requested configuration information 152 of any accessible PvD, and to be informed of any changes to the 153 configuration information comprising an accessible PvD. 155 R3 scope networking functionality to a specified PvD 157 For every existing API function that interacts with the node's 158 networking stack, be it at a relatively high level like 159 getaddrinfo() [9] or at the level of something like Sockets API's 160 sendmsg(), there MUST be a means by which an application can 161 specify the PvD within which networking operations are to be 162 restricted. 164 R4 use one and only specified scope per networking functionality 165 invocation 167 For every unique invocation of a networking API function, there 168 MUST only be one specified PvD to which networking functionality 169 is to be restricted. At any given point in an application's 170 lifetime there MAY be several encapsulating layers of unspecified 171 PvDs (Section 3.2) through which the implementation must 172 progressively search to find a specified PvD, but ultimately a 173 networking function MUST use one and only one PvD for its 174 operations, even if that PvD is a "null PvD" (Section 3.3). 176 R5 make consistent use of programmatic references to PvDs 178 For uniformity and simplicity, every PvD-aware API functional 179 element SHOULD use (as return values of function calls, function 180 arguments, et cetera) the same programmatic reference for PvDs, 181 e.g. a construct containing a PvD identifier [10] or some 182 equivalent shorthand reference token (see Section 4.6 for a 183 discussion of implementation considerations). Regardless of the 184 implementation strategy chosen, a given programmatic reference 185 MUST remain constant over the lifetime of the node's continuous 186 attachment to the PvD to which it refers (until a disconnection 187 or disassociation event occurs). Additionally, references MAY 188 change with successive re-associations to the same PvD whereas 189 PvD identifiers, by definition, will not. 191 It is important to note that there is always a provisioning domain 192 within which networking functionality is scoped. For simply- 193 connected hosts this may be the implicit PvD [11] created by a single 194 networking interface connected to a traditional, shared LAN segment. 195 For multihomed hosts the "default provisioning domain" is likely a 196 matter of policy, but MAY be a "null" PvD, i.e. one completely devoid 197 of networking configuration information (no addresses, no routes, et 198 cetera). See Section 3 for further discussion. 200 The utility of such an API (allowing applications to learn of and 201 control the scope of networking functionality) suggests that the 202 Provisioning Domain is perhaps a more useful operational definition 203 for the original IPv6 concept of a "site-local scope" than the ill- 204 fated [RFC3879], "ill-defined concept" [12] of a site. It also 205 suggests one possible way by which operating system support for a 206 PvD-aware API might be implemented. 208 2.2. Requirements for supporting operating systems 210 The multiple PvD model of host behaviour is perhaps closer to the 211 Strong End System Model than the Weak End System Model characterized 212 in RFC 1122 [RFC1122] section 3.3.4.2 [13], but owing to its 213 recognition of a many-to-many relationship between interfaces and 214 PvDs should be considered a unique model unto itself. 216 In the PvD-aware End System Model, the "two key requirement issues 217 related to multihoming" are restated as: 219 a. A host MAY silently discard an incoming datagram whose 220 destination address does not correspond to any PvD associated 221 with the physical (or virtual) interface through which it is 222 received. 224 b. A host MUST restrict itself to sending (non-source-routed) IP 225 datagrams only through the physical (or virtual) interfaces that 226 correspond to the PvD associated with the IP source address of 227 the datagrams. 229 In order to support a PvD-aware application's use of multiple PVDs, 230 several additional requirements must be met by the host operating 231 system, especially when performing functions on behalf of 232 applications or when no direct application intervention is possible, 233 as discussed in the following sections. 235 2.2.1. Source address selection 236 Whenever a source address is to be selected on behalf of an 237 application it is essential for consistent use that only source 238 addresses belonging to the specified PvD be used a candidate set. 239 (See RFC 6418 [RFC6418] section 3.5 [14] for references to issues 240 arising from poor source address selection.) 242 For nodes following the PvD-aware End System Model, RFC 6724 243 [RFC6724] section 4 [15] is amended as follows: 245 R6 The candidate source addresses MUST be restricted to the set of 246 unicast addresses associated with the concurrently specified PvD. 248 Additionally, source address selection policies from PvDs other 249 than the concurrently specified PvD MUST NOT be applied. 251 2.2.2. Route isolation 253 Whenever a routing lookup for a given destination is to be performed, 254 it is essential that only routes belonging to the currently specified 255 PvD be consulted. Applications and libraries that use the inherent 256 routing reachability check (and subsequent source address selection) 257 performed during something like the Sockets API connect() call on a 258 UDP socket to learn reachability information cheaply cannot function 259 correctly otherwise. RFC 6418 [RFC6418] section 4.2 [16] contains 260 more discussion and references to issues arising from insufficiently 261 isolated routing information. 263 For nodes following the PvD-aware End System Model: 265 R7 The set of routes consulted for any routing decision MUST be 266 restricted to the routes associated with the concurrently 267 specified PvD. 269 2.2.3. Automatic PvD metadata marking 271 In many cases, an application can examine a source address or the 272 destination address of a received datagram and use that address's 273 association with a given PvD to learn, for example, the PvD with 274 which an incoming connection may be associated. It may, however, be 275 impossible for an application to make this determination on its own 276 if, for example, an incoming TCP connection is destined to a RFC 1918 277 [RFC1918] address that happens to be configured in multiple PvDs at 278 the same time. In such circumstances, the supporting operating 279 system will need to provide additional assistance. 281 For nodes following the PvD-aware End System Model: 283 R8 When performing networking functionality on behalf of an 284 application, the supporting operating system MUST record and make 285 available to the application either (1) all the information the 286 application might need to make a determination of the applicable 287 PvD on its own or (2) the API's PvD programmatic reference 288 directly. 290 A supporting operating system SHOULD record and make available 291 the API's PvD programmatic reference; other approaches invite 292 ambiguity among applications' interpretation of available 293 information. 295 2.2.4. Additional system and library support 297 Frequently, operating systems have several additional supporting 298 libraries and services for more advance networking functionality. 299 Using the system's own PvD API, and fulfilling the above 300 requirements, it should be possible to extend these services to 301 provide correct per-PvD isolation of information and enable 302 consistent application use of PvDs. 304 3. Conceptual PvDs 306 3.1. The 'default' PvD 308 Because there is always one specified provisioning domain to which an 309 individual invocation of networking functionality is restricted 310 (Section 2.1) there must necessarily exist a system "default PvD". 311 This provisioning domain is the one which networking functionality 312 MUST use when no other specified PvD can be determined. 314 Using the system's default PvD enables support of basic [17] uses of 315 the PvD API (i.e. backward compatibility for unmodified 316 applications). 318 The operating system MAY change the default PvD accordingly to 319 policy. It is expected that nodes will use a variety of information, 320 coupled with administrative policy, to promote one of any number of 321 concurrently available PvDs to be the system's default PvD. 323 R9 A PvD-aware API implementation MUST include a mechanism for 324 applications to learn the programmatic reference to the system's 325 concurrent default PvD. 327 R10 A PvD-aware API implementation SHOULD contain a mechanism 328 enabling an application to be notified of changes to the 329 concurrent default PvD in a comparatively efficient manner (i.e. 330 more efficient than polling). 332 3.2. The 'unspecified' PvD 334 An application may at some times wish to be specific about which PvD 335 should be used for networking operations and at other times may 336 prefer to defer the choice of specific PvD to one specified elsewhere 337 (including the system default PvD). 339 For example, if an application has specified the PvD to be used for 340 all functions called by its process and child processes 341 (Section 4.3), it may indicate that certain invocations should 342 instead use the system default PvD by using a programmatic reference 343 to the "unspecified PvD". 345 R11 API implementors MUST reserve a programmatic reference to 346 represent an "unspecified PvD": an indication that the 347 application defers the selection of a specific PvD. 349 R12 When invoked without a specific PvD, or with a programmatic 350 reference to the "unspecified PvD", networking functionality MUST 351 find a specific PvD to be used by examining the successive 352 encapsulating layers of possible specificity supported by the API 353 (Section 4.3), e.g. look first for a "fiber-specific default" 354 PvD, then a "thread-specific default" PvD, a "process-specific 355 default" PvD, and ultimately use the system's default PvD if no 356 other specified PvD can be found. 358 3.3. The 'null' PvD 360 If there are no PvDs accessible to an application, whether as a 361 matter of policy (insufficient privileges) (Section 4.5) or as a 362 matter of natural circumstance (the node is not connected to any 363 network), the construct of a 'null' PvD may be useful to ensure 364 networking functions fail (and fail quickly). 366 R13 API implementors MAY reserve a programmatic reference to 367 represent a "null PvD": an unchanging provisioning domain devoid 368 of any and all networking configuration information. 370 It is possible for operating systems to enforce that only PvD-aware 371 applications may function normally by administratively configuring 372 the default PvD to be the "null PvD". 374 3.4. The 'loopback' PvD 376 TBD: is it useful to have a "loopback" PvD, i.e. one consisting 377 solely of all addresses configured on the node and all locally 378 delivered routes? 380 4. Requirements for new API functionality 382 4.1. Learning PvD availability 384 R14 A PvD-aware API MUST implement a mechanism whereby an application 385 can receive a set of the API's PvD programmatic references 386 representing the complete set of PvDs (both explicit [18] and 387 implicit [19]) with which the node is currently associated. 389 R15 A PvD-aware API implementation SHOULD contain a mechanism 390 enabling an application to be notified of changes in the above 391 set of actively associated PvDs in a comparatively efficient 392 manner (i.e. more efficient than polling). 394 In may also be of use to applications to receive notifications of 395 pending changes to the set of currently connected PvDs. For example, 396 if it is known that a connection to a PvD is scheduled to be 397 terminated shortly, an application may be able to take some 398 appropriate action (migrate connections to another PvD, send 399 notifications, et cetera). 401 4.2. Learning network configuration information comprising a PvD 403 R16 A PvD-aware API MUST include a mechanism whereby by an 404 application, using the API's PvD programmatic reference, can 405 receive elements of the network configuration information that 406 comprise a PvD. At a minimum, this mechanism MUST be capable of 407 answering queries for: 409 * the PvD identifier 411 * all participating interfaces 413 * all IPv4 and all non-deprecated IPv6 addresses 415 * all configured DNS nameservers 417 A PvD's network configuration information is neither guaranteed to be 418 learned atomically nor is it guaranteed to be static. Addresses, 419 routes, and even DNS nameservers and participating interfaces may 420 each change over the lifetime of the node's association to a given 421 PvD. Timely notification of such changes may be of particular 422 importance to some applications. 424 R17 A PvD-aware API implementation SHOULD contain a mechanism 425 enabling an application to be notified of changes in the 426 networking configuration information comprising a PvD in a 427 comparatively efficient manner (i.e. more efficient than 428 polling). 430 R18 A network configuration query API implementation SHOULD take 431 extensibility into account, to support querying for configuration 432 information not yet conceived of with minimal adverse impact to 433 applications. 435 4.3. Scoping functionality to a specific PvD 437 R19 A PvD-aware API implementation MUST include a mechanism for an 438 application to specify the programmatic reference of the PvD to 439 which all networking functionality MUST be restricted when not 440 otherwise explicitly specified (a configurable, application- 441 specific "default PvD"). 443 R20 The API implementation MUST support setting such a "default PvD" 444 for an application's entire process (and by extension its child 445 processes). Additionally, the API SHOULD support an application 446 setting a "default PvD" at every granularity of "programming 447 parallelization", i.e. not only per-process, but also per-thread, 448 per-fiber, et cetera. At every supported layer of granularity, 449 if no PvD reference has been set the next coarser layer's setting 450 MUST be consulted (up to and including the system's default PvD) 451 when identifying the specified PvD to be used. 453 R21 For every degree of granularity at which an application may 454 specify a "default PvD" there MUST exist a corresponding 455 mechanism to retrieve any concurrently specified implementation- 456 specific PvD programmatic reference. If no PvD has been 457 specified for at the granularity of a given query, the 458 "unspecified PvD" must be returned. 460 With access to this functionality it is possible to start non-PvD- 461 aware applications within a single PvD context with no adverse 462 impact. Furthermore, with judicious use of a sufficiently granular 463 API, existing general purpose networking APIs can be wrapped to 464 appear PvD-aware. 466 4.4. Explicit versus Implicit PvDs 467 R22 Because programmatic references to PvDs are returned for both 468 explicit and implicit PvDs, the MPvD API implementation MUST be 469 equally applicable and useful for any valid type of PvD; it MUST 470 NOT be necessary for a PvD-aware application to distinguish 471 between explicit and implicit PvDs to function properly. 473 4.5. Policy restrictions 475 This document does not make recommendations about policies governing 476 the use of any or all elements of a PvD API, save only to note that 477 some restrictions on use may be deemed necessary or appropriate. 479 R23 A PvD API implementation MAY implement policy controls whereby 480 access to PvD availability information, configuration elements, 481 and/or explicit scoping requests is variously permitted or denied 482 to certain applications. 484 4.6. Programmatic reference implementation considerations 486 PvD identifiers may be of a length or form not easily handled 487 directly in some programming environments, and unauthenticated PvD 488 identifiers are assumed to be only probabilistically unique [20]. As 489 such, API implementations should consider using some alternative 490 programmatic reference (a node-specific "handle" or "token"), which 491 is fully under the control of the operating system, to identify an 492 instance of a single provisioning domain's network configuration 493 information. 495 Even though a PvD identifier may uniquely correspond to, say, a 496 network operator, there is no guarantee that the configuration 497 information (delegated prefixes, configured IP addresses, and so on) 498 will be the same with every successive association to the same PvD 499 identifier. An implementation may elect to change the value of the 500 programmatic reference to a given PvD identifier for each temporally 501 distinct association. Doing so presents some advantages worth 502 considering: 504 Collisions in the PvD identifier space will inherently be treated 505 as distinct by applications not concerned solely with identifiers. 507 Changing the value of a reference can disabuse application writers 508 of inappropriately caching configuration information from one 509 association instance to another. 511 Whether two PvDs are "identical" is perhaps better left to 512 applications to decide since "PvD equivalence" for a given 513 application may alternatively be determined by successfully 514 accessing some restricted resource. 516 This document makes no specific requirement on the type of 517 programmatic reference used by the API. 519 5. Existing networking APIs 521 5.1. Updating existing APIs 523 From the perspective of a PvD-aware operating system, all previously 524 existing non-PvD-enabled networking functionality had historically 525 been executed within the context of a single, implicit provisioning 526 domain. A sufficiently granular API to specify which PvD is to be 527 used to scope subsequent networking functionality (Section 4.3) can 528 be used to wrap non-PvD-aware APIs, giving them this new PvD-aware 529 capability. However, 531 R24 Operating system implementors SHOULD consider updating existing 532 networking APIs to take or return programmatic references to PvDs 533 directly. 535 This may mean creating new functions with an additional PvD 536 programmatic reference argument, adding a PvD programmatic reference 537 field to an existing structure or class that is itself an argument or 538 return type, or finding other means by which to use a programmatic 539 reference with minimal or no disruption to existing applications or 540 libraries. 542 5.2. Requirements for name resolution APIs 544 RFC 3493 [RFC3493] getaddrinfo() [21] and getnameinfo() [22] APIs 545 deserve explicit discussion. Previously stated requirements make it 546 clear that it MUST be possible for an application to perform normal 547 name resolution constrained to the DNS configuration within a 548 specified PVD. This MUST be possible using at least the techniques 549 of Section 4.3. 551 The following additional requirements are places on PvD-aware 552 implementations of these functions: 554 R25 All DNS protocol communications with a PvD's nameservers MUST be 555 restricted to use only source addresses and routes associated 556 with the PvD. 558 R26 If getaddrinfo() is called with the AI_ADDRCONFIG flag specified, 559 IPv4 addresses shall be returned only if an IPv4 address is 560 configured within the specified provisioning domain and IPv6 561 addresses shall be returned only if an IPv6 address is configured 562 within the specified provision domain. The loopback address is 563 (still) not considered for this case as valid as a configured 564 address. 566 6. Acknowledgements 568 The core concepts presented in this document were developed during 569 the Android multinetworking effort by Lorenzo Colitti, Robert 570 Greenwalt, Paul Jensen, and Sreeram Ramachandran. 572 Additional thanks to the coffee shops of Tokyo. 574 7. IANA Considerations 576 This memo includes no request to IANA. 578 8. Security Considerations 580 An important new security impact of a PvD-aware API is that it 581 becomes much simpler (by design) to write a well-functioning 582 application to create a bridging data path between two PvDs that 583 would not otherwise have been so easily connected. 585 For some operating systems, existing APIs already make this bridging 586 possible, though some functionality like DNS resolution may have been 587 difficult to implement. Indeed, the very aim of an MPvD API is to 588 make implementing a PvD-aware application simple and to make its 589 functioning more "correct" ("first class" support for such 590 functionality). 592 Operating system implementations have several points of potential 593 policy control including: 595 o use of certain PvDs MAY be restricted by policy (e.g. only 596 approved users, groups, or applications might be permitted 597 access), and/or 599 o use of more than one PvD (or the MPvD API itself) MAY be similarly 600 restricted. 602 9. References 604 9.1. Normative References 606 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 607 Communication Layers", STD 3, RFC 1122, DOI 10.17487/ 608 RFC1122, October 1989, 609 . 611 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 612 Requirement Levels", BCP 14, RFC 2119, March 1997. 614 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 615 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 616 3493, DOI 10.17487/RFC3493, February 2003, 617 . 619 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 620 "Default Address Selection for Internet Protocol Version 6 621 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 622 . 624 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 625 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 626 . 628 9.2. Informative References 630 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 631 E. Lear, "Address Allocation for Private Internets", BCP 632 5, RFC 1918, February 1996. 634 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 635 Addresses", RFC 3879, DOI 10.17487/RFC3879, September 636 2004, . 638 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 639 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 640 November 2005, . 642 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 643 Provisioning Domains Problem Statement", RFC 6418, DOI 644 10.17487/RFC6418, November 2011, 645 . 647 Author's Address 648 Erik Kline 649 Google Japan KK 650 6-10-1 Roppongi 651 Mori Tower, 44th floor 652 Minato, Tokyo 106-6126 653 JP 655 Email: ek@google.com