idnits 2.17.1 draft-ietf-behave-turn-ipv6-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 400. 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 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 29, 2008) is 5656 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 (-16) exists of draft-ietf-behave-turn-09 ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 3697 (Obsoleted by RFC 6437) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 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: May 2, 2009 October 29, 2008 7 Traversal Using Relays around NAT (TURN) Extension for IPv4/IPv6 8 Transition 9 draft-ietf-behave-turn-ipv6-05.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 2, 2009. 36 Abstract 38 This document defines the REQUESTED-ADDRESS-TYPE attribute for 39 Traversal Using Relays around NAT (TURN). The REQUESTED-ADDRESS-TYPE 40 attribute allows a client to explicitly request the address type the 41 TURN server will allocate (e.g., an IPv4-only node may request the 42 TURN server to allocate an IPv6 address). Additionally, this 43 document also defines a new error response code with the value 440 44 (Address Family not Supported). 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 51 4. Creating an Allocation . . . . . . . . . . . . . . . . . . . . 4 52 4.1. Sending an Allocate Request . . . . . . . . . . . . . . . 4 53 4.1.1. The REQUESTED-ADDRESS-TYPE Attribute . . . . . . . . . 4 54 4.2. Receiving an Allocate Request . . . . . . . . . . . . . . 5 55 4.2.1. Unsupported Address Family . . . . . . . . . . . . . . 5 56 5. Refreshing an Allocation . . . . . . . . . . . . . . . . . . . 6 57 5.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 6 58 5.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 6 59 6. Packet Translations . . . . . . . . . . . . . . . . . . . . . 6 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 8.1. New STUN Attribute Registry . . . . . . . . . . . . . . . 8 63 8.2. New STUN Response Code Registry . . . . . . . . . . . . . 8 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 65 10. Normative References . . . . . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 67 Intellectual Property and Copyright Statements . . . . . . . . . . 10 69 1. Introduction 71 Traversal Using Relays around NAT (TURN) [I-D.ietf-behave-turn] is a 72 protocol that allows for an element behind a NAT or firewall to 73 receive incoming data over UDP or TCP. It is most useful for 74 elements behind symmetric NATs or firewalls that wish to be on the 75 receiving end of a connection to a single peer. 77 This document defines the REQUESTED-ADDRESS-TYPE attribute, which is 78 an extension to TURN that allows a client to explicitly request the 79 address type the TURN server will allocate (e.g., an IPv4-only node 80 may request the TURN server to allocate an IPv6 address). 82 This document also defines and registers a new error response code 83 with the value 440 (Address Family not Supported). 85 2. Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 3. Overview of Operation 93 When a user wishes a TURN server to allocate an address of a specific 94 type, it sends an Allocate Request to the TURN server with a 95 REQUESTED-ADDRESS-TYPE attribute. TURN can run over UDP and TCP, as 96 it allows for a client to request address/port pairs for receiving 97 both UDP and TCP. 99 Assuming the request is authenticated and has not been tampered with, 100 the TURN server allocates a transport address of the type indicated 101 in the REQUESTED-ADDRESS-TYPE attribute. This address is called the 102 allocated transport address. 104 The TURN server returns the allocated address in the response to the 105 Allocate Request. This response contains a RELAY-ADDRESS attribute 106 indicating the mapped IP address and port that the server assigned to 107 the client. 109 TURN servers allocate a single relayed-transport-address per 110 allocation request. Therefore, Allocate Requests cannot carry more 111 than one REQUESTED-ADDRESS-TYPE attribute. Consequently, a client 112 that wishes to allocate more than one address at a TURN server (e.g., 113 an IPv4 and an IPv6 address) needs to perform several allocation 114 requests (one allocation request per address). 116 4. Creating an Allocation 118 The behavior specified here affects the processing defined in Section 119 6 of [I-D.ietf-behave-turn]. 121 4.1. Sending an Allocate Request 123 A client that wishes to obtain a transport address of a specific 124 address type includes a REQUESTED-ADDRESS-TYPE attribute in the 125 Allocate Request that sends to the TURN server. Clients MUST NOT 126 include more than one REQUESTED-ADDRESS-TYPE attribute in an Allocate 127 Request. The mechanisms to formulate an Allocate Request are 128 described in Section 6.1 of [I-D.ietf-behave-turn]. 130 4.1.1. The REQUESTED-ADDRESS-TYPE Attribute 132 The REQUESTED-ADDRESS-TYPE attribute is used by clients to request 133 the allocation of a specific address type from a server. The 134 following is the format of the REQUESTED-ADDRESS-TYPE attribute. 135 Note that TURN attributes are TLV (Type-Length-Value) encoded, with a 136 16 bit type, a 16 bit length, and a variable-length value. 138 0 1 2 3 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Type | Length | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Family | Reserved | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Figure 1: Format of REQUESTED-ADDRESS-TYPE Attribute 148 Type: the type of the REQUESTED-ADDRESS-TYPE attribute is 0x0017. As 149 specified in [I-D.ietf-behave-rfc3489bis], attributes with values 150 between 0x0000 and 0x7FFF are comprehension-required, which means 151 that the client or server cannot successfully process the message 152 unless it understands the attribute. 154 Length: this 16-bit field contains the length of the attribute in 155 bytes. The length of this attribute is 4 bytes. 157 Family: there are two values defined for this field and specified in 158 [I-D.ietf-behave-rfc3489bis]: 0x01 for IPv4 addresses and 0x02 for 159 IPv6 addresses. 161 Reserved: at this point, the 24 bits in the reserved field SHOULD be 162 set to zero by the client and MUST be ignored by the server. 164 The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate 165 Requests. 167 4.2. Receiving an Allocate Request 169 Assuming the request is authenticated and has not been tampered with, 170 the TURN server processes the Allocate request. Following the rules 171 in [I-D.ietf-behave-rfc3489bis], if the server does not understand 172 the REQUESTED-ADDRESS-TYPE attribute, it generates an Allocate Error 173 Response, which includes an ERROR-CODE attribute with response code 174 420 (Unknown Attribute). This response will contain an UNKNOWN- 175 ATTRIBUTE attribute listing the unknown REQUESTED-ADDRESS-TYPE 176 attribute. 178 If the server can successfully process the request, it allocates a 179 transport address to the TURN client, called the allocated transport 180 address, and returns it in the response to the Allocate Request. 182 As specified in [I-D.ietf-behave-turn], the Allocate Response 183 contains the same transaction ID contained in the Allocate Request 184 and the RELAY-ADDRESS attribute that sets it to the allocated 185 transport address. 187 The RELAY-ADDRESS attribute indicates the mapped IP address and port. 188 It is encoded in the same way as the XOR-MAPPED-ADDRESS 189 [I-D.ietf-behave-rfc3489bis]. 191 If the REQUESTED-ADDRESS-TYPE attribute is absent, the server MUST 192 allocate an IPv4 transport address to the TURN client. 194 4.2.1. Unsupported Address Family 196 This document defines the following new error response code: 198 440 (Address Family not Supported): The server did not support the 199 address family requested by the client. The client SHOULD NOT 200 retry. 202 If the server does not support the address family requested by the 203 client, it MUST generate an Allocate Error Response, and it MUST 204 include an ERROR-CODE attribute with the response code defined in 205 this draft, 440 (Address Family not Supported). 207 5. Refreshing an Allocation 209 The behavior specified here affects the processing defined in Section 210 7 of [I-D.ietf-behave-turn]. 212 5.1. Sending a Refresh Request 214 To perform a binding refresh, the client generates a Refresh Request 215 as described in Section 7.1 of [I-D.ietf-behave-turn]. The client 216 MUST NOT include any REQUESTED-ADDRESS-TYPE attribute in its Refresh 217 Request. 219 5.2. Receiving a Refresh Request 221 If a server receives a Refresh Request with a REQUESTED-ADDRESS-TYPE 222 attribute, it MUST ignore the attribute and process the request as if 223 the attribute was not there. 225 6. Packet Translations 227 The TURN specification [I-D.ietf-behave-turn] describes how TURN 228 relays should relay traffic consisting of IPv4 packets (i.e., IPv4- 229 to-IPv4 translations). The relay translates the IP addresses and 230 port numbers of the packets based on the allocation's state data. 231 How to translate other header fields is also specified in 232 [I-D.ietf-behave-turn]. This document addresses IPv4-to-IPv6, IPv6- 233 to-IPv4, and IPv6-to-IPv6 translations. 235 TURN relays performing any translation MUST translate the IP 236 addresses and port numbers of the packets based on the allocation's 237 state information as specified in [I-D.ietf-behave-turn]. TURN 238 relays performing an IPv4-to-IPv6 or an IPv6-to-IPv4 translations 239 SHOULD translate other header fields following SIIT (Stateless IP/ 240 ICMP Translation Algorithm) as described in Sections 3 and 4 of 241 [RFC2765] respectively. Additionally, when the outgoing packet's 242 size exceeds the outgoing link's MTU, the relay needs to generate an 243 ICMP error (ICMPv6 Packet Too Big or ICMPv4 Destination Unreachable) 244 reporting the MTU size. If the packet is being sent to the peer, the 245 relay SHOULD reduce the MTU reported in the ICMP message by 48 bytes 246 to allow room for the overhead of a Data indication. 248 Note that the use of SIIT is at the "should" level. Having the 249 use of SIIT at the "should" level instead of at the "must" level 250 makes it possible to use different translation algorithms that may 251 be developed in the future. 253 A TURN relay performing an IPv6-to-IPv6 translation translates other 254 header fields per the following rules: 256 Flow Label: the relay should consider that it is handling two 257 different IPv6 flows. Therefore, the Flow label [RFC3697] SHOULD 258 NOT be copied as part of the translation. The relay SHOULD set 259 the Flow label to 0. The relay MAY choose to set the Flow label 260 to a different value if it supports [RFC3697]. 262 Hop Limit: the relay MUST act as a regular router with respect to 263 decrementing the Hop Limit and generating an ICMPv6 error if it 264 reaches zero. 266 Fragmentation: If the incoming packet did not include a Fragment 267 header and the outgoing packet size does not exceed the outgoing 268 link's MTU, the relay MUST send the outgoing packet without a 269 Fragment header. 271 If the incoming packet did not include a Fragment header and the 272 outgoing packet size exceeds the outgoing link's MTU, the delay 273 MUST drop the outgoing packet and send an ICMP message of type 2 274 code 0 ("Packet too big") to the sender of the incoming packet. 275 If the packet is being sent to the peer, the relay MUST reduce the 276 MTU reported in the ICMP message by 48 bytes to allow room for the 277 overhead of a Data indication. 279 If the incoming packet included a Fragment header and the outgoing 280 packet size (with a Fragment header included) does not exceed the 281 outgoing link's MTU, the relay MUST send the outgoing packet with 282 a Fragment header. The relay MUST set the fields of the Fragment 283 header as appropriate for a packet originating from the server. 285 If the incoming packet included a Fragment header and the outgoing 286 packet size exceeds the outgoing link's MTU, the relay MUST 287 fragment the outgoing packet into fragments of no more than 1280 288 bytes. The relay MUST set the fields of the Fragment header as 289 appropriate for a packet originating from the server. 291 Extension Headers: the relay SHOULD send outgoing packet without any 292 IPv6 extension headers, with the exception of the Fragmentation 293 header as described above. 295 7. Security Considerations 297 The attribute and error response code defined in this document do not 298 have any special security considerations beyond those for other 299 attributes and Error response codes. All the security considerations 300 applicable to STUN [I-D.ietf-behave-rfc3489bis] and TURN are 301 applicable to this document as well. 303 8. IANA Considerations 305 The IANA is requested to register the following values under the STUN 306 Attributes registry and under the STUN Response Code Registry. 308 8.1. New STUN Attribute Registry 310 0x0017: REQUESTED-ADDRESS-TYPE 312 8.2. New STUN Response Code Registry 314 440 Address Family not Supported 316 9. Acknowledgements 318 The authors would like to thank Alfred E. Heggestad, Remi Denis- 319 Courmont, and Philip Matthews for their feedback on this document. 321 10. Normative References 323 [I-D.ietf-behave-rfc3489bis] 324 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 325 "Session Traversal Utilities for (NAT) (STUN)", 326 draft-ietf-behave-rfc3489bis-18 (work in progress), 327 July 2008. 329 [I-D.ietf-behave-turn] 330 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 331 Relays around NAT (TURN): Relay Extensions to Session 332 Traversal Utilities for NAT (STUN)", 333 draft-ietf-behave-turn-09 (work in progress), July 2008. 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, March 1997. 338 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 339 (SIIT)", RFC 2765, February 2000. 341 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 342 "IPv6 Flow Label Specification", RFC 3697, March 2004. 344 Authors' Addresses 346 Gonzalo Camarillo 347 Ericsson 348 Hirsalantie 11 349 Jorvas 02420 350 Finland 352 Email: Gonzalo.Camarillo@ericsson.com 354 Oscar Novo 355 Ericsson 356 Hirsalantie 11 357 Jorvas 02420 358 Finland 360 Email: Oscar.Novo@ericsson.com 362 Full Copyright Statement 364 Copyright (C) The IETF Trust (2008). 366 This document is subject to the rights, licenses and restrictions 367 contained in BCP 78, and except as set forth therein, the authors 368 retain all their rights. 370 This document and the information contained herein are provided on an 371 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 372 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 373 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 374 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 375 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 376 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 378 Intellectual Property 380 The IETF takes no position regarding the validity or scope of any 381 Intellectual Property Rights or other rights that might be claimed to 382 pertain to the implementation or use of the technology described in 383 this document or the extent to which any license under such rights 384 might or might not be available; nor does it represent that it has 385 made any independent effort to identify any such rights. Information 386 on the procedures with respect to rights in RFC documents can be 387 found in BCP 78 and BCP 79. 389 Copies of IPR disclosures made to the IETF Secretariat and any 390 assurances of licenses to be made available, or the result of an 391 attempt made to obtain a general license or permission for the use of 392 such proprietary rights by implementers or users of this 393 specification can be obtained from the IETF on-line IPR repository at 394 http://www.ietf.org/ipr. 396 The IETF invites any interested party to bring to its attention any 397 copyrights, patents or patent applications, or other proprietary 398 rights that may cover technology that may be required to implement 399 this standard. Please address the information to the IETF at 400 ietf-ipr@ietf.org.