draft-ietf-ospf-transition-to-ospfv3-09.txt   draft-ietf-ospf-transition-to-ospfv3-10.txt 
Internet Draft I. Chen Internet Draft I. Chen
<draft-ietf-ospf-transition-to-ospfv3-09.txt> Ericsson <draft-ietf-ospf-transition-to-ospfv3-10.txt> Ericsson
Intended Status: Standards Track A. Lindem Intended Status: Standards Track A. Lindem
Updates: 5838 Cisco Updates: 5838 Cisco
R. Atkinson R. Atkinson
Consultant Consultant
Expires in 6 months June 17, 2016 Expires in 6 months June 28, 2016
OSPFv3 over IPv4 for IPv6 Transition OSPFv3 over IPv4 for IPv6 Transition
<draft-ietf-ospf-transition-to-ospfv3-09.txt> <draft-ietf-ospf-transition-to-ospfv3-10.txt>
Status of this Memo Status of this Memo
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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
skipping to change at page 3, line 8 skipping to change at page 3, line 8
This document defines a mechanism to use IPv4 to transport OSPFv3 This document defines a mechanism to use IPv4 to transport OSPFv3
packets. Using OSPFv3 over IPv4 with the existing OSPFv3 Address packets. Using OSPFv3 over IPv4 with the existing OSPFv3 Address
Family extension can simplify transition from an OSPFv2 IPv4-only Family extension can simplify transition from an OSPFv2 IPv4-only
routing domain to an OSPFv3 dual-stack routing domain. This document routing domain to an OSPFv3 dual-stack routing domain. This document
updates RFC 5838 to support virtual links in the IPv4 unicast address updates RFC 5838 to support virtual links in the IPv4 unicast address
family when using OSPFv3 over IPv4. family when using OSPFv3 over IPv4.
Table of Contents Table of Contents
1. Introduction ....................................................3 1. Introduction ....................................................3
2. Terminology .....................................................4 1.1. IPv4-only Use Case .........................................4
3. Encapsulation in IPv4 ...........................................4 2. Terminology .....................................................5
3.1. Source Address .............................................6 3. Encapsulation in IPv4 ...........................................5
3.2. Destination ................................................6 3.1. Source Address .............................................7
3.3. Operation over Virtual Link ................................6 3.2. Destination ................................................7
4. IPv4-only Use Case ..............................................7 3.3. Operation over Virtual Link ................................7
5. Security Considerations .........................................8 4. Security Considerations .........................................8
6. IANA Considerations .............................................8 5. IANA Considerations .............................................8
7. Acknowledgments .................................................8 6. Acknowledgments .................................................8
8. References ......................................................8 7. References ......................................................9
7.1. Normative References........................................9
7.2. informative References......................................9
1. Introduction 1. Introduction
Using OSPFv3 [RFC5340] over IPv4 [RFC791] with the existing OSPFv3 Using OSPFv3 [RFC5340] over IPv4 [RFC791] with the existing OSPFv3
Address Family extension can simplify transition from an IPv4-only Address Family extension can simplify transition from an IPv4-only
routing domain to an IPv6 [RFC2460], or dual-stack routing domain. routing domain to an IPv6 [RFC2460], or dual-stack routing domain.
Dual-stack routing protocols, such as Border Gateway Protocol Dual-stack routing protocols, such as Border Gateway Protocol
[RFC4271], have an advantage during the transition, because both IPv4 [RFC4271], have an advantage during the transition, because both IPv4
and IPv6 address families can be advertised using either IPv4 or and IPv6 address families can be advertised using either IPv4 or IPv6
IPv6. Some IPv4-specific and IPv6-specific routing protocols share transport. Some IPv4-specific and IPv6-specific routing protocols
enough similarities in their protocol packet formats and protocol share enough similarities in their protocol packet formats and
signaling that it is trivial to deploy an initial IPv6 routing domain protocol signaling that it is trivial to deploy an initial IPv6
by transporting the routing protocol over IPv4, thereby allowing IPv6 routing domain by transporting the routing protocol over IPv4,
routing domains to be deployed and tested before decommissioning IPv4 thereby allowing IPv6 routing domains to be deployed and tested
and moving to an IPv6-only network. before decommissioning IPv4 and moving to an IPv6-only network.
In the case of the Open Shortest Path First (OSPF) interior gateway In the case of the Open Shortest Path First (OSPF) interior gateway
routing protocol (IGP), OSPFv2 [RFC2328] is the IGP deployed over routing protocol (IGP), OSPFv2 [RFC2328] is the IGP deployed over
IPv4, while OSPFv3 [RFC5340] is the IGP deployed over IPv6. OSPFv3 IPv4, while OSPFv3 [RFC5340] is the IGP deployed over IPv6. OSPFv3
further supports multiple address families [RFC5838], including both further supports multiple address families [RFC5838], including both
the IPv6 unicast address family and the IPv4 unicast address family. the IPv6 unicast address family and the IPv4 unicast address family.
Consequently, it is possible to deploy OSPFv3 over IPv4 without any Consequently, it is possible to deploy OSPFv3 over IPv4 without any
changes to either OSPFv3 or to IPv4. During the transition to IPv6, changes to either OSPFv3 or to IPv4. During the transition to IPv6,
future OSPF extensions can focus on OSPFv3 and OSPFv2 can move to future OSPF extensions can focus on OSPFv3 and OSPFv2 can move to
maintenance mode. maintenance mode.
skipping to change at page 4, line 20 skipping to change at page 4, line 22
superset of the IPv4 deployment, it is expected that OSPFv3 would be superset of the IPv4 deployment, it is expected that OSPFv3 would be
transported over IPv6. transported over IPv6.
Throughout this document, OSPF is used when the text applies to both Throughout this document, OSPF is used when the text applies to both
OSPFv2 and OSPFv3. OSPFv2 or OSPFv3 is used when the text is OSPFv2 and OSPFv3. OSPFv2 or OSPFv3 is used when the text is
specific to one version of the OSPF protocol. Similarly, IP is used specific to one version of the OSPF protocol. Similarly, IP is used
when the text describes either version of the Internet protocol. when the text describes either version of the Internet protocol.
IPv4 or IPv6 is used when the text is specific to a single version of IPv4 or IPv6 is used when the text is specific to a single version of
the Internet protocol. the Internet protocol.
1.1. IPv4-only Use Case
OSPFv3 only requires IPv6 link-local addresses to form adjacencies,
and does not require IPv6 global-scope addresses to establish an
IPv6 routing domain. However, IPv6 over Ethernet [RFC2464] uses a
different EtherType (0x86dd) from IPv4 (0x0800) and the Address
Resolution Protocol (ARP) (0x0806) [RFC826] used with IPv4.
Some existing deployed link-layer equipment only supports IPv4 and
ARP. Such equipment contains hardware filters keyed on the
EtherType field of the Ethernet frame to filter which frames will
be accepted by that link-layer equipment. Because IPv6 uses a
different EtherType, IPv6 framing for OSPFv3 will not work with
that equipment. In other cases, PPP might be used over a serial
interface, but again only IPv4 over PPP might be supported over
such interface. It is hoped that equipment with such limitations
will be eventually upgraded or replaced.
In some locations, especially locations with less communications
infrastructure, satellite communications (SATCOM) is used to reduce
deployment costs for data networking. SATCOM often has lower cost
to deploy than running new copper or optical cables over long
distances to connect remote areas. Also, in a wide range of
locations including places with good communications infrastructure,
Very Small Aperture Terminals (VSAT) often are used by banks and
retailers to connect their branches and stores to a central
location.
Some widely deployed VSAT equipment has either (A) Ethernet
interfaces that only support Ethernet Address Resolution Protocol
(ARP) and IPv4, or (B) serial interfaces that only support IPv4 and
Point-to-Point Protocol (PPP) packets. Such deployments and
equipment still can deploy and use OSPFv3 over IPv4 today, and then
later migrate to OSPFv3 over IPv6 after equipment is upgraded or
replaced. This can have lower operational costs than running
OSPFv2 and then trying to make a flag-day switch to OSPFv3. By
running OSPFv3 over IPv4 now, the eventual transition to dual-
stack, and then to IPv6-only can be optimized.
2. Terminology 2. Terminology
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Encapsulation in IPv4 3. Encapsulation in IPv4
Unlike 6to4 encapsulation [RFC3056] that tunnels IPv6 traffic through An OSPFv3 packet can be directly encapsulated within an IPv4 packet
an IPv4 network, an OSPFv3 packet can be directly encapsulated within as the payload, without the IPv6 packet header, as illustrated in
an IPv4 packet as the payload, without the IPv6 packet header, as Figure 1. For OSPFv3 transported over IPv4, the IPv4 packet has an
illustrated in Figure 1. For OSPFv3 transported over IPv4, the IPv4 IPv4 protocol type of 89, denoting that the payload is an OSPF
packet has an IPv4 protocol type of 89, denoting that the payload is packet. The payload of the IPv4 packet consists of an OSPFv3 packet,
an OSPF packet. The payload of the IPv4 packet consists of an OSPFv3 beginning with the OSPF packet header having its OSPF version field
packet, beginning with the OSPF packet header having its OSPF version set to 3.
field set to 3.
An OSPFv3 packet followed by an OSPF link-local signaling (LLS) An OSPFv3 packet followed by an OSPF link-local signaling (LLS)
extension data block [RFC5613] encapsulated in an IPv4 packet is extension data block [RFC5613] encapsulated in an IPv4 packet is
illustrated in Figure 2. illustrated in Figure 2.
Since an IPv4 header without options is only 20 bytes long and is
shorter than an IPv6 header, an OSPFv3 packet encapsulated in a
20-byte IPv4 header is shorter than an OSPFv3 packet encapsulated in
an IPv6 header. Consequently, the link MTU for IPv6 is sufficient to
transport an OSPFv3 packet encapsulated in a 20-byte IPv4 header. If
the link MTU is not sufficient to transport an OSPFv3 packet in IPv4,
then OSPFv3 can rely on IP fragmentation and reassembly [RFC791].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| 4 | IHL |Type of Service| Total Length | | | 4 | IHL |Type of Service| Total Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Identification |Flags| Fragment Offset | | | Identification |Flags| Fragment Offset | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol 89 | Header Checksum | IPv4 | Time to Live | Protocol 89 | Header Checksum | IPv4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header
| Source Address | | Source Address |
skipping to change at page 6, line 9 skipping to change at page 7, line 9
| | | |
+---------------+ +---------------+
Figure 2: The IPv4 packet encapsulating an OSPFv3 packet with Figure 2: The IPv4 packet encapsulating an OSPFv3 packet with
a trailing OSPF link-local signaling data block. a trailing OSPF link-local signaling data block.
3.1. Source Address 3.1. Source Address
For OSPFv3 over IPv4, the source address is the primary IPv4 For OSPFv3 over IPv4, the source address is the primary IPv4
address for the interface over which the packet is transmitted. address for the interface over which the packet is transmitted.
All OSPFv3 routers on the link SHOULD share the same IPv4 subnet All OSPFv3 routers on the link should share the same IPv4 subnet
for IPv4 transport to function correctly. for IPv4 transport to function correctly.
While OSPFv2 operates on a subnet, OSPFv3 operates on a link While OSPFv2 operates on a subnet, OSPFv3 operates on a link
[RFC5340]. Accordingly, an OSPFv3 router implementation MAY [RFC5340]. Accordingly, an OSPFv3 router implementation MAY
support adjacencies with OSPFv3 neighbors on different IPv4 support adjacencies with OSPFv3 neighbors on different IPv4
subnets. If this is supported, the IPv4 data plane MUST resolve subnets. If this is supported, the IPv4 data plane MUST resolve
IPv4 addresses to layer-2 addresses using Address Resolution IPv4 addresses to layer-2 addresses using Address Resolution
Protocol (ARP) on multi-access networks and point-to-point over LAN Protocol (ARP) on multi-access networks and point-to-point over LAN
[RFC5309] for direct next-hops on different IPv4 subnets. When [RFC5309] for direct next-hops on different IPv4 subnets. When
OSPFv3 adjacencies on different IPv4 subnets are supported, OSPFv3 adjacencies on different IPv4 subnets are supported,
skipping to change at page 7, line 16 skipping to change at page 8, line 16
links are supported. links are supported.
As illustrated in Figure 1, this document specifies OSPFv3 As illustrated in Figure 1, this document specifies OSPFv3
transport over IPv4. As a result, OSPFv3 virtual links can be transport over IPv4. As a result, OSPFv3 virtual links can be
supported with IPv4 address families by simply setting the IPv4 supported with IPv4 address families by simply setting the IPv4
destination address to a reachable IPv4 unicast address for the destination address to a reachable IPv4 unicast address for the
virtual link endpoint. Hence, the restriction in Section 2.8 of virtual link endpoint. Hence, the restriction in Section 2.8 of
RFC 5838 [RFC5838] is relaxed since virtual links can now be RFC 5838 [RFC5838] is relaxed since virtual links can now be
supported for IPv4 address families as long as the transport is supported for IPv4 address families as long as the transport is
also IPv4. If IPv4 transport, as specified herein, is used for also IPv4. If IPv4 transport, as specified herein, is used for
IPv6 address families, virtual links cannot be supported. Hence, it IPv6 address families, virtual links cannot be supported. Hence, in
is RECOMMENDED to use the IP transport matching the address family OSPF routing domains that require virtual links, the IP transport
in OSPF routing domains requiring virtual links. MUST match the address family (IPv4 or IPv6).
4. IPv4-only Use Case
OSPFv3 only requires IPv6 link-local addresses to form adjacencies,
and does not require IPv6 global-scope addresses to establish an IPv6
routing domain. However, IPv6 over Ethernet [RFC2464] uses a
different EtherType (0x86dd) from IPv4 (0x0800) and the Address
Resolution Protocol (ARP) (0x0806) [RFC826] used with IPv4.
Some existing deployed link-layer equipment only supports IPv4 and
ARP. Such equipment contains hardware filters keyed on the EtherType
field of the Ethernet frame to filter which frames will be accepted
by that link-layer equipment. Because IPv6 uses a different
EtherType, IPv6 framing for OSPFv3 will not work with that equipment.
In other cases, PPP might be used over a serial interface, but again
only IPv4 over PPP might be supported over such interface. It is
hoped that equipment with such limitations will be eventually
upgraded or replaced.
In some locations, especially locations with less communications
infrastructure, satellite communications (SATCOM) is used to reduce
deployment costs for data networking. SATCOM often has lower cost to
deploy than running new copper or optical cables over long distances
to connect remote areas. Also, in a wide range of locations
including places with good communications infrastructure, Very Small
Aperture Terminals (VSAT) often are used by banks and retailers to
connect their branches and stores to a central location.
Some widely deployed VSAT equipment has either (A) Ethernet
interfaces that only support Ethernet Address Resolution Protocol
(ARP) and IPv4, or (B) serial interfaces that only support IPv4 and
Point-to-Point Protocol (PPP) packets. Such deployments and
equipment still can deploy and use OSPFv3 over IPv4 today, and then
later migrate to OSPFv3 over IPv6 after equipment is upgraded or
replaced. This can have lower operational costs than running OSPFv2
and then trying to make a flag-day switch to OSPFv3. By running
OSPFv3 over IPv4 now, the eventual transition to dual-stack, and then
to IPv6-only can be optimized.
5. Security Considerations 4. Security Considerations
As described in [RFC4552], OSPFv3 uses IPsec [RFC4301] for As described in [RFC4552], OSPFv3 uses IPsec [RFC4301] for
authentication and confidentiality. Consequently, an OSPFv3 packet authentication and confidentiality. Consequently, an OSPFv3 packet
transported within an IPv4 packet requires IPsec to provide transported within an IPv4 packet requires IPsec to provide
authentication and confidentiality. Further work such as [ipsecospf] authentication and confidentiality. Further work such as [ipsecospf]
would be required to support IPsec protection for OSPFv3 over IPv4 would be required to support IPsec protection for OSPFv3 over IPv4
transport. transport.
An optional OSPFv3 Authentication Trailer [RFC7166] also has been An optional OSPFv3 Authentication Trailer [RFC7166] also has been
defined as an alternative to using IPsec. The calculation of the defined as an alternative to using IPsec. The calculation of the
skipping to change at page 8, line 36 skipping to change at page 8, line 46
the length of hash measured in octets. the length of hash measured in octets.
The processing of the optional Authentication Trailer is contained The processing of the optional Authentication Trailer is contained
entirely within the OSPFv3 protocol. In other words, each OSPFv3 entirely within the OSPFv3 protocol. In other words, each OSPFv3
router instance is responsible for the authentication, without router instance is responsible for the authentication, without
involvement from IPsec or any other IP layer function. Consequently, involvement from IPsec or any other IP layer function. Consequently,
except for calculation of the Apad value, transporting OSPFv3 packets except for calculation of the Apad value, transporting OSPFv3 packets
using IPv4 does not change the generation or validation of the using IPv4 does not change the generation or validation of the
optional OSPFv3 Authentication Trailer. optional OSPFv3 Authentication Trailer.
6. IANA Considerations 5. IANA Considerations
No actions are required from IANA as result of the publication of No actions are required from IANA as result of the publication of
this document. this document.
7. Acknowledgments 6. Acknowledgments
The authors would like to thank Alexander Okonnikov for his thorough The authors would like to thank Alexander Okonnikov for his thorough
review and valuable feedback. The authors would also like to thank review and valuable feedback. The authors would also like to thank
Wenhu Lu for acting as document shepherd. Wenhu Lu for acting as document shepherd.
8. References 7. References
8.1. Normative References 7.1. Normative References
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981. 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
skipping to change at page 9, line 25 skipping to change at page 9, line 34
R. Aggarwal, "Support of Address Families in OSPFv3", RFC R. Aggarwal, "Support of Address Families in OSPFv3", RFC
5838, April 2010. 5838, April 2010.
[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.
[RFC5309] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point [RFC5309] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point
Operation over LAN in Link State Routing Protocols", RFC Operation over LAN in Link State Routing Protocols", RFC
5309, October 2008. 5309, October 2008.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 7.2. Informative References
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI
10.17487/RFC5881, June 2010.
8.2. Informative References
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, January Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
2006. 2006.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009.
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37, Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, November 1982. RFC 826, November 1982.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998. Networks", RFC 2464, December 1998.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI
10.17487/RFC5881, June 2010.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, June 2006. for OSPFv3", RFC 4552, June 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 7166, March 2014. Authentication Trailer for OSPFv3", RFC 7166, March 2014.
[ipsecospf] Gupta, M. and Melam, M, Work in progress, "draft-gupta- [ipsecospf] Gupta, M. and Melam, M, Work in progress, "draft-gupta-
 End of changes. 19 change blocks. 
85 lines changed or deleted 91 lines changed or added

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