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) C. Pignataro
Request for Comments: 7676 Cisco Systems
Category: Standards Track R. Bonica
ISSN: 2070-1721 Juniper Networks
S. Krishnan
Ericsson
October 2015
<span class="h1">IPv6 Support for Generic Routing Encapsulation (GRE)</span>
Abstract
Generic Routing Encapsulation (GRE) can be used to carry any network-
layer payload protocol over any network-layer delivery protocol.
Currently, GRE procedures are specified for IPv4, used as either the
payload or delivery protocol. However, GRE procedures are not
specified for IPv6.
This document specifies GRE procedures for IPv6, used as either the
payload or delivery protocol.
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="./rfc5741#section-2">Section 2 of RFC 5741</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/rfc7676">http://www.rfc-editor.org/info/rfc7676</a>.
<span class="grey">Pignataro, 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="./rfc7676">RFC 7676</a> GRE IPv6 October 2015</span>
Copyright Notice
Copyright (c) 2015 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.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Requirements Language . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. GRE Header Fields . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Checksum Present . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. IPv6 as GRE Payload . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. GRE Protocol Type Considerations . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. MTU Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.3">3.3</a>. Fragmentation Considerations . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. IPv6 as GRE Delivery Protocol . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. Next Header Considerations . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.2">4.2</a>. Checksum Considerations . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.3">4.3</a>. MTU Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</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>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<span class="grey">Pignataro, 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="./rfc7676">RFC 7676</a> GRE IPv6 October 2015</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Generic Routing Encapsulation (GRE) [<a href="./rfc2784" title=""Generic Routing Encapsulation (GRE)"">RFC2784</a>] [<a href="./rfc2890" title=""Key and Sequence Number Extensions to GRE"">RFC2890</a>] can be used
to carry any network-layer payload protocol over any network-layer
delivery protocol. Currently, GRE procedures are specified for IPv4
[<a href="./rfc791" title=""Internet Protocol"">RFC791</a>], used as either the payload or delivery protocol. However,
GRE procedures are not specified for IPv6 [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>].
This document specifies GRE procedures for IPv6, used as either the
payload or delivery protocol. Like <a href="./rfc2784">RFC 2784</a>, this document describes
how GRE has been implemented by several vendors.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</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="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Terminology</span>
The following terms are used in this document:
o GRE delivery header: An IPv4 or IPv6 header whose source address
represents the GRE ingress node and whose destination address
represents the GRE egress node. The GRE delivery header
encapsulates a GRE header.
o GRE header: The GRE protocol header. The GRE header is
encapsulated in the GRE delivery header and encapsulates the GRE
payload.
o GRE payload: A network-layer packet that is encapsulated by the
GRE header.
o GRE overhead: The combined size of the GRE delivery header and the
GRE header, measured in octets.
o Path MTU (PMTU): The minimum MTU of all the links in a path
between a source node and a destination node. If the source and
destination node are connected through Equal-Cost Multipath
(ECMP), the PMTU is equal to the minimum link MTU of all links
contributing to the multipath.
o Path MTU Discovery (PMTUD): A procedure for dynamically
discovering the PMTU between two nodes on the Internet. PMTUD
procedures for IPv6 are defined in [<a href="./rfc1981" title=""Path MTU Discovery for IP version 6"">RFC1981</a>].
<span class="grey">Pignataro, 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="./rfc7676">RFC 7676</a> GRE IPv6 October 2015</span>
o GRE MTU (GMTU): The maximum transmission unit, i.e., maximum
packet size in octets, that can be conveyed over a GRE tunnel
without fragmentation of any kind. The GMTU is equal to the PMTU
associated with the path between the GRE ingress and the GRE
egress, minus the GRE overhead.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. GRE Header Fields</span>
This document does not change the GRE header format or any behaviors
specified by <a href="./rfc2784">RFC 2784</a> or <a href="./rfc2890">RFC 2890</a>.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Checksum Present</span>
The GRE ingress node SHOULD set the Checksum Present field in the GRE
header to zero. However, implementations MAY support a configuration
option that causes the GRE ingress node to set the Checksum Present
field to one.
As per <a href="./rfc2784#section-2.2">Section 2.2 of RFC 2784</a>, the GRE egress node uses the Checksum
Present field to calculate the length of the GRE header. If the
Checksum Present field is set to one, the GRE egress node MUST use
the GRE Checksum to verify the integrity of the GRE header and
payload.
Setting the Checksum Present field to zero reduces the computational
cost of GRE encapsulation and decapsulation. In many cases, the GRE
Checksum is partially redundant with other checksums. For example:
o If the payload protocol is IPv4, the IPv4 header is protected by
both the GRE Checksum and the IPv4 Checksum.
o If the payload carries TCP [<a href="./rfc793" title=""Transmission Control Protocol"">RFC793</a>], the TCP pseudo header, TCP
header, and TCP payload are protected by both the GRE Checksum and
TCP Checksum.
o If the payload carries UDP [<a href="./rfc768" title=""User Datagram Protocol"">RFC768</a>], the UDP pseudo header, UDP
header, and UDP payload are protected by both the GRE Checksum and
UDP Checksum.
However, if the GRE Checksum Present field is set to zero, the GRE
header is not protected by any checksum. Furthermore, depending on
which of the above-mentioned conditions are true, selected portions
of the GRE payload will not be protected by any checksum.
Network operators should evaluate risk factors in their networks and
configure GRE ingress nodes appropriately.
<span class="grey">Pignataro, 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="./rfc7676">RFC 7676</a> GRE IPv6 October 2015</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. IPv6 as GRE Payload</span>
The following considerations apply to GRE tunnels that carry an IPv6
payload.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. GRE Protocol Type Considerations</span>
The Protocol Type field in the GRE header MUST be set to Ether Type
[<a href="./rfc7042" title=""IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters"">RFC7042</a>] 0x86DD (IPv6).
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. MTU Considerations</span>
A GRE tunnel MUST be able to carry a 1280-octet IPv6 packet from
ingress to egress, without fragmenting the payload packet. All GRE
tunnels with a GMTU of 1280 octets or greater satisfy this
requirement. GRE tunnels that can fragment and reassemble delivery
packets also satisfy this requirement, regardless of their GMTU.
However, the ability to fragment and reassemble delivery packets is
not a requirement of this specification. This specification requires
only that GRE ingress nodes refrain from activating GRE tunnels that
do not satisfy the above-mentioned requirement.
Before activating a GRE tunnel and periodically thereafter, the GRE
ingress node MUST verify the tunnel's ability to carry a 1280-octet
IPv6 payload packet from ingress to egress, without fragmenting the
payload. Having executed those procedures, the GRE ingress node MUST
activate or deactivate the tunnel accordingly.
Implementation details regarding the above-mentioned verification
procedures are beyond the scope of this document. However, a GRE
ingress node can verify tunnel capabilities by sending a 1280-octet
IPv6 packet addressed to itself through the tunnel under test.
Many existing implementations [<a href="./rfc7588" title=""A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem"">RFC7588</a>] do not support the above-
mentioned verification procedures. Unless deployed in environments
where the GMTU is guaranteed to be greater than 1280, these
implementations MUST be configured so that the GRE endpoints can
fragment and reassemble the GRE delivery packet.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Fragmentation Considerations</span>
When the GRE ingress receives an IPv6 payload packet whose length is
less than or equal to the GMTU, it can encapsulate and forward the
packet without fragmentation of any kind. In this case, the GRE
ingress router MUST NOT fragment the payload or delivery packets.
<span class="grey">Pignataro, 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="./rfc7676">RFC 7676</a> GRE IPv6 October 2015</span>
When the GRE ingress receives an IPv6 payload packet whose length is
greater than the GMTU, and the GMTU is greater than or equal to 1280
octets, the GRE ingress router MUST:
o discard the IPv6 payload packet
o send an ICMPv6 Packet Too Big (PTB) [<a href="./rfc4443" title=""Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"">RFC4443</a>] message to the IPv6
payload packet source. The MTU field in the ICMPv6 PTB message is
set to the GMTU.
When the GRE ingress receives an IPv6 payload packet whose length is
greater than the GMTU, and the GMTU is less than 1280 octets, the GRE
ingress router MUST:
o encapsulate the entire IPv6 packet in a single GRE header and IP
delivery header
o fragment the delivery header, so that it can be reassembled by the
GRE egress
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IPv6 as GRE Delivery Protocol</span>
The following considerations apply when the delivery protocol is
IPv6.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Next Header Considerations</span>
When the GRE delivery protocol is IPv6, the GRE header MAY
immediately follow the GRE delivery header. Alternatively, IPv6
extension headers MAY be inserted between the GRE delivery header and
the GRE header.
If the GRE header immediately follows the GRE delivery header, the
Next Header field in the IPv6 header of the GRE delivery packet MUST
be set to 47. If extension headers are inserted between the GRE
delivery header and the GRE header, the Next Header field in the last
IPv6 extension header MUST be set to 47.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Checksum Considerations</span>
As stated in [<a href="./rfc2784" title=""Generic Routing Encapsulation (GRE)"">RFC2784</a>], the GRE header can contain a checksum. If
present, the GRE header checksum can be used to detect corruption of
the GRE header and GRE payload.
The GRE header checksum cannot be used to detect corruption of the
IPv6 delivery header. Furthermore, the IPv6 delivery header does not
contain a checksum of its own. Therefore, no available checksum can
be used to detect corruption of the IPv6 delivery header.
<span class="grey">Pignataro, 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="./rfc7676">RFC 7676</a> GRE IPv6 October 2015</span>
In one failure scenario, the destination address in the IPv6 delivery
header is corrupted. As a result, the IPv6 delivery packet is
delivered to a node other than the intended GRE egress node.
Depending upon the state and configuration of that node, it will
either:
a. Drop the packet
b. Decapsulate the payload and forward it to its intended
destination
c. Decapsulate the payload and forward it to a node other than its
intended destination.
Behaviors a) and b) are acceptable. Behavior c) is not acceptable.
Behavior c) is possible only when the following conditions are true:
1. The intended GRE egress node is a Virtual Private Network (VPN)
Provider Edge (PE) router.
2. The node to which the GRE delivery packet is mistakenly delivered
is also a VPN PE router.
3. VPNs are attached to both of the above-mentioned nodes. At least
two of these VPN's number hosts are from a non-unique (e.g.,
[<a href="./rfc1918" title=""Address Allocation for Private Internets"">RFC1918</a>]) address space.
4. The intended GRE egress node maintains state that causes it to
decapsulate the packet and forward the payload to its intended
destination
5. The node to which the GRE delivery packet is mistakenly delivered
maintains state that causes it to decapsulate the packet and
forward the payload to an identically numbered host in another
VPN.
While the failure scenario described above is extremely unlikely, a
single misdelivered packet can adversely impact applications running
on the node to which the packet is misdelivered. Furthermore,
leaking packets across VPN boundaries also constitutes a security
breach. The risk associated with behavior c) could be mitigated with
end-to-end authentication of the payload.
Before deploying GRE over IPv6, network operators should consider the
likelihood of behavior c) in their network. GRE over IPv6 MUST NOT
be deployed other than where the network operator deems the risk
associated with behavior c) to be acceptable.
<span class="grey">Pignataro, 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="./rfc7676">RFC 7676</a> GRE IPv6 October 2015</span>
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. MTU Considerations</span>
By default, the GRE ingress node cannot fragment the IPv6 delivery
header. However, implementations MAY support an optional
configuration in which the GRE ingress node can fragment the IPv6
delivery header.
Also by default, the GRE egress node cannot reassemble the IPv6
delivery header. However, implementations MAY support an optional
configuration in which the GRE egress node can reassemble the IPv6
delivery header.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
The Security Considerations section of [<a href="./rfc4023" title=""Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)"">RFC4023</a>] identifies threats
encountered when MPLS is delivered over GRE. These threats apply to
any GRE payload. As stated in <a href="./rfc4023">RFC 4023</a>, these various threats can be
mitigated through options such as authenticating and/or encrypting
the delivery packet using IPsec [<a href="./rfc4301" title=""Security Architecture for the Internet Protocol"">RFC4301</a>]. Alternatively, when the
payload is IPv6, these threats can also be mitigated by
authenticating and/or encrypting the payload using IPsec, instead of
the delivery packet. Otherwise, the current specification introduces
no security considerations beyond those mentioned in <a href="./rfc2784">RFC 2784</a>.
More generally, security considerations for IPv6 are discussed in
[<a href="./rfc4942" title=""IPv6 Transition/ Co-existence Security Considerations"">RFC4942</a>]. Operational security for IPv6 is discussed in [<a href="#ref-OPSEC-V6" title=""Operational Security Considerations for IPv6 Networks"">OPSEC-V6</a>],
and security concerns for tunnels in general are discussed in
[<a href="./rfc6169" title=""Security Concerns with IP Tunneling"">RFC6169</a>].
<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-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-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-RFC793">RFC793</a>] Postel, J., "Transmission Control Protocol", STD 7,
<a href="./rfc793">RFC 793</a>, DOI 10.17487/RFC0793, September 1981,
<<a href="http://www.rfc-editor.org/info/rfc793">http://www.rfc-editor.org/info/rfc793</a>>.
[<a id="ref-RFC1981">RFC1981</a>] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", <a href="./rfc1981">RFC 1981</a>, DOI 10.17487/RFC1981, August
1996, <<a href="http://www.rfc-editor.org/info/rfc1981">http://www.rfc-editor.org/info/rfc1981</a>>.
<span class="grey">Pignataro, 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="./rfc7676">RFC 7676</a> GRE IPv6 October 2015</span>
[<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>>.
[<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-RFC2784">RFC2784</a>] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", <a href="./rfc2784">RFC 2784</a>,
DOI 10.17487/RFC2784, March 2000,
<<a href="http://www.rfc-editor.org/info/rfc2784">http://www.rfc-editor.org/info/rfc2784</a>>.
[<a id="ref-RFC2890">RFC2890</a>] Dommety, G., "Key and Sequence Number Extensions to GRE",
<a href="./rfc2890">RFC 2890</a>, DOI 10.17487/RFC2890, September 2000,
<<a href="http://www.rfc-editor.org/info/rfc2890">http://www.rfc-editor.org/info/rfc2890</a>>.
[<a id="ref-RFC4023">RFC4023</a>] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", <a href="./rfc4023">RFC 4023</a>, DOI 10.17487/RFC4023, March 2005,
<<a href="http://www.rfc-editor.org/info/rfc4023">http://www.rfc-editor.org/info/rfc4023</a>>.
[<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-RFC4443">RFC4443</a>] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", <a href="./rfc4443">RFC 4443</a>,
DOI 10.17487/RFC4443, March 2006,
<<a href="http://www.rfc-editor.org/info/rfc4443">http://www.rfc-editor.org/info/rfc4443</a>>.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-OPSEC-V6">OPSEC-V6</a>] Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
Security Considerations for IPv6 Networks", Work in
Progress, <a href="./draft-ietf-opsec-v6-07">draft-ietf-opsec-v6-07</a>, September 2015.
[<a id="ref-RFC1918">RFC1918</a>] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
<a href="https://www.rfc-editor.org/bcp/bcp5">BCP 5</a>, <a href="./rfc1918">RFC 1918</a>, DOI 10.17487/RFC1918, February 1996,
<<a href="http://www.rfc-editor.org/info/rfc1918">http://www.rfc-editor.org/info/rfc1918</a>>.
[<a id="ref-RFC4942">RFC4942</a>] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
Co-existence Security Considerations", <a href="./rfc4942">RFC 4942</a>,
DOI 10.17487/RFC4942, September 2007,
<<a href="http://www.rfc-editor.org/info/rfc4942">http://www.rfc-editor.org/info/rfc4942</a>>.
<span class="grey">Pignataro, 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="./rfc7676">RFC 7676</a> GRE IPv6 October 2015</span>
[<a id="ref-RFC6169">RFC6169</a>] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", <a href="./rfc6169">RFC 6169</a>,
DOI 10.17487/RFC6169, April 2011,
<<a href="http://www.rfc-editor.org/info/rfc6169">http://www.rfc-editor.org/info/rfc6169</a>>.
[<a id="ref-RFC7042">RFC7042</a>] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
IETF Protocol and Documentation Usage for IEEE 802
Parameters", <a href="https://www.rfc-editor.org/bcp/bcp141">BCP 141</a>, <a href="./rfc7042">RFC 7042</a>, DOI 10.17487/RFC7042,
October 2013, <<a href="http://www.rfc-editor.org/info/rfc7042">http://www.rfc-editor.org/info/rfc7042</a>>.
[<a id="ref-RFC7588">RFC7588</a>] Bonica, R., Pignataro, C., and J. Touch, "A Widely
Deployed Solution to the Generic Routing Encapsulation
(GRE) Fragmentation Problem", <a href="./rfc7588">RFC 7588</a>,
DOI 10.17487/RFC7588, July 2015,
<<a href="http://www.rfc-editor.org/info/rfc7588">http://www.rfc-editor.org/info/rfc7588</a>>.
Acknowledgements
The authors would like to thank Fred Baker, Stewart Bryant, Benoit
Claise, Ben Campbell, Carlos Jesus Bernardos Cano, Spencer Dawkins,
Dino Farinacci, David Farmer, Brian Haberman, Tom Herbert, Kathleen
Moriarty, Fred Templin, Joe Touch, Andrew Yourtchenko, and Lucy Yong
for their thorough review and useful comments.
<span class="grey">Pignataro, 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="./rfc7676">RFC 7676</a> GRE IPv6 October 2015</span>
Authors' Addresses
Carlos Pignataro
Cisco Systems
7200-12 Kit Creek Road
Research Triangle Park, North Carolina 27709
United States
Email: cpignata@cisco.com
Ron Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, Virginia
United States
Email: rbonica@juniper.net
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
Pignataro, et al. Standards Track [Page 11]
</pre>
|
