MIF Working Group D. Anipko
Internet-Draft Microsoft Corporation
Intended status: Informational July 2013
Expires: December 31, 2013
Multiple Provisioning Domain Architecture
draft-anipko-mif-mpvd-arch-00
Abstract
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.
Status of this Memo
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 December 31, 2013.
Copyright Notice
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
Anipko Expires December 31, 2013 [Page 1]
Internet-Draft MPVD architecture July 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Definitions and types of PVDs . . . . . . . . . . . . . . . . 3
2.1. Explicit and implicit PVDs . . . . . . . . . . . . . . . . 4
2.2. Relationship between PVDs and interfaces . . . . . . . . . 5
2.3. PVD identity/naming . . . . . . . . . . . . . . . . . . . 5
2.4. Relationship to dual-stack networks . . . . . . . . . . . 5
2.5. Elements of PVD . . . . . . . . . . . . . . . . . . . . . 6
3. Example network configurations and number of PVDs . . . . . . 6
4. Reference model of PVD-aware node . . . . . . . . . . . . . . 6
4.1. Constructions and maintenance of separate PVDs . . . . . . 6
4.2. Consistent use of PVDs for network connections . . . . . . 6
4.2.1. Name resolution . . . . . . . . . . . . . . . . . . . 6
4.2.2. Next-hop and source address selection . . . . . . . . 6
4.3. Connectivity tests . . . . . . . . . . . . . . . . . . . . 7
4.4. Relationship to interface management and connection manager 7
5. PVD support in APIs . . . . . . . . . . . . . . . . . . . . . 7
5.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. PVD-aware nodes trust to PVDs . . . . . . . . . . . . . . . . 7
6.1. Untrusted PVDs . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Authenticated PVDs . . . . . . . . . . . . . . . . . . . . 8
6.3. Trusted PVDs . . . . . . . . . . . . . . . . . . . . . . . 8
6.3.1. Trust via strong ID . . . . . . . . . . . . . . . . . 8
6.3.2. Trust via attachment . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
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:
Anipko Expires December 31, 2013 [Page 2]
Internet-Draft MPVD architecture July 2013
1. Lack of consistent and distinctive management of configuration
elements, associated with different networks.
2. Inappropriate mixed use of configuration elements, associated
with different networks, in the course of a particular network
activity / connection.
3. Use of a particular network, not consistent with the intent of
the scenario / involved parties, leading to connectivity failure
and / or other undesired consequences.
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:
1. Introducing a formal notion of the PVD, including PVD identity,
and ways for nodes to learn the intended associations among
acquired network configuration information elements.
2. Introducing a reference model for a PVD-aware node, preventing
inadvertent mixed use of the configuration information, which may
belong to different PVDs.
3. Providing recommendations on PVD selection based on PVD identity
and connectivity tests for common scenarios.
1.1. Requirements Language
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].
2. Definitions and types of PVDs
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
Anipko Expires December 31, 2013 [Page 3]
Internet-Draft MPVD architecture July 2013
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.
2.1. Explicit and implicit PVDs
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.
Anipko Expires December 31, 2013 [Page 4]
Internet-Draft MPVD architecture July 2013
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.
2.2. Relationship between PVDs and interfaces
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.
2.3. PVD identity/naming
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.
2.4. Relationship to dual-stack networks
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
Anipko Expires December 31, 2013 [Page 5]
Internet-Draft MPVD architecture July 2013
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.
2.5. Elements of PVD
3. Example network configurations and number of PVDs
4. Reference model of PVD-aware node
4.1. Constructions and maintenance of separate PVDs
4.2. Consistent use of PVDs for network connections
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.
4.2.1. Name resolution
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.
4.2.2. Next-hop and source address selection
Anipko Expires December 31, 2013 [Page 6]
Internet-Draft MPVD architecture July 2013
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.
4.3. Connectivity tests
4.4. Relationship to interface management and connection managers
5. PVD support in APIs
In all cases changes in available PVDs must be somehow exposed,
appropriately for each of the approaches.
5.1. Basic
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.
5.2. Intermediate
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.
5.3. Advanced
PVDs are directly exposed to applications, for enumeration and
selection, within limits allowed by the node policies and / or user
preferences.
6. PVD-aware nodes trust to PVDs
6.1. Untrusted PVDs
Anipko Expires December 31, 2013 [Page 7]
Internet-Draft MPVD architecture July 2013
6.2. Authenticated PVDs
6.3. Trusted PVDs
6.3.1. Trust via strong ID
6.3.2. Trust via attachment
7. Acknowledgements
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
All drafts are required to have a security considerations section.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[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.
[RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", RFC 6418,
November 2011.
[RFC6419] Wasserman, M. and P. Seite, "Current Practices for
Multiple-Interface Hosts", RFC 6419, November 2011.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A. and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
Author's Address
Anipko Expires December 31, 2013 [Page 8]
Internet-Draft MPVD architecture July 2013
Dmitry Anipko
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Phone: +1 425 703 7070
Email: dmitry.anipko@microsoft.com
Anipko Expires December 31, 2013 [Page 9]