draft-ietf-ipngwg-unicast-aggr-02.txt   draft-ietf-ipngwg-unicast-aggr-03.txt 
INTERNET-DRAFT R. Hinden, Ipsilon Networks INTERNET-DRAFT R. Hinden, Nokia
July 16, 1997 M. O'Dell, UUNET January 22, 1998 M. O'Dell, UUNET
S. Deering, Cisco S. Deering, Cisco
An IPv6 Aggregatable Global Unicast Address Format An IPv6 Aggregatable Global Unicast Address Format
<draft-ietf-ipngwg-unicast-aggr-02.txt> <draft-ietf-ipngwg-unicast-aggr-03.txt>
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.'' ``working draft'' or ``work in progress.''
Please check the 1id-abstracts.txt listing contained in the internet- Please check the 1id-abstracts.txt listing contained in the internet-
drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft. current status of any Internet Draft.
This internet draft expires on January 17, 1998. This internet draft expires on August 22, 1998.
1.0 Introduction 1.0 Introduction
This document defines an IPv6 aggregatable global unicast address This document defines an IPv6 aggregatable global unicast address
format for use in the Internet. The address format defined in this format for use in the Internet. The address format defined in this
document is consistent with the IPv6 Protocol [IPV6] and the "IPv6 document is consistent with the IPv6 Protocol [IPV6] and the ''IPv6
Addressing Architecture" [ARCH]. It is designed to facilitate Addressing Architecture'' [ARCH]. It is designed to facilitate
scalable Internet routing. scalable Internet routing.
This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast This documented replaces RFC 2073, ''An IPv6 Provider-Based Unicast
Address Format". RFC 2073 will become historic. Address Format''. RFC 2073 will become historic.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119]. document are to be interpreted as described in [RFC 2119].
2.0 Overview of the IPv6 Address 2.0 Overview of the IPv6 Address
IPv6 addresses are 128-bit identifiers for interfaces and sets of IPv6 addresses are 128-bit identifiers for interfaces and sets of
interfaces. There are three types of addresses: Unicast, Anycast, interfaces. There are three types of addresses: Unicast, Anycast,
and Multicast. This document defines a specific type of Unicast and Multicast. This document defines a specific type of Unicast
skipping to change at page 3, line 47 skipping to change at page 3, line 43
( S.A ) ( S.B ) ( P5 ) ( P6 )( S.C ) ( S.A ) ( S.B ) ( P5 ) ( P6 )( S.C )
\___/ \___/ \___/ \___/ \___/ \___/ \___/ \___/ \___/ \___/
| / \ | / \
_|_ _/_ \ ___ _|_ _/_ \ ___
/ \ / \ +-/ \ / \ / \ +-/ \
( S.D ) ( S.E ) ( S.F ) ( S.D ) ( S.E ) ( S.F )
\___/ \___/ \___/ \___/ \___/ \___/
As shown in the figure above, the aggregatable address format is As shown in the figure above, the aggregatable address format is
designed to support long-haul providers (shown as P1, P2, P3, and designed to support long-haul providers (shown as P1, P2, P3, and
P4), exchanges [EXCH] (shown as X1 and X2), multiple levels of P4), exchanges (shown as X1 and X2), multiple levels of providers
providers (shown at P5 and P6), and subscribers (shown as S.x) (shown at P5 and P6), and subscribers (shown as S.x) Exchanges
Exchanges (unlike current NAPs, FIXes, etc.) will allocate IPv6 (unlike current NAPs, FIXes, etc.) will allocate IPv6 addresses.
addresses. Organizations who connect to these exchanges will also Organizations who connect to these exchanges will also subscribe
subscribe (directly, indirectly via the exchange, etc.) for long-haul (directly, indirectly via the exchange, etc.) for long-haul service
service from one or more long-haul providers. Doing so, they will from one or more long-haul providers. Doing so, they will achieve
achieve addressing independence from long-haul transit providers. addressing independence from long-haul transit providers. They will
They will be able to change long-haul providers without having to be able to change long-haul providers without having to renumber
renumber their organization. They can also be multihomed via the their organization. They can also be multihomed via the exchange to
exchange to more than one long-haul provider without having to have more than one long-haul provider without having to have address
address prefixes from each long-haul provider. Note that the prefixes from each long-haul provider. Note that the mechanisms used
mechanisms used for this type of provider selection and portability for this type of provider selection and portability are not discussed
are not discussed in the document. in the document.
3.1 Aggregatable Global Unicast Address Structure 3.1 Aggregatable Global Unicast Address Structure
The aggregatable global unicast address format is as follows: The aggregatable global unicast address format is as follows:
| 3 | 13 | 32 | 16 | 64 bits | | 3| 13 | 8 | 24 | 16 | 64 bits |
+---+-----+-----------+--------+--------------------------------+ +--+-----+---+--------+--------+--------------------------------+
|FP | TLA | NLA ID | SLA ID | Interface ID | |FP| TLA |RES| NLA | SLA | Interface ID |
| | ID | | | | | | ID | | ID | ID | |
+---+-----+-----------+--------+--------------------------------+ +--+-----+---+--------+--------+--------------------------------+
<--Public Topology---> Site <--Public Topology---> Site
<--------> <-------->
Topology Topology
<------Interface Identifier-----> <------Interface Identifier----->
Where Where
FP Format Prefix (001) FP Format Prefix (001)
TLA ID Top-Level Aggregation Identifier TLA ID Top-Level Aggregation Identifier
RES Reserved for future use
NLA ID Next-Level Aggregation Identifier NLA ID Next-Level Aggregation Identifier
SLA ID Site-Level Aggregation Identifier SLA ID Site-Level Aggregation Identifier
INTERFACE ID Interface Identifier INTERFACE ID Interface Identifier
The following sections specify each part of the IPv6 Aggregatable The following sections specify each part of the IPv6 Aggregatable
Global Unicast address format. Global Unicast address format.
3.2 Top-Level Aggregation ID 3.2 Top-Level Aggregation ID
Top-Level Aggregation Identifiers (TLA ID) are the top level in the Top-Level Aggregation Identifiers (TLA ID) are the top level in the
routing hierarchy. Default-free routers must have a routing table routing hierarchy. Default-free routers must have a routing table
entry for every active TLA ID and will probably have additional entry for every active TLA ID and will probably have additional
entries providing routing information for the TLA ID in which they entries providing routing information for the TLA ID in which they
are located. They may have additional entries in order to optimize are located. They may have additional entries in order to optimize
routing for their specific topology, but the routing topology at all routing for their specific topology, but the routing topology at all
levels must be designed to minimize the number of additional entries levels must be designed to minimize the number of additional entries
fed into the default free routing tables. fed into the default free routing tables.
This addressing format supports 8,192 (2^13) TLA ID's. Additional This addressing format supports 8,192 (2^13) TLA ID's. Additional
TLA ID's may be added by using this format for additional format TLA ID's may be added by either growing the TLA field to the right
prefixes. The addition of another FP will add another 8,192 TLA into the reserved field or by using this format for additional format
ID's. prefixes.
The rules for TLA ID assignment are defined in [TLAASN]. The issues relating to TLA ID assignment are beyond the scope of this
document. They will be described in a document under preparation.
3.3 Next-Level Aggregation Identifier 3.3 Reserved
The Reserved field is reserved for future use and must be set to
zero.
The Reserved field allows for future growth of the TLA and NLA fields
as appropriate. See section 4.0 for a discussion.
3.4 Next-Level Aggregation Identifier
Next-Level Aggregation Identifier's are used by organizations Next-Level Aggregation Identifier's are used by organizations
assigned a TLA ID to create an addressing hierarchy and to identify assigned a TLA ID to create an addressing hierarchy and to identify
sites. The organization can assign the top part of the NLA ID in a sites. The organization can assign the top part of the NLA ID in a
manner to create an addressing hierarchy appropriate to its network. manner to create an addressing hierarchy appropriate to its network.
It can use the remainder of the bits in the field to identify sites It can use the remainder of the bits in the field to identify sites
it wishes to serve. This is shown as follows: it wishes to serve. This is shown as follows:
| n | 32-n bits | 16 | 64 bits | | n | 24-n bits | 16 | 64 bits |
+-----+--------------------+--------+-----------------+ +-----+--------------------+--------+-----------------+
|NLA1 | Site ID | SLA ID | Interface ID | |NLA1 | Site ID | SLA ID | Interface ID |
+-----+--------------------+--------+-----------------+ +-----+--------------------+--------+-----------------+
Each organization assigned a TLA ID receives 32 bits of NLA ID space. Each organization assigned a TLA ID receives 24 bits of NLA ID space.
This NLA ID space allows each organization to provide service to This NLA ID space allows each organization to provide service to
approximately as many organizations as the current IPv4 Internet can approximately as many organizations as the current IPv4 Internet can
support total nodes. support total networks.
Organizations assigned TLA ID's may also support NLA ID's in their Organizations assigned TLA ID's may also support NLA ID's in their
own Site ID space. This allows the organization assigned a TLA ID to own Site ID space. This allows the organization assigned a TLA ID to
provide service to organizations providing public transit service and provide service to organizations providing public transit service and
to organizations who do not provide public transit service. These to organizations who do not provide public transit service. These
organizations receiving an NLA ID may also choose to use their Site organizations receiving an NLA ID may also choose to use their Site
ID space to support other NLA ID's. This is shown as follows: ID space to support other NLA ID's. This is shown as follows:
| n | 32-n bits | 16 | 64 bits | | n | 24-n bits | 16 | 64 bits |
+-----+--------------------+--------+-----------------+ +-----+--------------------+--------+-----------------+
|NLA1 | Site ID | SLA ID | Interface ID | |NLA1 | Site ID | SLA ID | Interface ID |
+-----+--------------------+--------+-----------------+ +-----+--------------------+--------+-----------------+
| m | 32-n-m | 16 | 64 bits | | m | 24-n-m | 16 | 64 bits |
+-----+--------------+--------+-----------------+ +-----+--------------+--------+-----------------+
|NLA2 | Site ID | SLA ID | Interface ID | |NLA2 | Site ID | SLA ID | Interface ID |
+-----+--------------+--------+-----------------+ +-----+--------------+--------+-----------------+
| o |32-n-m-o| 16 | 64 bits | | o |24-n-m-o| 16 | 64 bits |
+-----+--------+--------+-----------------+ +-----+--------+--------+-----------------+
|NLA3 | Site ID| SLA ID | Interface ID | |NLA3 | Site ID| SLA ID | Interface ID |
+-----+--------+--------+-----------------+ +-----+--------+--------+-----------------+
The rules for NLA ID assignment are defined in [TLAASN].
The design of the bit layout of the NLA ID space for a specific TLA The design of the bit layout of the NLA ID space for a specific TLA
ID is left to the organization responsible for that TLA ID. Likewise ID is left to the organization responsible for that TLA ID. Likewise
the design of the bit layout of the next level NLA ID is the the design of the bit layout of the next level NLA ID is the
responsibility of the previous level NLA ID. It is recommended that responsibility of the previous level NLA ID. It is recommended that
organizations assigning NLA address space use "slow start" allocation organizations assigning NLA address space use "slow start" allocation
procedures as is currently done with IPv4 CIDR blocks. procedures similar to [RFC2050].
The design of an NLA ID allocation plan is a tradeoff between routing The design of an NLA ID allocation plan is a tradeoff between routing
aggregation efficiency and flexibility. Creating hierarchies allows aggregation efficiency and flexibility. Creating hierarchies allows
for greater amount of aggregation and results in smaller routing for greater amount of aggregation and results in smaller routing
tables. Flat NLA ID assignment provides for easier allocation and tables. Flat NLA ID assignment provides for easier allocation and
attachment flexibility, but results in larger routing tables. attachment flexibility, but results in larger routing tables.
3.4 Site-Level Aggregation Identifier 3.5 Site-Level Aggregation Identifier
The SLA ID field is used by an individual organization to create its The SLA ID field is used by an individual organization to create its
own local addressing hierarchy and to identify subnets. This is own local addressing hierarchy and to identify subnets. This is
analogous to subnets in IPv4 except that each organization has a much analogous to subnets in IPv4 except that each organization has a much
greater number of subnets. The 16 bit SLA ID field support 65,535 greater number of subnets. The 16 bit SLA ID field support 65,535
individual subnets. individual subnets.
Organizations may choose to either route their SLA ID "flat" (e.g., Organizations may choose to either route their SLA ID "flat" (e.g.,
not create any logical relationship between the SLA identifiers that not create any logical relationship between the SLA identifiers that
results in larger routing tables), or to create a two or more level results in larger routing tables), or to create a two or more level
skipping to change at page 7, line 24 skipping to change at page 7, line 24
The approach chosen for structuring an SLA ID field is the The approach chosen for structuring an SLA ID field is the
responsibility of the individual organization. responsibility of the individual organization.
The number of subnets supported in this address format should be The number of subnets supported in this address format should be
sufficient for all but the largest of organizations. Organizations sufficient for all but the largest of organizations. Organizations
which need additional subnets can arrange with the organization they which need additional subnets can arrange with the organization they
are obtaining Internet service from to obtain additional site are obtaining Internet service from to obtain additional site
identifiers and use this to create additional subnets. identifiers and use this to create additional subnets.
3.5 Interface ID 3.6 Interface ID
Interface identifiers are used to identify interfaces on a link. Interface identifiers are used to identify interfaces on a link.
They are required to be unique on that link. They may also be unique They are required to be unique on that link. They may also be unique
over a broader scope. In many cases an interface's identifier will over a broader scope. In many cases an interfaces identifier will be
be the same or be based on the interface's link-layer address. the same or be based on the interface's link-layer address.
Interface IDs used in the aggregatable global unicast address format Interface IDs used in the aggregatable global unicast address format
are required to be 64 bits long and to be constructed in IEEE EUI-64 are required to be 64 bits long and to be constructed in IEEE EUI-64
format [EUI-64]. These identifiers may have global scope when a format [EUI-64]. These identifiers may have global scope when a
global token (e.g., IEEE 48bit MAC) is available or may have local global token (e.g., IEEE 48bit MAC) is available or may have local
scope where a global token is not available (e.g., serial links, scope where a global token is not available (e.g., serial links,
tunnel end-points, etc.). The "u" bit (universal/local bit in IEEE tunnel end-points, etc.). The "u" bit (universal/local bit in IEEE
EUI-64 terminology) in the EUI-64 identifier must be set correctly, EUI-64 terminology) in the EUI-64 identifier must be set correctly,
as defined in [ARCH], to indicate global or local scope. as defined in [ARCH], to indicate global or local scope.
The procedures for creating EUI-64 based Interface Identifiers is The procedures for creating EUI-64 based Interface Identifiers is
defined in [ARCH]. The details on forming interface identifiers is defined in [ARCH]. The details on forming interface identifiers is
defined in the appropriate "IPv6 over <link>" specification such as defined in the appropriate "IPv6 over <link>" specification such as
"IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
4.0 Acknowledgments 4.0 Technical Motivation
The design choices for the size of the fields in the aggregatable
address format were based on the need to meet a number of technical
requirements. These are described in the following paragraphs.
The size of the Top-Level Aggregation Identifier is 13 bits. This
allows for 8,192 TLA ID's. This size was chosen to insure that the
default-free routing table in top level routers in the Internet is
kept within the limits, with a reasonable margin, of the current
routing technology. The margin is important because default-free
routers will also carry a significant number of longer (i.e., more-
specific) prefixes for optimizing paths internal to a TLA and between
TLAs.
The important issue is not only the size of the default-free routing
table, but the complexity of the topology that determines the number
of copies of the default-free routes that a router must examine while
computing a forwarding table. Current practice with IPv4 it is
common to see a prefix announced fifteen times via different paths.
The complexity of Internet topology is very likely to increase in the
future. It is important that IPv6 default-free routing support
additional complexity as well as a considerably larger internet.
It should be noted for comparison that the current IPv4 default-free
routing table is approximately 47,000 prefixes. While this shows
that it is possible to support more routes than 8,192 it is matter of
debate if the number of prefixes supported today in IPv4 is already
too high for current routing technology. There are serious issues of
route stability as well as cases of providers not supporting all top
level prefixes. The technical requirement was to pick a TLA ID size
that was below, with a reasonable margin, what was being done with
IPv4.
The choice of 13 bits for the TLA field was an engineering
compromise. Fewer bits would have been too small by not supporting
enough top level organizations. More bits would have exceeded what
can be reasonably accommodated, with a reasonable margin, with
current routing technology in order to deal with the issues described
in the previous paragraphs.
If in the future, routing technology improves to support a larger
number of top level routes in the default-free routing tables there
are two choices on how to increase the number TLA identifiers. The
first is to expand the TLA ID field into the reserved field. This
would increase the number of TLA ID's to approximately 2 million.
The second approach is to allocate another format prefix (FP) for use
with this address format. Either or a combination of these
approaches allows the number of TLA ID's to increase significantly.
The size of the Reserved field is 8 bits. This size was chosen to
allow significant growth of either the TLA ID and/or the NLA ID
fields.
The size of the Next-Level Aggregation Identifier field is 24 bits.
This allows for approximately sixteen million NLA ID's if used in a
flat manner. Used hierarchically it allows for a complexity roughly
equivalent to the IPv4 address space (assuming an average network
size of 254 interfaces). If in the future additional room for
complexity is needed in the NLA ID, this may be accommodated by
extending the NLA ID into the Reserved field.
The size of the Site-Level Aggregation Identifier field is 16 bits.
This supports 65,535 individual subnets per site. The design goal
for the size of this field was to be sufficient for all but the
largest of organizations. Organizations which need additional
subnets can arrange with the organization they are obtaining Internet
service from to obtain additional site identifiers and use this to
create additional subnets.
The Site-Level Aggregation Identifier field was given a fixed size in
order to force the length of all prefixes identifying a particular
site to be the same length (i.e., 48 bits). This facilitates
movement of sites in the topology (e.g., changing service providers
and multi-homing to multiple service providers).
The Interface ID Interface Identifier field is 64 bits. This size
was chosen to meet the requirement specified in [ARCH] to support
EUI-64 based Interface Identifiers.
5.0 Acknowledgments
The authors would like to express our thanks to Thomas Narten, Bob The authors would like to express our thanks to Thomas Narten, Bob
Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema, Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema,
Scott Bradner, Brian Carpenter, and John Stewart for their review and Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg
constructive comments. for their review and constructive comments.
5.0 References 6.0 References
[ALLOC] IAB and IESG, "IPv6 Address Allocation Management", [ALLOC] IAB and IESG, "IPv6 Address Allocation Management",
RFC1881, December 1995. RFC1881, December 1995.
[ARCH] Hinden, R., "IP Version 6 Addressing Architecture", [ARCH] Hinden, R., "IP Version 6 Addressing Architecture",
Internet Draft, <draft-ietf-ipngwg-addr-arch-v2-02.txt>, Internet Draft, <draft-ietf-ipngwg-addr-arch-v2-02.txt>,
July 1997. July 1997.
[AUTH] Atkinson, R., "IP Authentication Header", RFC1826, August [AUTH] Atkinson, R., "IP Authentication Header", RFC1826, August
1995. 1995.
[AUTO] Thompson, S., Narten T., "IPv6 Stateless Address [AUTO] Thompson, S., T. Narten., "IPv6 Stateless Address
Autoconfiguration", RFC1971, August 1996. Autoconfiguration", RFC1971, August 1996.
[CIDR] Fuller, V., T. Li, K. Varadhan, J. Yu, "Supernetting: an
Address Assignment and Aggregation Strategy", RFC1338.
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", Internet Draft, <draft-ietf-ipngwg-trans- Networks", Internet Draft, <draft-ietf-ipngwg-trans-
ethernet-00.txt>, March 1997. ethernet-00.txt>, March 1997.
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority", Registration Authority",
http://standards.ieee.org/db/oui/tutorials/EUI64.html, http://standards.ieee.org/db/oui/tutorials/EUI64.html,
March 1997. March 1997.
[EXCH] Huitema, C., R. Hinden, "Internet Exchanges", document
under preparation.
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
Networks", Internet Draft, <draft-ietf-ipngwg-trans-fddi- Networks", Internet Draft, <draft-ietf-ipngwg-trans-fddi-
net-00.txt>, March 1997. net-00.txt>, March 1997.
[IPV6] Deering, S., Hinden, R., Editors, "Internet Protocol, [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6
Version 6 (IPv6) Specification", RFC1883, December 1995. (IPv6) Specification", RFC1883, December 1995.
[RFC2050] Hubbard, K., M. Kosters, D. Conrad, D. Karrenberg, J.
Postel, "Internet Registry IP Allocation Guidelines",
RFC1466, BCP12, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC2119, BCP14, March 1997. Requirement Levels", RFC2119, BCP14, March 1997.
[TLAASN] Hinden, R., "TLA and NLA Assignment Rules", Internet Draft, 7.0 Security Considerations
<draft-ietf-ipngwg-tla-assignment-00.txt>, July 1997.
6.0 Security Considerations
IPv6 addressing documents do not have any direct impact on Internet IPv6 addressing documents do not have any direct impact on Internet
infrastructure security. Authentication of IPv6 packets is defined infrastructure security. Authentication of IPv6 packets is defined
in [AUTH]. in [AUTH].
7.0 Authors' Addresses 8.0 Authors' Addresses
Robert M. Hinden phone: 1 408 990-2004 Robert M. Hinden phone: 1 408 990-2004
Ipsilon Networks, Inc. email: hinden@ipsilon.com Nokia . email: hinden@ipsilon.com
232 Java Drive 232 Java Drive
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Mike O'Dell phone: 1 703 206-5890 Mike O'Dell phone: 1 703 206-5890
UUNET Technologies, Inc. email: mo@uunet.uu.net UUNET Technologies, Inc. email: mo@uunet.uu.net
3060 Williams Drive 3060 Williams Drive
Fairfax, VA 22030 Fairfax, VA 22030
USA USA
 End of changes. 32 change blocks. 
63 lines changed or deleted 147 lines changed or added

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