idnits 2.17.1 draft-ietf-behave-turn-ipv6-08.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 (December 17, 2009) is 5243 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-05 ** 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: June 20, 2010 S. Perreault, Ed. 6 Viagenie 7 December 17, 2009 9 Traversal Using Relays around NAT (TURN) Extension for IPv6 10 draft-ietf-behave-turn-ipv6-08 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 June 20, 2010. 45 Copyright Notice 47 Copyright (c) 2009 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 . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . 10 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 87 10.1. New STUN Attribute Registry . . . . . . . . . . . . . . . 12 88 10.2. New STUN Response Code Registry . . . . . . . . . . . . . 12 89 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 90 12. Normative References . . . . . . . . . . . . . . . . . . . . . 12 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 93 1. Introduction 95 Traversal Using Relays around NAT (TURN) [I-D.ietf-behave-turn] is a 96 protocol that allows for an element behind a NAT to receive incoming 97 data over UDP or TCP. It is most useful for elements behind 98 symmetric NATs that wish to be on the receiving end of a connection 99 to a single peer. 101 The base specification of TURN [I-D.ietf-behave-turn] only defines 102 IPv4-to-IPv4 relaying. This document adds IPv6 support to TURN, 103 which includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. 104 This document defines the REQUESTED-ADDRESS-FAMILY attribute, which 105 is an extension to TURN that allows a client to explicitly request 106 the address type the TURN server will allocate (e.g., an IPv4-only 107 node may request the TURN server to allocate an IPv6 address). This 108 document also defines and registers new error response codes. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 3. Overview of Operation 118 When a user wishes a TURN server to allocate an address of a specific 119 type, it sends an Allocate Request to the TURN server with a 120 REQUESTED-ADDRESS-FAMILY attribute. TURN can run over UDP and TCP, 121 as it allows for a client to request address/port pairs for receiving 122 both UDP and TCP. 124 Assuming the request is authenticated, the TURN server allocates a 125 transport address of the type indicated in the REQUESTED-ADDRESS- 126 FAMILY attribute. This address is called the allocated transport 127 address. 129 The TURN server returns the allocated address in the response to the 130 Allocate Request. This response contains a XOR-RELAYED-ADDRESS 131 attribute indicating the IP address and port that the server 132 allocated for the client. 134 TURN servers allocate a single relayed-transport-address per 135 allocation request. Therefore, Allocate Requests cannot carry more 136 than one REQUESTED-ADDRESS-FAMILY attribute. Consequently, a client 137 that wishes to allocate more than one address at a TURN server (e.g., 138 an IPv4 and an IPv6 address) needs to perform several allocation 139 requests (one allocation request per address). 141 A TURN server that supports a set of address families is assumed to 142 be able to relay packets between them. If a server does not support 143 the address family requested by a client, the server returns a 440 144 (Address Family not Supported) error response. 146 4. Creating an Allocation 148 The behavior specified here affects the processing defined in Section 149 6 of [I-D.ietf-behave-turn]. 151 4.1. Sending an Allocate Request 153 A client that wishes to obtain a transport address of a specific 154 address type includes a REQUESTED-ADDRESS-FAMILY attribute, which is 155 defined in Section 4.1.1, in the Allocate Request that it sends to 156 the TURN server. Clients MUST NOT include more than one REQUESTED- 157 ADDRESS-FAMILY attribute in an Allocate Request. The mechanisms to 158 formulate an Allocate Request are described in Section 6.1 of 159 [I-D.ietf-behave-turn]. 161 Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an 162 Allocate request that contains a RESERVATION-TOKEN attribute. 164 4.1.1. The REQUESTED-ADDRESS-FAMILY Attribute 166 The REQUESTED-ADDRESS-FAMILY attribute is used by clients to request 167 the allocation of a specific address type from a server. The 168 following is the format of the REQUESTED-ADDRESS-FAMILY attribute. 169 Note that TURN attributes are TLV (Type-Length-Value) encoded, with a 170 16 bit type, a 16 bit length, and a variable-length value. 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Type | Length | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Family | Reserved | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Figure 1: Format of REQUESTED-ADDRESS-FAMILY Attribute 182 Type: the type of the REQUESTED-ADDRESS-FAMILY attribute is 0x0017. 184 As specified in [RFC5389], attributes with values between 0x0000 and 185 0x7FFF are comprehension-required, which means that the client or 186 server cannot successfully process the message unless it understands 187 the attribute. 189 Length: this 16-bit field contains the length of the attribute in 190 bytes. The length of this attribute is 4 bytes. 192 Family: there are two values defined for this field and specified in 193 [RFC5389]: 0x01 for IPv4 addresses and 0x02 for IPv6 addresses. 195 Reserved: at this point, the 24 bits in the reserved field MUST be 196 set to zero by the client and MUST be ignored by the server. 198 The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate 199 Requests. 201 4.2. Receiving an Allocate Request 203 Assuming the request is authenticated and has not been tampered with, 204 the TURN server processes the Allocate request. If it contains both 205 a RESERVATION-TOKEN and a REQUESTED-ADDRESS-FAMILY, the server 206 replies with a 400 (Bad Request) Allocate Error Response. Following 207 the rules in [RFC5389], if the server does not understand the 208 REQUESTED-ADDRESS-FAMILY attribute, it generates an Allocate Error 209 Response, which includes an ERROR-CODE attribute with response code 210 420 (Unknown Attribute). This response will contain an UNKNOWN- 211 ATTRIBUTE attribute listing the unknown REQUESTED-ADDRESS-FAMILY 212 attribute. 214 If the server can successfully process the request, it allocates a 215 transport address to the TURN client, called the allocated transport 216 address, and returns it in the response to the Allocate Request. 218 As specified in [I-D.ietf-behave-turn], the Allocate Response 219 contains the same transaction ID contained in the Allocate Request 220 and the XOR-RELAYED-ADDRESS attribute that sets it to the allocated 221 transport address. 223 The XOR-RELAYED-ADDRESS attribute indicates the allocated IP address 224 and port. It is encoded in the same way as the XOR-MAPPED-ADDRESS 225 [RFC5389]. 227 If the REQUESTED-ADDRESS-FAMILY attribute is absent, the server MUST 228 allocate an IPv4 transport address to the TURN client. If allocation 229 of IPv4 addresses is disabled by local policy, the server returns a a 230 440 (Address Family not Supported) Allocate Error Response. 232 If the server does not support the address family requested by the 233 client, it MUST generate an Allocate Error Response, and it MUST 234 include an ERROR-CODE attribute with the 440 (Address Family not 235 Supported) response code, which is defined in Section 4.2.1. 237 4.2.1. Unsupported Address Family 239 This document defines the following new error response code: 241 440 (Address Family not Supported): The server did not support the 242 address family requested by the client. 244 4.3. Receiving an Allocate Error Response 246 If the client receives an Allocate error response with the 440 247 (Unsupported Address Family) error code, the client SHOULD NOT retry 248 its request. 250 5. Refreshing an Allocation 252 The behavior specified here affects the processing defined in Section 253 7 of [I-D.ietf-behave-turn]. 255 5.1. Sending a Refresh Request 257 To perform a binding refresh, the client generates a Refresh Request 258 as described in Section 7.1 of [I-D.ietf-behave-turn]. The client 259 MUST NOT include any REQUESTED-ADDRESS-FAMILY attribute in its 260 Refresh Request. 262 5.2. Receiving a Refresh Request 264 If a server receives a Refresh Request with a REQUESTED-ADDRESS- 265 FAMILY attribute, and the attribute's value doesn't match the address 266 family of the allocation, the server MUST reply with a 443 (Peer 267 Address Family Mismatch) Refresh Error Response. 269 6. CreatePermission 271 The behavior specified here affects the processing defined in Section 272 9 of [I-D.ietf-behave-turn]. 274 6.1. Sending a CreatePermission Request 276 The client MUST only include XOR-PEER-ADDRESS attributes with 277 addresses of the same address family as the relayed transport address 278 for the allocation. 280 6.2. Receiving a CreatePermission request 282 If an XOR-PEER-ADDRESS attribute contains an address of an address 283 family different than the relayed transport address for the 284 allocation, the server MUST generate an error response with the 443 285 (Peer Address Family Mismatch) response code, which is defined in 286 Section 6.2.1. 288 6.2.1. Peer Address Family Mismatch 290 This document defines the following new error response code: 292 443 (Peer Address Family Mismatch): A peer address was of a 293 different address family than the relayed transport address of the 294 allocation. 296 7. Channels 298 The behavior specified here affects the processing defined in Section 299 11 of [I-D.ietf-behave-turn]. 301 7.1. Sending a ChannelBind Request 303 The client MUST only include a XOR-PEER-ADDRESS attribute with an 304 address of the same address family as the relayed transport address 305 for the allocation. 307 7.2. Receiving a ChannelBind Request 309 If the XOR-PEER-ADDRESS attribute contains an address of an address 310 family different than the relayed transport address for the 311 allocation, the server MUST generate an error response with the 443 312 (Peer Address Family Mismatch) response code, which is defined in 313 Section 6.2.1. 315 8. Packet Translations 317 The TURN specification [I-D.ietf-behave-turn] describes how TURN 318 relays should relay traffic consisting of IPv4 packets (i.e., IPv4- 319 to-IPv4 translations). The relay translates the IP addresses and 320 port numbers of the packets based on the allocation's state data. 321 How to translate other header fields is also specified in 322 [I-D.ietf-behave-turn]. This document addresses IPv4-to-IPv6, IPv6- 323 to-IPv4, and IPv6-to-IPv6 translations. 325 TURN relays performing any translation MUST translate the IP 326 addresses and port numbers of the packets based on the allocation's 327 state information as specified in [I-D.ietf-behave-turn]. The 328 following sections specify how to translate other header fields. 330 As discussed in Section 2.6 of [I-D.ietf-behave-turn], translations 331 in TURN are designed so that a TURN server can be implemented as an 332 application that runs in userland under commonly available operating 333 systems and that does not require special privileges. The 334 translations specified in the following sections follow this 335 principle. 337 The descriptions below have two parts: a preferred behavior and an 338 alternate behavior. The server SHOULD implement the preferred 339 behavior. However, if that is not possible for a particular field, 340 then the server SHOULD implement the alternative behavior. 342 Note that the use of the behaviors specified in the following 343 sections is at the "should" level. Having its use at the "should" 344 level instead of at the "must" level makes it possible to use 345 different translation algorithms that may be developed in the 346 future. 348 8.1. IPv4-to-IPv6 Translations 350 Flow Label 352 Preferred behavior: The relay sets the Flow label to 0. The relay 353 can choose to set the Flow label to a different value if it 354 supports [RFC3697]. 356 Alternative behavior: the relay sets the Flow label to the default 357 value for outgoing packets. 359 Hop Limit 361 Preferred behavior: as specified in Section 2 of 362 [I-D.ietf-behave-v6v4-xlate]. 364 Alternative behavior: the relay sets the Hop Limit to the default 365 value for outgoing packets. 367 Fragmentation 368 Preferred behavior: as specified in Section 2 of 369 [I-D.ietf-behave-v6v4-xlate]. 371 Alternative behavior: the relay assembles incoming fragments. The 372 relay follows its default behavior to send outgoing packets. 374 For both preferred and alternative behavior, the DONT-FRAGMENT 375 attribute MUST be ignored by the server. 377 Extension Headers 379 Preferred behavior: the relay sends outgoing packet without any 380 IPv6 extension headers, with the exception of the Fragmentation 381 header as described above. 383 Alternative behavior: same as preferred. 385 8.2. IPv6-to-IPv6 Translations 387 Flow Label 389 The relay should consider that it is handling two different IPv6 390 flows. Therefore, the Flow label [RFC3697] SHOULD NOT be copied as 391 part of the translation. 393 Preferred behavior: The relay sets the Flow label to 0. The relay 394 can choose to set the Flow label to a different value if it 395 supports [RFC3697]. 397 Alternative behavior: the relay sets the Flow label to the default 398 value for outgoing packets. 400 Hop Limit 402 Preferred behavior: the relay acts as a regular router with 403 respect to decrementing the Hop Limit and generating an ICMPv6 404 error if it reaches zero. 406 Alternative behavior: the relay sets the Hop Limit to the default 407 value for outgoing packets. 409 Fragmentation 410 Preferred behavior: If the incoming packet did not include a 411 Fragment header and the outgoing packet size does not exceed the 412 outgoing link's MTU, the relay sends the outgoing packet without a 413 Fragment header. 415 If the incoming packet did not include a Fragment header and the 416 outgoing packet size exceeds the outgoing link's MTU, the relay 417 drops the outgoing packet and send an ICMP message of type 2 code 418 0 ("Packet too big") to the sender of the incoming packet. If the 419 packet is being sent to the peer, the relay reduces the MTU 420 reported in the ICMP message by 48 bytes to allow room for the 421 overhead of a Data indication. 423 If the incoming packet included a Fragment header and the outgoing 424 packet size (with a Fragment header included) does not exceed the 425 outgoing link's MTU, the relay sends the outgoing packet with a 426 Fragment header. The relay sets the fields of the Fragment header 427 as appropriate for a packet originating from the server. 429 If the incoming packet included a Fragment header and the outgoing 430 packet size exceeds the outgoing link's MTU, the relay MUST 431 fragment the outgoing packet into fragments of no more than 1280 432 bytes. The relay sets the fields of the Fragment header as 433 appropriate for a packet originating from the server. 435 Alternative behavior: the relay assembles incoming fragments. The 436 relay follows its default behavior to send outgoing packets. 438 For both preferred and alternative behavior, the DONT-FRAGMENT 439 attribute MUST be ignored by the server. 441 Extension Headers 443 Preferred behavior: the relay sends outgoing packet without any 444 IPv6 extension headers, with the exception of the Fragmentation 445 header as described above. 447 Alternative behavior: same as preferred. 449 8.3. IPv6-to-IPv4 Translations 451 Type of Service and Precedence 452 Preferred behavior: as specified in Section 3 of 453 [I-D.ietf-behave-v6v4-xlate]. 455 Alternative behavior: the relay sets the Type of Service and 456 Precedence to the default value for outgoing packets. 458 Time to Live 460 Preferred behavior: as specified in Section 3 of 461 [I-D.ietf-behave-v6v4-xlate]. 463 Alternative behavior: the relay sets the Time to Live to the 464 default value for outgoing packets. 466 Fragmentation 468 Preferred behavior: as specified in Section 3 of 469 [I-D.ietf-behave-v6v4-xlate]. Additionally, when the outgoing 470 packet's size exceeds the outgoing link's MTU, the relay needs to 471 generate an ICMP error (ICMPv6 Packet Too Big) reporting the MTU 472 size. If the packet is being sent to the peer, the relay SHOULD 473 reduce the MTU reported in the ICMP message by 48 bytes to allow 474 room for the overhead of a Data indication. 476 Alternative behavior: the relay assembles incoming fragments. The 477 relay follows its default behavior to send outgoing packets. 479 For both preferred and alternative behavior, the DONT-FRAGMENT 480 attribute MUST be ignored by the server. 482 9. Security Considerations 484 The attribute and error response code defined in this document do not 485 have any special security considerations beyond those for other 486 attributes and Error response codes. All the security considerations 487 applicable to STUN [RFC5389] and TURN are applicable to this document 488 as well. 490 10. IANA Considerations 492 The IANA is requested to register the following values under the STUN 493 Attributes registry and under the STUN Response Code Registry. 495 10.1. New STUN Attribute Registry 497 0x0017: REQUESTED-ADDRESS-FAMILY 499 10.2. New STUN Response Code Registry 501 440 Address Family not Supported 502 443 Peer Address Family Mismatch 504 11. Acknowledgements 506 The authors would like to thank Alfred E. Heggestad, Dan Wing, Marc 507 Petit-Huguenin, Philip Matthews, and Remi Denis-Courmont for their 508 feedback on this document. 510 12. Normative References 512 [I-D.ietf-behave-turn] 513 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 514 Relays around NAT (TURN): Relay Extensions to Session 515 Traversal Utilities for NAT (STUN)", 516 draft-ietf-behave-turn-16 (work in progress), July 2009. 518 [I-D.ietf-behave-v6v4-xlate] 519 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 520 Algorithm", draft-ietf-behave-v6v4-xlate-05 (work in 521 progress), December 2009. 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, March 1997. 526 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 527 "IPv6 Flow Label Specification", RFC 3697, March 2004. 529 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 530 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 531 October 2008. 533 Authors' Addresses 535 Gonzalo Camarillo 536 Ericsson 537 Hirsalantie 11 538 Jorvas 02420 539 Finland 541 Email: Gonzalo.Camarillo@ericsson.com 543 Oscar Novo 544 Ericsson 545 Hirsalantie 11 546 Jorvas 02420 547 Finland 549 Email: Oscar.Novo@ericsson.com 551 Simon Perreault (editor) 552 Viagenie 553 2600 boul. Laurier, suite 625 554 Quebec, QC G1V 4W1 555 Canada 557 Phone: +1 418 656 9254 558 Email: simon.perreault@viagenie.ca 559 URI: http://www.viagenie.ca