idnits 2.17.1 draft-ietf-behave-turn-ipv6-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 2010) is 5039 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-10 ** Obsolete normative reference: RFC 3697 (Obsoleted by RFC 6437) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE G. Camarillo 3 Internet-Draft O. Novo 4 Intended status: Standards Track Ericsson 5 Expires: January 9, 2011 S. Perreault, Ed. 6 Viagenie 7 July 8, 2010 9 Traversal Using Relays around NAT (TURN) Extension for IPv6 10 draft-ietf-behave-turn-ipv6-11 12 Abstract 14 This document adds IPv6 support to Traversal Using Relays around NAT 15 (TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, 16 and IPv6-to-IPv4 relaying. This document defines the REQUESTED- 17 ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY 18 attribute allows a client to explicitly request the address type the 19 TURN server will allocate (e.g., an IPv4-only node may request the 20 TURN server to allocate an IPv6 address). 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on January 9, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 65 4. Creating an Allocation . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Sending an Allocate Request . . . . . . . . . . . . . . . 4 67 4.1.1. The REQUESTED-ADDRESS-FAMILY Attribute . . . . . . . . 4 68 4.2. Receiving an Allocate Request . . . . . . . . . . . . . . 5 69 4.2.1. Unsupported Address Family . . . . . . . . . . . . . . 6 70 4.3. Receiving an Allocate Error Response . . . . . . . . . . . 6 71 5. Refreshing an Allocation . . . . . . . . . . . . . . . . . . . 6 72 5.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 6 73 5.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 6 74 6. CreatePermission . . . . . . . . . . . . . . . . . . . . . . . 6 75 6.1. Sending a CreatePermission Request . . . . . . . . . . . . 7 76 6.2. Receiving a CreatePermission request . . . . . . . . . . . 7 77 6.2.1. Peer Address Family Mismatch . . . . . . . . . . . . . 7 78 7. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 7.1. Sending a ChannelBind Request . . . . . . . . . . . . . . 7 80 7.2. Receiving a ChannelBind Request . . . . . . . . . . . . . 7 81 8. Packet Translations . . . . . . . . . . . . . . . . . . . . . 7 82 8.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . . 8 83 8.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . . 9 84 8.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . . 11 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 86 9.1. Tunnel Amplification Attack . . . . . . . . . . . . . . . 12 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 88 10.1. New STUN Attribute . . . . . . . . . . . . . . . . . . . . 13 89 10.2. New STUN Error Codes . . . . . . . . . . . . . . . . . . . 13 90 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 93 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 96 1. Introduction 98 Traversal Using Relays around NAT (TURN) [I-D.ietf-behave-turn] is a 99 protocol that allows for an element behind a NAT to receive incoming 100 data over UDP or TCP. It is most useful for elements behind NATs 101 without Endpoint-Independent Mapping [RFC4787] that wish to be on the 102 receiving end of a connection to a single peer. 104 The base specification of TURN [I-D.ietf-behave-turn] only defines 105 IPv4-to-IPv4 relaying. This document adds IPv6 support to TURN, 106 which includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. 107 This document defines the REQUESTED-ADDRESS-FAMILY attribute, which 108 is an extension to TURN that allows a client to explicitly request 109 the address type the TURN server will allocate (e.g., an IPv4-only 110 node may request the TURN server to allocate an IPv6 address). This 111 document also defines and registers new error response codes. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 3. Overview of Operation 121 When a user wishes a TURN server to allocate an address of a specific 122 type, it sends an Allocate Request to the TURN server with a 123 REQUESTED-ADDRESS-FAMILY attribute. TURN can run over UDP and TCP, 124 and it allows for a client to request address/port pairs for 125 receiving both UDP and TCP. 127 After the request has been successfully authenticated, the TURN 128 server allocates a transport address of the type indicated in the 129 REQUESTED-ADDRESS-FAMILY attribute. This address is called the 130 relayed transport address. 132 The TURN server returns the relayed transport address in the response 133 to the Allocate Request. This response contains a XOR-RELAYED- 134 ADDRESS attribute indicating the IP address and port that the server 135 allocated for the client. 137 TURN servers allocate a single relayed transport address per 138 allocation request. Therefore, Allocate Requests cannot carry more 139 than one REQUESTED-ADDRESS-FAMILY attribute. Consequently, a client 140 that wishes to allocate more than one relayed transport address at a 141 TURN server (e.g., an IPv4 and an IPv6 address) needs to perform 142 several allocation requests (one allocation request per relayed 143 transport address). 145 A TURN server that supports a set of address families is assumed to 146 be able to relay packets between them. If a server does not support 147 the address family requested by a client, the server returns a 440 148 (Address Family not Supported) error response. 150 4. Creating an Allocation 152 The behavior specified here affects the processing defined in Section 153 6 of [I-D.ietf-behave-turn]. 155 4.1. Sending an Allocate Request 157 A client that wishes to obtain a relayed transport address of a 158 specific address type includes a REQUESTED-ADDRESS-FAMILY attribute, 159 which is defined in Section 4.1.1, in the Allocate Request that it 160 sends to the TURN server. Clients MUST NOT include more than one 161 REQUESTED-ADDRESS-FAMILY attribute in an Allocate Request. The 162 mechanisms to formulate an Allocate Request are described in Section 163 6.1 of [I-D.ietf-behave-turn]. 165 Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an 166 Allocate request that contains a RESERVATION-TOKEN attribute. 168 4.1.1. The REQUESTED-ADDRESS-FAMILY Attribute 170 The REQUESTED-ADDRESS-FAMILY attribute is used by clients to request 171 the allocation of a specific address type from a server. The 172 following is the format of the REQUESTED-ADDRESS-FAMILY attribute. 173 Note that TURN attributes are TLV (Type-Length-Value) encoded, with a 174 16 bit type, a 16 bit length, and a variable-length value. 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Type | Length | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Family | Reserved | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Figure 1: Format of REQUESTED-ADDRESS-FAMILY Attribute 186 Type: the type of the REQUESTED-ADDRESS-FAMILY attribute is 0x0017. 187 As specified in [RFC5389], attributes with values between 0x0000 and 188 0x7FFF are comprehension-required, which means that the client or 189 server cannot successfully process the message unless it understands 190 the attribute. 192 Length: this 16-bit field contains the length of the attribute in 193 bytes. The length of this attribute is 4 bytes. 195 Family: there are two values defined for this field and specified in 196 [RFC5389], Section 15.1: 0x01 for IPv4 addresses and 0x02 for IPv6 197 addresses. 199 Reserved: at this point, the 24 bits in the reserved field MUST be 200 set to zero by the client and MUST be ignored by the server. 202 The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate 203 Requests. 205 4.2. Receiving an Allocate Request 207 Once a server has verified that the request is authenticated and has 208 not been tampered with, the TURN server processes the Allocate 209 request. If it contains both a RESERVATION-TOKEN and a REQUESTED- 210 ADDRESS-FAMILY, the server replies with a 400 (Bad Request) Allocate 211 Error Response. Following the rules in [RFC5389], if the server does 212 not understand the REQUESTED-ADDRESS-FAMILY attribute, it generates 213 an Allocate Error Response, which includes an ERROR-CODE attribute 214 with response code 420 (Unknown Attribute). This response will 215 contain an UNKNOWN-ATTRIBUTE attribute listing the unknown REQUESTED- 216 ADDRESS-FAMILY attribute. 218 If the server can successfully process the request, it allocates a 219 transport address for the TURN client, called the relayed transport 220 address, and returns it in the response to the Allocate Request. 222 As specified in [I-D.ietf-behave-turn], the Allocate Response 223 contains the same transaction ID contained in the Allocate Request 224 and the XOR-RELAYED-ADDRESS attribute is set to the relayed transport 225 address. 227 The XOR-RELAYED-ADDRESS attribute indicates the allocated IP address 228 and port. It is encoded in the same way as the XOR-MAPPED-ADDRESS 229 [RFC5389]. 231 If the REQUESTED-ADDRESS-FAMILY attribute is absent, the server MUST 232 allocate an IPv4 relayed transport address for the TURN client. If 233 allocation of IPv4 addresses is disabled by local policy, the server 234 returns a a 440 (Address Family not Supported) Allocate Error 235 Response. 237 If the server does not support the address family requested by the 238 client, it MUST generate an Allocate Error Response, and it MUST 239 include an ERROR-CODE attribute with the 440 (Address Family not 240 Supported) response code, which is defined in Section 4.2.1. 242 4.2.1. Unsupported Address Family 244 This document defines the following new error response code: 246 440 (Address Family not Supported): The server did not support the 247 address family requested by the client. 249 4.3. Receiving an Allocate Error Response 251 If the client receives an Allocate error response with the 440 252 (Unsupported Address Family) error code, the client MUST NOT retry 253 its request. 255 5. Refreshing an Allocation 257 The behavior specified here affects the processing defined in Section 258 7 of [I-D.ietf-behave-turn]. 260 5.1. Sending a Refresh Request 262 To perform an allocation refresh, the client generates a Refresh 263 Request as described in Section 7.1 of [I-D.ietf-behave-turn]. The 264 client MUST NOT include any REQUESTED-ADDRESS-FAMILY attribute in its 265 Refresh Request. 267 5.2. Receiving a Refresh Request 269 If a server receives a Refresh Request with a REQUESTED-ADDRESS- 270 FAMILY attribute, and the attribute's value doesn't match the address 271 family of the allocation, the server MUST reply with a 443 (Peer 272 Address Family Mismatch) Refresh Error Response. 274 6. CreatePermission 276 The behavior specified here affects the processing defined in Section 277 9 of [I-D.ietf-behave-turn]. 279 6.1. Sending a CreatePermission Request 281 The client MUST only include XOR-PEER-ADDRESS attributes with 282 addresses of the same address family as the relayed transport address 283 for the allocation. 285 6.2. Receiving a CreatePermission request 287 If an XOR-PEER-ADDRESS attribute contains an address of an address 288 family different than the relayed transport address for the 289 allocation, the server MUST generate an error response with the 443 290 (Peer Address Family Mismatch) response code, which is defined in 291 Section 6.2.1. 293 6.2.1. Peer Address Family Mismatch 295 This document defines the following new error response code: 297 443 (Peer Address Family Mismatch): A peer address was of a 298 different address family than the relayed transport address of the 299 allocation. 301 7. Channels 303 The behavior specified here affects the processing defined in Section 304 11 of [I-D.ietf-behave-turn]. 306 7.1. Sending a ChannelBind Request 308 The client MUST only include a XOR-PEER-ADDRESS attribute with an 309 address of the same address family as the relayed transport address 310 for the allocation. 312 7.2. Receiving a ChannelBind Request 314 If the XOR-PEER-ADDRESS attribute contains an address of an address 315 family different than the relayed transport address for the 316 allocation, the server MUST generate an error response with the 443 317 (Peer Address Family Mismatch) response code, which is defined in 318 Section 6.2.1. 320 8. Packet Translations 322 The TURN specification [I-D.ietf-behave-turn] describes how TURN 323 relays should relay traffic consisting of IPv4 packets (i.e., IPv4- 324 to-IPv4 translations). The relay translates the IP addresses and 325 port numbers of the packets based on the allocation's state data. 326 How to translate other header fields is also specified in 327 [I-D.ietf-behave-turn]. This document addresses IPv4-to-IPv6, IPv6- 328 to-IPv4, and IPv6-to-IPv6 translations. 330 TURN relays performing any translation MUST translate the IP 331 addresses and port numbers of the packets based on the allocation's 332 state information as specified in [I-D.ietf-behave-turn]. The 333 following sections specify how to translate other header fields. 335 As discussed in Section 2.6 of [I-D.ietf-behave-turn], translations 336 in TURN are designed so that a TURN server can be implemented as an 337 application that runs in userland under commonly available operating 338 systems and that does not require special privileges. The 339 translations specified in the following sections follow this 340 principle. 342 The descriptions below have two parts: a preferred behavior and an 343 alternate behavior. The server SHOULD implement the preferred 344 behavior. Otherwise, the server MUST implement the alternate 345 behavior and MUST NOT do anything else. 347 8.1. IPv4-to-IPv6 Translations 349 Traffic Class 351 Preferred behavior: as specified in Section 3 of 352 [I-D.ietf-behave-v6v4-xlate]. 354 Alternate behavior: the relay sets the Traffic Class to the 355 default value for outgoing packets. 357 Flow Label 359 Preferred behavior: The relay sets the Flow label to 0. The relay 360 can choose to set the Flow label to a different value if it 361 supports [RFC3697]. 363 Alternate behavior: the relay sets the Flow label to the default 364 value for outgoing packets. 366 Hop Limit 367 Preferred behavior: as specified in Section 3 of 368 [I-D.ietf-behave-v6v4-xlate]. 370 Alternate behavior: the relay sets the Hop Limit to the default 371 value for outgoing packets. 373 Fragmentation 375 Preferred behavior: as specified in Section 3 of 376 [I-D.ietf-behave-v6v4-xlate]. 378 Alternate behavior: the relay assembles incoming fragments. The 379 relay follows its default behavior to send outgoing packets. 381 For both preferred and alternate behavior, the DONT-FRAGMENT 382 attribute ([I-D.ietf-behave-turn], Section 14.8) MUST be ignored 383 by the server. 385 Extension Headers 387 Preferred behavior: the relay sends outgoing packet without any 388 IPv6 extension headers, with the exception of the Fragmentation 389 header as described above. 391 Alternate behavior: same as preferred. 393 8.2. IPv6-to-IPv6 Translations 395 Flow Label 397 The relay should consider that it is handling two different IPv6 398 flows. Therefore, the Flow label [RFC3697] SHOULD NOT be copied as 399 part of the translation. 401 Preferred behavior: The relay sets the Flow label to 0. The relay 402 can choose to set the Flow label to a different value if it 403 supports [RFC3697]. 405 Alternate behavior: the relay sets the Flow label to the default 406 value for outgoing packets. 408 Hop Limit 409 Preferred behavior: the relay acts as a regular router with 410 respect to decrementing the Hop Limit and generating an ICMPv6 411 error if it reaches zero. 413 Alternate behavior: the relay sets the Hop Limit to the default 414 value for outgoing packets. 416 Fragmentation 418 Preferred behavior: If the incoming packet did not include a 419 Fragment header and the outgoing packet size does not exceed the 420 outgoing link's MTU, the relay sends the outgoing packet without a 421 Fragment header. 423 If the incoming packet did not include a Fragment header and the 424 outgoing packet size exceeds the outgoing link's MTU, the relay 425 drops the outgoing packet and send an ICMP message of type 2 code 426 0 ("Packet too big") to the sender of the incoming packet. If the 427 packet is being sent to the peer, the relay reduces the MTU 428 reported in the ICMP message by 48 bytes to allow room for the 429 overhead of a Data indication. 431 If the incoming packet included a Fragment header and the outgoing 432 packet size (with a Fragment header included) does not exceed the 433 outgoing link's MTU, the relay sends the outgoing packet with a 434 Fragment header. The relay sets the fields of the Fragment header 435 as appropriate for a packet originating from the server. 437 If the incoming packet included a Fragment header and the outgoing 438 packet size exceeds the outgoing link's MTU, the relay MUST 439 fragment the outgoing packet into fragments of no more than 1280 440 bytes. The relay sets the fields of the Fragment header as 441 appropriate for a packet originating from the server. 443 Alternate behavior: the relay assembles incoming fragments. The 444 relay follows its default behavior to send outgoing packets. 446 For both preferred and alternate behavior, the DONT-FRAGMENT 447 attribute MUST be ignored by the server. 449 Extension Headers 451 Preferred behavior: the relay sends outgoing packet without any 452 IPv6 extension headers, with the exception of the Fragmentation 453 header as described above. 455 Alternate behavior: same as preferred. 457 8.3. IPv6-to-IPv4 Translations 459 Type of Service and Precedence 461 Preferred behavior: as specified in Section 4 of 462 [I-D.ietf-behave-v6v4-xlate]. 464 Alternate behavior: the relay sets the Type of Service and 465 Precedence to the default value for outgoing packets. 467 Time to Live 469 Preferred behavior: as specified in Section 4 of 470 [I-D.ietf-behave-v6v4-xlate]. 472 Alternate behavior: the relay sets the Time to Live to the default 473 value for outgoing packets. 475 Fragmentation 477 Preferred behavior: as specified in Section 4 of 478 [I-D.ietf-behave-v6v4-xlate]. Additionally, when the outgoing 479 packet's size exceeds the outgoing link's MTU, the relay needs to 480 generate an ICMP error (ICMPv6 Packet Too Big) reporting the MTU 481 size. If the packet is being sent to the peer, the relay SHOULD 482 reduce the MTU reported in the ICMP message by 48 bytes to allow 483 room for the overhead of a Data indication. 485 Alternate behavior: the relay assembles incoming fragments. The 486 relay follows its default behavior to send outgoing packets. 488 For both preferred and alternate behavior, the DONT-FRAGMENT 489 attribute MUST be ignored by the server. 491 9. Security Considerations 493 Translation between IPv4 and IPv6 creates a new way for clients to 494 obtain IPv4 or IPv6 access which they did not have before. For 495 example, an IPv4-only client having access to a TURN server 496 implementing this specification is now able to access the IPv6 497 internet. This needs to be considered when establishing security and 498 monitoring policies. 500 The loop attack described in [I-D.ietf-behave-turn] Section 17.1.7 501 may be more easily done in cases where address spoofing is easier to 502 accomplish over IPv6. Mitigation of this attack over IPv6 is the 503 same as for IPv4. 505 All the security considerations applicable to STUN [RFC5389] and TURN 506 [I-D.ietf-behave-turn] are applicable to this document as well. 508 9.1. Tunnel Amplification Attack 510 An attacker might attempt to cause data packets to loop numerous 511 times between a TURN server and a tunnel between IPv4 and IPv6. The 512 attack goes as follows. 514 Suppose an attacker knows that a tunnel endpoint will forward 515 encapsulated packets from a given IPv6 address (this doesn't 516 necessarily need to be the tunnel endpoint's address). Suppose he 517 then spoofs two packets from this address: 518 1. An allocate request asking for a v4 address, and 519 2. A ChannelBind request establishing a channel to the IPv4 address 520 of the tunnel endpoint 522 Then he has set up an amplification attack: 523 o The TURN relay will re-encapsulate IPv6 UDP data in v4 and send it 524 to the tunnel endpoint 525 o The tunnel endpoint will decapsulate packets from the v4 interface 526 and send them to v6 528 So if the attacker sends a packet of the following form... 530 IPv6: src=2001:DB9::1 dst=2001:DB8::2 531 UDP: 532 TURN: 533 IPv6: src=2001:DB9::1 dst=2001:DB8::2 534 UDP: 535 TURN: 536 IPv6: src=2001:DB9::1 dst=2001:DB8::2 537 UDP: 538 TURN: 539 ... 541 Then the TURN relay and the tunnel endpoint will send it back and 542 forth until the last TURN header is consumed, at which point the TURN 543 relay will send an empty packet, which the tunnel endpoint will drop. 545 The amplification potential here is limited by the MTU, so it's not 546 huge: IPv6+UDP+TURN takes 334 bytes, so you could get a four-to-one 547 amplification out of a 1500-byte packet. But the attacker could 548 still increase traffic volume by sending multiple packets or by 549 establishing multiple channels spoofed from different addresses 550 behind the same tunnel endpoint. 552 The attack is mitigated as follows. It is RECOMMENDED that TURN 553 relays not accept allocation or channel binding requests from 554 addresses known to be tunneled, and that they not forward data to 555 such addresses. In particular, a TURN relay MUST NOT accept Teredo 556 or 6to4 addresses in these requests. 558 10. IANA Considerations 560 The IANA is requested to register the following values under the STUN 561 Attributes registry and under the STUN Error Codes registry. 563 10.1. New STUN Attribute 565 0x0017: REQUESTED-ADDRESS-FAMILY 567 10.2. New STUN Error Codes 569 440 Address Family not Supported 570 443 Peer Address Family Mismatch 572 11. Acknowledgements 574 The authors would like to thank Alfred E. Heggestad, Dan Wing, Magnus 575 Westerlund, Marc Petit-Huguenin, Philip Matthews, and Remi Denis- 576 Courmont for their feedback on this document. 578 12. References 580 12.1. Normative References 582 [I-D.ietf-behave-turn] 583 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 584 Relays around NAT (TURN): Relay Extensions to Session 585 Traversal Utilities for NAT (STUN)", 586 draft-ietf-behave-turn-16 (work in progress), July 2009. 588 [I-D.ietf-behave-v6v4-xlate] 589 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 590 Algorithm", draft-ietf-behave-v6v4-xlate-10 (work in 591 progress), February 2010. 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, March 1997. 596 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 597 "IPv6 Flow Label Specification", RFC 3697, March 2004. 599 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 600 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 601 October 2008. 603 12.2. Informative References 605 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 606 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 607 RFC 4787, January 2007. 609 Authors' Addresses 611 Gonzalo Camarillo 612 Ericsson 613 Hirsalantie 11 614 Jorvas 02420 615 Finland 617 Email: Gonzalo.Camarillo@ericsson.com 619 Oscar Novo 620 Ericsson 621 Hirsalantie 11 622 Jorvas 02420 623 Finland 625 Email: Oscar.Novo@ericsson.com 626 Simon Perreault (editor) 627 Viagenie 628 2600 boul. Laurier, suite 625 629 Quebec, QC G1V 4W1 630 Canada 632 Phone: +1 418 656 9254 633 Email: simon.perreault@viagenie.ca 634 URI: http://www.viagenie.ca