< draft-anipko-mif-mpvd-arch-02.txt   draft-anipko-mif-mpvd-arch-03.txt >
MIF Working Group D. Anipko MIF Working Group D. Anipko
Internet-Draft Microsoft Corporation Internet-Draft Microsoft Corporation
Intended status: Informational July 26, 2013 Intended status: Informational September 22, 2013
Expires: January 25, 2014 Expires: March 24, 2014
Multiple Provisioning Domain Architecture Multiple Provisioning Domain Architecture
draft-anipko-mif-mpvd-arch-02 draft-anipko-mif-mpvd-arch-03
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 25, 2014. This Internet-Draft will expire on March 24, 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
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 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 PVDs . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Incremental deployment of explicit PVDs . . . . . . . . . 5 2.2. Implicit PVDs and incremental adoption of the explicit PVDs 5
2.3. Relationship between PVDs and interfaces . . . . . . . . . 5 2.3. Relationship between PVDs and interfaces . . . . . . . . . 5
2.4. PVD identity/naming . . . . . . . . . . . . . . . . . . . 6 2.4. PVD identity/naming . . . . . . . . . . . . . . . . . . . 5
2.5. Relationship to dual-stack networks . . . . . . . . . . . 6 2.5. Relationship to dual-stack networks . . . . . . . . . . . 6
2.6. Elements of PVD . . . . . . . . . . . . . . . . . . . . . 7 2.6. Elements of PVD . . . . . . . . . . . . . . . . . . . . . 7
3. Example network configurations and number of PVDs . . . . . . 7 3. Example network configurations and number of PVDs . . . . . . 7
4. Reference model of PVD-aware node . . . . . . . . . . . . . . 7 4. Reference model of PVD-aware node . . . . . . . . . . . . . . 7
4.1. Constructions and maintenance of separate PVDs . . . . . . 7 4.1. Constructions and maintenance of separate PVDs . . . . . . 7
4.2. Consistent use of PVDs for network connections . . . . . . 7 4.2. Consistent use of PVDs for network connections . . . . . . 7
4.2.1. Name resolution . . . . . . . . . . . . . . . . . . . 7 4.2.1. Name resolution . . . . . . . . . . . . . . . . . . . 7
4.2.2. Next-hop and source address selection . . . . . . . . 8 4.2.2. Next-hop and source address selection . . . . . . . . 8
4.3. Connectivity tests . . . . . . . . . . . . . . . . . . . . 8 4.3. Connectivity tests . . . . . . . . . . . . . . . . . . . . 9
4.4. Relationship to interface management and connection manager 8 4.4. Relationship to interface management and connection manager 9
5. PVD support in APIs . . . . . . . . . . . . . . . . . . . . . 8 5. PVD support in APIs . . . . . . . . . . . . . . . . . . . . . 9
5.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. PVD-aware nodes trust to PVDs . . . . . . . . . . . . . . . . 9 6. PVD-aware nodes trust to PVDs . . . . . . . . . . . . . . . . 10
6.1. Untrusted PVDs . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Untrusted PVDs . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Trusted PVDs . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Trusted PVDs . . . . . . . . . . . . . . . . . . . . . . . 11
6.2.1. Authenticated PVDs . . . . . . . . . . . . . . . . . . 10 6.2.1. Authenticated PVDs . . . . . . . . . . . . . . . . . . 11
6.2.2. PVDs trusted by attachment . . . . . . . . . . . . . . 10 6.2.2. PVDs trusted by attachment . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
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 and scenarios details, and are not discusses many specific issues and scenarios details, and are not
skipping to change at page 4, line 11 skipping to change at page 4, line 12
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.
It is assumed that normally, configuration information contained in a
single PVD, shall be sufficient for a node to fulfill a network
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
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
server into PVDs for any of the networks the node could become
attached to. Such creation / augmentation of PVD(s) could be static
or dynamic. The particular implementation mechanisms are outside of
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 ways, 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 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 by IETF-defined mechanisms. As an example, one could explicit PVDs by IETF-defined mechanisms. As an example, one could
think of one or several DHCP options, carrying PVD identity and / or think of one or several DHCP options, carrying PVD identity and / or
its elements. A different approach could be to introduce a DHCP its elements. A different approach could be to introduce a DHCP
option, which only carries identity of a PVD, while the association option, which only carries identity of a PVD, while the association
of network information elements with that identity, is implemented by of network information elements with that identity, is implemented by
the respective protocols - such as e.g., with a Router Discovery the respective protocols - such as e.g., with a Router Discovery
[RFC4861] option associating an address range with a 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.
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.
It shall be possible for networks to communicate that some of their It shall be possible for networks to communicate that some of their
configuration elements could be used within a context of other configuration elements could be used within a context of other
networks/PVDs. Based on such declaration and their policies, PVD- networks/PVDs. Based on such declaration and their policies, PVD-
aware nodes may choose to inject such elements into some or all other aware nodes may choose to inject such elements into some or all other
PVDs they connect to. PVDs they connect to.
When connected to networks, which don't advertise explicit PVD In some network topologies, the network infrastructure elements may
information, PVD-aware shall automatically create separate PVDs for need to advertise multiple PVDs. The details of how this is done
configuration received on different interfaces. Such PVDs are generally will be defined in the individual companion design
referred to in this document as "implicit". documents. However, where different design choices are possible, the
choice that requires smaller number of packets shall be preferred for
efficiency.
2.2. Incremental deployment of explicit PVDs 2.2. Implicit PVDs and incremental adoption of the 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 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. In features in networking protocols is a relatively slow process.
such environments, PVD-aware nodes may still provide benefits to
When connected to networks, which don't advertise explicit PVD
information, PVD-aware shall automatically create separate PVDs for
configuration received on multiple interfaces. Such PVDs are
referred to in this document as "implicit".
With implicit PVDs,PVD-aware nodes may still provide benefits to
their users, compared to non-PVD aware nodes, by using network their users, compared to non-PVD aware nodes, by using network
information from different interfaces separately and consistently to information from different interfaces separately and consistently to
serve network connection requests. serve network connection requests, following best practices described
in Section 4.
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
advertise 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.
2.3. Relationship between PVDs and interfaces 2.3. 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.
It is an intent of this architecture to support such scenarios among
others. Hence, it shall be noted that no hierarchical relationship
exists between interfaces and PVDs: it is possible for multiple PVDs
to be simultaneously accessible over one interface, as well as single
PVD to be simultaneously accessible over multiple interfaces.
2.4. 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
skipping to change at page 7, line 23 skipping to change at page 7, line 24
their properties by address family. their properties by address family.
2.6. 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
It is assumed that normally, configuration information contained in a
single PVD, shall be sufficient for a node to fulfill a network
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
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
server into PVDs for any of the networks the node could become
attached to. Such creation / augmentation of PVD(s) could be static
or dynamic. The particular implementation mechanisms are outside of
the scope of this document.
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
configuration elements to serve the specific network requests from configuration elements to serve the specific network requests from
beginning to end. This section describes specific examples of such beginning to end. This section describes specific examples of such
consistent use. consistent use.
4.2.1. Name resolution 4.2.1. Name resolution
When PVD-aware node needs to resolve a name of the destination used When PVD-aware node needs to resolve a name of the destination used
by a connection request, the node could decide to use one, or by a connection request, the node could decide to use one, or
multiple PVDs for a given name lookup. multiple PVDs for a given name lookup.
The node shall chose one PVD, if e.g., the node policy required to The node shall chose one PVD, if e.g., the node policy required to
use a particular PVD for a particular purpose (e.g. to download an use a particular PVD for a particular purpose (e.g. to download an
MMS using a specific APN over a cellular connection). To make the MMS using a specific APN over a cellular connection). To make the
choice, the node could use a match of the PVD DNS suffix or other choice, the node could use a match of the PVD DNS suffix or other
form of PVD ID, as determined by the node policy. form of PVD ID, as determined by the node policy.
skipping to change at page 8, line 44 skipping to change at page 9, line 13
associated with the used PVD. If needed, the node would use the associated with the used PVD. If needed, the node would use the
prefix policy from the same PVD for the best source address selection prefix policy from the same PVD for the best source address selection
among multiple candidates. among multiple candidates.
When destination/source pairs are identified, then they are sorted When destination/source pairs are identified, then they are sorted
using the [RFC6724] destination sorting rules and the prefix policy using the [RFC6724] destination sorting rules and the prefix policy
table from the used PVD. table from the used PVD.
4.3. Connectivity tests 4.3. Connectivity tests
Although some PVDs may appear as valid candidates for PVD selection
(e.g. good link quality, consistent connection parameters, etc.),
they may provide limited or no connectivity to the desired network or
the Internet. For example, some PVDs provide limited IP connectivity
(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
Internet. This may be more likely to happen for PVDs, which are not
trusted by the given PVD-aware node.
An attempt to use such PVD may lead to limited network connectivity
or connection failures for applications. To prevent the latter, a
PVD-aware node may perform connectivity test for the PVD, before
using it to serve network connection requests of the applications.
In current implementations, some nodes do that, for instance, by
trying to reach a dedicated web server (e.g., see [RFC6419]).
Per Section 4.2, a PVD-aware node shall maintain and use multiple
PVDs separately. The PVD-aware node shall perform connectivity test
and, only after validation of the PVD, consider using it to serve
application connections requests. Ongoing connectivity tests are
also required, since during the IP session, the end-to-end
connectivity could be disrupted for various reasons (e.g. poor L2,
IP QoS issues); hence a connectivity monitoring function is needed to
check the connectivity status and remove the PVD from the set of
usable PVDs if necessary.
There may be cases where a connectivity test for PVD selection may be
not appropriate and should be complemented, or replaced, by PVD
selection based on other factors. This could be realized e.g., by
leveraging some 3GPP and IEEE mechanisms, which would allow to expose
some PVD characteristics to the node (e.g. 3GPP Access Network
Discovery and Selection Function (ANDSF) [REF ANDSF], IEEE 802.11u/
ANQP [REF 802.11u]).
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,
skipping to change at page 10, line 24 skipping to change at page 11, line 24
6.2. Trusted PVDs 6.2. Trusted PVDs
Trusted PVDs are PVDs for which two conditions apply. First, a Trusted PVDs are PVDs for which two conditions apply. First, a
trust relationship must exist between the node that is using the PVD trust relationship must exist between the node that is using the PVD
configuration and the source that provided that configuration; this configuration and the source that provided that configuration; this
is the authorization portion of the trust relationship. Second, is the authorization portion of the trust relationship. Second,
there must be some way to validate the trust relationship. This is there must be some way to validate the trust relationship. This is
the authentication portion of the trust relationship. Two the authentication portion of the trust relationship. Two
mechanisms for validating the trust relationship are defined. mechanisms for validating the trust relationship are defined.
It shall be possible to validate the trust relationship for all
advertised elements of a trusted PVD, irrespectively of whether the
PVD elements are communicated as a whole, e.g. in a single DHCP
option, or separately, e.g. in supplementary RA options. Whether or
not this is feasible to provide mechanisms to implement trust
relationship for all PVD elements, will be determined in the
respective companion design documents.
6.2.1. Authenticated PVDs 6.2.1. Authenticated PVDs
One way to validate the trust relationship between a node and the One way to validate the trust relationship between a node and the
source of a PVD is through the combination of cryptographic source of a PVD is through the combination of cryptographic
authentication and an identifier configured on the node. In some authentication and an identifier configured on the node. In some
cases, the two could be the same; for example, if authentication is cases, the two could be the same; for example, if authentication is
done with a shared secret, the secret would have to be associated done with a shared secret, the secret would have to be associated
with the PVD identifier. Without a (PVD Identifier, shared key) with the PVD identifier. Without a (PVD Identifier, shared key)
tuple, authentication would be impossible, and hence authentication tuple, authentication would be impossible, and hence authentication
and authorization are combined. and authorization are combined.
 End of changes. 18 change blocks. 
69 lines changed or deleted 126 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/