draft-ietf-ospf-ipv4-embedded-ipv6-routing-04.txt   draft-ietf-ospf-ipv4-embedded-ipv6-routing-05.txt 
Network Working Group D. Cheng Network Working Group D. Cheng
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational M. Boucadair Intended status: Informational M. Boucadair
Expires: January 14, 2013 France Telecom Expires: March 30, 2013 France Telecom
A. Retana A. Retana
Hewlett-Packard Co. Cisco Systems
July 13, 2012 September 26, 2012
Routing for IPv4-embedded IPv6 Packets Routing for IPv4-embedded IPv6 Packets
draft-ietf-ospf-ipv4-embedded-ipv6-routing-04 draft-ietf-ospf-ipv4-embedded-ipv6-routing-05
Abstract Abstract
This document describes routing packets destined to IPv4-embedded This document describes routing packets destined to IPv4-embedded
IPv6 addresses across an IPv6 core using OSPFv3 with a separate IPv6 addresses across an IPv6 core using OSPFv3 with a separate
routing table. routing table.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2013. This Internet-Draft will expire on March 30, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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/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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
Table . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Table . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. OSPFv3 Topology with a Separate Instance ID . . . . . . . 7 3.3. OSPFv3 Topology with a Separate Instance ID . . . . . . . 7
3.4. OSPFv3 Topology with the Default Instance . . . . . . . . 7 3.4. OSPFv3 Topology with the Default Instance . . . . . . . . 7
4. IP Packets Translation . . . . . . . . . . . . . . . . . . . . 7 4. IP Packets Translation . . . . . . . . . . . . . . . . . . . . 7
4.1. Address Translation . . . . . . . . . . . . . . . . . . . 8 4.1. Address Translation . . . . . . . . . . . . . . . . . . . 8
5. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 8 5. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 8
5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6 5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6
Transit Network . . . . . . . . . . . . . . . . . . . . . 8 Transit Network . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 9 5.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 9
5.1.2. Forwarding Address . . . . . . . . . . . . . . . . . . 9 5.1.2. Forwarding Address . . . . . . . . . . . . . . . . . . 9
5.2. Advertising IPv4-embedded IPv6 Routes into an IPv6 5.2. Advertising IPv4 Addresses into Client Networks . . . . . 9
Backbone . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Using Inter-Area-Prefix-LSAs . . . . . . . . . . . . . 10
5.3. Advertising IPv4 Addresses into Client Networks . . . . . 10
6. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . . 10 6. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . . 10
7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . . 11 8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . . 10
9. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 11 9. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 11
10. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
14.1. Normative References . . . . . . . . . . . . . . . . . . . 12 14.1. Normative References . . . . . . . . . . . . . . . . . . . 12
14.2. Informative References . . . . . . . . . . . . . . . . . . 13 14.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This document describes a routing scenario where IPv4 packets are This document describes a routing scenario where IPv4 packets are
transported over an IPv6 network. transported over an IPv6 network.
In this document the following terminology is used: In this document the following terminology is used:
o An IPv4-embedded IPv6 address denotes an IPv6 address which o An IPv4-embedded IPv6 address denotes an IPv6 address which
contains an embedded 32-bit IPv4 address constructed according to contains an embedded 32-bit IPv4 address constructed according to
skipping to change at page 7, line 14 skipping to change at page 7, line 14
3.3. OSPFv3 Topology with a Separate Instance ID 3.3. OSPFv3 Topology with a Separate Instance ID
It is assumed that the scenario described in this document is under a It is assumed that the scenario described in this document is under a
single Autonomous System and, as such, an OSPFv3 instance ID (IID) is single Autonomous System and, as such, an OSPFv3 instance ID (IID) is
allocated locally and used for OSPFv3 operation dedicated to unicast allocated locally and used for OSPFv3 operation dedicated to unicast
IPv4-embedded IPv6 routing in an IPv6 network. This IID is IPv4-embedded IPv6 routing in an IPv6 network. This IID is
configured on OSPFv3 router interfaces that participate in the IPv4- configured on OSPFv3 router interfaces that participate in the IPv4-
embedded IPv6 topology. embedded IPv6 topology.
The range for a locally configured OSPFv3 IID is from 128 to 255, The range for a locally configured OSPFv3 IID is from 192 to 255,
inclusive, and this IID must be used to encode the "Instance ID" inclusive, and this IID must be used to encode the "Instance ID"
field in the packet header of OSPFv3 packets associated with the field in the packet header of OSPFv3 packets associated with the
OSPFv3 instance. OSPFv3 instance.
In addition, the "AF" bit in the OSPFv3 Option field MUST be set. In addition, the "AF" bit in the OSPFv3 Option field MUST be set.
During Hello packet processing, an adjacency may only be established During Hello packet processing, an adjacency may only be established
when the received Hello packet contains the same Instance ID as when the received Hello packet contains the same Instance ID as
configured on the receiving OSPFv3 interface. This insures that only configured on the receiving OSPFv3 interface. This insures that only
interfaces configured as part of the OSPFv3 unicast IPv4-embedded interfaces configured as part of the OSPFv3 unicast IPv4-embedded
skipping to change at page 8, line 7 skipping to change at page 8, line 7
For more details, the reader is referred to For more details, the reader is referred to
[I-D.ietf-ospf-mt-ospfv3]. [I-D.ietf-ospf-mt-ospfv3].
4. IP Packets Translation 4. IP Packets Translation
When transporting IPv4 packets across an IPv6 network with the When transporting IPv4 packets across an IPv6 network with the
mechanism described above, an IPv4 packet is translated to an IPv6 mechanism described above, an IPv4 packet is translated to an IPv6
packet at the ingress AFXLBR, and the IPv6 packet is translated back packet at the ingress AFXLBR, and the IPv6 packet is translated back
to an IPv4 packet at the egress AFXLBR. The IP packet translation is to an IPv4 packet at the egress AFXLBR. The IP packet translation is
accomplished in stateless manner according to rules specified in accomplished in stateless manner according to rules specified in
[RFC6145], with the address translation detail explained in the next [RFC6145], with the address translation details explained in the next
sub-section. sub-section.
4.1. Address Translation 4.1. Address Translation
Prior to address translation, an IPv6 prefix is allocated by the Prior to address translation, an IPv6 prefix is allocated by the
Autonomous System and it is used to form IPv4-embedded IPv6 Autonomous System and it is used to form IPv4-embedded IPv6
addresses. addresses.
The IPv6 prefix can either be the well-known IPv6 prefix (WKP) 64: The IPv6 prefix can either be the well-known IPv6 prefix (WKP) 64:
ff9b::/96, or a network-specific prefix that is unique to the ff9b::/96, or a network-specific prefix that is unique to the
Autonomous System; and for the later case, the IPv6 prefix length may Autonomous System; and for the latter case, the IPv6 prefix length
be 32, 40, 48, 56 or 64. In either case, this IPv6 prefix is used may be 32, 40, 48, 56 or 64. In either case, this IPv6 prefix is
during the address translation between an IPv4 address and an IPv4- used during the address translation between an IPv4 address and an
embedded IPv6 address, as described in [RFC6052]. IPv4-embedded IPv6 address, as described in [RFC6052].
During translation from an IPv4 header to an IPv6 header at an During translation from an IPv4 header to an IPv6 header at an
ingress AFXLBR, the source IPv4 address and destination IPv4 address ingress AFXLBR, the source IPv4 address and destination IPv4 address
are translated into the corresponding IPv6 source address and are translated into the corresponding IPv6 source address and
destination IPv6 address, respectively, and during translation from destination IPv6 address, respectively, and during translation from
an IPv6 header to an IPv4 header at an egress AFXLBR, the source IPv6 an IPv6 header to an IPv4 header at an egress AFXLBR, the source IPv6
address and destination IPv6 address are translated into the address and destination IPv6 address are translated into the
corresponding IPv4 source address and destination IPv4 address, corresponding IPv4 source address and destination IPv4 address,
respectively. Note that the address translation is accomplished in a respectively. Note that the address translation is accomplished in a
stateless manner. stateless manner.
5. Advertising IPv4-embedded IPv6 Routes 5. Advertising IPv4-embedded IPv6 Routes
In order to forward IPv4 packets to the proper destination across an In order to forward IPv4 packets to the proper destination across an
IPv6 network, IPv4 reachability needs to be disseminated throughout IPv6 network, IPv4 reachability needs to be disseminated throughout
the IPv6 network and this is performed by AFXLBRs that connect to the IPv6 network and this is performed by AFXLBRs that connect to
IPv4 client networks using OSPFv3. IPv4 client networks using OSPFv3.
With the scenario described in this document, i.e., a set of AFXLBRs With the scenario described in this document, i.e., a set of AFXLBRs
that inter-connect a bunch of IPv4 client networks with an IPv6 that inter-connect a bunch of IPv4 client networks with an IPv6
network, the IPv4 networks and IPv6 networks can belong to the same network, the IPv4 networks and IPv6 networks belong to separate and
or independent Autonomous Systems, and as such, these AFXLBRs should independent Autonomous Systems, and as such, these AFXLBRs behave as
behave as either Area Border Routers (ABRs) or AS Boundary Routers AS Boundary Routers (ASBRs).
(ASBRs), respectively.
5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6 Transit 5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6 Transit
Network Network
In this case, the IPv4 networks and IPv6 networks belong to separate
Autonomous Systems, and as such, the AFXLBRs are OSPF AS Boundary
Routers (ASBRs).
IPv4 addresses and prefixes in an IPv4 client network are translated IPv4 addresses and prefixes in an IPv4 client network are translated
into IPv4-embedded IPv6 addresses and prefixes, respectively, using into IPv4-embedded IPv6 addresses and prefixes, respectively, using
the IPv6 prefix allocated by the Autonomous System and the method the IPv6 prefix allocated by the Autonomous System and the method
specified in [RFC6052]. These routes are then advertised by one or specified in [RFC6052]. These routes are then advertised by one or
more attached ASBRs into the IPv6 transit network using AS-External- more attached ASBRs into the IPv6 transit network using AS-External-
LSAs [RFC5340], i.e., with advertising scope comprising the entire LSAs [RFC5340], i.e., with advertising scope comprising the entire
Autonomous System. Autonomous System.
5.1.1. Routing Metrics 5.1.1. Routing Metrics
By default, the metric in an AS-External-LSA that carries an IPv4- By default, the metric in an AS-External-LSA that carries an IPv4-
embedded IPv6 address or prefixes is a Type 1 external metric, which embedded IPv6 address or prefixes is a Type 1 external metric, which
is added to the metric of the intra-AS path to the ASBR during the is comparable to the link state metric and we assume that in most
OSPFv3 route calculation. Through ASBR configuration, the metric can cases, OSPFv2 is used in client IPv4 networks. This metric is added
be set to a Type 2 external metric, which is considered much larger to the metric of the intra-AS path to the ASBR during the OSPFv3
than the metric for any intra-AS path. Refer to the OSPFv3 route calculation. Through ASBR configuration, the metric can be set
specification [RFC5340] for more detail. In either case, an external to a Type 2 external metric, which is considered much larger than the
metric may take the same value as in an IPv4 network (using OSPFv2 or metric for any intra-AS path. Refer to the OSPFv3 specification
another routing protocol), but may also be specified based on some [RFC5340] for more detail. In either case, an external metric may
routing policy; the details of which are outside of the scope of this take the same value as in an IPv4 network (using OSPFv2 or another
routing protocol), but may also be specified based on some routing
policy; the details of which are outside of the scope of this
document. document.
5.1.2. Forwarding Address 5.1.2. Forwarding Address
If the "Forwarding Address" field of an OSPFv3 AS-External-LSA is If the "Forwarding Address" field of an OSPFv3 AS-External-LSA is
used to carry an IPv6 address, that must also be an IPv4-embedded used to carry an IPv6 address, that must also be an IPv4-embedded
IPv6 address where the embedded IPv4 address is the destination IPv6 address where the embedded IPv4 address is the destination
address in an IPv4 client network. However, since an AFXLBR sits on address in an IPv4 client network. However, since an AFXLBR sits on
the border of an IPv4 network and an IPv6 network, it is RECOMMENDED the border of an IPv4 network and an IPv6 network, it is RECOMMENDED
that the "Forwarding Address" field is not used, so that the AFXLBR that the "Forwarding Address" field is not used, so that the AFXLBR
can make the forwarding decision based on its own IPv4 routing table. can make the forwarding decision based on its own IPv4 routing table.
5.2. Advertising IPv4-embedded IPv6 Routes into an IPv6 Backbone 5.2. Advertising IPv4 Addresses into Client Networks
An alternate scenario is where the IPv4 and IPv6 networks belong to
the same Autonomous System. The routing information would then be
carried as internal (inter-area) through the backbone, which allows
us to keep the OSPFv2 client networks unchanged: for example, the
configuration of a stub area doesn't have to change if we want it to
receive internal information. In other words, the AFXLBRs will act
as ABRs between OSPFv2 and OSPFv3 areas.
In this case, the IPv6 area MUST be the OSPFv3 backbone and the IPv4
client networks MUST NOT be the backbone area in the OSPFv2 domain,
or be connected to it.
All AFXLBRs MUST identify themselves as Area Border Routers.
5.2.1. Using Inter-Area-Prefix-LSAs
IPv4 addresses and prefixes in an IPv4 client network are translated
into IPv4-embedded IPv6 addresses and prefixes, respectively, using
the IPv6 prefix allocated by the Autonomous System and the method
specified in [RFC6052]. These routes are then advertised by one or
more attached AFXLBRs into the IPv6 backbone using Inter-Area-Prefix-
LSAs. The process in [RFC5340] is modified so that the Inter-Area-
Prefix-LSAs are originated for prefixes contained in Intra-Area LSAs
(Type 1 and 2 [RFC2328]); prefixes originally contained in External-
LSAs SHOULD follow the process described in Section 5.1.
5.3. Advertising IPv4 Addresses into Client Networks
IPv4-embedded IPv6 routes injected into the IPv6 network from one IPv4-embedded IPv6 routes injected into the IPv6 network from one
IPv4 client network MAY be advertised into another IPv4 client IPv4 client network MAY be advertised into another IPv4 client
network, after the associated destination addresses and prefixes are network, after the associated destination addresses and prefixes are
translated back to IPv4 addresses and prefixes, respectively. For translated back to IPv4 addresses and prefixes, respectively. This
AS-External-LSAs, this operation is similar to normal OSPFv3 operation is similar to normal OSPFv3 operation, wherein an AS-
operation, wherein an AS-External-LSA can be advertised in a non- External-LSA can be advertised in a non-backbone area by default.
backbone area by default. For Inter-Area-Prefix-LSAs, this operation
is similar to the described in Section 5.2, wherein a Summary LSA is
originated by the AFXLBR if the prefix was included in an Inter-Area-
Prefix-LSA.
An IPv4 client network can limit which advertisements it receives An IPv4 client network can limit which advertisements it receives
through configuration. through configuration.
For the purpose of this document, IPv4-embedded IPv6 routes MUST NOT For the purpose of this document, IPv4-embedded IPv6 routes MUST NOT
be advertised into any IPv6 client networks that also connected to be advertised into any IPv6 client networks that also connected to
the IPv6 backbone/transit network. the IPv6 transit network.
6. Aggregation on IPv4 Addresses and Prefixes 6. Aggregation on IPv4 Addresses and Prefixes
In order to reduce the amount of LSAs that are injected to the IPv6 In order to reduce the amount of LSAs that are injected to the IPv6
network, an effort must be made to aggregate IPv4 addresses and network, an implementation should provide mechanisms to aggregate
prefixes at each AFXLBR prior to advertisement as IPv4-embedded IPv6 IPv4 addresses and prefixes at AFXLBR prior to advertisement as IPv4-
addresses and prefixes. embedded IPv6 addresses and prefixes. In general, the aggregation
practice should be based on routing policy, which is outside of the
scope of this document.
7. Forwarding 7. Forwarding
There are three cases in forwarding IP packets in the scenario There are three cases in forwarding IP packets in the scenario
described in this document: described in this document:
1. On an AFXLBR, if an IPv4 packet that is received on an interface 1. On an AFXLBR, if an IPv4 packet that is received on an interface
connecting to an IPv4 client network with a destination IPv4 connecting to an IPv4 client network with a destination IPv4
address belonging to another IPv4 client network, the header of address belonging to another IPv4 client network, the header of
the packet is translated to the corresponding IPv6 header as the packet is translated to the corresponding IPv6 header as
skipping to change at page 11, line 22 skipping to change at page 10, line 36
2. On an AFXLBR, if an IPv4-embedded IPv6 packet is received and the 2. On an AFXLBR, if an IPv4-embedded IPv6 packet is received and the
embedded destination IPv4 address is in its IPv4 routing table, embedded destination IPv4 address is in its IPv4 routing table,
the header of the packet is translated to the corresponding IPv4 the header of the packet is translated to the corresponding IPv4
header as described in Section 4, and the packet is then header as described in Section 4, and the packet is then
forwarded accordingly. forwarded accordingly.
3. On any router that is within the IPv4-embedded IPv6 topology 3. On any router that is within the IPv4-embedded IPv6 topology
subset of the IPv6 network, if an IPv4-embedded IPv6 packet is subset of the IPv6 network, if an IPv4-embedded IPv6 packet is
received and a route is found in the IPv4-embedded IPv6 routing received and a route is found in the IPv4-embedded IPv6 routing
table, the packet is forwarded accordingly. table, the packet is forwarded to the IPv6 next-hop just like the
handling for a normal IPv6 packet, without any translation.
The classification of IPv4-embedded IPv6 packet is according to the The classification of IPv4-embedded IPv6 packet is according to the
IPv6 prefix of the destination address, which is either the Well IPv6 prefix of the destination address, which is either the Well
Known Prefix (i.e., 64:ff9b::/96) or locally allocated as defined in Known Prefix (i.e., 64:ff9b::/96) or locally allocated as defined in
[RFC6052]. [RFC6052].
8. Backdoor Connections 8. Backdoor Connections
In some deployments, IPv4 client networks are inter-connected across In some deployments, IPv4 client networks are inter-connected across
the IPv6 network, but also directly connected to each other. The the IPv6 network, but also directly connected to each other. The
"backdoor" connections between IPv4 client networks can certainly be "backdoor" connections between IPv4 client networks can certainly be
used to transport IPv4 packets between IPv4 client networks. In used to transport IPv4 packets between IPv4 client networks. In
general, backdoor connections are preferred over the IPv6 network, general, backdoor connections are preferred over the IPv6 network,
since there requires no address family translation. since there requires no address family translation.
In the case of using Inter-Area-Prefix-LSAs, the backdoor connection
MUST NOT be the backbone area in the OSPFv2 domain.
9. Prevention of Loops 9. Prevention of Loops
If a LSA sent from an AFXLBR into a client network could then be If an LSA sent from an AFXLBR into a client network could then be
received by another AFXLBR, it would be possible for routing loops to received by another AFXLBR, it would be possible for routing loops to
occur. To prevent loops, an AFXLBR MUST set the DN-bit [RFC4576] in occur. To prevent loops, an AFXLBR MUST set the DN-bit [RFC4576] in
any LSA that it sends to a client network. The AFXLBR MUST also any LSA that it sends to a client network. The AFXLBR MUST also
ignore any LSA received from a client network that already has the ignore any LSA received from a client network that already has the
DN-bit sent. DN-bit sent.
10. MTU Issues 10. MTU Issues
In the IPv6 network, there are no new MTU issues introduced by this In the IPv6 network, there are no new MTU issues introduced by this
document. If a separate OSPFv3 instance (per [RFC5838]) is used for document. If a separate OSPFv3 instance (per [RFC5838]) is used for
skipping to change at page 14, line 4 skipping to change at page 13, line 14
Authors' Addresses Authors' Addresses
Dean Cheng Dean Cheng
Huawei Technologies Huawei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, California 95050 Santa Clara, California 95050
USA USA
Email: dean.cheng@huawei.com Email: dean.cheng@huawei.com
Mohamed Boucadair Mohamed Boucadair
France Telecom France Telecom
Rennes, 35000 Rennes, 35000
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Alvaro Retana Alvaro Retana
Hewlett-Packard Co. Cisco Systems
2610 Wycliff Road 7025 Kit Creek Rd.
Raleigh, NC 27607 Research Triangle Park, North Carolina 27709
USA USA
Email: alvaro.retana@hp.com Email: aretana@cisco.com
 End of changes. 24 change blocks. 
85 lines changed or deleted 48 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/