< draft-bradner-iana-allocation-03.txt   draft-bradner-iana-allocation-04.txt >
Network Working Group Scott Bradner Network Working Group Scott Bradner
Internet-Draft Harvard University Internet-Draft Harvard University
Vern Paxson Vern Paxson
ACIRI ACIRI
November 1999 January 2000
IANA Allocation Guidelines For Values In IANA Allocation Guidelines For Values In
the Internet Protocol and Related Headers the Internet Protocol and Related Headers
<draft-bradner-iana-allocation-03.txt> <draft-bradner-iana-allocation-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document will expire in March 2000. This document will expire in July 2000.
Abstract Abstract
This memo provides guidance for the IANA to use in assigning This memo provides guidance for the IANA to use in assigning
parameters for fields in the IPv4, TCP, UDP, ICMP and IPv6 protocol parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol
headers. headers.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
1. Introduction 1. Introduction
For many years the Internet Assigned Numbers Authority (IANA) For many years the Internet Assigned Numbers Authority (IANA)
(www.iana.org) has allocated parameter values for fields in the (www.iana.org) has allocated parameter values for fields in protocols
network protocols which have been created or are maintained by the which have been created or are maintained by the Internet Engineering
Internet Engineering Task Force (IETF). Starting a few years ago the Task Force (IETF). Starting a few years ago the IETF began to
IETF began to provide the IANA with guidance for the assignment of provide the IANA with guidance for the assignment of parameters for
parameters for fields in newly developed protocols. Unfortunately fields in newly developed protocols. Unfortunately this type of
this type of guidance was not consistently provided for the fields in guidance was not consistently provided for the fields in protocols
protocols developed before 1998. This memo attempts to codify developed before 1998. This memo attempts to codify existing IANA
existing IANA practice used in the assignment of parameters in the practice used in the assignment of parameters in the specific case of
specific case of some of these protocols. It is expected that some of these protocols. It is expected that additional memos will
additional memos will be developed in the future to codify existing be developed in the future to codify existing practice in other
practice in other cases. cases.
This memo addresses the fields within the IPv4, TCP, UDP, ICMP and This memo addresses the fields within the IPv4, IPv6, ICMP, UDP and
IPv6 headers for which the IANA assigns values. TCP protocol headers for which the IANA assigns values.
The terms "Specification Required", "Expert Review", "IESG Approval", The terms "Specification Required", "Expert Review", "IESG Approval",
"IETF Consensus", and "Standards Action", are used in this memo to "IETF Consensus", and "Standards Action", are used in this memo to
refer to the processes described in [CONS]. refer to the processes described in [CONS].
2. Temporary Assignments 2. Temporary Assignments
From time to time temporary assignments are made in the values for From time to time temporary assignments are made in the values for
fields in these headers for use in experiments. IESG Approval is fields in these headers for use in experiments. IESG Approval is
required for any such temporary assignments. required for any such temporary assignments.
3. IANA Considerations for fields in the IPv4 header 3. Version field in the IP header.
The first field in the IP header of all current versions of IP is the
Version field. New values in the Version field define new versions
of the IP protocol and are allocated only after an IETF Standards
Action.
4. IANA Considerations for fields in the IPv4 header
The IPv4 header [V4] contains the following fields that carry values The IPv4 header [V4] contains the following fields that carry values
assigned by the IANA: Version (by definition always 4 in IPv4), Type assigned by the IANA: Version, Type of Service, Protocol, Source
of Service, Protocol, Source Address, Destination Address, and Option Address, Destination Address, and Option Type.
Type.
3.1 IPv4 IP Version field 4.1 IPv4 IP Version field
The IANA allocates values from the IP Version name space following The IPv4 Version field is always 4.
a Standards Action process.
3.2 IPv4 Type of Service field 4.2 IPv4 Type of Service field
The Type of Service field described in [V4] has been superceded The Type of Service field described in [V4] has been superceded
[DIFF] by the 6-bit Differentiated Services (DS) field and a 2-bit [DIFF] by the 6-bit Differentiated Services (DS) field and a 2-bit
"currently unused" field. The IANA allocates values in the DS field which is currently reserved. The IANA allocates values in
field following the IANA Considerations section in [DIFF]. [ECN] the DS field following the IANA Considerations section in [DIFF].
describes an experimental use of the 2-bit "currently unused" [ECN] describes an experimental use of the 2-bit "currently
field. Other experimental uses of this field are assigned after unused" field. Other experimental uses of this field may be
IESG Approval processes. Permanent values in this field are assigned after IESG Approval processes. Permanent values in this
allocated following a Standards Action process. field are allocated following a Standards Action process.
3.3 IPv4 Protocol field 4.3 IPv4 Protocol field
IANA allocates values from the IPv4 Protocol name space following IANA allocates values from the IPv4 Protocol name space following
an Expert Review, IESG Approval or Standards Action process. The an Expert Review, IESG Approval or Standards Action process. The
Expert Review process should only be used in those special cases Expert Review process should only be used in those special cases
where non-disclosure information is involved. In these cases the where non-disclosure information is involved. In these cases the
expert should be designated by the IESG. expert(s) should be designated by the IESG.
3.4 IPv4 Source and Destination addresses 4.4 IPv4 Source and Destination addresses
The IPv4 source and destination addresses use the same values. The IPv4 source and destination addresses use the same namespace
These values fall into a number of ranges defined in [V4] and but do not necessarily use the same values. Values in these
[MULT]. fields fall into a number of ranges defined in [V4] and [MULT].
3.4.1 IPv4 Unicast addresses 4.4.1 IPv4 Unicast addresses
The Internet Corporation for Assigned Names and Numbers (ICANN) The Internet Corporation for Assigned Names and Numbers (ICANN)
recently accepted responsibility for the formulation of recently accepted responsibility for the formulation of
specific guidelines for the allocation of the values from the specific guidelines for the allocation of the values from the
IPv4 unicast address space (values 0.0.0.0 through IPv4 unicast address space (values 0.0.0.0 through
223.255.255.255 ) other than values from the ranges 0/8 (which 223.255.255.255 ) other than values from the ranges 0/8 (which
was reserved in [AN80]) and 127/8 (from which the loopback was reserved in [AN80]) and 127/8 (from which the loopback
address has been taken) along with other values already address has been taken) along with other values already
assigned by the IETF for special functions or purposes. (For assigned by the IETF for special functions or purposes. (For
example, the private addresses defined in RFC 1918.) Further example, the private addresses defined in RFC 1918.) Further
assignments in the 0/8 and 127/8 ranges require a Standards assignments in the 0/8 and 127/8 ranges require a Standards
Action process since current IP implementations may break if Action process since current IP implementations may break if
this is done. this is done.
3.4.2 IPv4 Multicast addresses 4.4.2 IPv4 Multicast addresses
IPv4 addresses that fall in the range from 224.0.0.0 through IPv4 addresses that fall in the range from 224.0.0.0 through
239.255.255.255 are known as multicast addresses. The IETF has 239.255.255.255 are known as multicast addresses. The IETF has
assigned a number of IPv4 multicast addresses for special assigned a number of IPv4 multicast addresses for special
purposes. For example, the values in the range from 224.0.0.0 purposes. For example, [ADSCP] assigned a number of IPv4
to 224.0.0.255 , inclusive, are reserved for the use of routing multicast address to correspond to IPv6 scoped multicast
protocols and other low-level topology discovery or maintenance addresses also, the values in the range from 224.0.0.0 to
protocols, such as gateway discovery and group membership 224.0.0.255 , inclusive, are reserved by the IANA for the use
reporting. (See the IANA web page) New values in this range are of routing protocols and other low-level topology discovery or
assigned following an IESG Approval or Standards Action maintenance protocols, such as gateway discovery and group
process. Assignments of individual multicast address follow an membership reporting. (See the IANA web page) New values in
Expert Review, IESG Approval or Standards Action process. this range are assigned following an IESG Approval or Standards
Until further work is done on multicast protocols large-scale Action process. Assignments of individual multicast address
assignments of IPv4 multicast addresses is not recommended. follow an Expert Review, IESG Approval or Standards Action
process. Until further work is done on multicast protocols
large-scale assignments of IPv4 multicast addresses is not
recommended.
3.4.3 IPv4 Reserved addresses From time to time, there are requests for temporary assignment
of multicast space for experimental purposes. these will
originate in an IESG Approval process and should be for a
limited duration such as one year.
4.4.3 IPv4 Reserved addresses
IPv4 addresses in the range from 240.0.0.0 through IPv4 addresses in the range from 240.0.0.0 through
255.255.255.255 are reserved [AN81, MULT] and compliant IPv4 255.255.255.255 are reserved [AN81, MULT] and compliant IPv4
implementations will discard any packets that make use of them. implementations will discard any packets that make use of them.
Addresses in this range are not to be assigned unless an IETF Addresses in this range are not to be assigned unless an IETF
Standards Action modifies the IPv4 protocol in such a way as to Standards Action modifies the IPv4 protocol in such a way as to
make these addresses valid. make these addresses valid.
3.5 IPv4 Option Type field 4.5 IPv4 Option Type field
The IANA allocates values from the IPv4 Option Type name space The IANA allocates values from the IPv4 Option Type name space
following an IESG Approval, IETF Consensus or Standards Action following an IESG Approval, IETF Consensus or Standards Action
process. process.
4. IANA Considerations for fields in the IPv6 header 5. IANA Considerations for fields in the IPv6 header
The IPv6 header [V6] contains the following fields that carry values The IPv6 header [V6] contains the following fields that carry values
assigned from IANA-managed name spaces: Version (by definition always assigned from IANA-managed name spaces: Version (by definition always
6 in IPv6), Traffic Class, Next Header, Source and Destination 6 in IPv6), Traffic Class, Next Header, Source and Destination
Address. In addition, the IPv6 Hop-by-Hop Options and Destination Address. In addition, the IPv6 Hop-by-Hop Options and Destination
Options extension headers include an Option Type field with values Options extension headers include an Option Type field with values
assigned from an IANA-managed name space. assigned from an IANA-managed name space.
4.1 IPv6 Version field 5.1 IPv6 Version field
The Version field in the IPv6 header uses the same name space as The IPv6 Version field is always 6.
the Version field in the IPv4 header. Values in this field are
allocated as described in Section 3.1.
4.2 IPv6 Traffic Class field 5.2 IPv6 Traffic Class field
The IPv6 Traffic Class uses the same namespace as the IPv4 6-bit The IPv6 Traffic Class field is described in [DIFF] as a 6-bit
DS field and 2-bit unused field. Values in these fields are Differentiated Services (DS) field and a 2-bit field which is
allocated as described in Section 3.2. currently reserved. See Section 4.2 for assignment guidelines for
these fields.
4.3 IPv6 Next Header field 5.3 IPv6 Next Header field
The IPv6 Next Header field carries values from the same name space The IPv6 Next Header field carries values from the same name space
as the IPv4 Protocol name space. These values are allocated as as the IPv4 Protocol name space. These values are allocated as
discussed in Section 3.3. discussed in Section 4.3.
4.4 IPv6 Source and Destination Unicast Addresses 5.4 IPv6 Source and Destination Unicast Addresses
The IPv6 Source and Destination address fields both use the same The IPv6 Source and Destination address fields both use the same
values and are described in [V6AD]. The addresses are divided values and are described in [V6AD]. The addresses are divided
into ranges defined by a variable length Format Prefix (FP). into ranges defined by a variable length Format Prefix (FP).
4.4.1 IPv4 Aggregatable Global Unicast Addresses 5.4.1 IPv6 Aggregatable Global Unicast Addresses
The Internet Corporation for Assigned Names and Numbers (ICANN) The IANA was given responsibility for all IPv6 address space by
recently accepted responsibility for the formulation of the IAB in RFC 1881. Recently the IANA agreed to specific
specific guidelines for the assignment of values in the guidelines for the assignment of values in the Aggregatable
Aggregatable Global Unicast Addresses FP (FP 001). Global Unicast Addresses FP (FP 001) formulated by the Regional
Internet Registries.
4.4.2 IPv6 Anycast Addresses 5.4.2 IPv6 Anycast Addresses
IPv6 anycast addresses are defined in [V6AD]. Anycast IPv6 anycast addresses are defined in [V6AD]. Anycast
addresses are allocated from the unicast address space and addresses are allocated from the unicast address space and
anycast addresses are syntactically indistinguishable from anycast addresses are syntactically indistinguishable from
unicast addresses. Assignment of IPv6 Anycast addresses unicast addresses. Assignment of IPv6 Anycast subnet addresses
follows the process used for IPv6 Aggregatable Global Unicast follows the process used described in [V6AD]. Assignment of
Addresses. (section 4.4) other IPv6 Anycast addresses follows the process used for IPv6
Aggregatable Global Unicast Addresses. (section 5.4.1)
4.4.3 IPv6 Multicast Addresses 5.4.3 IPv6 Multicast Addresses
IPv6 multicast addresses are defined in [V6AD]. They are IPv6 multicast addresses are defined in [V6AD]. They are
identified by a FP of 0xFF. Assignment guidelines for IPv6 identified by a FP of 0xFF. Assignment guidelines for IPv6
multicast addresses are described in [MASGN]. multicast addresses are described in [MASGN].
4.4.4 IPv6 Unassigned and Reserved IPv6 Format Prefixes 5.4.4 IPv6 Unassigned and Reserved IPv6 Format Prefixes
The responsibility for assigning values in each of the The responsibility for assigning values in each of the
"unassigned" and "reserved" Format Prefixes is delegated by "unassigned" and "reserved" Format Prefixes is delegated by
IESG Approval or Standards Action processes since the IESG Approval or Standards Action processes since the rules for
processing rules for these Format Prefixes have not been processing these Format Prefixes in IPv6 implementations have
defined. not been defined.
4.5 IPv6 Hop-by-Hop and Destination Option Fields 5.5 IPv6 Hop-by-Hop and Destination Option Fields
Values for the IPv6 Hop-by-Hop Options and Destination Options Values for the IPv6 Hop-by-Hop Options and Destination Options
fields are allocated using an IESG Approval, IETF Consensus or fields are allocated using an IESG Approval, IETF Consensus or
Standards Action processes. Standards Action processes.
5. IANA Considerations for fields in the ICMP header 5.6 IPv6 Neighbor Discovery Fields
The ICMP header [ICMP] contains the following fields that carry The IPv6 Neighbor Discovery header [NDV6] contains the following
fields that carry values assigned from IANA-managed name spaces:
Type, Code and Option Type.
Values for the IPv6 Neighbor Discovery Type, Code, and Option Type
fields are allocated using an IESG Approval or Standards Action
process.
6. IANA Considerations for fields in the IPv4 ICMP header
The IPv4 ICMP header [ICMP] contains the following fields that carry
values assigned from IANA-managed name spaces: Type and Code. values assigned from IANA-managed name spaces: Type and Code.
Values for the ICMP Type and Code fields are allocated using an IESG Values for the IPv4 ICMP Type and Code fields are allocated using an
Approval or Standards Action processes. IESG Approval or Standards Action processes.
6. IANA Considerations for fields in the UDP header 7. IANA Considerations for fields in the IPv6 ICMP header
The IPv6 ICMP header [ICMPV6] contains the following fields that
carry values assigned from IANA-managed name spaces: Type and Code.
Values for the IPv6 ICMP Type and Code fields are allocated using an
IESG Approval or Standards Action processes.
8. IANA Considerations for fields in the UDP header
The UDP header [UDP] contains the following fields that carry values The UDP header [UDP] contains the following fields that carry values
assigned from IANA-managed name spaces: Source and Destination Port. assigned from IANA-managed name spaces: Source and Destination Port.
Both the Source and Destination Port fields use the same namespace. Both the Source and Destination Port fields use the same namespace.
Values in this namespace are assigned following a Specification Values in this namespace are assigned following a Specification
Required, Expert Review, IESG Approval, IETF Consensus, or Standards Required, Expert Review, IESG Approval, IETF Consensus, or Standards
Action process. Note that some assignments may involve non- Action process. Note that some assignments may involve non-
disclosure information. disclosure information.
7. IANA Considerations for fields in the TCP header 9. IANA Considerations for fields in the TCP header
The TCP header [TCP] contains the following fields that carry values The TCP header [TCP] contains the following fields that carry values
assigned from IANA-managed name spaces: Source and Destination Port, assigned from IANA-managed name spaces: Source and Destination Port,
Reserved Bits, and Option Kind. Reserved Bits, and Option Kind.
7.1 TCP Source and Destination Port fields 9.1 TCP Source and Destination Port fields
Both the Source and Destination Port fields use the same Both the Source and Destination Port fields use the same
namespace. Values in this namespace are assigned following a namespace. Values in this namespace are assigned following a
Specification Required, Expert Review, IESG Approval, IETF Specification Required, Expert Review, IESG Approval, IETF
Consensus, or Standards Action process. Note that some Consensus, or Standards Action process. Note that some
assignments may involve non-disclosure information. assignments may involve non-disclosure information.
7.2 Reserved Bits in TCP Header 9.2 Reserved Bits in TCP Header
The reserved bits in the TCP header are assigned following a The reserved bits in the TCP header are assigned following a
Standards Action process. Standards Action process.
7.3 TCP Option Kind field 9.3 TCP Option Kind field
Values in the Option Kind field are assigned following an IESG Values in the Option Kind field are assigned following an IESG
Approval or Standards Action process. Approval or Standards Action process.
8. Security Considerations 10. Security Considerations
Security analyzers such as firewalls and network intrusion detection Security analyzers such as firewalls and network intrusion detection
monitors often rely on unambiguous interpretations of the fields monitors often rely on unambiguous interpretations of the fields
described in this memo. As new values for the fields are assigned, described in this memo. As new values for the fields are assigned,
existing security analyzers that do not understand the new values may existing security analyzers that do not understand the new values may
fail, resulting in either loss of connectivity if the analyzer fail, resulting in either loss of connectivity if the analyzer
declines to forward the unrecognized traffic, or loss of security if declines to forward the unrecognized traffic, or loss of security if
it does forward the traffic and the new values are used as part of an it does forward the traffic and the new values are used as part of an
attack. This vulnerability argues for high visibility (which the attack. This vulnerability argues for high visibility (which the
Standards Action and IETF Consensus processes ensure) for the Standards Action and IETF Consensus processes ensure) for the
assignments whenever possible. assignments whenever possible.
9. References 11. References
[ADSCP] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365,
July 1998
[AN80] Postel, J., "Assigned numbers", RFC 758, August 1979 [AN80] Postel, J., "Assigned numbers", RFC 758, August 1979
[AN81] Postel, J., "Assigned numbers", RFC 790, September 1981 [AN81] Postel, J., "Assigned numbers", RFC 790, September 1981
[CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998. Considerations Section in RFCs", RFC 2434, October 1998.
[DIFF] Nichols, K., S. Blake, F. Baker, D. Black, " Definition of the [DIFF] Nichols, K., S. Blake, F. Baker, D. Black, "Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6 Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers", RFC 2474, December 1998. Headers", RFC 2474, December 1998.
[ECN] Ramakrishnan, K., S. Floyd, "A Proposal to add Explicit [ECN] Ramakrishnan, K., S. Floyd, "A Proposal to add Explicit
Congestion Notification (ECN) to IP", RFC 2481, January 1999 Congestion Notification (ECN) to IP", RFC 2481, January 2000
[ICMP] Postel, J., "Internet Control Message Protocol", RFC 792, [ICMP] Postel, J., "Internet Control Message Protocol", RFC 792,
September 1981. September 1981.
[ICMPV6] Conta, A., S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463,
December 1998.
[MASGN] Hinden, R., and S. Deering, "IPv6 Multicast Address [MASGN] Hinden, R., and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, July 1998. Assignments", RFC 2375, July 1998.
[MULT] Deering, S. E., "Host extensions for IP multicasting", RFC [MULT] Deering, S. E., "Host extensions for IP multicasting", RFC
988, July 1986 988, July 1986
[NDV6] Narten, T., E. Nordmark, W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
[TCP] Postel, J., "Transmission Control Protocol", RFC 793, September [TCP] Postel, J., "Transmission Control Protocol", RFC 793, September
1981. 1981.
[UDP] Postel, J., "User Datagram Protocol", RFC 768, August 1980. [UDP] Postel, J., "User Datagram Protocol", RFC 768, August 1980.
[V4] Postel, J., "Internet Protocol", RFC 791, September, 1981. [V4] Postel, J., "Internet Protocol", RFC 791, September, 1981.
[V6] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6) [V6] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[V6AD] Hinden, R., S. Deering, "IP Version 6 Addressing [V6AD] Hinden, R., S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998 Architecture", RFC 2373, July 1998
10. Author's Addresses 12. Author's Addresses
Scott Bradner Scott Bradner
Harvard University Harvard University
Cambridge MA - USA Cambridge MA - USA
02138 02138
sob@harvard.edu sob@harvard.edu
+1 617 495 3864 +1 617 495 3864
Vern Paxson Vern Paxson
ACIRI / ICSI ACIRI / ICSI
1947 Center Street, Suite 600 1947 Center Street, Suite 600
Berkeley, CA - USA Berkeley, CA - USA
94704-1198 94704-1198
vern@aciri.org vern@aciri.org
+1 510/642-4274 x302 +1 510/642-4274 x302
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 56 change blocks. 
96 lines changed or deleted 137 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/