< draft-anipko-mif-mpvd-arch-01.txt   draft-anipko-mif-mpvd-arch-02.txt >
MIF Working Group D. Anipko MIF Working Group D. Anipko
Internet-Draft Microsoft Corporation Internet-Draft Microsoft Corporation
Intended status: Informational July 23, 2013 Intended status: Informational July 26, 2013
Expires: January 22, 2014 Expires: January 25, 2014
Multiple Provisioning Domain Architecture Multiple Provisioning Domain Architecture
draft-anipko-mif-mpvd-arch-01 draft-anipko-mif-mpvd-arch-02
Abstract Abstract
This document is a product of the work of MIF architecture design This document is a product of the work of MIF architecture design
team. It outlines a solution framework for some of the issues, team. It outlines a solution framework for some of the issues,
experienced by nodes that can be attached to multiple networks. The experienced by nodes that can be attached to multiple networks. The
framework defines the notion of a Provisioning Domain (PVD) - a framework defines the notion of a Provisioning Domain (PVD) - a
consistent set of network configuration information, and PVD-aware consistent set of network configuration information, and PVD-aware
nodes - nodes which learn PVDs from the attached network(s) and/or nodes - nodes which learn PVDs from the attached network(s) and/or
other sources and manage and use multiple PVDs for connectivity other sources and manage and use multiple PVDs for connectivity
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 January 22, 2014. This Internet-Draft will expire on January 25, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 14 skipping to change at page 2, line 13
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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Definitions and types of PVDs . . . . . . . . . . . . . . . . 3 2. Definitions and types of PVDs . . . . . . . . . . . . . . . . 3
2.1. Explicit and implicit PVDs . . . . . . . . . . . . . . . . 4 2.1. Explicit and implicit PVDs . . . . . . . . . . . . . . . . 4
2.2. Relationship between PVDs and interfaces . . . . . . . . . 5 2.2. Incremental deployment of explicit PVDs . . . . . . . . . 5
2.3. PVD identity/naming . . . . . . . . . . . . . . . . . . . 5 2.3. Relationship between PVDs and interfaces . . . . . . . . . 5
2.4. Relationship to dual-stack networks . . . . . . . . . . . 5 2.4. PVD identity/naming . . . . . . . . . . . . . . . . . . . 6
2.5. Elements of PVD . . . . . . . . . . . . . . . . . . . . . 6 2.5. Relationship to dual-stack networks . . . . . . . . . . . 6
3. Example network configurations and number of PVDs . . . . . . 6 2.6. Elements of PVD . . . . . . . . . . . . . . . . . . . . . 7
4. Reference model of PVD-aware node . . . . . . . . . . . . . . 6 3. Example network configurations and number of PVDs . . . . . . 7
4.1. Constructions and maintenance of separate PVDs . . . . . . 6 4. Reference model of PVD-aware node . . . . . . . . . . . . . . 7
4.2. Consistent use of PVDs for network connections . . . . . . 6 4.1. Constructions and maintenance of separate PVDs . . . . . . 7
4.2.1. Name resolution . . . . . . . . . . . . . . . . . . . 6 4.2. Consistent use of PVDs for network connections . . . . . . 7
4.2.2. Next-hop and source address selection . . . . . . . . 7 4.2.1. Name resolution . . . . . . . . . . . . . . . . . . . 7
4.3. Connectivity tests . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Next-hop and source address selection . . . . . . . . 8
4.4. Relationship to interface management and connection manager 7 4.3. Connectivity tests . . . . . . . . . . . . . . . . . . . . 8
5. PVD support in APIs . . . . . . . . . . . . . . . . . . . . . 7 4.4. Relationship to interface management and connection manager 8
5.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. PVD support in APIs . . . . . . . . . . . . . . . . . . . . . 8
5.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 9
6. PVD-aware nodes trust to PVDs . . . . . . . . . . . . . . . . 8 5.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Untrusted PVDs . . . . . . . . . . . . . . . . . . . . . . 8 6. PVD-aware nodes trust to PVDs . . . . . . . . . . . . . . . . 9
6.2. Trusted PVDs . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Untrusted PVDs . . . . . . . . . . . . . . . . . . . . . . 9
6.2.1. Authenticated PVDs . . . . . . . . . . . . . . . . . . 9 6.2. Trusted PVDs . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.2. PVDs trusted by attachment . . . . . . . . . . . . . . 9 6.2.1. Authenticated PVDs . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6.2.2. PVDs trusted by attachment . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Nodes attached to multiple networks may encounter problems due to Nodes attached to multiple networks may encounter problems due to
conflict of the networks configuration and/or simultaneous use of conflict of the networks configuration and/or simultaneous use of
the multiple available networks. While existing implementations the multiple available networks. While existing implementations
apply various techniques ([RFC6419]) to tackle such problems, in many apply various techniques ([RFC6419]) to tackle such problems, in many
cases the issues may still appear. The MIF problem statement cases the issues may still appear. The MIF problem statement
document [RFC6418] describes the general landscape as well as document [RFC6418] describes the general landscape as well as
discusses many specific issues details. discusses many specific issues and scenarios details, and are not
listed in this document.
Across the layers, problems enumerated in [RFC6418] can be grouped Across the layers, problems enumerated in [RFC6418] can be grouped
into 3 categories: 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 2. Inappropriate mixed use of configuration elements, associated
with different networks, in the course of a particular network with different networks, in the course of a particular network
activity / connection. activity / connection.
skipping to change at page 4, line 11 skipping to change at page 4, line 11
one provisioning domain being present on a single link. In some one provisioning domain being present on a single link. In some
scenarios, it is also possible for elements of the same domain to be scenarios, it is also possible for elements of the same domain to be
present on multiple links. present on multiple links.
Typical examples of information in a provisioning domain, learned Typical examples of information in a provisioning domain, learned
from the network, are: source address prefixes, to be used by from the network, are: source address prefixes, to be used by
connections within the provisioning domain, IP address of DNS server, connections within the provisioning domain, IP address of DNS server,
name of HTTP proxy server if available, DNS suffixes associated with name of HTTP proxy server if available, DNS suffixes associated with
the network etc. the network etc.
In some cases, other sources, such as e.g., node local policy, user It is assumed that normally, configuration information contained in a
input or other out of band mechanisms may be used to either construct single PVD, shall be sufficient for a node to fulfill a network
a PVD entirely (analogously to static IP configuration of an connection request by an application, and hence there should be no
need to attempt to merge information across different PVDs.
Nevertheless, even when a PVD lack some parts of the configuration,
merging of information from different PVD(s) shall not be done
automatically, since typically it would lead to issues described in
[RFC6418].
A node may use other sources, such as e.g., node local policy, user
input or other mechanisms, not defined by IETF, to either construct a
PVD entirely (analogously to static IP configuration of an
interface), or supplement with particular elements all or some PVDs interface), or supplement with particular elements all or some PVDs
learned from the network. learned from the network, or potentially merge information from
different PVDs, if such merge is known to the node to be safe, based
on explicit policies.
As an example, node administrator could inject a not ISP-specific DNS As an example, node administrator could inject a not ISP-specific DNS
server into PVDs for any of the networks the node could become server into PVDs for any of the networks the node could become
attached to. Such creation / augmentation of PVD(s) could be static attached to. Such creation / augmentation of PVD(s) could be static
or dynamic. The particular implementation mechanisms are outside of or dynamic. The particular implementation mechanisms are outside of
the scope of this document. the scope of this document.
Link-specific and/or vendor-proprietary mechanisms for discovery of
PVD information, different from the IETF-defined mechanisms, can be
used by the nodes separately from or together with IETF-defined
mechanisms, as long as they allow to discover necessary elements of
the PVD(s). In all cases, by default nodes must ensure that the
lifetime of all dynamically discovered PVD configuration is
appropriately limited by the relevant events - for example, if an
interface media state change was indicated, the previously discovered
information may no longer be valid and needs to be re-discovered or
confirmed.
PVD-aware node: a node that supports association of network PVD-aware node: a node that supports association of network
configuration information into PVDs, and using the resultant PVDs to configuration information into PVDs, and using the resultant PVDs to
serve requests for network connections in a way, consistent with serve requests for network connections in ways, consistent with
recommendations of this architecture. recommendations of this architecture.
2.1. Explicit and implicit PVDs 2.1. Explicit and implicit PVDs
A node may receive explicit information from the network and/or other A node may receive explicit information from the network and/or other
sources, about presence of PVDs and association of particular network sources, about presence of PVDs and association of particular network
information with a particular PVD. PVDs, constructed based on such information with a particular PVD. PVDs, constructed based on such
information, are referred to in this document as "explicit". information, are referred to in this document as "explicit".
Protocol changes/extensions will likely be required to support the Protocol changes/extensions will likely be required to support the
explicit PVDs. As an example, one could think of one or several DHCP explicit PVDs by IETF-defined mechanisms. As an example, one could
options, defining a PVD identity and elements. A different approach think of one or several DHCP options, carrying PVD identity and / or
could be to introduce a DHCP option, which only introduces identity its elements. A different approach could be to introduce a DHCP
of a PVD, while the association of network information elements with option, which only carries identity of a PVD, while the association
that identity, is implemented by the respective protocols - such as of network information elements with that identity, is implemented by
e.g., with a Router Discovery [RFC4861] option declaring association the respective protocols - such as e.g., with a Router Discovery
of an address range with a particular PVD. [RFC4861] option associating an address range with a PVD.
Specific, existing or new, features of networking protocols to enable Specific, existing or new, features of networking protocols to enable
delivery of PVD identity and association with various network delivery of PVD identity and association with various network
information elements will be defined in companion design documents. information elements will be defined in companion design documents.
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.
When connected to networks, which don't advertise explicit PVD
information, PVD-aware shall automatically create separate PVDs for
configuration received on different interfaces. Such PVDs are
referred to in this document as "implicit".
2.2. Incremental deployment of explicit PVDs
It is likely that for a long time there may be networks which do not 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 advertise explicit PVD information, since deployment of any new
features in networking protocols is a relatively slow process. When features in networking protocols is a relatively slow process. In
connected to such networks, PVD-aware nodes may still provide such environments, PVD-aware nodes may still provide benefits to
benefits to their users, compared to non-PVD aware nodes, by creating their users, compared to non-PVD aware nodes, by using network
separate PVDs for configuration received on different interfaces. information from different interfaces separately and consistently to
Such PVDs are referred to in this document as "implicit". This serve network connection requests.
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 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 link the interface is attached to, and only some of the networks
advertize PVD information, the PVD-aware node shall create explicit advertise PVD information, the PVD-aware node shall create explicit
PVDs based on explicitly learned PVD information, and associate the PVDs based on explicitly learned PVD information, and associate the
rest of the configuration with an implicit PVD created for that rest of the configuration with an implicit PVD created for that
interface. interface.
It shall be possible for networks to communicate that some of their 2.3. Relationship between PVDs and interfaces
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 Implicit PVDs are limited to network configuration information
received on a single interface. Explicit PVDs, in practice will received on a single interface. Explicit PVDs, in practice will
often also be scoped to a configuration related to a particular often also be scoped to a configuration related to a particular
interface, however per this architecture there is no such requirement interface, however per this architecture there is no such requirement
or limitation and as defined in this architecture, explicit PVDs may or limitation and as defined in this architecture, explicit PVDs may
include information related to more than one interfaces, if the node include information related to more than one interfaces, if the node
learns presence of the same PVD on those interfaces and the learns presence of the same PVD on those interfaces and the
authentication of the PVD ID meets the level required by the node authentication of the PVD ID meets the level required by the node
policy. policy.
2.3. PVD identity/naming 2.4. PVD identity/naming
For explicit PVDs, PVD ID (globally unique ID, that possibly is For explicit PVDs, PVD ID (globally unique ID, that possibly is
human-readable) is received as part of that information. For human-readable) is received as part of that information. For
implicit PVDs, the node assigns a locally generated globally unique implicit PVDs, the node assigns a locally generated globally unique
ID to each implicit PVD. ID to each implicit PVD.
PVD-aware node may use these IDs to choose a PVD with matching ID for PVD-aware node may use these IDs to choose a PVD with matching ID for
special-purpose connection requests, in accordance with node policy special-purpose connection requests, in accordance with node policy
or choice by advanced applications, and/or to present human-readable or choice by advanced applications, and/or to present human-readable
IDs to the end-user for selection of Internet-connected PVDs. IDs to the end-user for selection of Internet-connected PVDs.
2.4. Relationship to dual-stack networks A single network provider may operate multiple networks, including
networks at different locations. In such cases, the provider may
chose whether to advertise single or multiple PVD identities at all
or some of those networks, as it suits their business needs. This
architecture doesn't impose specific requirements in this regard.
When multiple nodes are connected to the same link, where one or more
explicit PVDs are available, this architecture assumes that the
information about all available PVDs is advertized by the networks to
all the connected nodes. At the same time, the connected nodes may
have different heuristics, policies and/or other settings, including
configured set of their trusted PVDs, which may lead to different
PVDs actually being used by different nodes for their connections.
Possible extensions, where different sets of PVDs may be advertised
by the networks to different connected nodes, are out of scope for
this document.
2.5. 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, where each PVD contain information for multiple PVDs to be created, where each PVD contain information for
only one address family, or for a single PVD that contains only one address family, or for a single PVD that contains
information about multiple address families. This architecture information about multiple address families. This architecture
requires that accompanying design documents for accompanying protocol requires that accompanying design documents for accompanying protocol
changes must support PVDs containing information from multiple changes must support PVDs containing information from multiple
address families. PVD-aware nodes must be capable of dealing with address families. PVD-aware nodes must be capable of dealing with
both single-family and multi-family PVDs. both single-family and multi-family PVDs.
Nevertheless, for explicit PVDs, the choice of either of the For explicit PVDs, the choice of either of the approaches is a policy
approaches is a policy decision of a network administrator and/or decision of a network administrator and/or node user/administrator.
node user/administrator. Since some of the IP configuration Since some of the IP configuration information that can be learned
information that can be learned from the network can be applicable to from the network can be applicable to multiple address families (for
multiple address families (for instance DHCP address selection option instance DHCP address selection option [I-D.ietf-6man-addr-select-
[I-D.ietf-6man-addr-select-opt]), it is likely that dual-stack opt]), it is likely that dual-stack networks will deploy single PVDs
networks will deploy single PVDs for both address families. for both address families.
For implicit PVDs, by default PVD-aware nodes shall including For implicit PVDs, by default PVD-aware nodes shall including
multiple IP families into single implicit PVD created for an multiple IP families into single implicit PVD created for an
interface. interface. At the time of writing of this document in dual-stack
networks it appears to be a common practice for configuration of both
address families to be provided by a single source.
A PVD-aware node that provides API to use / enumerate / inspect PVDs A PVD-aware node that provides API to use / enumerate / inspect PVDs
and/or their properties shall provide ability to filter PVDs and/or and/or their properties shall provide ability to filter PVDs and/or
their properties by address family. their properties by address family.
2.5. Elements of PVD 2.6. Elements of PVD
3. Example network configurations and number of PVDs 3. Example network configurations and number of PVDs
4. Reference model of PVD-aware node 4. Reference model of PVD-aware node
4.1. Constructions and maintenance of separate PVDs 4.1. Constructions and maintenance of separate PVDs
4.2. Consistent use of PVDs for network connections 4.2. Consistent use of PVDs for network connections
PVDs enable PVD-aware nodes to use consistently a correct set of PVDs enable PVD-aware nodes to use consistently a correct set of
skipping to change at page 7, line 15 skipping to change at page 8, line 12
In either case, by default the node uses information obtained in a In either case, by default the node uses information obtained in a
name service lookup to establish connections only within the same PVD name service lookup to establish connections only within the same PVD
from which the lookup results were obtained. from which the lookup results were obtained.
For simplicity, when we say that name service lookup results were For simplicity, when we say that name service lookup results were
obtained from a PVD, what we mean is that the name service query was obtained from a PVD, what we mean is that the name service query was
issued against a name service the configuration of which is present issued against a name service the configuration of which is present
in a particular PVD. In that sense, the results are "from" that in a particular PVD. In that sense, the results are "from" that
particular PVD. particular PVD.
Some nodes may support transports and/or APIs, which provide an
abstraction of a single connection, aggregating multiple underlying
connections. MPTCP [RFC6182] is an example of such transport
protocol. For the connections provided by such transports/APIs, a
PVD-aware node may use different PVDs for servicing of that logical
connection, provided that all operations on the underlying
connections are done consistently within their corresponding PVD(s).
4.2.2. Next-hop and source address selection 4.2.2. Next-hop and source address selection
For the purpose of this discussion, let's assume the preceding name For the purpose of this discussion, let's assume the preceding name
lookup succeeded in a particular PVD. For each obtained destination lookup succeeded in a particular PVD. For each obtained destination
address, the node shall perform a next-hop lookup among routers, address, the node shall perform a next-hop lookup among routers,
associated with that PVD. As an example, such association could be associated with that PVD. As an example, such association could be
determined by the node via matching the source address prefixes/ determined by the node via matching the source address prefixes/
specific routes advertized by the router against known PVDs, or specific routes advertized by the router against known PVDs, or
receiving explicit PVD affiliation advertized through a new Router receiving explicit PVD affiliation advertized through a new Router
Discovery [RFC4861] option. Discovery [RFC4861] option.
skipping to change at page 7, line 47 skipping to change at page 9, line 4
4.3. Connectivity tests 4.3. Connectivity tests
4.4. Relationship to interface management and connection managers 4.4. Relationship to interface management and connection managers
5. PVD support in APIs 5. PVD support in APIs
In all cases changes in available PVDs must be somehow exposed, In all cases changes in available PVDs must be somehow exposed,
appropriately for each of the approaches. appropriately for each of the approaches.
5.1. Basic 5.1. Basic
Applications are not PVD-aware in any manner, and only submit Applications are not PVD-aware in any manner, and only submit
connection requests. The node performs PVD selection implicitly, connection requests. The node performs PVD selection implicitly,
without any otherwise applications participation, and based purely on without any otherwise applications participation, and based purely on
node-specific administrative policies and/or choices made by the user node-specific administrative policies and/or choices made by the user
in a user interface provided by the operating environment, not by the in a user interface provided by the operating environment, not by the
application. application.
As an example, such PVD selection can be done at the name service
lookup step, by using the relevant configuration elements, such as
e.g., those described in [RFC6731]. As another example, the PVD
selection could be done based on application identity or type (i.e.,
a node could always use a particular PVD for a VOIP application).
5.2. Intermediate 5.2. Intermediate
Applications indirectly participate in selection of PVD by specifying Applications indirectly participate in selection of PVD by specifying
hard requirements and soft preferences. The node performs PVD hard requirements and soft preferences. The node performs PVD
selection, based on applications inputs and policies and/or user selection, based on applications inputs and policies and/or user
preferences. Some / all properties of the resultant PVD may be preferences. Some / all properties of the resultant PVD may be
exposed to applications. exposed to applications.
5.3. Advanced 5.3. Advanced
PVDs are directly exposed to applications, for enumeration and PVDs are directly exposed to applications, for enumeration and
selection. Node polices and/or user choices, may still override the selection. Node polices and/or user choices, may still override the
skipping to change at page 10, line 14 skipping to change at page 11, line 33
[I-D.ietf-6man-addr-select-opt] [I-D.ietf-6man-addr-select-opt]
Matsumoto, A., Fujisaki, T. and T. Chown, "Distributing Matsumoto, A., Fujisaki, T. and T. Chown, "Distributing
Address Selection Policy using DHCPv6", Internet-Draft Address Selection Policy using DHCPv6", Internet-Draft
draft-ietf-6man-addr-select-opt-10, April 2013. draft-ietf-6man-addr-select-opt-10, April 2013.
[RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S. and J.
Iyengar, "Architectural Guidelines for Multipath TCP
Development", RFC 6182, March 2011.
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", RFC 6418, Provisioning Domains Problem Statement", RFC 6418,
November 2011. November 2011.
[RFC6419] Wasserman, M. and P. Seite, "Current Practices for [RFC6419] Wasserman, M. and P. Seite, "Current Practices for
Multiple-Interface Hosts", RFC 6419, November 2011. Multiple-Interface Hosts", RFC 6419, November 2011.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A. and T. Chown, [RFC6724] Thaler, D., Draves, R., Matsumoto, A. and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012. (IPv6)", RFC 6724, September 2012.
 End of changes. 25 change blocks. 
75 lines changed or deleted 141 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/