idnits 2.17.1 draft-ietf-behave-turn-ipv6-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (October 14, 2009) is 5306 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) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 3697 (Obsoleted by RFC 6437) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE S. Perreault, Ed. 3 Internet-Draft Viagenie 4 Intended status: Standards Track G. Camarillo 5 Expires: April 17, 2010 O. Novo 6 Ericsson 7 October 14, 2009 9 Traversal Using Relays around NAT (TURN) Extension for IPv6 10 draft-ietf-behave-turn-ipv6-07 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 17, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document adds IPv6 support to Traversal Using Relays around NAT 49 (TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, 50 and IPv6-to-IPv4 relaying. This document defines the REQUESTED- 51 ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY 52 attribute allows a client to explicitly request the address type the 53 TURN server will allocate (e.g., an IPv4-only node may request the 54 TURN server to allocate an IPv6 address). 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 61 4. Creating an Allocation . . . . . . . . . . . . . . . . . . . . 4 62 4.1. Sending an Allocate Request . . . . . . . . . . . . . . . 4 63 4.1.1. The REQUESTED-ADDRESS-FAMILY Attribute . . . . . . . . 4 64 4.2. Receiving an Allocate Request . . . . . . . . . . . . . . 5 65 4.2.1. Unsupported Address Family . . . . . . . . . . . . . . 6 66 4.3. Receiving an Allocate Error Response . . . . . . . . . . . 6 67 5. Refreshing an Allocation . . . . . . . . . . . . . . . . . . . 6 68 5.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 6 69 5.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 6 70 6. CreatePermission . . . . . . . . . . . . . . . . . . . . . . . 6 71 6.1. Sending a CreatePermission Request . . . . . . . . . . . . 6 72 6.2. Receiving a CreatePermission request . . . . . . . . . . . 6 73 6.2.1. Peer Address Family Mismatch . . . . . . . . . . . . . 7 74 7. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 7.1. Sending a ChannelBind Request . . . . . . . . . . . . . . 7 76 7.2. Receiving a ChannelBind Request . . . . . . . . . . . . . 7 77 8. Packet Translations . . . . . . . . . . . . . . . . . . . . . 7 78 8.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . . 8 79 8.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . . 9 80 8.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . . 10 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 10.1. New STUN Attribute Registry . . . . . . . . . . . . . . . 11 84 10.2. New STUN Response Code Registry . . . . . . . . . . . . . 11 85 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 86 12. Normative References . . . . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 Traversal Using Relays around NAT (TURN) [I-D.ietf-behave-turn] is a 92 protocol that allows for an element behind a NAT to receive incoming 93 data over UDP or TCP. It is most useful for elements behind 94 symmetric NATs that wish to be on the receiving end of a connection 95 to a single peer. 97 The base specification of TURN [I-D.ietf-behave-turn] only defines 98 IPv4-to-IPv4 relaying. This document adds IPv6 support to TURN, 99 which includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. 100 This document defines the REQUESTED-ADDRESS-FAMILY attribute, which 101 is an extension to TURN that allows a client to explicitly request 102 the address type the TURN server will allocate (e.g., an IPv4-only 103 node may request the TURN server to allocate an IPv6 address). This 104 document also defines and registers a new error response code with 105 the value 440 (Address Family not Supported). 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. Overview of Operation 115 When a user wishes a TURN server to allocate an address of a specific 116 type, it sends an Allocate Request to the TURN server with a 117 REQUESTED-ADDRESS-FAMILY attribute. TURN can run over UDP and TCP, 118 as it allows for a client to request address/port pairs for receiving 119 both UDP and TCP. 121 Assuming the request is authenticated and has not been tampered with, 122 the TURN server allocates a transport address of the type indicated 123 in the REQUESTED-ADDRESS-FAMILY attribute. This address is called 124 the allocated transport address. 126 The TURN server returns the allocated address in the response to the 127 Allocate Request. This response contains a XOR-RELAYED-ADDRESS 128 attribute indicating the IP address and port that the server 129 allocated for the client. 131 TURN servers allocate a single relayed-transport-address per 132 allocation request. Therefore, Allocate Requests cannot carry more 133 than one REQUESTED-ADDRESS-FAMILY attribute. Consequently, a client 134 that wishes to allocate more than one address at a TURN server (e.g., 135 an IPv4 and an IPv6 address) needs to perform several allocation 136 requests (one allocation request per address). 138 A TURN server that supports a set of address families is assumed to 139 be able to relay packets between them. If a server does not support 140 the address family requested by a client, the server returns a 440 141 (Address Family not Supported) error response. 143 4. Creating an Allocation 145 The behavior specified here affects the processing defined in Section 146 6 of [I-D.ietf-behave-turn]. 148 4.1. Sending an Allocate Request 150 A client that wishes to obtain a transport address of a specific 151 address type includes a REQUESTED-ADDRESS-FAMILY attribute, which is 152 defined in Section 4.1.1, in the Allocate Request that it sends to 153 the TURN server. Clients MUST NOT include more than one REQUESTED- 154 ADDRESS-FAMILY attribute in an Allocate Request. The mechanisms to 155 formulate an Allocate Request are described in Section 6.1 of 156 [I-D.ietf-behave-turn]. 158 Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an 159 Allocate request that contains a RESERVATION-TOKEN attribute. 161 4.1.1. The REQUESTED-ADDRESS-FAMILY Attribute 163 The REQUESTED-ADDRESS-FAMILY attribute is used by clients to request 164 the allocation of a specific address type from a server. The 165 following is the format of the REQUESTED-ADDRESS-FAMILY attribute. 166 Note that TURN attributes are TLV (Type-Length-Value) encoded, with a 167 16 bit type, a 16 bit length, and a variable-length value. 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Type | Length | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Family | Reserved | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Figure 1: Format of REQUESTED-ADDRESS-FAMILY Attribute 179 Type: the type of the REQUESTED-ADDRESS-FAMILY attribute is 0x0017. 180 As specified in [RFC5389], attributes with values between 0x0000 and 181 0x7FFF are comprehension-required, which means that the client or 182 server cannot successfully process the message unless it understands 183 the attribute. 185 Length: this 16-bit field contains the length of the attribute in 186 bytes. The length of this attribute is 4 bytes. 188 Family: there are two values defined for this field and specified in 189 [RFC5389]: 0x01 for IPv4 addresses and 0x02 for IPv6 addresses. 191 Reserved: at this point, the 24 bits in the reserved field MUST be 192 set to zero by the client and MUST be ignored by the server. 194 The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate 195 Requests. 197 4.2. Receiving an Allocate Request 199 Assuming the request is authenticated and has not been tampered with, 200 the TURN server processes the Allocate request. Following the rules 201 in [RFC5389], if the server does not understand the REQUESTED- 202 ADDRESS-FAMILY attribute, it generates an Allocate Error Response, 203 which includes an ERROR-CODE attribute with response code 420 204 (Unknown Attribute). This response will contain an UNKNOWN-ATTRIBUTE 205 attribute listing the unknown REQUESTED-ADDRESS-FAMILY attribute. 207 If the server can successfully process the request, it allocates a 208 transport address to the TURN client, called the allocated transport 209 address, and returns it in the response to the Allocate Request. 211 As specified in [I-D.ietf-behave-turn], the Allocate Response 212 contains the same transaction ID contained in the Allocate Request 213 and the XOR-RELAYED-ADDRESS attribute that sets it to the allocated 214 transport address. 216 The XOR-RELAYED-ADDRESS attribute indicates the allocated IP address 217 and port. It is encoded in the same way as the XOR-MAPPED-ADDRESS 218 [RFC5389]. 220 If the REQUESTED-ADDRESS-FAMILY attribute is absent, the server MUST 221 allocate an IPv4 transport address to the TURN client. 223 If the server does not support the address family requested by the 224 client, it MUST generate an Allocate Error Response, and it MUST 225 include an ERROR-CODE attribute with the 440 (Address Family not 226 Supported) response code, which is defined in Section 4.2.1. 228 4.2.1. Unsupported Address Family 230 This document defines the following new error response code: 232 440 (Address Family not Supported): The server did not support the 233 address family requested by the client. 235 4.3. Receiving an Allocate Error Response 237 If the client receives an Allocate error response with the 440 238 (Unsupported Address Family) error code, the client SHOULD NOT retry 239 its request. 241 5. Refreshing an Allocation 243 The behavior specified here affects the processing defined in Section 244 7 of [I-D.ietf-behave-turn]. 246 5.1. Sending a Refresh Request 248 To perform a binding refresh, the client generates a Refresh Request 249 as described in Section 7.1 of [I-D.ietf-behave-turn]. The client 250 MUST NOT include any REQUESTED-ADDRESS-FAMILY attribute in its 251 Refresh Request. 253 5.2. Receiving a Refresh Request 255 If a server receives a Refresh Request with a REQUESTED-ADDRESS- 256 FAMILY attribute, it MUST ignore the attribute and process the 257 request as if the attribute was not there. 259 6. CreatePermission 261 The behavior specified here affects the processing defined in Section 262 9 of [I-D.ietf-behave-turn]. 264 6.1. Sending a CreatePermission Request 266 The client MUST only include XOR-PEER-ADDRESS attributes with 267 addresses of the same address family as the relayed transport address 268 for the allocation. 270 6.2. Receiving a CreatePermission request 272 If an XOR-PEER-ADDRESS attribute contains an address of an address 273 family different than the relayed transport address for the 274 allocation, the server MUST generate an error response with the 443 275 (Peer Address Family Mismatch) response code, which is defined in 276 Section 6.2.1. 278 6.2.1. Peer Address Family Mismatch 280 This document defines the following new error response code: 282 443 (Peer Address Family Mismatch): A peer address was of a 283 different address family than the relayed transport address of the 284 allocation. 286 7. Channels 288 The behavior specified here affects the processing defined in Section 289 11 of [I-D.ietf-behave-turn]. 291 7.1. Sending a ChannelBind Request 293 The client MUST only include a XOR-PEER-ADDRESS attribute with an 294 address of the same address family as the relayed transport address 295 for the allocation. 297 7.2. Receiving a ChannelBind Request 299 If the XOR-PEER-ADDRESS attribute contains an address of an address 300 family different than the relayed transport address for the 301 allocation, the server MUST generate an error response with the 443 302 (Peer Address Family Mismatch) response code, which is defined in 303 Section 6.2.1. 305 8. Packet Translations 307 The TURN specification [I-D.ietf-behave-turn] describes how TURN 308 relays should relay traffic consisting of IPv4 packets (i.e., IPv4- 309 to-IPv4 translations). The relay translates the IP addresses and 310 port numbers of the packets based on the allocation's state data. 311 How to translate other header fields is also specified in 312 [I-D.ietf-behave-turn]. This document addresses IPv4-to-IPv6, IPv6- 313 to-IPv4, and IPv6-to-IPv6 translations. 315 TURN relays performing any translation MUST translate the IP 316 addresses and port numbers of the packets based on the allocation's 317 state information as specified in [I-D.ietf-behave-turn]. The 318 following sections specify how to translate other header fields. 320 As discussed in Section 2.6 of [I-D.ietf-behave-turn], translations 321 in TURN are designed so that a TURN server can be implemented as an 322 application that runs in userland under commonly available operating 323 systems and that does not require special privileges. The 324 translations specified in the following sections follow this 325 principle. 327 The descriptions below have two parts: a preferred behavior and an 328 alternate behavior. The server SHOULD implement the preferred 329 behavior. However, if that is not possible for a particular field, 330 then the server SHOULD implement the alternative behavior. 332 Note that the use of the behaviors specified in the following 333 sections is at the "should" level. Having its use at the "should" 334 level instead of at the "must" level makes it possible to use 335 different translation algorithms that may be developed in the 336 future. 338 8.1. IPv4-to-IPv6 Translations 340 Flow Label 342 Preferred behavior: The relay sets the Flow label to 0. The relay 343 can choose to set the Flow label to a different value if it 344 supports [RFC3697]. 346 Alternative behavior: the relay sets the Flow label to the default 347 value for outgoing packets. 349 Hop Limit 351 Preferred behavior: as specified in Section 3.1 of [RFC2765]. 353 Alternative behavior: the relay sets the Hop Limit to the default 354 value for outgoing packets. 356 Fragmentation 358 Preferred behavior: as specified in Section 3.1 of [RFC2765]. 360 Alternative behavior: the relay assembles incoming fragments. The 361 relay follows its default behavior to send outgoing packets. 363 If present, the DONT-FRAGMENT attribute MUST be ignored by the 364 server. 366 Extension Headers 368 Preferred behavior: the relay sends outgoing packet without any 369 IPv6 extension headers, with the exception of the Fragmentation 370 header as described above. 372 Alternative behavior: same as preferred. 374 8.2. IPv6-to-IPv6 Translations 376 Flow Label 378 The relay should consider that it is handling two different IPv6 379 flows. Therefore, the Flow label [RFC3697] SHOULD NOT be copied as 380 part of the translation. 382 Preferred behavior: The relay sets the Flow label to 0. The relay 383 can choose to set the Flow label to a different value if it 384 supports [RFC3697]. 386 Alternative behavior: the relay sets the Flow label to the default 387 value for outgoing packets. 389 Hop Limit 391 Preferred behavior: the relay acts as a regular router with 392 respect to decrementing the Hop Limit and generating an ICMPv6 393 error if it reaches zero. 395 Alternative behavior: the relay sets the Hop Limit to the default 396 value for outgoing packets. 398 Fragmentation 400 Preferred behavior: If the incoming packet did not include a 401 Fragment header and the outgoing packet size does not exceed the 402 outgoing link's MTU, the relay sends the outgoing packet without a 403 Fragment header. 405 If the incoming packet did not include a Fragment header and the 406 outgoing packet size exceeds the outgoing link's MTU, the delay 407 drops the outgoing packet and send an ICMP message of type 2 code 408 0 ("Packet too big") to the sender of the incoming packet. If the 409 packet is being sent to the peer, the relay reduces the MTU 410 reported in the ICMP message by 48 bytes to allow room for the 411 overhead of a Data indication. 413 If the incoming packet included a Fragment header and the outgoing 414 packet size (with a Fragment header included) does not exceed the 415 outgoing link's MTU, the relay sends the outgoing packet with a 416 Fragment header. The relay sets the fields of the Fragment header 417 as appropriate for a packet originating from the server. 419 If the incoming packet included a Fragment header and the outgoing 420 packet size exceeds the outgoing link's MTU, the relay MUST 421 fragment the outgoing packet into fragments of no more than 1280 422 bytes. The relay sets the fields of the Fragment header as 423 appropriate for a packet originating from the server. 425 Alternative behavior: the relay assembles incoming fragments. The 426 relay follows its default behavior to send outgoing packets. 428 If present, the DONT-FRAGMENT attribute MUST be ignored by the 429 server. 431 Extension Headers 433 Preferred behavior: the relay sends outgoing packet without any 434 IPv6 extension headers, with the exception of the Fragmentation 435 header as described above. 437 Alternative behavior: same as preferred. 439 8.3. IPv6-to-IPv4 Translations 441 Type of Service and Precedence 443 Preferred behavior: as specified in Section 4 of [RFC2765]. 445 Alternative behavior: the relay sets the Type of Service and 446 Precedence to the default value for outgoing packets. 448 Time to Live 450 Preferred behavior: as specified in Section 4.1 of [RFC2765]. 452 Alternative behavior: the relay sets the Time to Live to the 453 default value for outgoing packets. 455 Fragmentation 457 Preferred behavior: as specified in Section 4 of [RFC2765]. 458 Additionally, when the outgoing packet's size exceeds the 459 outgoing link's MTU, the relay needs to generate an ICMP error 460 (ICMPv6 Packet Too Big) reporting the MTU size. If the packet is 461 being sent to the peer, the relay SHOULD reduce the MTU reported 462 in the ICMP message by 48 bytes to allow room for the overhead of 463 a Data indication. 465 Alternative behavior: the relay assembles incoming fragments. The 466 relay follows its default behavior to send outgoing packets. 468 If present, the DONT-FRAGMENT attribute MUST be ignored by the 469 server. 471 9. Security Considerations 473 The attribute and error response code defined in this document do not 474 have any special security considerations beyond those for other 475 attributes and Error response codes. All the security considerations 476 applicable to STUN [RFC5389] and TURN are applicable to this document 477 as well. 479 10. IANA Considerations 481 The IANA is requested to register the following values under the STUN 482 Attributes registry and under the STUN Response Code Registry. 484 10.1. New STUN Attribute Registry 486 0x0017: REQUESTED-ADDRESS-FAMILY 488 10.2. New STUN Response Code Registry 490 440 Address Family not Supported 492 11. Acknowledgements 494 The authors would like to thank Alfred E. Heggestad, Remi Denis- 495 Courmont, and Philip Matthews for their feedback on this document. 497 12. Normative References 499 [I-D.ietf-behave-turn] 500 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 501 Relays around NAT (TURN): Relay Extensions to Session 502 Traversal Utilities for NAT (STUN)", 503 draft-ietf-behave-turn-16 (work in progress), July 2009. 505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 506 Requirement Levels", BCP 14, RFC 2119, March 1997. 508 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 509 (SIIT)", RFC 2765, February 2000. 511 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 512 "IPv6 Flow Label Specification", RFC 3697, March 2004. 514 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 515 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 516 October 2008. 518 Authors' Addresses 520 Simon Perreault (editor) 521 Viagenie 522 2600 boul. Laurier, suite 625 523 Quebec, QC G1V 4W1 524 Canada 526 Phone: +1 418 656 9254 527 Email: simon.perreault@viagenie.ca 528 URI: http://www.viagenie.ca 530 Gonzalo Camarillo 531 Ericsson 532 Hirsalantie 11 533 Jorvas 02420 534 Finland 536 Email: Gonzalo.Camarillo@ericsson.com 537 Oscar Novo 538 Ericsson 539 Hirsalantie 11 540 Jorvas 02420 541 Finland 543 Email: Oscar.Novo@ericsson.com