< draft-marques-sdnp-flow-spec-00.txt   draft-marques-sdnp-flow-spec-01.txt >
Network Working Group P. Marques Network Working Group P. Marques
Internet-Draft Internet-Draft Contrail Systems
Expires: April 13, 2012 L. Fang Intended status: Standards Track L. Fang
Cisco Systems Expires: October 01, 2012 Cisco Systems
P. Pan P. Pan
Infinera Corp Infinera Corp
A. Shukla A. Shukla
Juniper Networks Juniper Networks
October 11, 2011 M. Napierala
AT&T Labs
April 2012
Traffic classification, filtering and redirection for end-system IP Traffic classification in end-system IP VPNs.
VPNs. draft-marques-sdnp-flow-spec-01
draft-marques-sdnp-flow-spec-00
Abstract Abstract
When IP VPNs are used to interconnect end-systems When IP VPNs are used to interconnect end-systems [I-D.marques-l3vpn-
[I-D.marques-l3vpn-end-system] it may be desirable to introduce end-system] it may be desirable to introduce traffic control rules at
traffic control rules at a finer level of granularity than an IP a finer level of granularity than an IP destination address.
destination address.
This document extends the end-system IP VPN specification with This document extends the end-system IP VPN specification with
support for fine grain traffic classification, filtering and support for fine grain traffic classification, filtering and
redirection rules. It applies the existing BGP IP VPN flow redirection rules. It applies the existing BGP IP VPN flow
specification dissemination mechanism [RFC5575] to end-system IP VPNs specification dissemination mechanism [RFC5575] to end-system IP VPNs
in order to provide the ability to control IP packets that match a in order to provide the ability to control IP packets that match a
specific pattern, which may include fields other than the IP specific pattern, which may include fields other than the IP
destination address. destination address.
Status of this Memo Status of this Memo
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 April 13, 2012. This Internet-Draft will expire on October 01, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 Provisions Relating to IETF Documents (http://trustee.ietf.org/
(http://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. End-system functionality . . . . . . . . . . . . . . . . . . . 6 2. VPN Forwarder functionality . . . . . . . . . . . . . . . . . 4
3. XML schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. XML schema . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Signaling gateway functionality . . . . . . . . . . . . . . . 10 4. Signaling gateway functionality . . . . . . . . . . . . . . . 7
5. Top-of-rack switch . . . . . . . . . . . . . . . . . . . . . . 11 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
When end-system IP VPNs [I-D.marques-l3vpn-end-system] are used to When end-system IP VPNs [I-D.marques-l3vpn-end-system] are used to
interconnect Virtual Machines or other multi-tenant applications it interconnect Virtual Machines or other multi-tenant applications it
may be desirable to control the flow of traffic between sender(s) and may be desirable to control the flow of traffic between sender(s) and
receiver at a finer level of granularity than an IP destination host receiver at a finer level of granularity than an IP destination host
prefix. prefix.
In the IP protocol model, ingress points map traffic into forwarding In the IP protocol model, ingress points map traffic into forwarding
skipping to change at page 3, line 42 skipping to change at page 3, line 15
This document uses a point-to-multipoint model for traffic filtering This document uses a point-to-multipoint model for traffic filtering
rules where the traffic egress requests all the ingresses to perform rules where the traffic egress requests all the ingresses to perform
a given traffic classification action. The entity that advertises a given traffic classification action. The entity that advertises
the destination address of the traffic, or a proxy in its behalf, the destination address of the traffic, or a proxy in its behalf,
injects a flow-based route advertisement into the signaling injects a flow-based route advertisement into the signaling
infrastructure. This flow-based route is propagated according to VPN infrastructure. This flow-based route is propagated according to VPN
policies to all the ingress points of the VPN, the end-systems which policies to all the ingress points of the VPN, the end-systems which
contain VMs allowed to access the destination. contain VMs allowed to access the destination.
The traffic filtering rules are then applied at all the ingress The traffic filtering rules are then applied at all the ingress
points of the VPN. The egress MAY also choose to apply the same points of the VPN. The egress MAY also choose to apply the same rules
rules in cases where they are equivalent at both locations. in cases where they are equivalent at both locations.
+-----+ +--------+ +-----+ +--------+
| VM1 | --- | host 1 | - | VM1 | --- | host 1 | -
+-----+ +--------+ \ +-----+ +--------+ \
<filter> \+~~~~~~~~~+ +--------+ +------+ <filter> \+~~~~~~~~~+ +--------+ +------+
| network | ---- | host 3 | -- | VM 3 | | network | ---- | host 3 | -- | VM 3 |
+~~~~~~~~~+ +--------+ +------+ +~~~~~~~~~+ +--------+ +------+
/ /
+-----+ +--------+ / +-----+ +--------+ /
| VM2 | --- | host 2 | - / | VM2 | --- | host 2 | - /
+-----+ +--------+ +-----+ +--------+
<filter> <filter>
Figure 1
The figure above contains an example topology in which a given VM (VM The figure above contains an example topology in which a given VM (VM
3) provides a common infrastructure service. VM1 and VM2 belong to 3) provides a common infrastructure service. VM1 and VM2 belong to
different tenants and are in VPNs which are allowed to access the different tenants and are in VPNs which are allowed to access the
service in VM3. service in VM3.
This specification allows VM3 to advertise a traffic filtering rule, This specification allows VM3 to advertise a traffic filtering rule,
as a flow-spec route, requesting the Host OSes in host 1 and host 2 as a flow-spec route, requesting the VPN Forwarders for hosts 1 and 2
to limit any traffic flow to VM3's destination IP address such that, to limit any traffic flow to VM3's destination IP address such that,
for instance, only packets for a specific TCP destination port are for instance, only packets for a specific TCP destination port are
allowed. allowed.
It is important to note that traffic filtering does not avoid the It is important to note that traffic filtering does not avoid the
need for application level authorization and authentication. need for application level authorization and authentication.
When a flow-spec route is advertised, the number of possible ingress When a flow-spec route is advertised, the number of possible ingress
points it not known in advance. There is no mechanism to generate a points it not known in advance. There is no mechanism to generate a
positive or negative acknowledgement from the ingress points. This positive or negative acknowledgement from the ingress points. This
skipping to change at page 6, line 5 skipping to change at page 4, line 14
Using the same vrf-import and export policies that define the IP VPN, Using the same vrf-import and export policies that define the IP VPN,
the flow-spec routes are then imported from BGP into a vpn-specific the flow-spec routes are then imported from BGP into a vpn-specific
database and advertised to all the ingress end-system, which apply database and advertised to all the ingress end-system, which apply
them. them.
This document limits itself to "stateless" traffic classification This document limits itself to "stateless" traffic classification
rules that classify a given IP packet independently of any previous rules that classify a given IP packet independently of any previous
data traffic. data traffic.
2. End-system functionality 2. VPN Forwarder functionality
It is common for end-systems to support traffic classification . One In order to implement the functionality described in this document a
such example is the Linux "ipchains" functionality. This document VPN Forwarder MUST support stateless traffic classification rules
assumes that such functionality can be associated with a particular that are capable of matching the TCP/IP protocol fields defined in
Virtual Routing and Forwarding (VRF) table on the end-system and that [RFC5575].
each virtual interface is associated with a VRF. The traffic
classification rules described in this document are applied at the
VRF level.
The BGP Flow Specification [RFC5575] document lists a set of IPv4 This document assumes that this traffic filtering functionality can
protocol header fields and match operations that are though to be a be associated with a particular Virtual Routing and Forwarding (VRF)
minimum common set of supported functionality among hardware table, either directly or through the virtual interfaces associated
implementations. with the VRF. Conceptually, the traffic classification rules
described in this document are applied at the VRF level.
These fields are: The BGP Flow Specification [RFC5575] document lists a set of TCP/IP
packet header fields and match operations that are though to be a
minimum common set of supported functionality among implementations.
The defined packet header fields are:
o IPv4 destination address. o IPv4 destination address.
o IPv4 source address. o IPv4 source address.
o IP protocol identifier. o IP protocol identifier.
o Transport Ports: Source, Destination or Either. o Transport Ports: Source, Destination or Either.
o ICMP Type and Code. o ICMP Type and Code.
o TCP flags. o TCP flags.
o Packet length. o Packet length.
o Diffserv Code Point. o Diffserv Code Point.
o IPv4 fragmentation flags. o IPv4 fragmentation flags.
When numeric values are specified (i.e. fields other than IP When numeric values are specified (i.e. fields other than IP
addresses), the match operator can specify a list of values with addresses), the match operator can specify a list of values with
inequality operators. Note that this may result in one logical rule, inequality operators. Note that this may result in one logical rule,
as defined by this specification to be implemented as multiple as defined by this specification to be implemented as multiple
classification rules on the underlying OS implementation. For classification rules on the underlying implementation.
instance the match operations in the Linux "ipchains" implementation
are more restrictive.
The match operator is defined via the following BNF grammar: The match operator is defined via the following BNF grammar:
<match> ::= <terms> <match> ::= <terms>
<terms> ::= <term> <terms> ::= <term>
| <term> "||" <terms> | <term> "||" <terms>
| <term> "&&" <terms> | <term> "&&" <terms>
<term> ::= <operator> value <term> ::= <operator> value
<operator> ::= "<" | "<=" | "=" | "!=" | ">=" | ">" <operator> ::= "<" | "<=" | "=" | "!=" | ">=" | ">"
As an example, a value range is expressed as: ">= begin && <= end". As an example, a value range is expressed as: ">= begin && <= end".
The result of a flow-spec rule is one of the following actions: The result of a flow-spec rule is one of the following actions:
o allow o allow
o deny o deny
o rate-limit o rate-limit
skipping to change at page 7, line 37 skipping to change at page 5, line 42
o redirect o redirect
o copy o copy
o log o log
o set-dscp o set-dscp
The redirect and copy actions have as a target an FEC which should The redirect and copy actions have as a target an FEC which should
contain an unique UUID [RFC4122] identifier as well as information contain an unique UUID [RFC4122] identifier as well as information
regarding the SNPA address and label used for forwarding. regarding the IP next-hop address and label used for forwarding.
The copy action instructs the system to generate a copy of the The copy action instructs the system to generate a copy of the
original packet and forward to the specified FEC. Both copy and log original packet and forward to the specified FEC. Both copy and log
actions have an additional parameter which controls whether all actions have an additional parameter which controls whether all
matching packets or a sample is subject to the specified treatment. matching packets or a sample is subject to the specified treatment.
The 'set-dscp' action specifies the DSCP value to be assigned to the The 'set-dscp' action specifies the DSCP value to be assigned to the
outer IP header of the packet, when a packet is encapsulated. outer IP header of the packet, when a packet is encapsulated.
3. XML schema 3. XML schema
In the end-system IP VPN [I-D.marques-l3vpn-end-system] In the end-system IP VPN [I-D.marques-l3vpn-end-system]
specification, IP reachability information is encoded as XMPP "item" specification, IP reachability information is encoded as XMPP "item"
information belonging to collection nodes where each collection is information belonging to collection nodes where each collection is
the IP reachability information for a given VPN. End-systems can the IP reachability information for a given VPN. End-systems can
publish and receive notifications for these nodes. publish and receive notifications for these nodes.
This document uses the same approach. It uses a collection with the This document uses the same approach. It uses a collection with the
name of "<vpn-customer-name>/ip4-flow-spec" to publish and receive name of "<vpn-customer-name>/ip4-flow-spec" to publish and receive
updates corresponding to IPv4 flow-spec routes. When an end-system updates corresponding to IPv4 flow-spec routes. When an end-system
published a node into such a collection it must generate a node name published a node into such a collection it must generate a node name
skipping to change at page 9, line 27 skipping to change at page 6, line 39
<tcp-flags>=(syn|rst|ack|fin)</tcp-flags> <tcp-flags>=(syn|rst|ack|fin)</tcp-flags>
<ip-length>>40</ip-length> <ip-length>>40</ip-length>
<dscp>=0</dscp> <dscp>=0</dscp>
<ip4-fragment>=(df|first|more|last)</ip4-fragment> <ip4-fragment>=(df|first|more|last)</ip4-fragment>
<action> <action>
<accept/> <accept/>
<deny/> <deny/>
<rate-limit rate='10pps'/> <rate-limit rate='10pps'/>
<redirect> <redirect>
<fec uuid='550e8400-e29b-41d4-a716-446655440000'> <fec uuid='550e8400-e29b-41d4-a716-446655440000'>
<snpa af='1'>'infrastructure-ip-address'</snpa> <nlri af='1'>'infrastructure-ip-address'</nlri>
<label>1</label> <label>1</label>
</fec> </fec>
</redirect> </redirect>
<copy> <copy>
<fec>...</fec> <fec>...</fec>
<sample/> <sample/>
</copy> </copy>
<log/> <log/>
<set-dscp>128</set-dscp> <set-dscp>128</set-dscp>
</action> </action>
</entry> </entry>
</item> </item>
The sequence of XML elements in an item SHOULD follow the "flow The sequence of XML elements in an item SHOULD follow the "flow
specification" NLRI type order as the example above. IP source and specification" NLRI type order as the example above. IP source and
destination prefixes are encoded in their standard textual destination prefixes are encoded in their standard textual
representation of <dotted notation>"/"<prefix-length>. Protocol and representation of <dotted notation>"/"<prefix-length>. Protocol and
Port elements are expressed using the match operator syntax Port elements are expressed using the match operator syntax
documented above. "<port>" and "<destination-port>" or "<source- documented above. "<port>" and "<destination-port>" or "<source-
port>" SHOULD be mutually exclusive. The icmp type and code fields port>" SHOULD be mutually exclusive. The icmp type and code fields
as well as ip-length and dscp are again encoded using the value match as well as ip-length and dscp are again encoded using the value match
operator. The ">tcp-flags>" element uses either an equality or match operator. The "<tcp-flags>" element uses either an equality or match
operation of the TCP header flags. A binary match is expressed as operation of the TCP header flags. A binary match is expressed as "m
"m/(syn|rst|ack|fin)/". The "<ip4-fragment>" element may also use a /(syn|rst|ack|fin)/". The "<ip4-fragment>" element may also use a
binary match operation. binary match operation.
4. Signaling gateway functionality 4. Signaling gateway functionality
As with IP reachabilty information, signaling gateways create a As with IP reachabilty information, signaling gateways create a
routing database for each 'vpn-customer-name'. An XMPP client (an routing database for each 'vpn-customer-name'. An XMPP client (a VPN
end-system) can publish and subscribe to multiple of these databases. Forwarder) can publish and subscribe to multiple of these databases.
Each "virtual interface" on the end-system is associated with a Each "virtual interface" on the end-system is associated with a
virtual routing table on the gateway. virtual routing table on the gateway.
From a signaling perspective, the gateway functions as a IP VPN PE as From a signaling perspective, the gateway functions as a IP VPN PE as
described in section 8 of [RFC5575]. As with IP reachability, this described in section 8 of [RFC5575]. As with IP reachability, this
document uses the XMPP interface to delegate the forwarding document uses the XMPP interface to delegate the forwarding
functionality to the end-system, separating it from the signaling functionality to the VPN Forwarder, separating it from the signaling
node. node.
In [RFC5575] no route validation procedure is defined for the IP VPN 5. Applications
application. For the purposes of the end-system IP VPN application,
signaling gateways SHOULD enforce the following rules.
A flow-spec route is valid if its Route Target list is an exact
match to the export route target list for the virtual routing
table.
A flow-spec route is valid if it contains an IP destination
prefixes and there is an exact match between its Route Target list
and the Route Target list contained in the IP unicast route that
covers that specific destination prefix.
A flow-spec route should be considered unfeasible otherwise and
not imported into the specific virtual routing database.
5. Top-of-rack switch
It may be desirable to implement some of the traffic classification
functionality on a traditional network element, rather than in the
end-system. For instance the end-system may not fully support all
the desired functionality.
In this case, a network element can have access to the signaling
information using two different methods:
By receiving BGP signaling information directly. A Top-of-rack
switch, for example, could infer whether a given end-system is
downstream from it by examining the IP infrastructure addresses of
the end-systems and extracting information into its forwarding
plane whenever an end-point of a VPN is downstream.
By using a "men-in-the-middle" technique in which the XMPP client
sessions from end-systems terminate in the TOP-of-rack switches.
The switch can then establish an XMPP session to the signaling
gateway and proxy the information between the two sessions.
The second approach presents the switch itself with a simplified
interface in which it does not need to understand the policies
associated with a specific VPN.
6. Applications
This specification provides a mechanism to distribute traffic This specification provides a mechanism to distribute traffic
classification rules to many enforcement points. This may of classification rules to many enforcement points. This may of
interest in applications where it is desirable to avoid the standard interest in applications where it is desirable to avoid the standard
approach of a centralized enforcement point. Typically in situations approach of a centralized enforcement point. Typically in situations
where the volume of traffic or the nature of the problem make it more where the volume of traffic or the nature of the problem make it more
cost effective to do so. cost effective to do so.
One such application is the enforcement of stateless traffic One such application is the enforcement of stateless traffic
forwarding rules for infrastructure services. An application level forwarding rules for infrastructure services. An application level
skipping to change at page 13, line 5 skipping to change at page 7, line 56
import policies, the data-center management solution allows the import policies, the data-center management solution allows the
tenant specific VPNs to see these routes. The tenant VPN addresses tenant specific VPNs to see these routes. The tenant VPN addresses
must also be reachable on the storage VPN, in this example. must also be reachable on the storage VPN, in this example.
This specification allows the storage service to block out traffic This specification allows the storage service to block out traffic
that does not match the specific transport protocols used to provide that does not match the specific transport protocols used to provide
this service. It also allows confirming traffic to be marked with this service. It also allows confirming traffic to be marked with
the appropriate diffserv classification. The network administrator the appropriate diffserv classification. The network administrator
case also use this mechanism for diagnostic purposes. case also use this mechanism for diagnostic purposes.
7. Security Considerations 6. Security Considerations
There are two independent areas that are worth examining when it There are two independent areas that are worth examining when it
comes to security. The integrity of the control plane information comes to security. The integrity of the control plane information
and the forwarding actions. and the forwarding actions.
This document assumes that all signaling interactions use mutual This document assumes that all signaling interactions use mutual
authentication, where all communication channels are authenticated. authentication, where all communication channels are authenticated.
For traffic filtering and redirection this mechanism assumes a "best- For traffic filtering and redirection this mechanism assumes a "best-
effort" model. The ingress points will strive to perform the actions effort" model. The ingress points will strive to perform the actions
specified by the egress. However there are no strict guarantees that specified by the egress. However there are no strict guarantees that
skipping to change at page 14, line 5 skipping to change at page 8, line 25
the order of operations is such that no non-conforming traffic is the order of operations is such that no non-conforming traffic is
ever presented to the egress. ever presented to the egress.
For traffic filtering rules, the egress point can choose to apply the For traffic filtering rules, the egress point can choose to apply the
rules also in order to provide stronger guarantees. rules also in order to provide stronger guarantees.
Applications should themselves authenticate its communication peers Applications should themselves authenticate its communication peers
my methods that do not depend on the IP addresses used at the network my methods that do not depend on the IP addresses used at the network
layer. layer.
8. References 7. References
[I-D.marques-l3vpn-end-system] [I-D.marques-l3vpn-end-system]
Marques, P., Fang, L., and P. Pan, "End-system support for Marques, P., Fang, L., Pan, P., Shukla, A., Napierala, M.
BGP-signaled IP/VPNs.", draft-marques-l3vpn-end-system-01 and N. Bitar, "BGP-signaled end-system IP/VPNs.",
(work in progress), October 2011. Internet-Draft draft-marques-l3vpn-end-system-05, March
2012.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F. and D.L. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474, December
December 1998. 1998.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M. and R. Salz, "A Universally Unique
Unique IDentifier (UUID) URN Namespace", RFC 4122, IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
July 2005.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.
and D. McPherson, "Dissemination of Flow Specification and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, August 2009. Rules", RFC 5575, August 2009.
Authors' Addresses Authors' Addresses
Pedro Marques Pedro Marques
Contrail Systems
440 N Wolfe Rd
Sunnyvale, CA 94085
Email: pedro.r.marques@gmail.com Email: roque@contrailsystems.com
Luyuan Fang Luyuan Fang
Cisco Systems Cisco Systems
111 Wood Avenue South 111 Wood Avenue South
Iselin, NJ 08830 Iselin, NJ 08830
Email: lufang@cisco.com Email: lufang@cisco.com
Ping Pan Ping Pan
Infinera Corp Infinera Corp
140 Caspian Ct. 140 Caspian Ct.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: ppan@infinera.com Email: ppan@infinera.com
Amit Shukla Amit Shukla
Juniper Networks Juniper Networks
1194 N. Mathilda Av. 1194 N. Mathilda Av.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: amit@juniper.net Email: amit@juniper.net
Maria Napierala
AT&T Labs
200 Laurel Avenue
Middletown, NJ 07748
Email: mnapierala@att.com
 End of changes. 46 change blocks. 
132 lines changed or deleted 86 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/