1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
|
<pre>Internet Engineering Task Force (IETF) I. Chen
Request for Comments: 7949 Ericsson
Updates: <a href="./rfc5838">5838</a> A. Lindem
Category: Standards Track Cisco
ISSN: 2070-1721 R. Atkinson
Consultant
August 2016
<span class="h1">OSPFv3 over IPv4 for IPv6 Transition</span>
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 <a href="./rfc5838">RFC 5838</a> to support virtual links in the IPv4 unicast address
family when using OSPFv3 over IPv4.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(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 <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7949">http://www.rfc-editor.org/info/rfc7949</a>.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Chen, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7949">RFC 7949</a> OSPFv3 over IPv4 for IPv6 Transition August 2016</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. IPv4-Only Use Case .........................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Requirements Language ...........................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Encapsulation in IPv4 ...........................................<a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Source Address .............................................<a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. Destination Address ........................................<a href="#page-6">6</a>
<a href="#section-3.3">3.3</a>. OSPFv3 Header Checksum .....................................<a href="#page-6">6</a>
<a href="#section-3.4">3.4</a>. Operation over Virtual Links ...............................<a href="#page-7">7</a>
<a href="#section-4">4</a>. Management Considerations .......................................<a href="#page-7">7</a>
<a href="#section-4.1">4.1</a>. Coexistence with OSPFv2 ....................................<a href="#page-7">7</a>
<a href="#section-5">5</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-6">6</a>. References ......................................................<a href="#page-8">8</a>
<a href="#section-6.1">6.1</a>. Normative References .......................................<a href="#page-8">8</a>
<a href="#section-6.2">6.2</a>. Informative References .....................................<a href="#page-9">9</a>
Acknowledgments ...................................................<a href="#page-10">10</a>
Authors' Addresses ................................................<a href="#page-11">11</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Using OSPFv3 [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>] over IPv4 [<a href="./rfc791" title=""Internet Protocol"">RFC791</a>] with the existing OSPFv3
address family extension can simplify transition from an IPv4-only
routing domain to an IPv6 [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>] or dual-stack routing domain.
Dual-stack routing protocols, such as the Border Gateway Protocol
[<a href="./rfc4271" title=""A Border Gateway Protocol 4 (BGP-4)"">RFC4271</a>], have an advantage during the transition, because both IPv4
and IPv6 address families can be advertised using either IPv4 or IPv6
transport. Some IPv4-specific and IPv6-specific routing protocols
share enough similarities in their protocol packet formats and
protocol signaling that it is trivial to deploy an initial IPv6
routing domain by transporting the routing protocol over IPv4,
thereby allowing IPv6 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
routing protocol (IGP), OSPFv2 [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>] is the IGP deployed over
IPv4, while OSPFv3 [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>] is the IGP deployed over IPv6. OSPFv3
further supports multiple address families [<a href="./rfc5838" title=""Support of Address Families in OSPFv3"">RFC5838</a>], including both
the IPv6 unicast address family and the IPv4 unicast address family.
Consequently, it is possible to deploy OSPFv3 over IPv4 without any
changes to either OSPFv3 or IPv4. During the transition to IPv6,
future OSPF extensions can focus on OSPFv3, and OSPFv2 can move to
maintenance mode.
This document specifies how to use IPv4 to transport OSPFv3 packets.
The mechanism takes advantage of the fact that OSPFv2 and OSPFv3
share the same IP protocol number, 89. Additionally, the OSPF packet
header for both OSPFv2 and OSPFv3 includes the OSPF header version
<span class="grey">Chen, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7949">RFC 7949</a> OSPFv3 over IPv4 for IPv6 Transition August 2016</span>
(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
the header).
If the IPv4 topology and IPv6 topology are not identical, the most
likely cause is that some parts of the network deployment have not
yet been upgraded to support both IPv4 and IPv6. In situations where
the IPv4 deployment is a superset of the IPv6 deployment, it is
expected that OSPFv3 packets would be transported over IPv4, until
the rest of the network deployment is upgraded to support IPv6 in
addition to IPv4. In situations where the IPv6 deployment is a
superset of the IPv4 deployment, it is expected that OSPFv3 would be
transported over IPv6.
Throughout this document, "OSPF" is used when the text applies to
both OSPFv2 and OSPFv3. "OSPFv2" or "OSPFv3" is used when the text
is specific to one version of the OSPF protocol. Similarly, "IP" is
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 the Internet Protocol.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. IPv4-Only Use Case</span>
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 [<a href="./rfc2464" title=""Transmission of IPv6 Packets over Ethernet Networks"">RFC2464</a>] uses a
different EtherType (0x86dd) from IPv4 (0x0800) and the Address
Resolution Protocol (ARP) (0x0806) [<a href="./rfc826" title=""Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware"">RFC826</a>] 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, Point-to-Point Protocol (PPP) might be used over a
serial interface, but again only IPv4 over PPP might be supported
over such an 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) are 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 (VSATs) often are used by banks and retailers to
connect their branches and stores to a central location.
<span class="grey">Chen, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7949">RFC 7949</a> OSPFv3 over IPv4 for IPv6 Transition August 2016</span>
Some widely deployed VSAT equipment has either (A) Ethernet
interfaces that only support the Ethernet Address Resolution Protocol
(ARP) and IPv4, or (B) serial interfaces that only support IPv4 and
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 orchestrated.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Requirements Language</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Encapsulation in IPv4</span>
An OSPFv3 packet can be directly encapsulated within an IPv4 packet
as the payload, without the IPv6 packet header, as illustrated in
Figure 1. For OSPFv3 transported over IPv4, the IPv4 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 packet,
beginning with the OSPF packet header having its OSPF version field
set to 3.
An OSPFv3 packet followed by an OSPF link-local signaling (LLS)
extension data block [<a href="./rfc5613" title=""OSPF Link-Local Signaling"">RFC5613</a>] encapsulated in an IPv4 packet is
illustrated in Figure 2.
Since an IPv4 header without options is only 20 octets long and is
shorter than an IPv6 header, an OSPFv3 packet encapsulated in a
20-octet 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-octet 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
[<a href="./rfc791" title=""Internet Protocol"">RFC791</a>].
<span class="grey">Chen, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7949">RFC 7949</a> OSPFv3 over IPv4 for IPv6 Transition August 2016</span>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| 4 | IHL |Type of Service| Total Length | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Identification |Flags| Fragment Offset | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Time to Live | Protocol (89) | Header Checksum | IPv4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header
| Source Address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Destination Address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Options | Padding | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| 3 | Type | Packet length | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Router ID | OSPFv3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header
| Area ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Checksum | Instance ID | 0 | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| OSPFv3 Body ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: "IHL" stands for Internet Header Length.
Figure 1: An IPv4 Packet Encapsulating an OSPFv3 Packet
+---------------+
| IPv4 Header |
+---------------+
| OSPFv3 Header |
|...............|
| |
| OSPFv3 Body |
| |
+---------------+
| |
| LLS Data |
| |
+---------------+
Figure 2: The IPv4 Packet Encapsulating an OSPFv3 Packet with
a Trailing OSPF Link-Local Signaling Data Block
<span class="grey">Chen, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7949">RFC 7949</a> OSPFv3 over IPv4 for IPv6 Transition August 2016</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Source Address</span>
For OSPFv3 over IPv4, the source address is the primary IPv4 address
for the interface over which the packet is transmitted. All OSPFv3
routers on the link should share the same IPv4 subnet for IPv4
transport to function correctly.
While OSPFv2 operates on a subnet, OSPFv3 operates on a link
[<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>]. Accordingly, an OSPFv3 router implementation MAY support
adjacencies with OSPFv3 neighbors on different IPv4 subnets. If this
is supported, the IPv4 data plane MUST resolve IPv4 addresses to
Layer 2 addresses using ARP on multi-access networks and point-to-
point over LAN [<a href="./rfc5309" title=""Point-to-Point Operation over LAN in Link State Routing Protocols"">RFC5309</a>] for direct next hops on different IPv4
subnets. When OSPFv3 adjacencies on different IPv4 subnets are
supported, Bidirectional Forwarding Detection (BFD) [<a href="./rfc5881" title=""Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)"">RFC5881</a>] cannot
be used for adjacency loss detection since BFD is restricted to a
single subnet.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Destination Address</span>
As defined in OSPFv2, the IPv4 destination address of an OSPF
protocol packet is either an IPv4 multicast address or the IPv4
unicast address of an OSPFv2 neighbor. Two well-known link-local
multicast addresses are assigned to OSPFv2, the AllSPFRouters 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 interface
type, and the OSPF router's role on multi-access networks.
Thus, for an OSPFv3-over-IPv4 packet to be sent to AllSPFRouters, the
destination address field in the IPv4 packet MUST be 224.0.0.5. For
an OSPFv3-over-IPv4 packet to be sent to AllDRouters, the destination
address field in the IPv4 packet MUST be 224.0.0.6.
When an OSPF router sends a unicast OSPF packet over a connected
interface, the destination of such an IP packet is the address
assigned to the receiving interface. Thus, a unicast OSPFv3 packet
transported in an IPv4 packet would specify the OSPFv3 neighbor's
IPv4 address as the destination address.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. OSPFv3 Header Checksum</span>
For IPv4 transport, the pseudo-header used in the checksum
calculation will contain the IPv4 source and destination addresses,
the OSPFv3 protocol ID, and the OSPFv3 length from the OSPFv3 header
(Appendix A.3.1 of [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>]). The format is similar to the UDP
pseudo-header as described in [<a href="./rfc768" title=""User Datagram Protocol"">RFC768</a>] and is illustrated in
Figure 3.
<span class="grey">Chen, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7949">RFC 7949</a> OSPFv3 over IPv4 for IPv6 Transition August 2016</span>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Protocol (89) | OSPFv3 Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Pseudo-header for OSPFv3 over IPv4
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Operation over Virtual Links</span>
When an OSPF router sends an OSPF packet over a virtual link, the
receiving router might not be directly connected to the sending
router. Thus, the destination IP address of the IP packet must be a
reachable unicast IP address for the virtual link endpoint. Because
IPv6 is the presumed Internet protocol and an IPv4 destination is not
routable, the OSPFv3 address family extension [<a href="./rfc5838" title=""Support of Address Families in OSPFv3"">RFC5838</a>] specifies
that only virtual links in the IPv6 address family are supported.
As illustrated in Figure 1, this document specifies OSPFv3 transport
over IPv4. As a result, OSPFv3 virtual links can be supported with
IPv4 address families by simply setting the IPv4 destination address
to a reachable IPv4 unicast address for the virtual link endpoint.
Hence, the restriction in <a href="./rfc5838#section-2.8">Section 2.8 of RFC 5838</a> [<a href="./rfc5838" title=""Support of Address Families in OSPFv3"">RFC5838</a>] is
relaxed since virtual links can now be supported for IPv4 address
families as long as the transport is also IPv4. If IPv4 transport,
as specified herein, is used for IPv6 address families, virtual links
cannot be supported. Hence, in OSPF routing domains that require
virtual links, the IP transport MUST match the address family (IPv4
or IPv6).
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Management Considerations</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Coexistence with OSPFv2</span>
Since OSPFv2 [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>] and OSPFv3 over IPv4 as described herein use
exactly the same protocol and IPv4 addresses, OSPFv2 packets may be
delivered to the OSPFv3 process and vice versa. When this occurs,
the mismatched protocol packets will be dropped due to validation of
the version in the first octet of the OSPFv2/OSPFv3 protocol header.
Note that this will not prevent the packets from being delivered to
the correct protocol process as standard socket implementations will
deliver a copy to each socket matching the selectors.
<span class="grey">Chen, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7949">RFC 7949</a> OSPFv3 over IPv4 for IPv6 Transition August 2016</span>
Implementations of OSPFv3 over IPv4 transport SHOULD implement
separate counters for a protocol mismatch and SHOULD provide means to
suppress the ospfIfRxBadPacket and ospfVirtIfRxBadPacket SNMP
notifications as described in [<a href="./rfc4750" title=""OSPF Version 2 Management Information Base"">RFC4750</a>] and the ospfv3IfRxBadPacket
and ospv3VirtIfRxBadPacket SNMP notifications as described in
[<a href="./rfc5643" title=""Management Information Base for OSPFv3"">RFC5643</a>] when an OSPFv2 packet is received by the OSPFv3 process or
vice versa.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
OSPFv3 [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>] relies on IPsec [<a href="./rfc4301" title=""Security Architecture for the Internet Protocol"">RFC4301</a>] for authentication and
confidentiality. "Authentication/Confidentiality in OSPFv3"
[<a href="./rfc4552" title=""Authentication/Confidentiality for OSPFv3"">RFC4552</a>] specifies how IPsec is used with OSPFv3 over IPv6
transport. In order to use OSPFv3 with IPv4 transport as specified
herein, further work such as "Authentication/Confidentiality in
OSPFv2" [<a href="#ref-IPsec-OSPF">IPsec-OSPF</a>] would be required.
An optional OSPFv3 Authentication Trailer [<a href="./rfc7166" title=""Supporting Authentication Trailer for OSPFv3"">RFC7166</a>] also has been
defined as an alternative to using IPsec. The calculation of the
authentication data in the Authentication Trailer includes the source
IPv6 address to protect an OSPFv3 router from man-in-the-middle
attacks. For IPv4 encapsulation as described herein, the IPv4 source
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 length of the hash measured in octets.
The processing of the optional Authentication Trailer is contained
entirely within the OSPFv3 protocol. In other words, each OSPFv3
router instance is responsible for the authentication, without
involvement from IPsec or any other IP-layer function. Consequently,
except for calculation of the Apad value, transporting OSPFv3 packets
using IPv4 does not change the generation or validation of the
optional OSPFv3 Authentication Trailer.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-RFC791">RFC791</a>] Postel, J., "Internet Protocol", STD 5, <a href="./rfc791">RFC 791</a>,
DOI 10.17487/RFC0791, September 1981,
<<a href="http://www.rfc-editor.org/info/rfc791">http://www.rfc-editor.org/info/rfc791</a>>.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
<span class="grey">Chen, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7949">RFC 7949</a> OSPFv3 over IPv4 for IPv6 Transition August 2016</span>
[<a id="ref-RFC2328">RFC2328</a>] Moy, J., "OSPF Version 2", STD 54, <a href="./rfc2328">RFC 2328</a>,
DOI 10.17487/RFC2328, April 1998,
<<a href="http://www.rfc-editor.org/info/rfc2328">http://www.rfc-editor.org/info/rfc2328</a>>.
[<a id="ref-RFC2460">RFC2460</a>] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", <a href="./rfc2460">RFC 2460</a>, DOI 10.17487/RFC2460,
December 1998, <<a href="http://www.rfc-editor.org/info/rfc2460">http://www.rfc-editor.org/info/rfc2460</a>>.
[<a id="ref-RFC5309">RFC5309</a>] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point
Operation over LAN in Link State Routing Protocols",
<a href="./rfc5309">RFC 5309</a>, DOI 10.17487/RFC5309, October 2008,
<<a href="http://www.rfc-editor.org/info/rfc5309">http://www.rfc-editor.org/info/rfc5309</a>>.
[<a id="ref-RFC5340">RFC5340</a>] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", <a href="./rfc5340">RFC 5340</a>, DOI 10.17487/RFC5340, July 2008,
<<a href="http://www.rfc-editor.org/info/rfc5340">http://www.rfc-editor.org/info/rfc5340</a>>.
[<a id="ref-RFC5838">RFC5838</a>] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and
R. Aggarwal, "Support of Address Families in OSPFv3",
<a href="./rfc5838">RFC 5838</a>, DOI 10.17487/RFC5838, April 2010,
<<a href="http://www.rfc-editor.org/info/rfc5838">http://www.rfc-editor.org/info/rfc5838</a>>.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-IPsec-OSPF">IPsec-OSPF</a>]
Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv2", Work in Progress, <a href="./draft-gupta-ospf-ospfv2-sec-01">draft-gupta-ospf-</a>
<a href="./draft-gupta-ospf-ospfv2-sec-01">ospfv2-sec-01</a>, August 2009.
[<a id="ref-RFC768">RFC768</a>] Postel, J., "User Datagram Protocol", STD 6, <a href="./rfc768">RFC 768</a>,
DOI 10.17487/RFC0768, August 1980,
<<a href="http://www.rfc-editor.org/info/rfc768">http://www.rfc-editor.org/info/rfc768</a>>.
[<a id="ref-RFC826">RFC826</a>] Plummer, D., "Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37,
<a href="./rfc826">RFC 826</a>, DOI 10.17487/RFC0826, November 1982,
<<a href="http://www.rfc-editor.org/info/rfc826">http://www.rfc-editor.org/info/rfc826</a>>.
[<a id="ref-RFC2464">RFC2464</a>] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", <a href="./rfc2464">RFC 2464</a>, DOI 10.17487/RFC2464, December 1998,
<<a href="http://www.rfc-editor.org/info/rfc2464">http://www.rfc-editor.org/info/rfc2464</a>>.
[<a id="ref-RFC4271">RFC4271</a>] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", <a href="./rfc4271">RFC 4271</a>,
DOI 10.17487/RFC4271, January 2006,
<<a href="http://www.rfc-editor.org/info/rfc4271">http://www.rfc-editor.org/info/rfc4271</a>>.
<span class="grey">Chen, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7949">RFC 7949</a> OSPFv3 over IPv4 for IPv6 Transition August 2016</span>
[<a id="ref-RFC4301">RFC4301</a>] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", <a href="./rfc4301">RFC 4301</a>, DOI 10.17487/RFC4301,
December 2005, <<a href="http://www.rfc-editor.org/info/rfc4301">http://www.rfc-editor.org/info/rfc4301</a>>.
[<a id="ref-RFC4552">RFC4552</a>] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", <a href="./rfc4552">RFC 4552</a>, DOI 10.17487/RFC4552, June 2006,
<<a href="http://www.rfc-editor.org/info/rfc4552">http://www.rfc-editor.org/info/rfc4552</a>>.
[<a id="ref-RFC4750">RFC4750</a>] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed.,
Coltun, R., and F. Baker, "OSPF Version 2 Management
Information Base", <a href="./rfc4750">RFC 4750</a>, DOI 10.17487/RFC4750,
December 2006, <<a href="http://www.rfc-editor.org/info/rfc4750">http://www.rfc-editor.org/info/rfc4750</a>>.
[<a id="ref-RFC5613">RFC5613</a>] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
Yeung, "OSPF Link-Local Signaling", <a href="./rfc5613">RFC 5613</a>,
DOI 10.17487/RFC5613, August 2009,
<<a href="http://www.rfc-editor.org/info/rfc5613">http://www.rfc-editor.org/info/rfc5613</a>>.
[<a id="ref-RFC5643">RFC5643</a>] Joyal, D., Ed., and V. Manral, Ed., "Management
Information Base for OSPFv3", <a href="./rfc5643">RFC 5643</a>,
DOI 10.17487/RFC5643, August 2009,
<<a href="http://www.rfc-editor.org/info/rfc5643">http://www.rfc-editor.org/info/rfc5643</a>>.
[<a id="ref-RFC5881">RFC5881</a>] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", <a href="./rfc5881">RFC 5881</a>,
DOI 10.17487/RFC5881, June 2010,
<<a href="http://www.rfc-editor.org/info/rfc5881">http://www.rfc-editor.org/info/rfc5881</a>>.
[<a id="ref-RFC7166">RFC7166</a>] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", <a href="./rfc7166">RFC 7166</a>,
DOI 10.17487/RFC7166, March 2014,
<<a href="http://www.rfc-editor.org/info/rfc7166">http://www.rfc-editor.org/info/rfc7166</a>>.
Acknowledgments
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.
<span class="grey">Chen, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7949">RFC 7949</a> OSPFv3 over IPv4 for IPv6 Transition August 2016</span>
Authors' Addresses
Ing-Wher Chen
Ericsson
Email: ichen@kuatrotech.com
Acee Lindem
Cisco
Email: acee@cisco.com
RJ Atkinson
Consultant
Email: rja.lists@gmail.com
Chen, et al. Standards Track [Page 11]
</pre>
|
