| MIF Working Group | D. Anipko |
| Internet-Draft | Microsoft Corporation |
| Intended status: Informational | July 13, 2013 |
| Expires: January 14, 2014 |
Multiple Provisioning Domain Architecture
draft-anipko-mif-mpvd-arch-00
This document is a product of the work of MIF architecture design team. It outlines a solution framework for some of the issues, experienced by nodes that can be attached to multiple networks. The framework defines the notion of a Provisioning Domain (PVD) - a consistent set of network configuration information, and PVD-aware nodes - nodes which learn PVDs from the attached network(s) and/or other sources and manage and use multiple PVDs for connectivity separately and consistently.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Nodes attached to multiple networks may encounter problems due to conflict of the networks configuration and/or simultaneous use of the multiple available networks. While existing implementations apply various techniques (RFC 6419 [RFC6419]) to tackle such problems, in many cases the issues may still appear. The MIF problem statement document RFC 6418 [RFC6418] describes the general landscape as well as discusses many specific issues details.
Across the layers, problems enumerated in RFC 6418 [RFC6418] can be grouped into 3 categories:
As an illustration: an example of (1) is a single node-scoped list of DNS server IP addresses, learned from different networks, leading to failures or delays in resolution of name from particular namespaces; an example of (2) is use of an attempt to resolve a name of a HTTP proxy server, learned from a network A, with a DNS server, learned from a network B, likely to fail; an example of (3) is a use of employer-sponsored VPN connection for peer-to-peer connections, unrelated to employment activities.
This architecture describes a solution to these categories of problems, respectively, by:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
Provisioning Domain: a consistent set of network configuration information. Usually, the entire set available on a single interface is provided by a single source, such as network administrator. Typical examples of such information, learned from the network, are: source address prefixes, used by the network, IP address of DNS server, name of HTTP proxy server if available, DNS suffixes associated with the network etc.
It is also possible for other sources, such as e.g. node local policy, user input or other out of band mechanisms to either construct a PVD entirely (analogously to static IP configuration of an interface), or supplement with particular elements all or some PVDs learned from the network. As an example, node administrator could inject a not ISP-specific DNS server into PVDs for any of the networks the node could become attached to. Such creation / augmentation of PVD could be static or dynamic. The particular implementation mechanisms are outside of the scope of this document.
PVD-aware node: a node that supports association of network configuration information into PVDs, and using the resultant PVDs to serve requests for network connections in a way, consistent with recommendations of this architecture.
A node may receive explicit information from the network and/or other sources, about presence of PVDs and association of particular network information with a particular PVD. PVDs, constructed based on such information, are referred to in this document as "explicit".
Protocol changes/extensions will likely be required to support the explicit PVDs. As an example, one could think of one or several DHCP options, defining a PVD identity and elements. A different approach could be to introduce a DHCP option, which only introduces identity of a PVD, while the association of network information elements with that identity, is implemented by the respective protocols - such as e.g., with a Router Discovery [RFC4861] option declaring association of an address range with a particular PVD.
Specific, existing or new, features of networking protocols to enable delivery of PVD identity and association with various network information elements will be defined in companion design documents.
It is likely that for a long time there may be networks which do not advertise any explicit PVD information, since deployment of any new features in networking protocols is a relatively slow process. When connected to such networks, PVD-aware nodes may still provide benefits to their users, compared to non-PVD aware nodes, by creating separate PVDs for configuration received on different interfaces. Such PVDs are referred to in this document as "implicit". This allows the node to manage and use network information from different interfaces separately and consistently use the configuration to serve network connection requests.
In the mixed mode, where e.g. multiple networks are available on the link the interface is attached to, and only some of the networks advertize PVD information, the PVD-aware node shall create explicit PVDs based on explicitly learned PVD information, and associate the rest of the configuration with an implicit PVD created for that interface.
It shall be possible for networks to communicate that some of their configuration elements could be used within a context of other networks/PVDs. Based on such declaration and their policies, PVD-aware nodes may choose to inject such elements into some or all other PVDs they connect to.
Implicit PVDs are limited to network configuration information received on a single interface. Explicit PVDs, in practice will often also be scoped to a configuration related to a particular interface, however per this architecture there is no such requirement or limitation and as defined in this architecture, explicit PVDs may include information related to more than one interfaces, if the node learns presence of the same PVD on those interfaces and the authentication of the PVD ID meets the level required by the node policy.
For explicit PVDs, PVD ID (globally unique ID, that possibly is human-readable) is received as part of that information. For implicit PVDs, the node assigns a locally generated globally unique ID to each implicit PVD.
PVD-aware node may use these IDs to choose a PVD with matching ID for special-purpose connection requests, in accordance with node policy or choice by advanced applications, and/or to present human-readable IDs to the end-user for selection of Internet-connected PVDs.
When applied to dual-stack networks, the PVD definition allows for multiple PVDs to be created, where each PVD contain information for only one address family, or for a single PVD that contains information about multiple address families. This architecture requires that accompanying design documents for accompanying protocol changes must support PVDs containing information from multiple address families. PVD-aware nodes must be capable of dealing with both single-family and multi-family PVDs.
Nevertheless, for explicit PVDs, the choice of either of the approaches is a policy decision of a network administrator and/or node user/administrator. Since some of the IP configuration information that can be learned from the network can be applicable to multiple address families (for instance DHCP address selection option [I-D.ietf-6man-addr-select-opt]), it is likely that dual-stack networks will deploy single PVDs for both address families.
For implicit PVDs, by default PVD-aware nodes shall including multiple IP families into single implicit PVD created for an interface.
A PVD-aware node that provides API to use / enumerate / inspect PVDs and/or their properties shall provide ability to filter PVDs and/or their properties by address family.
PVDs enable PVD-aware nodes to use consistently a correct set of configuration elements to serve the specific network requests from beginning to end. This section describes specific examples of such consistent use.
When PVD-aware node needs to resolve a name of the destination used by a connection request, the node could decide to use one, or multiple PVDs for a given name lookup.
The node shall chose one PVD, if e.g., the node policy required to use a particular PVD for a particular purpose (e.g. to download an MMS using a specific APN over a cellular connection). To make the choice, the node could use a match of the PVD DNS suffix or other form of PVD ID, as determined by the node policy.
The node may pick multiple PVDs, if e.g., they are general purpose PVDs providing connectivity to the Internet, and the node desires to maximize chances for connectivity in Happy Eyeballs style. In this case, the node could do the lookups in parallel, or in sequence. Alternatively, the node may use for the lookup only one PVD, based on the PVD connectivity properties, user choice of the preferred Internet PVD, etc.
In either case, by default the node shall use for the following connection request the PVD, where the lookup results were obtained.
For the purpose of this discussion, let's assume the preceding name lookup succeeded in a particular PVD. For each obtained destination address, the node shall perform a next-hop lookup among routers, associated with that PVD. As an example, such association could be determined by the node via matching the source address prefixes/specific routes advertized by the router against known PVDs, or receiving explicit PVD affiliation advertized through a new Router Discovery [RFC4861] option.
For each destination, once the best next-hop is found, the node selects best source address according to the RFC 6724 [RFC6724] rules, but with a constraint that the source address must belong to a range associated with the used PVD. If needed, the node would use the prefix policy from the same PVD for the best source address selection among multiple candidates.
When destination/source pairs are identified, then they are sorted using the RFC 6724 [RFC6724] destination sorting rules and the prefix policy table from the used PVD.
In all cases changes in available PVDs must be somehow exposed, appropriately for each of the approaches.
Applications are not PVD-aware in any manner, and only submit connection requests. The node performs PVD selection implicitly, without any otherwise applications participation, and based purely on policies and/or user choice.
Applications indirectly participate in selection of PVD by specifying hard requirements and soft preferences. The node performs PVD selection, based on applications inputs and policies and/or user preferences. Some / all properties of the resultant PVD may be exposed to applications.
PVDs are directly exposed to applications, for enumeration and selection, within limits allowed by the node policies and / or user preferences.
This memo includes no request to IANA.
All drafts are required to have a security considerations section.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC6419] | Wasserman, M. and P. Seite, "Current Practices for Multiple-Interface Hosts", RFC 6419, November 2011. |
| [RFC6418] | Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011. |
| [RFC4861] | Narten, T., Nordmark, E., Simpson, W. and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. |
| [I-D.ietf-6man-addr-select-opt] | Matsumoto, A., Fujisaki, T. and T. Chown, "Distributing Address Selection Policy using DHCPv6", Internet-Draft draft-ietf-6man-addr-select-opt-10, April 2013. |
| [RFC6724] | Thaler, D., Draves, R., Matsumoto, A. and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. |