< draft-ietf-mif-mpvd-arch-10.txt   draft-ietf-mif-mpvd-arch-11.txt >
MIF Working Group D. Anipko, Ed. MIF Working Group D. Anipko, Ed.
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Informational February 09, 2015 Intended status: Informational March 17, 2015
Expires: August 11, 2015 Expires: September 16, 2015
Multiple Provisioning Domain Architecture Multiple Provisioning Domain Architecture
draft-ietf-mif-mpvd-arch-10 draft-ietf-mif-mpvd-arch-11
Abstract Abstract
This document is a product of the work of the MIF Architecture Design This document is a product of the work of the Multiple Interfaces
team. It outlines a solution framework for some of the issues Architecture Design team. It outlines a solution framework for some
experienced by nodes that can be attached to multiple networks of the issues experienced by nodes that can be attached to multiple
simultaneously. The framework defines the concept of a Provisioning networks simultaneously. The framework defines the concept of a
Domain (PvD) which is a a consistent set of network configuration Provisioning Domain (PvD) which is a a consistent set of network
information. PvD aware nodes learn PvD specific information from the configuration information. PvD aware nodes learn PvD specific
networks they are attached to and / or other sources. PvDs are used information from the networks they are attached to and / or other
to enable separation and configuration consistency in presence of sources. PvDs are used to enable separation and configuration
multiple concurrent connections. consistency in presence of multiple concurrent connections.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 11, 2015. This Internet-Draft will expire on September 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/ Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 8 skipping to change at page 2, line 4
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/ Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Definitions and Types of PvDs . . . . . . . . . . . . . . . . 3
2. Definitions and Types of PvDs . . . . . . . . . . . . . . . . 4
2.1. Explicit PvDs . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Explicit PvDs . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Implicit PvDs and Incremental Adoption of Explicit PvDs . 5 2.2. Implicit PvDs and Incremental Adoption of Explicit PvDs . 5
2.3. Relationship Between PvDs and Interfaces . . . . . . . . . 6 2.3. Relationship Between PvDs and Interfaces . . . . . . . . . 5
2.4. PvD Identity / Naming . . . . . . . . . . . . . . . . . . 6 2.4. PvD Identity / Naming . . . . . . . . . . . . . . . . . . 6
2.5. The Relationship to Dual-Stack Networks . . . . . . . . . 7 2.5. The Relationship to Dual-Stack Networks . . . . . . . . . 7
3. Conveying PvD information using DHCPv6 and Router Advertisement 8 3. Conveying PvD information . . . . . . . . . . . . . . . . . . 7
3.1. Separate Messages or One Message? . . . . . . . . . . . . 8 3.1. Separate Messages or One Message? . . . . . . . . . . . . 8
3.2. Securing PvD Information . . . . . . . . . . . . . . . . . 8 3.2. Securing PvD Information . . . . . . . . . . . . . . . . . 8
3.3. Backward Compatibility . . . . . . . . . . . . . . . . . . 8 3.3. Backward Compatibility . . . . . . . . . . . . . . . . . . 8
3.4. Retracting / Updating PvD Information . . . . . . . . . . 8 3.4. Retracting / Updating PvD Information . . . . . . . . . . 8
3.5. Conveying Configuration Information using IKEv2 . . . . . 9 3.5. Conveying Configuration Information using IKEv2 . . . . . 9
4. Example Network Configurations . . . . . . . . . . . . . . . . 9 4. Example Network Configurations . . . . . . . . . . . . . . . . 9
4.1. A Mobile Node . . . . . . . . . . . . . . . . . . . . . . 9 4.1. A Mobile Node . . . . . . . . . . . . . . . . . . . . . . 9
4.2. A Node with a VPN Connection . . . . . . . . . . . . . . . 10 4.2. A Node with a VPN Connection . . . . . . . . . . . . . . . 10
4.3. A Home Network and a Network Operator with Multiple PvDs . 11 4.3. A Home Network and a Network Operator with Multiple PvDs . 11
5. Reference Model for the PvD-aware Node . . . . . . . . . . . . 11 5. Reference Model for the PvD-aware Node . . . . . . . . . . . . 12
5.1. Constructions and Maintenance of Separate PvDs . . . . . . 12 5.1. Constructions and Maintenance of Separate PvDs . . . . . . 12
5.2. Consistent use of PvDs for Network Connections . . . . . . 12 5.2. Consistent use of PvDs for Network Connections . . . . . . 12
5.2.1. Name Resolution . . . . . . . . . . . . . . . . . . . 12 5.2.1. Name Resolution . . . . . . . . . . . . . . . . . . . 13
5.2.2. Next-hop and Source Address Selection . . . . . . . . 13 5.2.2. Next-hop and Source Address Selection . . . . . . . . 14
5.2.3. Listening Applications . . . . . . . . . . . . . . . . 14 5.2.3. Listening Applications . . . . . . . . . . . . . . . . 14
5.2.3.1. Processing of Incoming Traffic . . . . . . . . . . 14 5.2.3.1. Processing of Incoming Traffic . . . . . . . . . . 15
5.2.3.1.1. Connection-oriented APIs . . . . . . . . . . . 15 5.2.3.1.1. Connection-oriented APIs . . . . . . . . . . . 15
5.2.3.1.2. Connectionless APIs . . . . . . . . . . . . . 15 5.2.3.1.2. Connectionless APIs . . . . . . . . . . . . . 15
5.2.4. Enforcement of Security Policies . . . . . . . . . . . 15 5.2.4. Enforcement of Security Policies . . . . . . . . . . . 15
5.3. Connectivity Tests . . . . . . . . . . . . . . . . . . . . 15 5.3. Connectivity Tests . . . . . . . . . . . . . . . . . . . . 16
5.4. Relationship to Interface Management and Connection Manage 16 5.4. Relationship to Interface Management and Connection Manage 16
6. PvD support in APIs . . . . . . . . . . . . . . . . . . . . . 16 6. PvD support in APIs . . . . . . . . . . . . . . . . . . . . . 17
6.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. PvD Trust for PvD-Aware Node . . . . . . . . . . . . . . . . . 17 7. PvD Trust for PvD-Aware Node . . . . . . . . . . . . . . . . . 18
7.1. Untrusted PvDs . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Untrusted PvDs . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Trusted PvDs . . . . . . . . . . . . . . . . . . . . . . . 18 7.2. Trusted PvDs . . . . . . . . . . . . . . . . . . . . . . . 18
7.2.1. Authenticated PvDs . . . . . . . . . . . . . . . . . . 18 7.2.1. Authenticated PvDs . . . . . . . . . . . . . . . . . . 19
7.2.2. PvDs Trusted by Attachment . . . . . . . . . . . . . . 18 7.2.2. PvDs Trusted by Attachment . . . . . . . . . . . . . . 19
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Nodes attached to multiple networks may encounter problems from Nodes attached to multiple networks may encounter problems from
conflicting configuration between the networks, or attempts to conflicting configuration between the networks, or attempts to
simultaneously use more than one network. While various techniques simultaneously use more than one network. While various techniques
are currently used to tackle these problems ([RFC6419]), in many are currently used to tackle these problems ([RFC6419]), in many
cases issues may still appear. The MIF problem statement document cases issues may still appear. The Multiple Interfaces problem
[RFC6418] describes the general landscape and discusses many of the statement document [RFC6418] describes the general landscape and
specific issues and scenario details. discusses many of the specific issues and scenario details.
Problems, enumerated in [RFC6418], can be grouped into 3 categories: Problems, enumerated in [RFC6418], can be grouped into 3 categories:
1. Lack of consistent and distinctive management of configuration 1. Lack of consistent and distinctive management of configuration
elements associated with different networks. elements associated with different networks.
2. Inappropriate mixed use of configuration elements associated with 2. Inappropriate mixed use of configuration elements associated with
different networks during a particular network activity or different networks during a particular network activity or
connection. connection.
skipping to change at page 3, line 49 skipping to change at page 3, line 42
associations between acquired network configuration information associations between acquired network configuration information
elements. elements.
2. Introducing a reference model for PvD-aware nodes that prevents 2. Introducing a reference model for PvD-aware nodes that prevents
the inadvertent mixed use of configuration information which may the inadvertent mixed use of configuration information which may
belong to different PvDs. belong to different PvDs.
3. Providing recommendations on PvD selection based on PvD identity 3. Providing recommendations on PvD selection based on PvD identity
and connectivity tests for common scenarios. 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 2. Definitions and Types of PvDs
Provisioning Domain: Provisioning Domain:
A consistent set of network configuration information. A consistent set of network configuration information.
Classically, all of the configuration information available on a Classically, all of the configuration information available on a
single interface is provided by a single source (such as a network single interface is provided by a single source (such as a network
administrator) and can therefore be treated as a single administrator) and can therefore be treated as a single
provisioning domain. In modern IPv6 networks, multihoming can provisioning domain. In modern IPv6 networks, multihoming can
result in more than one provisioning domain being present on a result in more than one provisioning domain being present on a
single link. In some scenarios, it is also possible for elements single link. In some scenarios, it is also possible for elements
skipping to change at page 4, line 38 skipping to change at page 4, line 25
* DNS suffixes associated with the network * DNS suffixes associated with the network
* Default gateway address * Default gateway address
PvD-aware node: PvD-aware node:
A node that supports the association of network configuration A node that supports the association of network configuration
information into PvDs and the use of these PvDs to serve requests information into PvDs and the use of these PvDs to serve requests
for network connections in ways consistent with the for network connections in ways consistent with the
recommendations of this architecture. recommendations of this architecture.
PvD-aware application:
An application, that contains code and / or application-specific
configuration information explicitly aware of the notion of PvD
and / or specific types of PvD elements or properties.
2.1. Explicit PvDs 2.1. Explicit PvDs
A node may receive explicit information from the network and / or A node may receive explicit information from the network and / or
other sources conveying the presence of PvDs and the association of other sources conveying the presence of PvDs and the association of
particular network information with a particular PvD. PvDs that are particular network information with a particular PvD. PvDs that are
constructed based on such information are referred to as "explicit" constructed based on such information are referred to as "explicit"
in this document. in this document.
Protocol changes or extensions will likely be required to support Protocol changes or extensions will likely be required to support
explicit PvDs through IETF-defined mechanisms. As an example, one explicit PvDs through IETF-defined mechanisms. As an example, one
could think of one or more DHCP options carrying PvD identity and / could think of one or more DHCP options carrying PvD identity and /
or its elements. or its elements.
A different approach could be the introduction of a DHCP option which A different approach could be the introduction of a DHCP option which
only carries the identity of a PvD. Here, the associations between only carries the identity of a PvD. Here, the associations between
network information elements with the identity is implemented by the network information elements with the identity is implemented by the
respective protocols, for example with a Router Discovery [RFC4861] respective protocols, for example with a Router Discovery [RFC4861]
option associating an address range with a PvD. option associating an address range with a PvD. Additional discussion
can be found in Section 3.
Another example of a delivery mechanism for PvDs are key exchange or Another example of a delivery mechanism for PvDs are key exchange or
tunneling protocols, such as IKEv2 [RFC5996] that allow the tunneling protocols, such as IKEv2 [RFC5996] that allow the
transport of host configuration information. transport of host configuration information.
Specific, existing or new features of networking protocols that Specific, existing or new features of networking protocols that
enable the delivery of PvD identity and association with various enable the delivery of PvD identity and association with various
network information elements will be defined in companion design network information elements will be defined in companion design
documents. documents.
skipping to change at page 6, line 18 skipping to change at page 5, line 53
benefits to their users (when compared to non-PvD aware nodes) by benefits to their users (when compared to non-PvD aware nodes) by
following the best practices described in Section 5. following the best practices described in Section 5.
PvD-aware nodes shall treat network information from different PvD-aware nodes shall treat network information from different
interfaces, which is not identified as belonging explicitly to some interfaces, which is not identified as belonging explicitly to some
PvD, as belonging to separate PvDs, one per interface. PvD, as belonging to separate PvDs, one per interface.
Implicit PvDs can also occur in a mixed mode, i.e., where of multiple Implicit PvDs can also occur in a mixed mode, i.e., where of multiple
networks that are available on an attached link, only some advertise networks that are available on an attached link, only some advertise
PvD information. In this case, the PvD-aware node shall create PvD information. In this case, the PvD-aware node shall create
explicit PvDs from information explicitly labeled as beloinging to explicit PvDs from information explicitly labeled as belonging to
PvDs. It shall associate configuration information not labeled with PvDs. It shall associate configuration information not labeled with
an explicit PvD with implicit PvD(s) created for that interface. an explicit PvD with implicit PvD(s) created for that interface.
2.3. Relationship Between PvDs and Interfaces 2.3. Relationship Between PvDs and Interfaces
By default, implicit PvDs are limited to the network configuration By default, implicit PvDs are limited to the network configuration
information received on a single interface and by default one such information received on a single interface and by default one such
PvD is formed for each interface. If additional information is PvD is formed for each interface. If additional information is
available to the host (through mechanisms out of scope of this available to the host (through mechanisms out of scope of this
document), the host may form implicit PvDs with different document), the host may form implicit PvDs with different
granularity. For example, PvDs spanning multiple interfaces such a granularity. For example, PvDs spanning multiple interfaces such a
home network with a router that has multiple internal interfaces, or home network with a router that has multiple internal interfaces, or
multiple PvDs on a single interface such as a network that has multiple PvDs on a single interface such as a network that has
multiple uplink connections. multiple uplink connections.
In the simplest case, explicit PvDs will be scoped for configuration In the simplest case, explicit PvDs will be scoped for configuration
related only to a specific interface. However, there is no related only to a specific interface. However, there is no
requirement in this architecture for such a limitation. Explicit requirement in this architecture for such a limitation. Explicit
PvDs may include information related to more than one interface if PvDs may include information related to more than one interface if
the node learns the presence of the same PvD on those interfaces and the node learns the presence of the same PvD on those interfaces and
the authentication of the PvD ID meets the level required by the node the authentication of the PvD ID meets the level required by the node
policy (authentication of a PvD ID may be also required in scenarios policy (authentication of a PvD ID may be also required in scenarios
involving only one connected interface and / or PvD). involving only one connected interface and / or PvD; for additional
discussion of PvD Trust see Section 7).
This architecture supports such scenarios. Hence, no hierarchical This architecture supports such scenarios. Hence, no hierarchical
relationship exists between interfaces and PvDs: it is possible for relationship exists between interfaces and PvDs: it is possible for
multiple PvDs to be simultaneously accessible over one interface, as multiple PvDs to be simultaneously accessible over one interface, as
well as a single PvD to be simultaneously accessible over multiple well as a single PvD to be simultaneously accessible over multiple
interfaces. interfaces.
2.4. PvD Identity / Naming 2.4. PvD Identity / Naming
For explicit PvDs, the PvD ID is a value that is, or has a high For explicit PvDs, the PvD ID is a value that is, or has a high
probability of being globally unique, and is received as part of PvD probability of being globally unique, and is received as part of PvD
information. It shall be possible to generate a human-readable form information. It shall be possible to generate a human-readable form
of the PvD ID to present to the end-user, either based on the PvD ID of the PvD ID to present to the end-user, either based on the PvD ID
itself, or using meta-data associated with the ID. For implicit PvDs, itself, or using meta-data associated with the ID. For implicit PvDs,
the node assigns a locally generated ID with a high probability of the node assigns a locally generated ID with a high probability of
being globally unique to each implicit PvD. being globally unique to each implicit PvD.
We say that a PvD ID should be, or should have a high probability of
being globally unique. The purpose of this is to make it unlikely
that any individual node will ever accidentally see the same PvD name
twice if it is not actually referring to the same PvD. Protection
against deliberate attacks involving name clashes require that the
name be authenticated (see Section 7.2.1).
A PvD-aware node may use these IDs to select a PvD with a matching ID A PvD-aware node may use these IDs to select a PvD with a matching ID
for special-purpose connection requests in accordance with node for special-purpose connection requests in accordance with node
policy, as chosen by advanced applications, or to present a human- policy, as chosen by advanced applications, or to present a human-
readable representation of the IDs to the end-user for selection of readable representation of the IDs to the end-user for selection of
PvDs. PvDs.
A single network provider may operate multiple networks, including A single network provider may operate multiple networks, including
networks at different locations. In such cases, the provider may networks at different locations. In such cases, the provider may
chose whether to advertise single or multiple PvD identities at all chose whether to advertise single or multiple PvD identities at all
or some of those networks as it suits their business needs. This or some of those networks as it suits their business needs. This
skipping to change at page 7, line 27 skipping to change at page 7, line 23
When multiple nodes are connected to the same link with one or more When multiple nodes are connected to the same link with one or more
explicit PvDs available, this architecture assumes that the explicit PvDs available, this architecture assumes that the
information about all available PvDs is made available by the information about all available PvDs is made available by the
networks to all the connected nodes. At the same time, connected networks to all the connected nodes. At the same time, connected
nodes may have different heuristics, policies and / or other nodes may have different heuristics, policies and / or other
settings, including their configured sets of trusted PvDs. This may settings, including their configured sets of trusted PvDs. This may
lead to different PvDs actually being used by different nodes for lead to different PvDs actually being used by different nodes for
their connections. their connections.
Possible extensions, whereby networks advertize different sets of Possible extensions, whereby networks advertise different sets of
PvDs to different connected nodes are out of scope of this document. PvDs to different connected nodes are out of scope of this document.
2.5. The Relationship to Dual-Stack Networks 2.5. The Relationship to Dual-Stack Networks
When applied to dual-stack networks, the PvD definition allows for When applied to dual-stack networks, the PvD definition allows for
multiple PvDs to be created whereby each PvD contains information multiple PvDs to be created whereby each PvD contains information
relevant to only one address family, or for a single PvD containing relevant to only one address family, or for a single PvD containing
information for multiple address families. This architecture information for multiple address families. This architecture
requires that accompanying design documents describing PvD-related requires that accompanying design documents describing PvD-related
protocol changes must support PvDs containing information from protocol changes must support PvDs containing information from
skipping to change at page 8, line 6 skipping to change at page 8, line 5
By default for implicit PvDs, PvD-aware nodes shall include multiple By default for implicit PvDs, PvD-aware nodes shall include multiple
IP families into a single implicit PvD created for an interface. At IP families into a single implicit PvD created for an interface. At
the time of writing, in dual-stack networks it appears to be common the time of writing, in dual-stack networks it appears to be common
practice for the configuration of both address families to be practice for the configuration of both address families to be
provided by a single source. provided by a single source.
A PvD-aware node that provides an API to use, enumerate and inspect A PvD-aware node that provides an API to use, enumerate and inspect
PvDs and / or their properties shall provide the ability to filter PvDs and / or their properties shall provide the ability to filter
PvDs and / or their properties by address family. PvDs and / or their properties by address family.
3. Conveying PvD information using DHCPv6 and Router Advertisements 3. Conveying PvD information
DHCPv6 and Router Advertisements are the two most common methods of DHCPv6 and Router Advertisements are the two most common methods of
configuring hosts. To support the architecture described in this configuring hosts. To support the architecture described in this
document, these protocols would need to be extended to convey document, these protocols would need to be extended to convey
explicit PvD information. The following sections describe topic explicit PvD information. The following sections describe topic
which must be considered before finalizing a mechanism to augment which must be considered before finalizing a mechanism to augment
DHCPv6 and RAs with PvD information. DHCPv6 and RAs with PvD information.
3.1. Separate Messages or One Message? 3.1. Separate Messages or One Message?
skipping to change at page 8, line 29 skipping to change at page 8, line 28
this information: One way is to send information from each different this information: One way is to send information from each different
provisioning domain in separate messages. The second method is provisioning domain in separate messages. The second method is
combining the information from multiple PvDs into a single message. combining the information from multiple PvDs into a single message.
The latter method has the advantage of being more efficient but could The latter method has the advantage of being more efficient but could
have problems with to authentication and authorization, as well as have problems with to authentication and authorization, as well as
potential issues with accommodating information not tagged with any potential issues with accommodating information not tagged with any
PvD information. PvD information.
3.2. Securing PvD Information 3.2. Securing PvD Information
DHCPv6 and RAs both provide some form of authentication to ensure the DHCPv6 [RFC3315] and RAs [RFC3971] both provide some form of
identity of the source as well as the integrity of the secured authentication to ensure the identity of the source as well as the
message content. While this is useful, determining authenticity does integrity of the secured message content. While this is useful,
not tell a node whether the configuration source is actually allowed determining authenticity does not tell a node whether the
to provide information from a given PvD. To resolve this, there must configuration source is actually allowed to provide information from
be a mechanism for the PvD owner to attach some form of authorization a given PvD. To resolve this, there must be a mechanism for the PvD
token or signature to the configuration information that is owner to attach some form of authorization token or signature to the
delivered. configuration information that is delivered.
3.3. Backward Compatibility 3.3. Backward Compatibility
The extensions to RAs and DHCPv6 should be defined in such a manner The extensions to RAs and DHCPv6 should be defined in such a manner
than unmodified hosts (i.e. hosts not aware of PvDs) will continue than unmodified hosts (i.e., hosts not aware of PvDs) will continue
to function as well as they did prior to PvD information being added. to function as well as they did prior to PvD information being added.
This could imply that some information may need to be duplicated in This could imply that some information may need to be duplicated in
order to be conveyed to legacy hosts. Similarly, PvD aware hosts order to be conveyed to legacy hosts. Similarly, PvD aware hosts
need to be able to correctly utiilize legacy configuration sources need to be able to correctly utilize legacy configuration sources
which do not provide PvD information. There are also several which do not provide PvD information. There are also several
initiatives that are aimed at adding some form of additional initiatives that are aimed at adding some form of additional
information to prefixes [I-D.bhandari-dhc-class-based-prefix] and information to prefixes [I-D.bhandari-dhc-class-based-prefix] and
[I-D.korhonen-dmm-prefix-properties] and any new mechanism should try [I-D.korhonen-dmm-prefix-properties] and any new mechanism should try
to consider co-existence with such deployed mechanisms. to consider co-existence with such deployed mechanisms.
3.4. Retracting / Updating PvD Information 3.4. Retracting / Updating PvD Information
After PvD information is provisioned to a host, it may become After PvD information is provisioned to a host, it may become
outdated or superseded by updated information before the hosts would outdated or superseded by updated information before the hosts would
normally request updates. To resolve this requires that the normally request updates. To resolve this requires that the
skipping to change at page 10, line 6 skipping to change at page 10, line 6
PvD aware mobile node will treat the mobile network as an explicit PvD aware mobile node will treat the mobile network as an explicit
PvD. Conversely, the legacy Wi-Fi network may not explicitly PvD. Conversely, the legacy Wi-Fi network may not explicitly
communicate PvD information to the mobile node. The PvD aware mobile communicate PvD information to the mobile node. The PvD aware mobile
node will associate network configuration for the Wi-Fi network with node will associate network configuration for the Wi-Fi network with
an implicit PvD in this case. an implicit PvD in this case.
The following diagram illustrates the use of different PvDs in this The following diagram illustrates the use of different PvDs in this
scenario: scenario:
<----------- Wi-Fi 'Internet' PvD -------> <----------- Wi-Fi 'Internet' PvD ------->
+--------+ +---------+
| +----+ | +----+ _ __ _ _ | +-----+ | +-----+ _ __ _ _
| |WiFi| | | | ( ` ) ( ` )_ | |Wi-Fi| | | | ( ` ) ( ` )_
| |-IF +-|----+ |--------------------------( `) | |-IF + |----+ |---------------------------( `)
| | | | |WiFi| ( ) (_ Internet _) | | | | |Wi-Fi| ( ) ( Internet )
| +----+ | | AP | ( ) `- __ _) - | +-----+ | | AP | ( ) ( )
| | | | ( Service ) | | | | ( Service ) ( )
| | +----+ ( Provider's ) | | +-----+ ( Provider's ) ( )
| | ( Networks - | | ( Networks - ( )
| +----+ | `_ ) _ _ | +----+ | `_ ) ( )
| |CELL| | ( ) ( ` )_ | |CELL| | ( ) ( )
| |-IF +-|-------------------------------------( `) | |-IF +--|-------------------------------------( )
| | | | (_ __) (_ Internet _) | | | | (_ __) (_ _)
| +----+ | `- -- `- __ _) - | +----+ | `- -- `- __ _) -
+--------+ +---------+
<------- Mobile 'Internet' PvD -----------> <------- Mobile 'Internet' PvD ----------->
An example of PvD use with Wi-Fi and mobile interfaces. An example of PvD use with Wi-Fi and mobile interfaces.
4.2. A Node with a VPN Connection 4.2. A Node with a VPN Connection
If the node has established a VPN connection, zero or more (typically If the node has established a VPN connection, zero or more (typically
one) additional PvD(s) will be created. These may be implicit or one) additional PvD(s) will be created. These may be implicit or
explicit. The routing to IP addresses reachable within this PvD will explicit. The routing to IP addresses reachable within this PvD will
be set up via the VPN connection, and the routing of packets to be set up via the VPN connection, and the routing of packets to
skipping to change at page 12, line 29 skipping to change at page 12, line 37
o Construction of a PvD in its entirety (analogous to statically o Construction of a PvD in its entirety (analogous to statically
configuring IP on an interface) configuring IP on an interface)
o Supplementing some, or all learned PvDs with particular o Supplementing some, or all learned PvDs with particular
configuration elements configuration elements
o Merging of information from different PvDs (if this is explicitly o Merging of information from different PvDs (if this is explicitly
allowed by policy) allowed by policy)
As an example, a node administrator could inject a DNS server which As an example, a node administrator could configure the node to use a
is not ISP-specific into PvDs for use on any of the networks that the specific DNS resolver on a particular interface, or for a particular
node could attach to. Such creation / augmentation of PvD(s) could named PvD. In the case of a per-interface DNS resolver, this might
be static or dynamic. The specific mechanism(s) for implementing override or augment the DNS resolver configuration for PvDs that are
this are outside of scope of this document. discovered on that interface. Such creation/augmentation of PvD(s)
could be static or dynamic. The specific mechanism(s) for
implementing this are outside of scope of this document. Such a
merging or overriding of DNS resolver configuration might be contrary
to the policy that applies to a special-purpose connection, such as
for example those discussed in Section 5.2.1 and Section 5.2.4. In
such cases, either the special-purpose connection should not be used,
or the merging/overriding should not be performed.
5.2. Consistent use of PvDs for Network Connections 5.2. Consistent use of PvDs for Network Connections
PvDs enable PvD-aware nodes to consistently use the correct set of PvDs enable PvD-aware nodes to consistently use the correct set of
configuration elements to serve specific network requests from configuration elements to serve specific network requests from
beginning to end. This section provides examples of such use. beginning to end. This section provides examples of such use.
5.2.1. Name Resolution 5.2.1. Name Resolution
When a PvD-aware node needs to resolve the name of the destination When a PvD-aware node needs to resolve the name of the destination
for use by a connection request, the node could use one, or multiple for use by a connection request, the node could use one, or multiple
PvDs for a given name lookup. PvDs for a given name lookup.
The node shall chose a single PvD if, for example, the node policy The node shall chose a single PvD if, for example, the node policy
required the use of a particular PvD for a specific purpose (e.g. to required the use of a particular PvD for a specific purpose (e.g., to
download an MMS message using a specific APN over a cellular download an MMS message using a specific APN over a cellular
connection). To make this selection, the node could use a match connection or to direct traffic of enterprise applications to a VPN
between the PvD DNS suffix and an FQDN which is being resolved or connection to the enterprise network). To make this selection, the
match of PvD ID, as determined by the node policy. node could use a match between the PvD DNS suffix and an FQDN which
is being resolved or match of PvD ID, as determined by the node
policy.
The node may pick multiple PvDs, if for example, the PvDs are for The node may pick multiple PvDs, if for example, the PvDs are for
general purpose Internet connectivity, and the node is attempting to general purpose Internet connectivity, and the node is attempting to
maximize the probability of connectivity similar to the Happy maximize the probability of connectivity similar to the Happy
Eyeballs [RFC6555] approach. In this case, the node could perform Eyeballs [RFC6555] approach. In this case, the node could perform
DNS lookups in parallel, or in sequence. Alternatively, the node may DNS lookups in parallel, or in sequence. Alternatively, the node may
use only one PvD for the lookup, based on the PvD connectivity use only one PvD for the lookup, based on the PvD connectivity
properties, user configuration of preferred Internet PvD, etc. properties, user configuration of preferred Internet PvD, etc.
If an application implements an API that provides a way of explicitly If an application implements an API that provides a way of explicitly
skipping to change at page 13, line 44 skipping to change at page 14, line 13
connections are performed consistently within their corresponding connections are performed consistently within their corresponding
PvD(s). PvD(s).
5.2.2. Next-hop and Source Address Selection 5.2.2. Next-hop and Source Address Selection
For the purpose of this example, let us assume that the preceding For the purpose of this example, let us assume that the preceding
name lookup succeeded in a particular PvD. For each obtained name lookup succeeded in a particular PvD. For each obtained
destination address, the node shall perform a next-hop lookup among destination address, the node shall perform a next-hop lookup among
routers associated with that PvD. As an example, the node could routers associated with that PvD. As an example, the node could
determine such associations via matching the source address prefixes/ determine such associations via matching the source address prefixes/
specific routes advertized by the router against known PvDs, or specific routes advertised by the router against known PvDs, or
receiving an explicit PvD affiliation advertized through a new Router receiving an explicit PvD affiliation advertised through a new Router
Discovery [RFC4861] option. Discovery [RFC4861] option.
For each destination, once the best next-hop is found, the node For each destination, once the best next-hop is found, the node
selects the best source address according to rules defined in selects the best source address according to rules defined in
[RFC6724], but with the constraint that the source address must [RFC6724], but with the constraint that the source address must
belong to a range associated with the used PvD. If needed, the node belong to a range associated with the used PvD. If needed, the node
would use prefix policy from the same PvD for selecting the best would use prefix policy from the same PvD for selecting the best
source address from multiple candidates. source address from multiple candidates.
When destination / source pairs are identified, they are sorted using When destination / source pairs are identified, they are sorted using
skipping to change at page 15, line 29 skipping to change at page 15, line 40
For APIs/protocols that support multiple IP traffic flows associated For APIs/protocols that support multiple IP traffic flows associated
with a single transport API connection object (for example, multi with a single transport API connection object (for example, multi
path TCP), the processing rules may be adjusted accordingly. path TCP), the processing rules may be adjusted accordingly.
5.2.3.1.2. Connectionless APIs 5.2.3.1.2. Connectionless APIs
For connectionless APIs, the host should provide an API that PvD- For connectionless APIs, the host should provide an API that PvD-
aware applications can use to query the PvD associated with the aware applications can use to query the PvD associated with the
packet. For outgoing traffic on this transport API object, the OS packet. For outgoing traffic on this transport API object, the OS
should use the selected outgoing PvDs, determined as described above. should use the selected outgoing PvDs, determined as described in
Section 5.2.1 and Section 5.2.2.
5.2.4. Enforcement of Security Policies 5.2.4. Enforcement of Security Policies
By themselves, PvDs do not define, and cannot be used for By themselves, PvDs do not define, and cannot be used for
communication of, security policies. When implemented in a network, communication of, security policies. When implemented in a network,
this architecture provides the host with information about connected this architecture provides the host with information about connected
networks. The actual behavior of the host then depends on the host's networks. The actual behavior of the host then depends on the host's
policies (provisioned through mechanisms out of scope of this policies (provisioned through mechanisms out of scope of this
document), applied taking received PvD information into account. In document), applied taking received PvD information into account. In
some scenarios, e.g. a VPN, such policies could require the host to some scenarios, e.g., a VPN, such policies could require the host to
use only a particular VPN PvD for some / all of the application's use only a particular VPN PvD for some / all of the application's
traffic (VPN 'disable split tunneling' also known as 'force traffic (VPN 'disable split tunneling' also known as 'force
tunneling' behavior), or apply such restrictions only to selected tunneling' behavior), or apply such restrictions only to selected
applications and allow the simultaneous use of the VPN PvD together applications and allow the simultaneous use of the VPN PvD together
with the other connected PvDs by the other or all applications (VPN with the other connected PvDs by the other or all applications (VPN
'split tunneling' behavior). 'split tunneling' behavior).
5.3. Connectivity Tests 5.3. Connectivity Tests
Although some PvDs may appear as valid candidates for PvD selection Although some PvDs may appear as valid candidates for PvD selection
(e.g. good link quality, consistent connection parameters, etc.), (e.g., good link quality, consistent connection parameters, etc.),
they may provide limited or no connectivity to the desired network or they may provide limited or no connectivity to the desired network or
the Internet. For example, some PvDs provide limited IP connectivity the Internet. For example, some PvDs provide limited IP connectivity
(e.g., scoped to the link or to the access network), but require the (e.g., scoped to the link or to the access network), but require the
node to authenticate through a web portal to get full access to the node to authenticate through a web portal to get full access to the
Internet. This may be more likely to happen for PvDs which are not Internet. This may be more likely to happen for PvDs which are not
trusted by a given PvD-aware node. trusted by a given PvD-aware node.
An attempt to use such a PvD may lead to limited network connectivity An attempt to use such a PvD may lead to limited network connectivity
or application connection failures. To prevent the latter, a PvD- or application connection failures. To prevent the latter, a PvD-
aware node may perform a connectivity test for the PvD before using aware node may perform a connectivity test for the PvD before using
it to serve application network connection requests. In current it to serve application network connection requests. In current
implementations, some nodes already implement this e.g., by trying to implementations, some nodes already implement this e.g., by trying to
reach a dedicated web server (see [RFC6419]). reach a dedicated web server (see [RFC6419]).
Section 5.2 describes how a PvD-aware node shall maintain and use Section 5.2 describes how a PvD-aware node shall maintain and use
multiple PvDs separately. The PvD-aware node shall perform a multiple PvDs separately. The PvD-aware node shall perform a
connectivity test and, only after validation of the PvD, consider connectivity test and, only after validation of the PvD, consider
using it to serve application connections requests. Ongoing using it to serve application connections requests. Ongoing
connectivity tests are also required, since during the IP session, connectivity tests are also required, since during the IP session,
the end-to-end connectivity could be disrupted for various reasons the end-to-end connectivity could be disrupted for various reasons
(e.g. L2 problems, IP QoS issues); hence, a connectivity monitoring (e.g., L2 problems, IP QoS issues); hence, a connectivity monitoring
function is needed to check the connectivity status and remove the function is needed to check the connectivity status and remove the
PvD from the set of usable PvDs if necessary. PvD from the set of usable PvDs if necessary.
There may be cases where a connectivity test for PvD selection may There may be cases where a connectivity test for PvD selection may
not be appropriate and should be complemented, or replaced, by PvD not be appropriate and should be complemented, or replaced, by PvD
selection based on other factors. For example, this could be selection based on other factors. For example, this could be
realized by leveraging some 3GPP and IEEE mechanisms, which would realized by leveraging some 3GPP and IEEE mechanisms, which would
allow the exposure of some PvD characteristics to the node (e.g. allow the exposure of some PvD characteristics to the node (e.g.,
3GPP Access Network Discovery and Selection Function (ANDSF) 3GPP Access Network Discovery and Selection Function (ANDSF)
[TS23402], IEEE 802.11u [IEEE802.11u]/ANQP). [TS23402], IEEE 802.11u [IEEE802.11u]/ANQP).
5.4. Relationship to Interface Management and Connection Managers 5.4. Relationship to Interface Management and Connection Managers
Current devices, such as mobile handsets make use of proprietary Current devices, such as mobile handsets make use of proprietary
mechanisms and custom applications to manage connectivity in mechanisms and custom applications to manage connectivity in
environments with multiple interfaces and multiple sets of network environments with multiple interfaces and multiple sets of network
configuration. These mechanisms or applications are commonly known configuration. These mechanisms or applications are commonly known
as connection managers [RFC6419]. as connection managers [RFC6419].
Connection managers sometimes rely on policy servers to allow a node Connection managers sometimes rely on policy servers to allow a node
that is connected to multiple networks to perform network selection. that is connected to multiple networks to perform network selection.
They can also make use of routing guidance from the network (e.g. They can also make use of routing guidance from the network (e.g.,
3GPP ANDSF [TS23402]). Although connection managers solve some 3GPP ANDSF [TS23402]). Although connection managers solve some
connectivity problems, they rarely address network selection problems connectivity problems, they rarely address network selection problems
in a comprehensive manner. With proprietary solutions, it is in a comprehensive manner. With proprietary solutions, it is
challenging to present coherent behavior to the end user of the challenging to present coherent behavior to the end user of the
device, as different platforms present different behaviors even when device, as different platforms present different behaviors even when
connected to the same network, with the same type of interface, and connected to the same network, with the same type of interface, and
for the same purpose. The architecture described in this document for the same purpose. The architecture described in this document
should improve the hosts behavior by providing the hosts with tools should improve the hosts behavior by providing the hosts with tools
and guidance to make informed network selection decisions. and guidance to make informed network selection decisions.
skipping to change at page 18, line 9 skipping to change at page 18, line 27
7.1. Untrusted PvDs 7.1. Untrusted PvDs
Implicit and explicit PvDs for which no trust relationship exists are Implicit and explicit PvDs for which no trust relationship exists are
considered untrusted. Only PvDs which meet the requirements in considered untrusted. Only PvDs which meet the requirements in
Section 7.2 are trusted; any other PvD is untrusted. Section 7.2 are trusted; any other PvD is untrusted.
In order to avoid the various forms of misinformation that could In order to avoid the various forms of misinformation that could
occur when PvDs are untrusted, nodes that implement PvD separation occur when PvDs are untrusted, nodes that implement PvD separation
cannot assume that two explicit PvDs with the same identifier are cannot assume that two explicit PvDs with the same identifier are
actually the same PvD. A node that makes this assumption will be actually the same PvD. A node that makes this assumption will be
vulnerable to attacks where, for example, an open Wifi hotspot might vulnerable to attacks where, for example, an open Wi-Fi hotspot might
assert that it was part of another PvD and thereby attempt to draw assert that it was part of another PvD and thereby attempt to draw
traffic intended for that PvD onto its own network. traffic intended for that PvD onto its own network.
Since implicit PvD identifiers are synthesized by the node, this Since implicit PvD identifiers are synthesized by the node, this
issue cannot arise with implicit PvDs. issue cannot arise with implicit PvDs.
Mechanisms exist (for example, [RFC6731]) whereby a PvD can provide Mechanisms exist (for example, [RFC6731]) whereby a PvD can provide
configuration information that asserts special knowledge about the configuration information that asserts special knowledge about the
reachability of resources through that PvD. Such assertions cannot be reachability of resources through that PvD. Such assertions cannot be
validated unless the node has a trust relationship with the PvD; validated unless the node has a trust relationship with the PvD;
skipping to change at page 19, line 33 skipping to change at page 20, line 4
(denghui@chinamobile.com), Jouni Korhonen (jouni.nospam@gmail.com), (denghui@chinamobile.com), Jouni Korhonen (jouni.nospam@gmail.com),
Juan Carlos Zuniga (JuanCarlos.Zuniga@InterDigital.com), Konstantinos Juan Carlos Zuniga (JuanCarlos.Zuniga@InterDigital.com), Konstantinos
Pentikousis (k.pentikousis@huawei.com), Marc Blanchet Pentikousis (k.pentikousis@huawei.com), Marc Blanchet
(marc.blanchet@viagenie.ca), Margaret Wasserman (marc.blanchet@viagenie.ca), Margaret Wasserman
(margaretw42@gmail.com), Pierrick Seite (pierrick.seite@orange.com), (margaretw42@gmail.com), Pierrick Seite (pierrick.seite@orange.com),
Suresh Krishnan (suresh.krishnan@ericsson.com), Teemu Savolainen Suresh Krishnan (suresh.krishnan@ericsson.com), Teemu Savolainen
(teemu.savolainen@nokia.com), Ted Lemon (ted.lemon@nominum.com) and (teemu.savolainen@nokia.com), Ted Lemon (ted.lemon@nominum.com) and
Tim Chown (tjc@ecs.soton.ac.uk). Tim Chown (tjc@ecs.soton.ac.uk).
9. Acknowledgments 9. Acknowledgments
The authors would like to thank (in no specific order) Ian Farrer, The authors would like to thank (in no specific order) Ian Farrer,
Markus Stenberg and Mikael Abrahamsson for their review and comments. Markus Stenberg and Mikael Abrahamsson for their review and comments.
10. IANA Considerations 10. IANA Considerations
This memo does not include any IANA requests. This memo does not include any IANA requests.
11. Security Considerations 11. Security Considerations
There are at least three different forms of attacks that can be There are at least three different forms of attacks that can be
performed using configuration sources that support multiple performed using configuration sources that support multiple
provisioning domains. provisioning domains.
Tampering with provided configuration information: An attacker may Tampering with provided configuration information: An attacker may
attempt to modify information provided inside the PvD container attempt to modify information provided inside the PvD container
option. These attacks can easily be prevented by using message option. These attacks can easily be prevented by using message
integrity features provided by the underlying protocol used to integrity features provided by the underlying protocol used to
carry the configuration information. E.g. SEND [RFC3971] would carry the configuration information. E.g., SEND [RFC3971] would
detect any form of tampering with the RA contents and the DHCPv6 detect any form of tampering with the RA contents and the DHCPv6
[RFC3315] AUTH option that would detect any form of tampering with [RFC3315] AUTH option that would detect any form of tampering with
the DHCPv6 message contents. This attack can also be performed by the DHCPv6 message contents. This attack can also be performed by
a compromised configuration source by modifying information inside a compromised configuration source by modifying information inside
a specific PvD, in which case the mitigations proposed in the next a specific PvD, in which case the mitigations proposed in the next
subsection may be helpful. subsection may be helpful.
Rogue configuration source: A compromised configuration source, such Rogue configuration source: A compromised configuration source, such
as a router or a DHCPv6 server, may advertise information about as a router or a DHCPv6 server, may advertise information about
PvDs that it is not authorized to advertise. E.g., a coffee shop PvDs that it is not authorized to advertise. E.g., a coffee shop
WLAN may advertise configuration information purporting to be from WLAN may advertise configuration information purporting to be from
an enterprise and may try to attract enterprise related traffic. an enterprise and may try to attract enterprise related traffic.
This may also occur accidentally if two sites choose the same This may also occur accidentally if two sites choose the same
identifier (e.g., "linsky"). identifier (e.g., "linsky").
In order to detect and prevent this, the client must be able to In order to detect and prevent this, the client must be able to
authenticate the identifier provided by the network. This means authenticate the identifier provided by the network. This means
that the client must have configuration information that maps the that the client must have configuration information that maps the
PvD identifier to an authenticatable identity, and must be able to PvD identifier to an identity, and must be able to authenticate
authenticate that identity. that identity.
In addition, the network must provide information the client can In addition, the network must provide information the client can
use to authenticate the identity. This could take the form of a use to authenticate the identity. This could take the form of a
PKI-based or DNSSEC-based trust anchor, or a key remembered from a PKI-based or DNSSEC-based trust anchor, or a key remembered from a
previous leap-of-faith authentication of the identifier. previous leap-of-faith authentication of the identifier.
Because the PvD-specific information may come to the network Because the PvD-specific information may come to the network
infrastructure with which the client is actually communicating infrastructure with which the client is actually communicating
from some upstream provider, it is necessary in this case that the from some upstream provider, it is necessary in this case that the
PvD container and its contents be relayed to the client unchanged, PvD container and its contents be relayed to the client unchanged,
skipping to change at page 20, line 51 skipping to change at page 21, line 14
Replay attacks: A compromised configuration source or an on-link Replay attacks: A compromised configuration source or an on-link
attacker may try to capture advertised configuration information attacker may try to capture advertised configuration information
and replay it on a different link, or at a future point in time. and replay it on a different link, or at a future point in time.
This can be avoided by including a replay protection mechanism This can be avoided by including a replay protection mechanism
such as a timestamp or a nonce inside the PvD container to ensure such as a timestamp or a nonce inside the PvD container to ensure
the validity of the provided information. the validity of the provided information.
12. References 12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References
[I-D.bhandari-dhc-class-based-prefix] [I-D.bhandari-dhc-class-based-prefix]
Systems, C., Halwasia, G., Gundavelli, S., Deng, H., Systems, C., Halwasia, G., Gundavelli, S., Deng, H.,
Thiebaut, L., Korhonen, J. and I. Farrer, "DHCPv6 class Thiebaut, L., Korhonen, J. and I. Farrer, "DHCPv6 class
based prefix", Internet-Draft draft-bhandari-dhc-class- based prefix", Internet-Draft draft-bhandari-dhc-class-
based-prefix-05, July 2013. based-prefix-05, July 2013.
[I-D.korhonen-dmm-prefix-properties] [I-D.korhonen-dmm-prefix-properties]
Korhonen, J., Patil, B., Gundavelli, S., Seite, P. and D. Korhonen, J., Patil, B., Gundavelli, S., Seite, P. and D.
Liu, "IPv6 Prefix Mobility Management Properties", Liu, "IPv6 Prefix Mobility Management Properties",
Internet-Draft draft-korhonen-dmm-prefix-properties-03, Internet-Draft draft-korhonen-dmm-prefix-properties-03,
 End of changes. 46 change blocks. 
103 lines changed or deleted 109 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/