draft-ietf-ospf-transition-to-ospfv3-12.txt   rfc7949.txt 
Internet Draft I. Chen Internet Engineering Task Force (IETF) I. Chen
<draft-ietf-ospf-transition-to-ospfv3-12.txt> Ericsson Request for Comments: 7949 Ericsson
Intended Status: Standards Track A. Lindem Updates: 5838 A. Lindem
Updates: 5838 Cisco Category: Standards Track Cisco
R. Atkinson ISSN: 2070-1721 R. Atkinson
Consultant Consultant
Expires in 6 months June 30, 2016 August 2016
OSPFv3 over IPv4 for IPv6 Transition OSPFv3 over IPv4 for IPv6 Transition
<draft-ietf-ospf-transition-to-ospfv3-12.txt>
Status of this Memo
Distribution of this memo is unlimited.
This Internet-Draft is submitted in full conformance with the Abstract
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document defines a mechanism to use IPv4 to transport OSPFv3
Task Force (IETF), its areas, and its working groups. Note that packets. Using OSPFv3 over IPv4 with the existing OSPFv3 Address
other groups may also distribute working documents as Internet- Family extension can simplify transition from an OSPFv2 IPv4-only
Drafts. routing domain to an OSPFv3 dual-stack routing domain. This document
updates RFC 5838 to support virtual links in the IPv4 unicast address
family when using OSPFv3 over IPv4.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire in 6 months. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7949.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as Copyright (c) 2016 IETF Trust and the persons identified as the
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
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
This document defines a mechanism to use IPv4 to transport OSPFv3
packets. Using OSPFv3 over IPv4 with the existing OSPFv3 Address
Family extension can simplify transition from an OSPFv2 IPv4-only
routing domain to an OSPFv3 dual-stack routing domain. This document
updates RFC 5838 to support virtual links in the IPv4 unicast address
family when using OSPFv3 over IPv4.
Table of Contents Table of Contents
1. Introduction ....................................................3 1. Introduction ....................................................2
1.1. IPv4-only Use Case .........................................4 1.1. IPv4-Only Use Case .........................................3
2. Terminology .....................................................5 2. Requirements Language ...........................................4
3. Encapsulation in IPv4 ...........................................5 3. Encapsulation in IPv4 ...........................................4
3.1. Source Address .............................................7 3.1. Source Address .............................................6
3.2. Destination ................................................7 3.2. Destination Address ........................................6
3.3. OSPFv3 Header Checksum .....................................7 3.3. OSPFv3 Header Checksum .....................................6
3.4. Operation over Virtual Link ................................8 3.4. Operation over Virtual Links ...............................7
4. Management Considerations .......................................8 4. Management Considerations .......................................7
4.1. Coexistence with OSPFv2 ....................................8 4.1. Coexistence with OSPFv2 ....................................7
5. Security Considerations .........................................9 5. Security Considerations .........................................8
6. IANA Considerations .............................................9 6. References ......................................................8
7. Acknowledgments .................................................9 6.1. Normative References .......................................8
8. References .....................................................10 6.2. Informative References .....................................9
8.1. Normative References.......................................10 Acknowledgments ...................................................10
8.2. informative References.....................................10 Authors' Addresses ................................................11
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 the 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 IPv6 and IPv6 address families can be advertised using either IPv4 or IPv6
transport. Some IPv4-specific and IPv6-specific routing protocols transport. Some IPv4-specific and IPv6-specific routing protocols
share enough similarities in their protocol packet formats and share enough similarities in their protocol packet formats and
protocol signaling that it is trivial to deploy an initial IPv6 protocol signaling that it is trivial to deploy an initial IPv6
routing domain by transporting the routing protocol over IPv4, routing domain by transporting the routing protocol over IPv4,
thereby allowing IPv6 routing domains to be deployed and tested thereby allowing IPv6 routing domains to be deployed and tested
before decommissioning IPv4 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 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.
This document specifies how to use IPv4 to transport OSPFv3 packets. This document specifies how to use IPv4 to transport OSPFv3 packets.
The mechanism takes advantage of the fact that OSPFv2 and OSPFv3 The mechanism takes advantage of the fact that OSPFv2 and OSPFv3
share the same IP protocol number, 89. Additionally, the OSPF packet share the same IP protocol number, 89. Additionally, the OSPF packet
header for both OSPFv2 and OSPFv3 includes the OSPF header version header for both OSPFv2 and OSPFv3 includes the OSPF header version
(i.e., the field that distinguishes an OSPFv2 packet from an OSPFv3 (i.e., the field that distinguishes an OSPFv2 packet from an OSPFv3
packet) in the same location (i.e., the same offset from the start of packet) in the same location (i.e., the same offset from the start of
the header). the header).
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 superset of the IPv6 deployment, it is the IPv4 deployment is a superset of the IPv6 deployment, it is
expected that OSPFv3 packets would be transported over IPv4, until 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
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
OSPFv2 and OSPFv3. OSPFv2 or OSPFv3 is used when the text is both OSPFv2 and OSPFv3. "OSPFv2" or "OSPFv3" is used when the text
specific to one version of the OSPF protocol. Similarly, IP is used is specific to one version of the OSPF protocol. Similarly, "IP" is
when the text describes either version of the Internet protocol. used 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
the Internet protocol. version of the Internet Protocol.
1.1. IPv4-only Use Case 1.1. IPv4-Only Use Case
OSPFv3 only requires IPv6 link-local addresses to form adjacencies, OSPFv3 only requires IPv6 link-local addresses to form adjacencies,
and does not require IPv6 global-scope addresses to establish an and does not require IPv6 global-scope addresses to establish an IPv6
IPv6 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 the Address different EtherType (0x86dd) from IPv4 (0x0800) and the Address
Resolution Protocol (ARP) (0x0806) [RFC826] used with IPv4. Resolution Protocol (ARP) (0x0806) [RFC826] used with 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 ARP. Such equipment contains hardware filters keyed on the EtherType
EtherType field of the Ethernet frame to filter which frames will field of the Ethernet frame to filter which frames will be accepted
be accepted by that link-layer equipment. Because IPv6 uses a by that link-layer equipment. Because IPv6 uses a different
different EtherType, IPv6 framing for OSPFv3 will not work with EtherType, IPv6 framing for OSPFv3 will not work with that equipment.
that equipment. In other cases, PPP might be used over a serial In other cases, Point-to-Point Protocol (PPP) might be used over a
interface, but again only IPv4 over PPP might be supported over serial interface, but again only IPv4 over PPP might be supported
such interface. It is hoped that equipment with such limitations over such an interface. It is hoped that equipment with such
will be eventually upgraded or replaced. limitations will be 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) are used to reduce
deployment costs for data networking. SATCOM often has lower cost deployment costs for data networking. SATCOM often has lower cost to
to deploy than running new copper or optical cables over long deploy than running new copper or optical cables over long distances
distances to connect remote areas. Also, in a wide range of to connect remote areas. Also, in a wide range of locations
locations including places with good communications infrastructure, including places with good communications infrastructure, Very Small
Very Small Aperture Terminals (VSAT) often are used by banks and Aperture Terminals (VSATs) often are used by banks and retailers to
retailers to connect their branches and stores to a central connect their branches and stores to a central location.
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 the 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 PPP packets. Such deployments and equipment still can deploy and use
equipment still can deploy and use OSPFv3 over IPv4 today, and then OSPFv3 over IPv4 today, and then later migrate to OSPFv3 over IPv6
later migrate to OSPFv3 over IPv6 after equipment is upgraded or after equipment is upgraded or replaced. This can have lower
replaced. This can have lower operational costs than running operational costs than running OSPFv2 and then trying to make a flag-
OSPFv2 and then trying to make a flag-day switch to OSPFv3. By day switch to OSPFv3. By running OSPFv3 over IPv4 now, the eventual
running OSPFv3 over IPv4 now, the eventual transition to dual- transition to dual-stack, and then to IPv6-only, can be orchestrated.
stack, and then to IPv6-only can be optimized.
2. Terminology 2. Requirements Language
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
An OSPFv3 packet can be directly encapsulated within an IPv4 packet An OSPFv3 packet can be directly encapsulated within an IPv4 packet
as the payload, without the IPv6 packet header, as illustrated in as the payload, without the IPv6 packet header, as illustrated in
Figure 1. For OSPFv3 transported over IPv4, the IPv4 packet has an Figure 1. For OSPFv3 transported over IPv4, the IPv4 packet has an
IPv4 protocol type of 89, denoting that the payload is an OSPF IPv4 protocol type of 89, denoting that the payload is an OSPF
packet. The payload of the IPv4 packet consists of an OSPFv3 packet, packet. The payload of the IPv4 packet consists of an OSPFv3 packet,
beginning with the OSPF packet header having its OSPF version field beginning with the OSPF packet header having its OSPF version field
set to 3. 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 Since an IPv4 header without options is only 20 octets long and is
shorter than an IPv6 header, an OSPFv3 packet encapsulated in a shorter than an IPv6 header, an OSPFv3 packet encapsulated in a
20-byte IPv4 header is shorter than an OSPFv3 packet encapsulated in 20-octet IPv4 header is shorter than an OSPFv3 packet encapsulated in
an IPv6 header. Consequently, the link MTU for IPv6 is sufficient to an IPv6 header. Consequently, the link MTU for IPv6 is sufficient to
transport an OSPFv3 packet encapsulated in a 20-byte IPv4 header. If transport an OSPFv3 packet encapsulated in a 20-octet IPv4 header.
the link MTU is not sufficient to transport an OSPFv3 packet in IPv4, If the link MTU is not sufficient to transport an OSPFv3 packet in
then OSPFv3 can rely on IP fragmentation and reassembly [RFC791]. 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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Destination Address | | | Destination Address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Options | Padding | v | Options | Padding | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| 3 | Type | Packet length | | | 3 | Type | Packet length | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Router ID | OSPFv3 | Router ID | OSPFv3
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <span class="insert">|</span>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header
| Area ID | | Area ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Checksum | Instance ID | 0 | | | Checksum | Instance ID | 0 | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| OSPFv3 Body ... | | OSPFv3 Body ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: An IPv4 packet encapsulating an OSPFv3 packet. Note: "IHL" stands for Internet Header Length.
Figure 1: An IPv4 Packet Encapsulating an OSPFv3 Packet
+---------------+ +---------------+
| IPv4 Header | | IPv4 Header |
+---------------+ +---------------+
| OSPFv3 Header | | OSPFv3 Header |
|...............| |...............|
| | | |
| OSPFv3 Body | | OSPFv3 Body |
| | | |
+---------------+ +---------------+
| | | |
| 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 primary IPv4 For OSPFv3 over IPv4, the source address is the primary IPv4 address
address for the interface over which the packet is transmitted. for the interface over which the packet is transmitted. All OSPFv3
All OSPFv3 routers on the link should share the same IPv4 subnet routers on the link should share the same IPv4 subnet for IPv4
for IPv4 transport to function correctly. 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
support adjacencies with OSPFv3 neighbors on different IPv4 adjacencies with OSPFv3 neighbors on different IPv4 subnets. If this
subnets. If this is supported, the IPv4 data plane MUST resolve is supported, the IPv4 data plane MUST resolve IPv4 addresses to
IPv4 addresses to layer-2 addresses using Address Resolution Layer 2 addresses using ARP on multi-access networks and point-to-
Protocol (ARP) on multi-access networks and point-to-point over LAN point over LAN [RFC5309] for direct next hops on different IPv4
[RFC5309] for direct next-hops on different IPv4 subnets. When subnets. When OSPFv3 adjacencies on different IPv4 subnets are
OSPFv3 adjacencies on different IPv4 subnets are supported, supported, Bidirectional Forwarding Detection (BFD) [RFC5881] cannot
Bidirectional Forwarding Detection (BFD) [RFC5881] cannot be used be used for adjacency loss detection since BFD is restricted to a
for adjacency loss detection since BFD is restricted to a single single subnet.
subnet.
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
address (224.0.0.5) and the AllDRouters address (224.0.0.6). The (224.0.0.5) and the AllDRouters address (224.0.0.6). The multicast
multicast address used depends on the OSPF packet type, the OSPF address used depends on the OSPF packet type, the OSPF interface
interface type, and the OSPF router's role on multi-access 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
the destination address field in the IPv4 packet MUST be 224.0.0.5. destination address field in the IPv4 packet MUST be 224.0.0.5. For
For an OSPFv3 over IPv4 packet to be sent to AllDRouters, the an OSPFv3-over-IPv4 packet to be sent to AllDRouters, the destination
destination address field in the IPv4 packet MUST be 224.0.0.6. address field in the IPv4 packet MUST 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. OSPFv3 Header Checksum 3.3. OSPFv3 Header Checksum
For IPv4 transport, the pseudo-header used in the checksum For IPv4 transport, the pseudo-header used in the checksum
calculation will contain the IPv4 source and destination addresses, calculation will contain the IPv4 source and destination addresses,
the OSPFv3 protocol ID, and the OSPFv3 length from the OSPFv3 the OSPFv3 protocol ID, and the OSPFv3 length from the OSPFv3 header
header (Appendix A.3.1 [RFC5340]). The format is similar to the (Appendix A.3.1 of [RFC5340]). The format is similar to the UDP
UDP pseudo-header as described in [RFC768] and is illustrated in pseudo-header as described in [RFC768] and is illustrated in
Figure 3. Figure 3.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address | | Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address | | Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Protocol (89) | OSPFv3 Packet Length | | 0 | Protocol (89) | OSPFv3 Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Pseudo-header for OSPFv3 over IPv4.
Figure 3: Pseudo-header for OSPFv3 over IPv4
3.4. Operation over Virtual Links 3.4. 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 that might not be directly connected receiving router might not be directly connected to the sending
to the sending router. Thus, the destination IP address of the IP router. Thus, the destination IP address of the IP packet must be a
packet must be a reachable unicast IP address for the virtual link reachable unicast IP address for the virtual link endpoint. Because
endpoint. Because IPv6 is the presumed Internet protocol and an IPv6 is the presumed Internet protocol and an IPv4 destination is not
IPv4 destination is not routable, the OSPFv3 address family routable, the OSPFv3 address family extension [RFC5838] specifies
extension [RFC5838] specifies that only IPv6 address family virtual that only virtual links in the IPv6 address family are supported.
links are supported.
As illustrated in Figure 1, this document specifies OSPFv3 As illustrated in Figure 1, this document specifies OSPFv3 transport
transport over IPv4. As a result, OSPFv3 virtual links can be over IPv4. As a result, OSPFv3 virtual links can be supported with
supported with IPv4 address families by simply setting the IPv4 IPv4 address families by simply setting the IPv4 destination address
destination address to a reachable IPv4 unicast address for the to a reachable IPv4 unicast address for the virtual link endpoint.
virtual link endpoint. Hence, the restriction in Section 2.8 of Hence, the restriction in Section 2.8 of RFC 5838 [RFC5838] is
RFC 5838 [RFC5838] is relaxed since virtual links can now be relaxed since virtual links can now be supported for IPv4 address
supported for IPv4 address families as long as the transport is families as long as the transport is also IPv4. If IPv4 transport,
also IPv4. If IPv4 transport, as specified herein, is used for as specified herein, is used for IPv6 address families, virtual links
IPv6 address families, virtual links cannot be supported. Hence, in cannot be supported. Hence, in OSPF routing domains that require
OSPF routing domains that require virtual links, the IP transport virtual links, the IP transport MUST match the address family (IPv4
MUST match the address family (IPv4 or IPv6). or IPv6).
4. Management Considerations 4. Management Considerations
4.1. Coexistence with OSPFv2 4.1. Coexistence with OSPFv2
Since OSPFv2 [RFC2328] and OSPFv3 over IPv4 as described herein use Since OSPFv2 [RFC2328] and OSPFv3 over IPv4 as described herein use
exactly the same protocol and IPv4 addresses, OSPFv2 packets may be exactly the same protocol and IPv4 addresses, OSPFv2 packets may be
delivered to the OSPFv3 process and vice versa. When this occurs, delivered to the OSPFv3 process and vice versa. When this occurs,
the mismatched protocol packets will be dropped due to validation the mismatched protocol packets will be dropped due to validation of
of the version in the first octet of the OSPFv2/OSPFv3 protocol the version in the first octet of the OSPFv2/OSPFv3 protocol header.
header. Note that this will not prevent the packets from being Note that this will not prevent the packets from being delivered to
delivered to the correct protocol process as standard socket the correct protocol process as standard socket implementations will
implementations will deliver a copy to each socket matching the deliver a copy to each socket matching the selectors.
selectors.
Implementations of OSPFv3 over IPv4 transport SHOULD implement Implementations of OSPFv3 over IPv4 transport SHOULD implement
separate counters for a protocol mismatch and SHOULD provide means separate counters for a protocol mismatch and SHOULD provide means to
to suppress the ospfIfRxBadPacket and ospfVirtIfRxBadPacket SNMP suppress the ospfIfRxBadPacket and ospfVirtIfRxBadPacket SNMP
notifications as described in [RFC4750] and the ospfv3IfRxBadPacket notifications as described in [RFC4750] and the ospfv3IfRxBadPacket
and ospv3VirtIfRxBadPacket SNMP notifications as described in and ospv3VirtIfRxBadPacket SNMP notifications as described in
[RFC5643] when an OSPFv2 packet is received by the OSPFv3 process [RFC5643] when an OSPFv2 packet is received by the OSPFv3 process or
or vice versa. vice versa.
5. Security Considerations 5. Security Considerations
As specified in [RFC5340], OSPFv3 relies on IPsec [RFC4301] for OSPFv3 [RFC5340] relies on IPsec [RFC4301] for authentication and
authentication and confidentiality. [RFC4552] specifies how IPsec is confidentiality. "Authentication/Confidentiality in OSPFv3"
used with OSPFv3 over IPv6 transport. In order to use OSPFv3 with [RFC4552] specifies how IPsec is used with OSPFv3 over IPv6
IPv4 transport as specified herein, further work such as [ipsecospf] transport. In order to use OSPFv3 with IPv4 transport as specified
would be required. herein, further work such as "Authentication/Confidentiality in
OSPFv2" [IPsec-OSPF] would be required.
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 octets. the length of the 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 6. References
No actions are required from IANA as result of the publication of
this document.
7. Acknowledgments
The authors would like to thank Alexander Okonnikov for his thorough 6.1. Normative References
review and valuable feedback and Suresh Krishnan for pointing out
that clear specification for pseudo-header used in the OSPFv3 packet
checksum calculation was required. The authors would also like to
thank Wenhu Lu for acting as document shepherd.
8. References [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>.
8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
1981. DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
[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, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5309] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point
for IPv6", RFC 5340, July 2008. Operation over LAN in Link State Routing Protocols",
RFC 5309, DOI 10.17487/RFC5309, October 2008,
<http://www.rfc-editor.org/info/rfc5309>.
[RFC2328] Moy, J., "OSPF Version 2", STD54, RFC 2328, April 1998. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>.
[RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and
R. Aggarwal, "Support of Address Families in OSPFv3", RFC R. Aggarwal, "Support of Address Families in OSPFv3",
5838, April 2010. RFC 5838, DOI 10.17487/RFC5838, April 2010,
<http://www.rfc-editor.org/info/rfc5838>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5309] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point
Operation over LAN in Link State Routing Protocols", RFC
5309, October 2008.
8.2. Informative References 6.2. Informative References
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [IPsec-OSPF]
Border Gateway Protocol 4 (BGP-4)", RFC 4271, January Gupta, M. and N. Melam, "Authentication/Confidentiality
2006. for OSPFv2", Work in Progress, draft-gupta-ospf-
ospfv2-sec-01, August 2009.
[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>.
[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, DOI 10.17487/RFC0826, November 1982,
<http://www.rfc-editor.org/info/rfc826>.
[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, DOI 10.17487/RFC2464, December 1998,
<http://www.rfc-editor.org/info/rfc2464>.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
10.17487/RFC0768, August 1980. Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
10.17487/RFC5881, June 2010. December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
<http://www.rfc-editor.org/info/rfc4552>.
[RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed.,
Coltun, R., and F. Baker, "OSPF Version 2 Management Coltun, R., and F. Baker, "OSPF Version 2 Management
Information Base", RFC 4750, DOI 10.17487/RFC4750, Information Base", RFC 4750, DOI 10.17487/RFC4750,
December 2006. December 2006, <http://www.rfc-editor.org/info/rfc4750>.
[RFC5643] Joyal, D., Ed., and V. Manral, Ed., "Management [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
Information Base for OSPFv3", RFC 5643, DOI Yeung, "OSPF Link-Local Signaling", RFC 5613,
10.17487/RFC5643, August 2009. DOI 10.17487/RFC5613, August 2009,
<http://www.rfc-editor.org/info/rfc5613>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality [RFC5643] Joyal, D., Ed., and V. Manral, Ed., "Management
for OSPFv3", RFC 4552, June 2006. Information Base for OSPFv3", RFC 5643,
DOI 10.17487/RFC5643, August 2009,
<http://www.rfc-editor.org/info/rfc5643>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
Internet Protocol", RFC 4301, December 2005. (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
DOI 10.17487/RFC5881, June 2010,
<http://www.rfc-editor.org/info/rfc5881>.
[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,
DOI 10.17487/RFC7166, March 2014,
<http://www.rfc-editor.org/info/rfc7166>.
[ipsecospf] Gupta, M. and Melam, M, Work in progress, "draft-gupta- Acknowledgments
ospf-ospfv2-sec-01.txt", August 2009.
The authors would like to thank Alexander Okonnikov for his thorough
review and valuable feedback and Suresh Krishnan for pointing out
that clear specification for the pseudo-header used in the OSPFv3
packet checksum calculation was required. The authors would also
like to thank Wenhu Lu for acting as document shepherd.
Authors' Addresses Authors' Addresses
I. Chen Ing-Wher Chen
Ericsson Ericsson
Email: ichen@kuatrotech.com Email: ichen@kuatrotech.com
A. Lindem Acee Lindem
Cisco Cisco
Email: acee@cisco.com Email: acee@cisco.com
R. Atkinson RJ Atkinson
Consultant Consultant
Email: rja.lists@gmail.com Email: rja.lists@gmail.com
 End of changes. 77 change blocks. 
265 lines changed or deleted 274 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/