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
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
|
<pre>Internet Engineering Task Force (IETF) G. Camarillo
Request for Comments: 6156 O. Novo
Category: Standards Track Ericsson
ISSN: 2070-1721 S. Perreault, Ed.
Viagenie
April 2011
<span class="h1">Traversal Using Relays around NAT (TURN) Extension for IPv6</span>
Abstract
This document adds IPv6 support to Traversal Using Relays around NAT
(TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6,
and IPv6-to-IPv4 relaying. This document defines the REQUESTED-
ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY
attribute allows a client to explicitly request the address type the
TURN server will allocate (e.g., an IPv4-only node may request the
TURN server to allocate an IPv6 address).
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/rfc6156">http://www.rfc-editor.org/info/rfc6156</a>.
Copyright Notice
Copyright (c) 2011 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">Camarillo, 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="./rfc6156">RFC 6156</a> TURN Extension for IPv4/IPv6 Transition April 2011</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Overview of Operation . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-4">4</a>. Creating an Allocation . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. Sending an Allocate Request . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4.1.1">4.1.1</a>. The REQUESTED-ADDRESS-FAMILY Attribute . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4.2">4.2</a>. Receiving an Allocate Request . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.2.1">4.2.1</a>. Unsupported Address Family . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.3">4.3</a>. Receiving an Allocate Error Response . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Refreshing an Allocation . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.1">5.1</a>. Sending a Refresh Request . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.2">5.2</a>. Receiving a Refresh Request . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-6">6</a>. CreatePermission . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-6.1">6.1</a>. Sending a CreatePermission Request . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-6.2">6.2</a>. Receiving a CreatePermission Request . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6.2.1">6.2.1</a>. Peer Address Family Mismatch . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-7">7</a>. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-7.1">7.1</a>. Sending a ChannelBind Request . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-7.2">7.2</a>. Receiving a ChannelBind Request . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-8">8</a>. Packet Translations . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-8.1">8.1</a>. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-8.2">8.2</a>. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-8.3">8.3</a>. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-9">9</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-9.1">9.1</a>. Tunnel Amplification Attack . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-10">10</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-10.1">10.1</a>. New STUN Attribute . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-10.2">10.2</a>. New STUN Error Codes . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-11">11</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-12">12</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-12.1">12.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-12.2">12.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<span class="grey">Camarillo, 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="./rfc6156">RFC 6156</a> TURN Extension for IPv4/IPv6 Transition April 2011</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Traversal Using Relays around NAT (TURN) [<a href="./rfc5766" title=""Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"">RFC5766</a>] is a protocol that
allows for an element behind a NAT to receive incoming data over UDP
or TCP. It is most useful for elements behind NATs without Endpoint-
Independent Mapping [<a href="./rfc4787" title=""Network Address Translation (NAT) Behavioral Requirements for Unicast UDP"">RFC4787</a>] that wish to be on the receiving end of
a connection to a single peer.
The base specification of TURN [<a href="./rfc5766" title=""Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"">RFC5766</a>] only defines IPv4-to-IPv4
relaying. This document adds IPv6 support to TURN, which includes
IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. This document
defines the REQUESTED-ADDRESS-FAMILY attribute, which is an extension
to TURN that allows a client to explicitly request the address type
the TURN server will allocate (e.g., an IPv4-only node may request
the TURN server to allocate an IPv6 address). This document also
defines and registers new error response codes.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</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>. Overview of Operation</span>
When a user wishes a TURN server to allocate an address of a specific
type, it sends an Allocate request to the TURN server with a
REQUESTED-ADDRESS-FAMILY attribute. TURN can run over UDP and TCP,
and it allows for a client to request address/port pairs for
receiving both UDP and TCP.
After the request has been successfully authenticated, the TURN
server allocates a transport address of the type indicated in the
REQUESTED-ADDRESS-FAMILY attribute. This address is called the
relayed transport address.
The TURN server returns the relayed transport address in the response
to the Allocate request. This response contains an XOR-RELAYED-
ADDRESS attribute indicating the IP address and port that the server
allocated for the client.
TURN servers allocate a single relayed transport address per
allocation request. Therefore, Allocate requests cannot carry more
than one REQUESTED-ADDRESS-FAMILY attribute. Consequently, a client
that wishes to allocate more than one relayed transport address at a
TURN server (e.g., an IPv4 and an IPv6 address) needs to perform
several allocation requests (one allocation request per relayed
transport address).
<span class="grey">Camarillo, 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="./rfc6156">RFC 6156</a> TURN Extension for IPv4/IPv6 Transition April 2011</span>
A TURN server that supports a set of address families is assumed to
be able to relay packets between them. If a server does not support
the address family requested by a client, the server returns a 440
(Address Family not Supported) error response.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Creating an Allocation</span>
The behavior specified here affects the processing defined in <a href="./rfc5766#section-6">Section</a>
<a href="./rfc5766#section-6">6 of [RFC5766]</a>.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Sending an Allocate Request</span>
A client that wishes to obtain a relayed transport address of a
specific address type includes a REQUESTED-ADDRESS-FAMILY attribute,
which is defined in <a href="#section-4.1.1">Section 4.1.1</a>, in the Allocate request that it
sends to the TURN server. Clients MUST NOT include more than one
REQUESTED-ADDRESS-FAMILY attribute in an Allocate request. The
mechanisms to formulate an Allocate request are described in <a href="./rfc5766#section-6.1">Section</a>
<a href="./rfc5766#section-6.1">6.1 of [RFC5766]</a>.
Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an
Allocate request that contains a RESERVATION-TOKEN attribute.
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. The REQUESTED-ADDRESS-FAMILY Attribute</span>
The REQUESTED-ADDRESS-FAMILY attribute is used by clients to request
the allocation of a specific address type from a server. The
following is the format of the REQUESTED-ADDRESS-FAMILY attribute.
Note that TURN attributes are TLV (Type-Length-Value) encoded, with a
16-bit type, a 16-bit length, and a variable-length value.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of REQUESTED-ADDRESS-FAMILY Attribute
Type: the type of the REQUESTED-ADDRESS-FAMILY attribute is 0x0017.
As specified in [<a href="./rfc5389" title=""Session Traversal Utilities for NAT (STUN)"">RFC5389</a>], attributes with values between 0x0000
and 0x7FFF are comprehension-required, which means that the client
or server cannot successfully process the message unless it
understands the attribute.
<span class="grey">Camarillo, 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="./rfc6156">RFC 6156</a> TURN Extension for IPv4/IPv6 Transition April 2011</span>
Length: this 16-bit field contains the length of the attribute in
bytes. The length of this attribute is 4 bytes.
Family: there are two values defined for this field and specified in
<a href="./rfc5389#section-15.1">[RFC5389], Section 15.1</a>: 0x01 for IPv4 addresses and 0x02 for IPv6
addresses.
Reserved: at this point, the 24 bits in the Reserved field MUST be
set to zero by the client and MUST be ignored by the server.
The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate
requests.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Receiving an Allocate Request</span>
Once a server has verified that the request is authenticated and has
not been tampered with, the TURN server processes the Allocate
request. If it contains both a RESERVATION-TOKEN and a REQUESTED-
ADDRESS-FAMILY, the server replies with a 400 (Bad Request) Allocate
error response. Following the rules in [<a href="./rfc5389" title=""Session Traversal Utilities for NAT (STUN)"">RFC5389</a>], if the server does
not understand the REQUESTED-ADDRESS-FAMILY attribute, it generates
an Allocate error response, which includes an ERROR-CODE attribute
with 420 (Unknown Attribute) response code. This response will
contain an UNKNOWN-ATTRIBUTE attribute listing the unknown REQUESTED-
ADDRESS-FAMILY attribute.
If the server can successfully process the request, it allocates a
transport address for the TURN client, called the relayed transport
address, and returns it in the response to the Allocate request.
As specified in [<a href="./rfc5766" title=""Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"">RFC5766</a>], the Allocate response contains the same
transaction ID contained in the Allocate request, and the XOR-
RELAYED-ADDRESS attribute is set to the relayed transport address.
The XOR-RELAYED-ADDRESS attribute indicates the allocated IP address
and port. It is encoded in the same way as the XOR-MAPPED-ADDRESS
[<a href="./rfc5389" title=""Session Traversal Utilities for NAT (STUN)"">RFC5389</a>].
If the REQUESTED-ADDRESS-FAMILY attribute is absent, the server MUST
allocate an IPv4-relayed transport address for the TURN client. If
allocation of IPv4 addresses is disabled by local policy, the server
returns a 440 (Address Family not Supported) Allocate error response.
If the server does not support the address family requested by the
client, it MUST generate an Allocate error response, and it MUST
include an ERROR-CODE attribute with the 440 (Address Family not
Supported) response code, which is defined in <a href="#section-4.2.1">Section 4.2.1</a>.
<span class="grey">Camarillo, 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="./rfc6156">RFC 6156</a> TURN Extension for IPv4/IPv6 Transition April 2011</span>
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. Unsupported Address Family</span>
This document defines the following new error response code:
440 (Address Family not Supported): The server does not support the
address family requested by the client.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Receiving an Allocate Error Response</span>
If the client receives an Allocate error response with the 440
(Unsupported Address Family) error code, the client MUST NOT retry
its request.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Refreshing an Allocation</span>
The behavior specified here affects the processing defined in <a href="./rfc5766#section-7">Section</a>
<a href="./rfc5766#section-7">7 of [RFC5766]</a>.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Sending a Refresh Request</span>
To perform an allocation refresh, the client generates a Refresh
Request as described in <a href="./rfc5766#section-7.1">Section 7.1 of [RFC5766]</a>. The client MUST
NOT include any REQUESTED-ADDRESS-FAMILY attribute in its Refresh
Request.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Receiving a Refresh Request</span>
If a server receives a Refresh Request with a REQUESTED-ADDRESS-
FAMILY attribute, and the attribute's value doesn't match the address
family of the allocation, the server MUST reply with a 443 (Peer
Address Family Mismatch) Refresh error response.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. CreatePermission</span>
The behavior specified here affects the processing defined in <a href="./rfc5766#section-9">Section</a>
<a href="./rfc5766#section-9">9 of [RFC5766]</a>.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Sending a CreatePermission Request</span>
The client MUST only include XOR-PEER-ADDRESS attributes with
addresses of the same address family as that of the relayed transport
address for the allocation.
<span class="grey">Camarillo, 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="./rfc6156">RFC 6156</a> TURN Extension for IPv4/IPv6 Transition April 2011</span>
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Receiving a CreatePermission Request</span>
If an XOR-PEER-ADDRESS attribute contains an address of an address
family different than that of the relayed transport address for the
allocation, the server MUST generate an error response with the 443
(Peer Address Family Mismatch) response code, which is defined in
<a href="#section-6.2.1">Section 6.2.1</a>.
<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>. Peer Address Family Mismatch</span>
This document defines the following new error response code:
443 (Peer Address Family Mismatch): A peer address was of a
different address family than that of the relayed transport
address of the allocation.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Channels</span>
The behavior specified here affects the processing defined in <a href="./rfc5766#section-11">Section</a>
<a href="./rfc5766#section-11">11 of [RFC5766]</a>.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Sending a ChannelBind Request</span>
The client MUST only include an XOR-PEER-ADDRESS attribute with an
address of the same address family as that of the relayed transport
address for the allocation.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Receiving a ChannelBind Request</span>
If the XOR-PEER-ADDRESS attribute contains an address of an address
family different than that of the relayed transport address for the
allocation, the server MUST generate an error response with the 443
(Peer Address Family Mismatch) response code, which is defined in
<a href="#section-6.2.1">Section 6.2.1</a>.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Packet Translations</span>
The TURN specification [<a href="./rfc5766" title=""Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"">RFC5766</a>] describes how TURN relays should
relay traffic consisting of IPv4 packets (i.e., IPv4-to-IPv4
translations). The relay translates the IP addresses and port
numbers of the packets based on the allocation's state data. How to
translate other header fields is also specified in [<a href="./rfc5766" title=""Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"">RFC5766</a>]. This
document addresses IPv4-to-IPv6, IPv6-to-IPv4, and IPv6-to-IPv6
translations.
<span class="grey">Camarillo, 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="./rfc6156">RFC 6156</a> TURN Extension for IPv4/IPv6 Transition April 2011</span>
TURN relays performing any translation MUST translate the IP
addresses and port numbers of the packets based on the allocation's
state information as specified in [<a href="./rfc5766" title=""Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"">RFC5766</a>]. The following sections
specify how to translate other header fields.
As discussed in <a href="./rfc5766#section-2.6">Section 2.6 of [RFC5766]</a>, translations in TURN are
designed so that a TURN server can be implemented as an application
that runs in "user-land" under commonly available operating systems
and that does not require special privileges. The translations
specified in the following sections follow this principle.
The descriptions below have two parts: a preferred behavior and an
alternate behavior. The server SHOULD implement the preferred
behavior. Otherwise, the server MUST implement the alternate
behavior and MUST NOT do anything else.
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. IPv4-to-IPv6 Translations</span>
Traffic Class
Preferred behavior: as specified in <a href="./rfc6145#section-4">Section 4 of [RFC6145]</a>.
Alternate behavior: the relay sets the Traffic Class to the
default value for outgoing packets.
Flow Label
Preferred behavior: the relay sets the Flow label to 0. The relay
can choose to set the Flow label to a different value if it
supports the IPv6 Flow Label field [<a href="./rfc3697" title=""IPv6 Flow Label Specification"">RFC3697</a>].
Alternate behavior: the relay sets the Flow label to the default
value for outgoing packets.
Hop Limit
Preferred behavior: as specified in <a href="./rfc6145#section-4">Section 4 of [RFC6145]</a>.
Alternate behavior: the relay sets the Hop Limit to the default
value for outgoing packets.
Fragmentation
Preferred behavior: as specified in <a href="./rfc6145#section-4">Section 4 of [RFC6145]</a>.
Alternate behavior: the relay assembles incoming fragments. The
relay follows its default behavior to send outgoing packets.
<span class="grey">Camarillo, 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="./rfc6156">RFC 6156</a> TURN Extension for IPv4/IPv6 Transition April 2011</span>
For both preferred and alternate behavior, the DONT-FRAGMENT
attribute (<a href="./rfc5766#section-14.8">[RFC5766], Section 14.8</a>) MUST be ignored by the server.
Extension Headers
Preferred behavior: the relay sends the outgoing packet without
any IPv6 extension headers, with the exception of the Fragment
Header as described above.
Alternate behavior: same as preferred.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. IPv6-to-IPv6 Translations</span>
Flow Label
The relay should consider that it is handling two different IPv6
flows. Therefore, the Flow label [<a href="./rfc3697" title=""IPv6 Flow Label Specification"">RFC3697</a>] SHOULD NOT be copied
as part of the translation.
Preferred behavior: the relay sets the Flow label to 0. The relay
can choose to set the Flow label to a different value if it
supports the IPv6 Flow Label field [<a href="./rfc3697" title=""IPv6 Flow Label Specification"">RFC3697</a>].
Alternate behavior: the relay sets the Flow label to the default
value for outgoing packets.
Hop Limit
Preferred behavior: the relay acts as a regular router with
respect to decrementing the Hop Limit and generating an ICMPv6
error if it reaches zero.
Alternate behavior: the relay sets the Hop Limit to the default
value for outgoing packets.
Fragmentation
Preferred behavior: if the incoming packet did not include a
Fragment Header and the outgoing packet size does not exceed the
outgoing link's MTU, the relay sends the outgoing packet without a
Fragment Header.
If the incoming packet did not include a Fragment Header and the
outgoing packet size exceeds the outgoing link's MTU, the relay
drops the outgoing packet and sends an ICMP message of Type 2,
Code 0 ("Packet too big") to the sender of the incoming packet.
<span class="grey">Camarillo, 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="./rfc6156">RFC 6156</a> TURN Extension for IPv4/IPv6 Transition April 2011</span>
If the packet is being sent to the peer, the relay reduces the MTU
reported in the ICMP message by 48 bytes to allow room for the
overhead of a Data indication.
If the incoming packet included a Fragment Header and the outgoing
packet size (with a Fragment Header included) does not exceed the
outgoing link's MTU, the relay sends the outgoing packet with a
Fragment Header. The relay sets the fields of the Fragment Header
as appropriate for a packet originating from the server.
If the incoming packet included a Fragment Header and the outgoing
packet size exceeds the outgoing link's MTU, the relay MUST
fragment the outgoing packet into fragments of no more than 1280
bytes. The relay sets the fields of the Fragment Header as
appropriate for a packet originating from the server.
Alternate behavior: the relay assembles incoming fragments. The
relay follows its default behavior to send outgoing packets.
For both preferred and alternate behavior, the DONT-FRAGMENT
attribute MUST be ignored by the server.
Extension Headers
Preferred behavior: the relay sends the outgoing packet without
any IPv6 extension headers, with the exception of the Fragment
Header as described above.
Alternate behavior: same as preferred.
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. IPv6-to-IPv4 Translations</span>
Type of Service and Precedence
Preferred behavior: as specified in <a href="./rfc6145#section-5">Section 5 of [RFC6145]</a>.
Alternate behavior: the relay sets the Type of Service and
Precedence to the default value for outgoing packets.
Time to Live
Preferred behavior: as specified in <a href="./rfc6145#section-5">Section 5 of [RFC6145]</a>.
Alternate behavior: the relay sets the Time to Live to the default
value for outgoing packets.
<span class="grey">Camarillo, 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="./rfc6156">RFC 6156</a> TURN Extension for IPv4/IPv6 Transition April 2011</span>
Fragmentation
Preferred behavior: as specified in <a href="./rfc6145#section-5">Section 5 of [RFC6145]</a>.
Additionally, when the outgoing packet's size exceeds the outgoing
link's MTU, the relay needs to generate an ICMP error (ICMPv6
Packet Too Big) reporting the MTU size. If the packet is being
sent to the peer, the relay SHOULD reduce the MTU reported in the
ICMP message by 48 bytes to allow room for the overhead of a Data
indication.
Alternate behavior: the relay assembles incoming fragments. The
relay follows its default behavior to send outgoing packets.
For both preferred and alternate behavior, the DONT-FRAGMENT
attribute MUST be ignored by the server.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
Translation between IPv4 and IPv6 creates a new way for clients to
obtain IPv4 or IPv6 access that they did not have before. For
example, an IPv4-only client having access to a TURN server
implementing this specification is now able to access the IPv6
Internet. This needs to be considered when establishing security and
monitoring policies.
The loop attack described in <a href="./rfc5766#section-17.1.7">[RFC5766], Section 17.1.7</a>, may be more
easily done in cases where address spoofing is easier to accomplish
over IPv6. Mitigation of this attack over IPv6 is the same as for
IPv4.
All the security considerations applicable to STUN [<a href="./rfc5389" title=""Session Traversal Utilities for NAT (STUN)"">RFC5389</a>] and TURN
[<a href="./rfc5766" title=""Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"">RFC5766</a>] are applicable to this document as well.
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Tunnel Amplification Attack</span>
An attacker might attempt to cause data packets to loop numerous
times between a TURN server and a tunnel between IPv4 and IPv6. The
attack goes as follows.
Suppose an attacker knows that a tunnel endpoint will forward
encapsulated packets from a given IPv6 address (this doesn't
necessarily need to be the tunnel endpoint's address). Suppose he
then spoofs these two packets from this address:
1. An Allocate request asking for a v4 address, and
2. A ChannelBind request establishing a channel to the IPv4 address
of the tunnel endpoint
<span class="grey">Camarillo, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6156">RFC 6156</a> TURN Extension for IPv4/IPv6 Transition April 2011</span>
Then he has set up an amplification attack:
o The TURN relay will re-encapsulate IPv6 UDP data in v4 and send it
to the tunnel endpoint.
o The tunnel endpoint will decapsulate packets from the v4 interface
and send them to v6.
So, if the attacker sends a packet of the following form:
IPv6: src=2001:db9::1 dst=2001:db8::2
UDP: <ports>
TURN: <channel id>
IPv6: src=2001:db9::1 dst=2001:db8::2
UDP: <ports>
TURN: <channel id>
IPv6: src=2001:db9::1 dst=2001:db8::2
UDP: <ports>
TURN: <channel id>
...
Then the TURN relay and the tunnel endpoint will send it back and
forth until the last TURN header is consumed, at which point the TURN
relay will send an empty packet that the tunnel endpoint will drop.
The amplification potential here is limited by the MTU, so it's not
huge: IPv6+UDP+TURN takes 334 bytes, so you could get a four-to-one
amplification out of a 1500-byte packet. But the attacker could
still increase traffic volume by sending multiple packets or by
establishing multiple channels spoofed from different addresses
behind the same tunnel endpoint.
The attack is mitigated as follows. It is RECOMMENDED that TURN
relays not accept allocation or channel binding requests from
addresses known to be tunneled, and that they not forward data to
such addresses. In particular, a TURN relay MUST NOT accept Teredo
or 6to4 addresses in these requests.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. IANA Considerations</span>
IANA registered the following values under the "STUN Attributes"
registry and under the "STUN Error Codes" registry.
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. New STUN Attribute</span>
0x0017: REQUESTED-ADDRESS-FAMILY
<span class="grey">Camarillo, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6156">RFC 6156</a> TURN Extension for IPv4/IPv6 Transition April 2011</span>
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. New STUN Error Codes</span>
440 Address Family not Supported
443 Peer Address Family Mismatch
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Acknowledgements</span>
The authors would like to thank Alfred E. Heggestad, Dan Wing, Magnus
Westerlund, Marc Petit-Huguenin, Philip Matthews, and Remi Denis-
Courmont for their feedback on this document.
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. References</span>
<span class="h3"><a class="selflink" id="section-12.1" href="#section-12.1">12.1</a>. Normative References</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>, March 1997.
[<a id="ref-RFC3697">RFC3697</a>] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", <a href="./rfc3697">RFC 3697</a>, March 2004.
[<a id="ref-RFC5389">RFC5389</a>] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", <a href="./rfc5389">RFC 5389</a>,
October 2008.
[<a id="ref-RFC5766">RFC5766</a>] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", <a href="./rfc5766">RFC 5766</a>, April 2010.
[<a id="ref-RFC6145">RFC6145</a>] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", <a href="./rfc6145">RFC 6145</a>, April 2011.
<span class="h3"><a class="selflink" id="section-12.2" href="#section-12.2">12.2</a>. Informative References</span>
[<a id="ref-RFC4787">RFC4787</a>] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", <a href="https://www.rfc-editor.org/bcp/bcp127">BCP 127</a>,
<a href="./rfc4787">RFC 4787</a>, January 2007.
<span class="grey">Camarillo, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6156">RFC 6156</a> TURN Extension for IPv4/IPv6 Transition April 2011</span>
Authors' Addresses
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
Oscar Novo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Oscar.Novo@ericsson.com
Simon Perreault (editor)
Viagenie
2600 boul. Laurier, suite D2-630
Quebec, QC G1V 2M2
Canada
Phone: +1 418 656 9254
EMail: simon.perreault@viagenie.ca
URI: <a href="http://www.viagenie.ca">http://www.viagenie.ca</a>
Camarillo, et al. Standards Track [Page 14]
</pre>
|
