draft-ietf-6man-prefixlen-p2p-01.txt   rfc6164.txt 
6man M. Kohno Internet Engineering Task Force (IETF) M. Kohno
Internet-Draft Juniper Networks, Keio University Request for Comments: 6164 Juniper Networks, Keio University
Intended status: Standards Track B. Nitzan Category: Standards Track B. Nitzan
Expires: June 17, 2011 Juniper Networks ISSN: 2070-1721 Juniper Networks
R. Bush R. Bush
Y. Matsuzaki Y. Matsuzaki
Internet Initiative Japan Internet Initiative Japan
L. Colitti L. Colitti
Google Google
T. Narten T. Narten
IBM Corporation IBM Corporation
December 14, 2010 April 2011
Using 127-bit IPv6 Prefixes on Inter-Router Links Using 127-Bit IPv6 Prefixes on Inter-Router Links
draft-ietf-6man-prefixlen-p2p-01.txt
Abstract Abstract
On inter-router point-to-point links, it is useful for security and On inter-router point-to-point links, it is useful, for security and
other reasons, to use 127-bit IPv6 prefixes. Such a practice other reasons, to use 127-bit IPv6 prefixes. Such a practice
parallels the use of 31-bit prefixes in IPv4 [RFC3021]. This parallels the use of 31-bit prefixes in IPv4. This document
document specifies motivation and usages of 127-bit IPv6 prefix specifies the motivation for, and usages of, 127-bit IPv6 prefix
lengths on inter-router point-to-point links. lengths on inter-router point-to-point links.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on June 17, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6164.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Conventions Used In This Document . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope of This Memo ..............................................3
3. Scope Of This Memo . . . . . . . . . . . . . . . . . . . . . . 3 3. Conventions Used in This Document ...............................3
4. Problems identified with 127-bit prefix lengths in the past . . 4 4. Problems Identified with 127-Bit Prefix Lengths in the Past .....3
5. Reasons for using longer prefixes . . . . . . . . . . . . . . . 4 5. Reasons for Using Longer Prefixes ...............................4
5.1. Ping-pong issue . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Ping-Pong Issue ............................................4
5.2. Neighbor Cache Exhaustion issue . . . . . . . . . . . . . . 4 5.2. Neighbor Cache Exhaustion Issue ............................4
5.3. Other reasons . . . . . . . . . . . . . . . . . . . . . . . 5 5.3. Other Reasons ..............................................5
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Recommendations .................................................5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations .........................................6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. Contributors ....................................................6
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgments .................................................6
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References .....................................................6
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References ......................................6
11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 10.2. Informative References ....................................7
11.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Conventions Used In This Document
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. Introduction 1. Introduction
[RFC4291] specifies that interface IDs for all unicast address, [RFC4291] specifies that interface IDs for all unicast addresses,
except those that start with the binary value 000, are required to be except those that start with the binary value 000, are required to be
64 bits long and to be constructed in Modified EUI-64 format. In 64 bits long and to be constructed in Modified EUI-64 format. In
addition, it defines the Subnet-Router anycast address, which is addition, it defines the Subnet-Router anycast address, which is
intended to be used for applications where a node needs to intended to be used for applications where a node needs to
communicate with any one of the set of routers on a link. communicate with any one of the set of routers on a link.
Some operators have been using 127-bit prefixes, but this has been Some operators have been using 127-bit prefixes, but this has been
discouraged due to conflicts with Subnet-Router anycast [RFC3627]. discouraged due to conflicts with Subnet-Router anycast [RFC3627].
However, using 64-bit prefixes creates security issues which are However, using 64-bit prefixes creates security issues that are
particularly problematic on inter-router links, and there are other particularly problematic on inter-router links, and there are other
valid reasons to use prefixes longer than 64 bits, in particular /127 valid reasons to use prefixes longer than 64 bits, in particular /127
(see Section 5). (see Section 5).
This document provides rationale for using 127-bit prefix lengths, This document provides a rationale for using 127-bit prefix lengths,
reevaluates the reasons why doing so was considered harmful, and reevaluates the reasons why doing so was considered harmful, and
specifies how /127 prefixes can be used on inter-router links specifies how /127 prefixes can be used on inter-router links
configured for use as point-to-point links. configured for use as point-to-point links.
3. Scope Of This Memo 2. Scope of This Memo
This document is applicable to cases where operators assign specific This document is applicable to cases where operators assign specific
addresses on inter-router point-to-point links and do not rely on addresses on inter-router point-to-point links and do not rely on
link-local addresses. Many operators assign specific addresses for link-local addresses. Many operators assign specific addresses for
purposes of network monitoring, reverse DNS resolution for traceroute the purposes of network monitoring, reverse DNS resolution for
and other management tools, EBGP peering sessions, and so on. traceroute and other management tools, External Border Gateway
Protocol (EBGP) [RFC4271] peering sessions, and so on.
For the purposes of this document, an inter-router point-to-point For the purposes of this document, an inter-router point-to-point
link is a link to which only two routers and no hosts are attached. link is a link to which only two routers and no hosts are attached.
This may include Ethernet links which are configured to be point-to- This may include Ethernet links that are configured to be point-to-
point. Links between a router and a host, or links to which both point. Links between a router and a host, or links to which both
routers and hosts are attached, are out of scope of this document. routers and hosts are attached, are out of scope of this document.
The recommendations in this document does not apply to link-local The recommendations in this document do not apply to the link-local
address scope. address scope.
4. Problems identified with 127-bit prefix lengths in the past 3. Conventions Used in This Document
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].
4. Problems Identified with 127-Bit Prefix Lengths in the Past
[RFC3627] discourages the use of 127-bit prefix lengths due to [RFC3627] discourages the use of 127-bit prefix lengths due to
conflicts with the Subnet-Router anycast addresses, while stating conflicts with the Subnet-Router anycast addresses, while stating
that the utility of Subnet-Router Anycast for point-to-point links is that the utility of Subnet-Router anycast for point-to-point links is
questionable. questionable.
[RFC5375] also says the usage of 127-bit prefix lengths is not valid [RFC5375] also says the usage of 127-bit prefix lengths is not valid
and should be strongly discouraged, but the stated reason for doing and should be strongly discouraged, but the stated reason for doing
this is to be in compliance with [RFC3627]. this is to be in compliance with [RFC3627].
Though the analyses in the RFCs are correct, operational experience Though the analyses in the RFCs are correct, operational experience
with IPv6 has shown that /127 prefixes can be used successfully. with IPv6 has shown that /127 prefixes can be used successfully.
5. Reasons for using longer prefixes 5. Reasons for Using Longer Prefixes
There are reasons network operators use IPv6 prefix lengths greater There are reasons network operators use IPv6 prefix lengths greater
than 64, particularly 127, for inter-router point-to-point links. than 64, particularly 127, for inter-router point-to-point links.
5.1. Ping-pong issue 5.1. Ping-Pong Issue
A forwarding loop may occur on a point-to-point link with a prefix A forwarding loop may occur on a point-to-point link with a prefix
length shorter than 127. This does not affect interfaces that length shorter than 127. This does not affect interfaces that
perform Neighbor Discovery, but some point-to-point links, which uses perform Neighbor Discovery, but some point-to-point links, which use
medium such as SONET, do not use Neighbor Discovery. As a a medium such as the Synchronous Optical Network (SONET), do not use
consequence, configuring any prefix length shorter than 127 bits on Neighbor Discovery. As a consequence, configuring any prefix length
these links can create an attack vector in the network. shorter than 127 bits on these links can create an attack vector in
the network.
The pingpong issue happens in case of IPv4 as well. But due to the The ping-pong issue happens in the case of IPv4 as well. But due to
scarcity of IPv4 address space, the current practice is to assign the scarcity of IPv4 address space, the current practice is to assign
long prefix lengths such as /30 or /31 [RFC3021] on point-to-point long prefix lengths such as /30 or /31 [RFC3021] on point-to-point
links, thus the problem did not come to the fore. links; thus, the problem did not come to the fore.
The latest ICMPv6 specification [RFC4443] mitigates this problem by The latest ICMPv6 specification [RFC4443] mitigates this problem by
specifying that a router receiving a packet on a point-to-point link, specifying that a router receiving a packet on a point-to-point link,
which is destined to an address within a subnet assigned to that same where the packet is destined to an address within a subnet assigned
link (other than one of the receiving router's own addresses), MUST to that same link (other than one of the receiving router's own
NOT forward the packet back on that link. Instead, it SHOULD addresses), MUST NOT forward the packet back on that link. Instead,
generate an ICMPv6 Destination Unreachable message code 3 in it SHOULD generate an ICMPv6 Destination Unreachable message (code 3)
response. This check is on the forwarding processing path, so it may in response. This check is on the forwarding processing path, so it
have performance impact. may have performance impact.
5.2. Neighbor Cache Exhaustion issue 5.2. Neighbor Cache Exhaustion Issue
As described in Section 4.3.2 of [RFC3756], the use of a 64-bit As described in Section 4.3.2 of [RFC3756], the use of a 64-bit
prefix length on an inter-router link that uses Neighbor Discovery prefix length on an inter-router link that uses Neighbor Discovery
(e.g., Ethernet) potentially allows for denial-of-service attacks on (e.g., Ethernet) potentially allows for denial-of-service attacks on
the routers on the link. the routers on the link.
Consider an Ethernet link between two routers A and B to which a /64 Consider an Ethernet link between two routers, A and B, to which a
subnet has been assigned. A packet sent to any address on the /64 /64 subnet has been assigned. A packet sent to any address on the
(except the addresses of A and B) will cause the router attempting to /64 (except the addresses of A and B) will cause the router
forward it to create an new cache entry in state INCOMPLETE, send a attempting to forward it to create a new cache entry in INCOMPLETE
Neighbor Solicitation message to be sent on the link, start a state, send a Neighbor Solicitation message on the link, start a
retransmit timer, and so on [RFC4861]. retransmit timer, and so on [RFC4861].
By sending a continuous stream of packets to a large number of the By sending a continuous stream of packets to a large number of the
2^64 - 3 unassigned addresses on the link (one for each router and 2^64 - 3 unassigned addresses on the link (one for each router and
one for Subnet-Router Anycast), an attacker can create a large number one for Subnet-Router anycast), an attacker can create a large number
of neighbor cache entries and send a large number of Neighbor of neighbor cache entries and cause one of the routers to send a
Solicitation packets which will never receive replies, thereby large number of Neighbor Solicitation packets that will never receive
consuming large amounts of memory and processing resources. Sending replies, thereby consuming large amounts of memory and processing
the packets to one of the 2^24 addresses on the link which has the resources. Sending the packets to one of the 2^24 addresses on the
same Solicited-Node multicast address as one of the routers also link that has the same Solicited-Node multicast address as one of the
causes the victim to spend large amounts of processing time routers also causes the victim to spend large amounts of processing
discarding useless Neighbor Solicitation messages. time discarding useless Neighbor Solicitation messages.
Careful implementation and rate-limiting can limit the impact of such Careful implementation and rate-limiting can limit the impact of such
an attack, but are unlikely to neutralize it completely. Rate- an attack, but are unlikely to neutralize it completely. Rate-
limiting neighbor solicitation messages will reduce CPU usage, and limiting Neighbor Solicitation messages will reduce CPU usage, and
following the garbage-collection recommendations in [RFC4861] will following the garbage-collection recommendations in [RFC4861] will
maintain reachability, but if the link is down and neighbor cache maintain reachability, but if the link is down and neighbor cache
entries have expired while the attack is ongoing, legitimate traffic entries have expired while the attack is ongoing, legitimate traffic
(for example, BGP sessions) over the link might never be re- (for example, BGP sessions) over the link might never be
established because the routers cannot resolve each others' IPv6 re-established, because the routers cannot resolve each others' IPv6
addresses to MAC addresses. addresses to link-layer addresses.
This attack is not specific to point-to-point links, but is This attack is not specific to point-to-point links, but is
particularly harmful in the case of point-to-point backbone links, particularly harmful in the case of point-to-point backbone links,
which may carry large amounts of traffic to many destinations over which may carry large amounts of traffic to many destinations over
long distances. long distances.
While there are a number of ways to mitigate this kind of issue, While there are a number of ways to mitigate this kind of issue,
assigning /127 subnets eliminates it completely. assigning /127 subnets eliminates it completely.
5.3. Other reasons 5.3. Other Reasons
Though address space conservation considerations are less important Though address space conservation considerations are less important
for IPv6 than they are in IPv4, some operators prefer not to assign for IPv6 than they are in IPv4, some operators prefer not to assign
/64s to individual point-to-point links. Instead, they may be able /64s to individual point-to-point links. Instead, they may be able
to number all of their point-to-point links out of a single (or small to number all of their point-to-point links out of a single /64 or a
number of) /64s. small number of /64s.
6. Recommendations 6. Recommendations
Routers MUST support the assignment of /127 prefixes on point-to- Routers MUST support the assignment of /127 prefixes on point-to-
point inter-router links. Routers MUST disable subnet-router anycast point inter-router links. Routers MUST disable Subnet-Router anycast
for the prefix when /127 prefixes are used. for the prefix when /127 prefixes are used.
When assigning and using any /127 prefixes, the following When assigning and using any /127 prefixes, the following
considerations apply. Some addresses have special meanings, in considerations apply. Some addresses have special meanings, in
particular addresses corresponding to reserved anycast addresses. particular addresses corresponding to reserved anycast addresses.
When assigning prefixes (and addresses) to links, care should be When assigning prefixes (and addresses) to links, care should be
taken to ensure that addresses reserved for such purposes aren't taken to ensure that addresses reserved for such purposes aren't
inadvertently assigned and used as unicast addresses. Otherwise, inadvertently assigned and used as unicast addresses. Otherwise,
nodes may receive packets that they are not intended to receive. nodes may receive packets that they are not intended to receive.
Specifically, assuming that a number of point-to-point links will be Specifically, assuming that a number of point-to-point links will be
numbered out of a single /64 prefix: numbered out of a single /64 prefix:
a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be (a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be
assigned as unicast addresses, to avoid colliding with the Subnet- assigned as unicast addresses, to avoid colliding with the
Router anycast address [RFC4291]. Subnet-Router anycast address [RFC4291].
b) Addresses in which the rightmost 64 bits are assigned the (b) Addresses in which the rightmost 64 bits are assigned the
highest 128 values, (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff: highest 128 values (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff:
ffff), SHOULD NOT be used as unicast addresses to avoid colliding ffff) SHOULD NOT be used as unicast addresses, to avoid
with Reserved Subnet Anycast Addresses [RFC2526]. colliding with reserved subnet anycast addresses [RFC2526].
7. Security Considerations 7. Security Considerations
This document does not have inherent security considerations. It This document does not have inherent security considerations. It
does discuss security related issues and proposes a solution to them. does discuss security-related issues and proposes a solution to them.
8. IANA Considerations
None.
9. Contributors 8. Contributors
Chris Morrow, morrowc@google.com Chris Morrow, morrowc@google.com
Pekka Savola, pekkas@netcore.fi Pekka Savola, pekkas@netcore.fi
Remi Despres, remi.despres@free.fr Remi Despres, remi.despres@free.fr
Seiichi Kawamura, kawamucho@mesh.ad.jp Seiichi Kawamura, kawamucho@mesh.ad.jp
10. Acknowledgments 9. Acknowledgments
We'd like to thank Ron Bonica, Pramod Srinivasan, Olivier Vautrin, The authors would like to thank Ron Bonica, Pramod Srinivasan,
Tomoya Yoshida, Warren Kumari and Tatsuya Jinmei for their helpful Olivier Vautrin, Tomoya Yoshida, Warren Kumari, and Tatsuya Jinmei
inputs. for their helpful inputs.
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[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.
11.2. Informative References 10.2. Informative References
[RFC2526] Johnson, J. and S. Deering, "Reserved IPv6 Subnet Anycast [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
Addresses", RFC 2526, March 1999. Addresses", RFC 2526, March 1999.
[RFC3021] Retana, A., White, R., and V. Fuller, "Using 31-Bit [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson,
Prefixes on IPv4 Point-to-Point Links", December 2000. "Using 31-Bit Prefixes on IPv4 Point-to-Point Links",
RFC 3021, December 2000.
[RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers
Considered Harmful", RFC 3627, September 2003. Considered Harmful", RFC 3627, September 2003.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Discovery (ND) Trust Models and Threats", RFC 3756, Neighbor Discovery (ND) Trust Models and Threats",
May 2004. RFC 3756, May 2004.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Message Protocol (ICMPv6) for the Internet Protocol Border Gateway Protocol 4 (BGP-4)", RFC 4271,
Version 6 (IPv6) Specification", RFC 4443, March 2006. January 2006.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
March 2006.
[RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O.,
and C. Hahn, "IPv6 Unicast Address Assignment and C. Hahn, "IPv6 Unicast Address Assignment
Considerations", RFC 5375, December 2008. Considerations", RFC 5375, December 2008.
Authors' Addresses Authors' Addresses
Miya Kohno Miya Kohno
Juniper Networks, Keio University Juniper Networks, Keio University
Shinjuku Park Tower, 3-7-1 Nishishinjuku Shinjuku Park Tower, 3-7-1 Nishishinjuku
Shinjuku-ku, Tokyo 163-1035 Shinjuku-ku, Tokyo 163-1035
Japan Japan
Email: mkohno@juniper.net EMail: mkohno@juniper.net
Becca Nitzan Becca Nitzan
Juniper Networks Juniper Networks
1194 North Marhilda Avenue 1194 North Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: nitzan@juniper.net EMail: nitzan@juniper.net
Randy Bush Randy Bush
Internet Initiative Japan Internet Initiative Japan
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, WA 98110 Bainbridge Island, WA 98110
USA USA
Email: randy@psg.com EMail: randy@psg.com
Yoshinobu Matsuzaki Yoshinobu Matsuzaki
Internet Initiative Japan Internet Initiative Japan
Jinbocho Mitsui Building, Jinbocho Mitsui Building
1-105 Kanda Jinbo-cho, Tokyo 101-0051 1-105 Kanda Jinbo-cho, Tokyo 101-0051
Japan Japan
Email: maz@iij.ad.jp EMail: maz@iij.ad.jp
Lorenzo Colitti Lorenzo Colitti
Google Google
1600 Amphitheatre Parkway, 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: lorenzo@google.com EMail: lorenzo@google.com
Thomas Narten Thomas Narten
IBM Corporation IBM Corporation
3039 Cornwallis Ave. 3039 Cornwallis Ave.
PO Box 12195 - BRQA/502 Research Triangle Park, NC 27709-2195 PO Box 12195
Research Triangle Park, NC 27709-2195
USA USA
Email: narten@us.ibm.com EMail: narten@us.ibm.com
 End of changes. 62 change blocks. 
138 lines changed or deleted 137 lines changed or added

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