idnits 2.17.1 draft-ietf-behave-turn-ipv6-03.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 304. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 328. 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 440 (Address Family not Supported): The server did not support the address family requested by the client. The client SHOULD not retry. -- 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 6, 2007) is 6136 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 (-18) exists of draft-ietf-behave-rfc3489bis-06 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-03 Summary: 1 error (**), 0 flaws (~~), 4 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: January 7, 2008 July 6, 2007 7 Extension to the Simple Traversal Underneath NAT (STUN) Relay Usage for 8 IPv4/IPv6 Transition 9 draft-ietf-behave-turn-ipv6-03.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 January 7, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document defines the REQUESTED-ADDRESS-TYPE attribute for the 43 Simple Traversal Underneath NAT (STUN) Relay Usage, which allows a 44 client to explicitly request the address type the STUN relay server 45 will allocate (e.g., an IPv4-only node may request the STUN relay 46 server to allocate an IPv6 address). Additionally, this document 47 also defines a new error response code with the value 440 (Address 48 Family not Supported). 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . . 3 55 4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. Allocating a Binding . . . . . . . . . . . . . . . . . . . 4 57 4.2. Refreshing a Binding . . . . . . . . . . . . . . . . . . . 5 58 5. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Allocate Request . . . . . . . . . . . . . . . . . . . . . 5 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 7.1. New STUN Attribute Registry . . . . . . . . . . . . . . . . 6 63 7.2. New STUN Response Code Registry . . . . . . . . . . . . . . 7 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 65 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Intellectual Property and Copyright Statements . . . . . . . . . . 8 69 1. Introduction 71 The relay usage of Simple Traversal Underneath NAT (STUN) 72 [I-D.ietf-behave-turn] is a protocol that allows for an element 73 behind a NAT or firewall to receive incoming data over TCP or UDP 74 connections. It is most useful for elements behind symmetric NATs or 75 firewalls that wish to be on the receiving end of a connection to a 76 single peer. 78 This document defines the REQUESTED-ADDRESS-TYPE attribute, which is 79 an extension to the STUN relay usage that allows a client to 80 explicitly request the address type the STUN relay server will 81 allocate (e.g., an IPv4-only node may request the STUN relay server 82 to allocate an IPv6 address). 84 This document also defines and registers a new error response code 85 with the value 440 (Address Family not Supported). 87 2. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 3. Overview of Operation 95 When a user wishes a STUN relay server to allocate an address of a 96 specific type, it sends an Allocate Request to the STUN relay server 97 with a REQUESTED-ADDRESS-TYPE attribute. STUN relay can run over UDP 98 and TCP, as it allows for a client to request address/port pairs for 99 receiving both UDP and TCP. 101 Assuming the request is authenticated and has not been tampered with, 102 the STUN relay server allocates a transport address of the type 103 indicated in the REQUESTED-ADDRESS-TYPE attribute. This address is 104 called the allocated transport address. 106 The STUN relay server returns the allocated address in the response 107 to the Allocate Request. This response contains a RELAY-ADDRESS 108 attribute indicating the mapped IP address and port that the server 109 assigned to the client. 111 For simplicity reasons, STUN relay servers are designed to allocate a 112 single address per allocation request. Therefore, Allocate Requests 113 cannot carry more than one REQUESTED-ADDRESS-TYPE attribute. 114 Consequently, a client that wishes to allocate more than one address 115 at a STUN relay server (e.g., an IPv4 and an IPv6 address) needs to 116 perform several allocation requests (one allocation request per 117 address). 119 4. Client Behavior 121 Client behavior for Allocate requests depends on whether the request 122 is an initial one, for the purposes of obtaining a new relayed 123 transport address, or a subsequent one, used for refreshing an 124 existing allocation. 126 The client behavior specified here affects the transport processing 127 defined in Section 9.1 of the STUN relay usage 128 [I-D.ietf-behave-turn]. 130 4.1. Allocating a Binding 132 A client that wishes to obtain a transport address of a specific 133 address type includes a REQUESTED-ADDRESS-TYPE attribute in the 134 Allocate Request that sends to the STUN relay server. Clients MUST 135 NOT include more than one REQUESTED-ADDRESS-TYPE attribute in an 136 Allocate Request. The mechanisms to formulate an Allocate Request 137 are described in Section 9.1.2 of [I-D.ietf-behave-turn]. 139 The REQUESTED-ADDRESS-TYPE attribute is used by clients to request 140 the allocation of a specific address type from a server. The 141 following is the format of the REQUESTED-ADDRESS-TYPE attribute. 142 Note that attributes in STUN relay are TLV (Type-Length-Value) 143 encoded, with a 16 bit type, a 16 bit length, and a variable-length 144 value. 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Type | Length | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Family | Reserved | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Type: the type of the REQUESTED-ADDRESS-TYPE attribute is 0x0017. As 155 specified in [I-D.ietf-behave-rfc3489bis], Attributes with values 156 less than or equal to 0x7fff are mandatory to understand, which means 157 that the client or server cannot successfully process the message 158 unless it understands the attribute. 160 Length: this 16-bit field contains the length of the attribute in 161 bytes. The length of this attribute is 4 bytes. 163 Family: there are two values defined for this field and specified in 164 [I-D.ietf-behave-rfc3489bis]: 0x01 for IPv4 addresses and 0x02 for 165 IPv6 addresses. 167 Reserved: at this point, the 24 bits in the reserved field SHOULD be 168 set to zero by the client and MUST be ignored by the server. 170 The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate 171 Requests. 173 4.2. Refreshing a Binding 175 To perform a binding refresh, the client generates an Allocate 176 Request as described in the previous section. The client includes 177 the same REQUESTED-ADDRESS-TYPE attribute as it included in its 178 initial Allocate Request. 180 If the Allocate Response contains the same transport address as 181 previously obtained, the binding has been refreshed. If, however, 182 the response was an Allocate Error Response with an ERROR-CODE 183 indicating a 430 response, it means that the binding has expired at 184 the server. Other response codes do not imply that the binding has 185 expired, just that the refresh has failed. 187 5. Server Behavior 189 The server behavior specified here affects the transport processing 190 defined in Section 9.1.1 of STUN relay [I-D.ietf-behave-turn]. 192 5.1. Allocate Request 194 Assuming the request is authenticated and has not been tampered with, 195 the STUN relay server processes the request. Following the rules in 196 [I-D.ietf-behave-rfc3489bis], if the server does not understand the 197 REQUESTED-ADDRESS-TYPE attribute, it generates an Allocate Error 198 Response, which includes an ERROR-CODE attribute with response code 199 420 (Unknown Attribute). This response will contain an UNKNOWN- 200 ATTRIBUTE attribute listing the unknown REQUESTED-ADDRESS-TYPE 201 attribute. 203 This document defines the following new error response code: 205 440 (Address Family not Supported): The server did not support the 206 address family requested by the client. The client SHOULD not 207 retry. 209 If the server does not support the address family requested by the 210 client, it MUST generate an Allocate Error Response, and it MUST 211 include an ERROR-CODE attribute with the response code defined in 212 this draft, 440 (Address Family not Supported). 214 If the server can successfully process the request, it allocates a 215 transport address to the STUN relay client, called the allocated 216 transport address, and returns it in the response to the Allocate 217 Request. 219 As specified in [I-D.ietf-behave-turn], the Allocate Response 220 contains the same transaction ID contained in the Allocate Request 221 and the RELAY-ADDRESS attribute that sets it to the allocated 222 transport address. 224 The RELAY-ADDRESS attribute indicates the mapped IP address and port. 225 It is encoded in the same way as the MAPPED-ADDRESS 226 [I-D.ietf-behave-rfc3489bis]. 228 If the REQUESTED-ADDRESS-TYPE attribute is absent, the server MUST 229 allocate a IPv4 transport address to the STUN relay client. 231 6. Security Considerations 233 The attribute and error response code defined in this document do not 234 have any special security considerations beyond those for other 235 attributes and Error response codes. All the security considerations 236 applicable to STUN [I-D.ietf-behave-rfc3489bis] and to its relay 237 usage are applicable to this document as well. 239 7. IANA Considerations 241 The IANA is requested to register the following values under the STUN 242 Attributes registry and under the STUN Response Code Registry. 244 7.1. New STUN Attribute Registry 246 0x0017: REQUESTED-ADDRESS-TYPE 248 7.2. New STUN Response Code Registry 250 440 Address Family not Supported 252 8. Acknowledgements 254 The authors would like to thank Alfred E. Heggestad and Remi Denis- 255 Courmont for their feedback on this document. 257 9. Normative References 259 [I-D.ietf-behave-rfc3489bis] 260 Rosenberg, J., "Session Traversal Utilities for (NAT) 261 (STUN)", draft-ietf-behave-rfc3489bis-06 (work in 262 progress), March 2007. 264 [I-D.ietf-behave-turn] 265 Rosenberg, J., "Obtaining Relay Addresses from Simple 266 Traversal Underneath NAT (STUN)", 267 draft-ietf-behave-turn-03 (work in progress), March 2007. 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, March 1997. 272 Authors' Addresses 274 Gonzalo Camarillo 275 Ericsson 276 Hirsalantie 11 277 Jorvas 02420 278 Finland 280 Email: Gonzalo.Camarillo@ericsson.com 282 Oscar Novo 283 Ericsson 284 Hirsalantie 11 285 Jorvas 02420 286 Finland 288 Email: Oscar.Novo@ericsson.com 290 Full Copyright Statement 292 Copyright (C) The IETF Trust (2007). 294 This document is subject to the rights, licenses and restrictions 295 contained in BCP 78, and except as set forth therein, the authors 296 retain all their rights. 298 This document and the information contained herein are provided on an 299 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 300 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 301 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 302 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 303 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 304 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 306 Intellectual Property 308 The IETF takes no position regarding the validity or scope of any 309 Intellectual Property Rights or other rights that might be claimed to 310 pertain to the implementation or use of the technology described in 311 this document or the extent to which any license under such rights 312 might or might not be available; nor does it represent that it has 313 made any independent effort to identify any such rights. Information 314 on the procedures with respect to rights in RFC documents can be 315 found in BCP 78 and BCP 79. 317 Copies of IPR disclosures made to the IETF Secretariat and any 318 assurances of licenses to be made available, or the result of an 319 attempt made to obtain a general license or permission for the use of 320 such proprietary rights by implementers or users of this 321 specification can be obtained from the IETF on-line IPR repository at 322 http://www.ietf.org/ipr. 324 The IETF invites any interested party to bring to its attention any 325 copyrights, patents or patent applications, or other proprietary 326 rights that may cover technology that may be required to implement 327 this standard. Please address the information to the IETF at 328 ietf-ipr@ietf.org. 330 Acknowledgment 332 Funding for the RFC Editor function is provided by the IETF 333 Administrative Support Activity (IASA).