draft-ietf-ospf-transition-to-ospfv3-02.txt   draft-ietf-ospf-transition-to-ospfv3-03.txt 
Internet Draft I. Chen Internet Draft I. Chen
<draft-ietf-ospf-transition-to-ospfv3-02.txt> Ericsson <draft-ietf-ospf-transition-to-ospfv3-03.txt> Ericsson
Intended Status: Standards Track A. Lindem Intended Status: Standards Track A. Lindem
Cisco Updates: 5838 Cisco
R. Atkinson R. Atkinson
Consultant Consultant
Expires in 6 months August 27, 2015 Expires in 6 months January 26, 2016
OSPFv3 over IPv4 for IPv6 Transition OSPFv3 over IPv4 for IPv6 Transition
<draft-ietf-ospf-transition-to-ospfv3-02.txt> <draft-ietf-ospf-transition-to-ospfv3-02.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.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 Internet-Draft will expire on date. This Internet-Draft will expire in 6 months.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as Copyright (c) 2016 IETF Trust and the persons identified as
the document authors. All rights reserved. the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Abstract
This document defines a mechanism to use IPv4 to transport OSPFv3 This document defines a mechanism to use IPv4 to transport OSPFv3
packets, in order to facilitate transition from IPv4-only to IPv6 and packets. Using OSPFv3 over IPv4 with the existing OSPFv3 Address
dual-stack within a routing domain. Using OSPFv3 over IPv4 with the Family extension can simplify transition from an OSFPv2 IPv4-only
existing OSPFv3 Address Family extension can simplify transition from routing domain to an OSPFv3 dual-stack routing domain. This document
an OSFPv2 IPv4-only routing domain to an OSPFv3 dual-stack routing updates RFC 5838 to support virtual links in the IPv4 unicast address
domain. family when using OSPFv3 over IPv4.
Table of Contents Table of Contents
1. Introduction ....................................................3 1. Introduction ....................................................3
2. Terminology .....................................................4 2. Terminology .....................................................4
3. Encapsulation in IPv4 ...........................................4 3. Encapsulation in IPv4 ...........................................4
3.1. Source Address .............................................6 3.1. Source Address .............................................6
3.2. Destination ................................................6 3.2. Destination ................................................6
3.3. Operation over Virtual Link ................................6 3.3. Operation over Virtual Link ................................6
4. IPv4-only Use Case ..............................................7 4. IPv4-only Use Case ..............................................7
5. Security Considerations .........................................7 5. Security Considerations .........................................7
6. IANA Considerations .............................................8 6. IANA Considerations .............................................8
7. References ......................................................8 7. References ......................................................8
1. Introduction 1. Introduction
To facilitate transition from IPv4 [RFC791] to IPv6 [RFC2460], dual- Using OSPFv3 [RFC5340] over IPv4 [RFC791] with the existing OSPFv3
stack or IPv6 routing protocols should be gradually deployed. Dual- Address Family extension can simplify transition from an IPv4-only
stack routing protocols, such as Border Gateway Protocol [RFC4271], routing domain to an IPv6 [RFC2460], or dual-stack routing domain.
have an advantage during the transition, because both IPv4 and IPv6 Dual-stack routing protocols, such as Border Gateway Protocol
topologies can be transported using either IPv4 or IPv6. Some [RFC4271], have an advantage during the transition, because both IPv4
IPv4-specific and IPv6-specific routing protocols share enough and IPv6 address families can be advertised using either IPv4 or
similarities in their protocol packet formats and protocol signaling IPv6. Some IPv4-specific and IPv6-specific routing protocols share
that it is trivial to deploy an initial IPv6 routing domain by enough similarities in their protocol packet formats and protocol
carrying the routing protocol over IPv4 initially, thereby allowing signaling that it is trivial to deploy an initial IPv6 routing domain
IPv6 routing domains be deployed and tested before decommissioning by transporting the routing protocol over IPv4, thereby allowing IPv6
IPv4 and moving to an IPv6-only network. routing domains to be deployed and tested 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 either to OSPFv3 or to IPv4. During the transition to IPv6, changes to either OSPFv3 or to IPv4. During the transition to IPv6,
future OSPF extension can focus on OSPFv3 and OSPFv2 can move into future OSPF extensions can focus on OSPFv3 and OSPFv2 can move to
maintenance mode. maintenance mode.
This document specifies how to use IPv4 packets to transport OSPFv3 This document specifies how to use IPv4 to transport OSPFv3 packets.
packets. The mechanism takes advantage of the fact that OSPFv2 and The mechanism takes advantage of the fact that OSPFv2 and OSPFv3
OSPFv3 share the same IP protocol number, 89. Additionally, the OSPF share the same IP protocol number, 89. Additionally, the OSPF packet
packet header for both OSPFv2 and OSPFv3 places the OSPF header header for both OSPFv2 and OSPFv3 includes the OSPF header version
version (i.e., the field that distinguishes an OSPFv2 packet from an (i.e., the field that distinguishes an OSPFv2 packet from an OSPFv3
OSPFv3 packet) in the same location. packet) in the same location (i.e., the same offset from the start of
the header).
This document does not attempt to connect an IPv4 topology and an
IPv6 topology that are not congruent. In normal operation, it is
expected that the IPv4 topology within the OSPF domain will be
congruent with the IPv6 topology of that OSPF domain. In such cases,
it is expected either that all OSPFv3 packets will be transported
over IPv4 or that all OSPFv3 packets will be transported over IPv6.
If the IPv4 topology and IPv6 topology are not identical, the most If the IPv4 topology and IPv6 topology are not identical, the most
likely cause is that some parts of the network deployment have not likely cause is that some parts of the network deployment have not
yet been upgraded to support both IPv4 and IPv6. In situations where yet been upgraded to support both IPv4 and IPv6. In situations where
the IPv4 deployment is a proper superset of the IPv6 deployment, it the IPv4 deployment is a proper superset of the IPv6 deployment, it
is expected that OSPFv3 packets would be transported over IPv4, until is expected that OSPFv3 packets would be transported over IPv4, until
the rest of the network deployment is upgraded to support IPv6 in the rest of the network deployment is upgraded to support IPv6 in
addition to IPv4. In situations where the IPv6 deployment is a addition to IPv4. In situations where the IPv6 deployment is a
proper superset of the IPv4 deployment, it is expected that OSPFv3 proper superset of the IPv4 deployment, it is expected that OSPFv3
would be transported over IPv6. would be 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 protocol. the Internet protocol.
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 Unlike 6to4 encapsulation [RFC3056] that tunnels IPv6 traffic through
an IPv4 network, an OSPFv3 packet can be directly encapsulated within an IPv4 network, an OSPFv3 packet can be directly encapsulated within
an IPv4 packet as the payload, without the IPv6 packet header, as an IPv4 packet as the payload, without the IPv6 packet header, as
illustrated in Figure 1. For OSPFv3 transported over IPv4, the IPv4 illustrated in Figure 1. For OSPFv3 transported over IPv4, the IPv4
packet has an IPv4 protocol type of 89, denoting that the payload is packet has an IPv4 protocol type of 89, denoting that the payload is
an OSPF packet. The payload of the IPv4 packet consists of an OSPFv3 an OSPF packet. The payload of the IPv4 packet consists of an OSPFv3
packet, beginning with the OSPF packet header with the OSPF version packet, beginning with the OSPF packet header having its OSPF version
number 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.
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
skipping to change at page 6, line 7 skipping to change at page 6, line 7
| | | |
| LLS Data | | LLS Data |
| | | |
+---------------+ +---------------+
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 IPv4 interface 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 MUST share the same IPv4 subnet for All OSPFv3 routers on the link MUST share the same IPv4 subnet for
IPv4 transport to function correctly. IPv4 transport to function correctly.
3.2. Destination Address 3.2. Destination Address
As defined in OSPFv2, the IPv4 destination address of an OSPF As defined in OSPFv2, the IPv4 destination address of an OSPF
protocol packet is either an IPv4 multicast address or the IPv4 protocol packet is either an IPv4 multicast address or the IPv4
unicast address of an OSPFv2 neighbor. Two well-known link-local unicast address of an OSPFv2 neighbor. Two well-known link-local
multicast addresses are assigned to OSPFv2, the AllSPFRouters multicast addresses are assigned to OSPFv2, the AllSPFRouters
address (224.0.0.5) and the AllDRouters address (224.0.0.6). The address (224.0.0.5) and the AllDRouters address (224.0.0.6). The
multicast address used depends on the OSPF packet type, the OSPF multicast address used depends on the OSPF packet type, the OSPF
interface type, and the OSPF router's role on multi-access interface type, and the OSPF router's role on multi-access
networks. networks.
Thus, for an OSPFv3 over IPv4 packet to be sent to AllSPFRouters, Thus, for an OSPFv3 over IPv4 packet to be sent to AllSPFRouters,
the destination address field in the IPv4 packet should be the destination address field in the IPv4 packet MUST be 224.0.0.5.
224.0.0.5. For an OSPFv3 over IPv4 packet to be sent to For an OSPFv3 over IPv4 packet to be sent to AllDRouters, the
AllDRouters, the destination address field in the IPv4 packet destination address field in the IPv4 packet MUST be 224.0.0.6.
should be 224.0.0.6.
When an OSPF router sends a unicast OSPF packet over a connected When an OSPF router sends a unicast OSPF packet over a connected
interface, the destination of such an IP packet is the address interface, the destination of such an IP packet is the address
assigned to the receiving interface. Thus, a unicast OSPFv3 packet assigned to the receiving interface. Thus, a unicast OSPFv3 packet
transported in an IPv4 packet would specify the OSPFv3 neighbor's transported in an IPv4 packet would specify the OSPFv3 neighbor's
IPv4 address as the destination address. IPv4 address as the destination address.
3.3. Operation over Virtual Link 3.3. Operation over Virtual Links
When an OSPF router sends an OSPF packet over a virtual link, the When an OSPF router sends an OSPF packet over a virtual link, the
receiving router is a router which is not directly connected to the receiving router is a router that might not be directly connected
sending router. Thus, the destination IP address of the IP packet to the sending router. Thus, the destination IP address of the IP
must be a reachable unicast IP address of the receiving router. packet must be a reachable unicast IP address for the virtual link
Because IPv6 is the presumed Internet protocol and an IPv4 endpoint. Because IPv6 is the presumed Internet protocol and an
destination is not routable, the OSPFv3 address family extension IPv4 destination is not routable, the OSPFv3 address family
[RFC5838] specifies that only IPv6 address family virtual links are extension [RFC5838] specifies that only IPv6 address family virtual
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, an IPv4 packet in which the transport over IPv4. As a result, OSPFv3 virtual links can be
destination field is a unicast IPv4 address assigned to the virtual supported with IPv4 address families by simply setting the IPv4
router is routable, and OSPFv3 virtual links in IPv4 unicast destination address to a reachable IPv4 unicast address for the
address families can be supported. Hence, the restriction in virtual link endpoint. Hence, the restriction in Section 2.8 of
Section 2.8 of RFC 5838 [RFC5838] is removed. If IPv4 transport, RFC 5838 [RFC5838] is removed. If IPv4 transport, as specified
as specified herein, is used for IPv6 address families, virtual herein, is used for IPv6 address families, virtual links cannot be
links cannot be supported. Hence, it is RECOMMENDED to use the IP supported. Hence, it is RECOMMENDED to use the IP transport
transport matching the address family in OSPF routing domains matching the address family in OSPF routing domains requiring
requiring virtual links. virtual links.
4. IPv4-only Use Case 4. IPv4-only Use Case
OSPFv3 only requires IPv6 link-local addresses to establish a routing OSPFv3 only requires IPv6 link-local addresses to form adjacencies,
domain, and does not require IPv6 global-scope addresses to establish and does not require IPv6 global-scope addresses to establish an IPv6
a routing domain. However, IPv6 over Ethernet [RFC2464] uses a routing domain. However, IPv6 over Ethernet [RFC2464] uses a
different EtherType (0x86dd) from IPv4 (0x0800) and also from the different EtherType (0x86dd) from IPv4 (0x0800) and the Address
Address Resolution Protocol (ARP) (0x0806) [RFC826] that is used with Resolution Protocol (ARP) (0x0806) [RFC826] used with IPv4.
IPv4.
Some existing deployed link-layer equipment only supports IPv4 and Some existing deployed link-layer equipment only supports IPv4 and
ARP. Such equipment contains hardware filters keyed on the EtherType ARP. Such equipment contains hardware filters keyed on the EtherType
field of the Ethernet frame to filter which frames will be accepted field of the Ethernet frame to filter which frames will be accepted
into that link-layer equipment. Because IPv6 uses a different by that link-layer equipment. Because IPv6 uses a different
EtherType, IPv6 framing for OSPFv3 won't work with that equipment. EtherType, IPv6 framing for OSPFv3 will not work with that equipment.
In other cases, PPP might be used over a serial interface, but again In other cases, PPP might be used over a serial interface, but again
only IPv4 over PPP might be supported over that interface. It is only IPv4 over PPP might be supported over such interface. It is
hoped that equipment with such limitations will be replaced hoped that equipment with such limitations will be eventually
eventually. upgraded or replaced.
In some locations, especially locations with less communications In some locations, especially locations with less communications
infrastructure, satellite communications (SATCOM) is used to reduce infrastructure, satellite communications (SATCOM) is used to reduce
deployment costs for data networking. SATCOM often has lower cost to deployment costs for data networking. SATCOM often has lower cost to
deploy than running new copper or optical cables for long distances deploy than running new copper or optical cables over long distances
to connect remote areas. Also, in a wide range of locations to connect remote areas. Also, in a wide range of locations
including places with good communications infrastructure, Very Small including places with good communications infrastructure, Very Small
Aperture Terminals (VSAT) often are used by banks and retailers to Aperture Terminals (VSAT) often are used by banks and retailers to
connect their stores to their main offices. connect their branches and stores to a central location.
Some widely deployed VSAT equipment has either (A) Ethernet Some widely deployed VSAT equipment has either (A) Ethernet
interfaces that only support Ethernet Address Resolution Protocol interfaces that only support Ethernet Address Resolution Protocol
(ARP) and IPv4, or (B) serial interfaces that only support IPv4 and (ARP) and IPv4, or (B) serial interfaces that only support IPv4 and
Point-to-Point Protocol (PPP) packets. Such deployments and Point-to-Point Protocol (PPP) packets. Such deployments and
equipment still can deploy and use OSPFv3 over IPv4 today, and then equipment still can deploy and use OSPFv3 over IPv4 today, and then
later migrate to OSPFv3 over IPv6 after equipment is upgraded or later migrate to OSPFv3 over IPv6 after equipment is upgraded or
replaced. This can have lower operational costs than running OSPFv2 replaced. This can have lower operational costs than running OSPFv2
and then trying to make a flag-day switch to running OSPFv3. By and then trying to make a flag-day switch to OSPFv3. By running
running OSPFv3 over IPv4 now, the eventual transition to dual-stack, OSPFv3 over IPv4 now, the eventual transition to dual-stack, and then
and then to IPv6-only can be optimized. to IPv6-only can be optimized.
5. Security Considerations 5. 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
authentication data in the Authentication Trailer includes the source authentication data in the Authentication Trailer includes the source
IPv6 address to protect an OSPFv3 router from Man-in-the-Middle IPv6 address to protect an OSPFv3 router from Man-in-the-Middle
attacks. For IPv4 encapsulation as described herein, the IPv4 source attacks. For IPv4 encapsulation as described herein, the IPv4 source
address should be placed in the first 4 octets of Apad followed by address should be placed in the first 4 octets of Apad followed by
the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times, where L is the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times, where L is
the length of hash measured in octet. 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 value Apad, transporting OSPFv3 packets except for calculation of the Apad value, transporting OSPFv3 packets
using IPv4 does not change the operation of the optional OSPFv3 using IPv4 does not change the generation or validation of the
Authentication Trailer. optional OSPFv3 Authentication Trailer.
6. IANA Considerations 6. 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. References 7. References
7.1. Normative References 7.1. Normative References
skipping to change at page 9, line 41 skipping to change at page 9, line 39
[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-
ospf-ospfv2-sec-01.txt", August 2009. ospf-ospfv2-sec-01.txt", August 2009.
Authors' Addresses Authors' Addresses
I. Chen I. Chen
Ericsson Ericsson
Email: ing-wher.chen@ericsson.com Email: ichen@kuatrotech.com
A. Lindem A. Lindem
Cisco Cisco
Email: acee@cisco.com Email: acee@cisco.com
R. Atkinson R. Atkinson
Consultant Consultant
 End of changes. 25 change blocks. 
82 lines changed or deleted 75 lines changed or added

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