idnits 2.17.1 draft-camarillo-midcom-turn-ipv6-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 307. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 284. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 297. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 12, 2005) is 6771 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-02 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIDCOM G. Camarillo 3 Internet-Draft O. Novo 4 Expires: April 15, 2006 Ericsson 5 October 12, 2005 7 Traversal Using Relay NAT (TURN) Extension for IPv4/IPv6 transition 8 draft-camarillo-midcom-turn-ipv6-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of 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 15, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document defines the Traversal Using Relay NAT (TURN) REQUESTED- 42 ADDRESS-TYPE attribute, which allows a client to explicitly request 43 the address type the TURN server will allocate (e.g., an IPv4-only 44 node may request the TURN server to allocate an IPv6 address). This 45 document also registers the IPv6 address type. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . . 3 52 4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4.1. Allocating a Binding . . . . . . . . . . . . . . . . . . . 4 54 4.2. Refreshing a Binding . . . . . . . . . . . . . . . . . . . 5 55 5. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5.1. Allocate Request . . . . . . . . . . . . . . . . . . . . . 5 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 61 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 63 Intellectual Property and Copyright Statements . . . . . . . . . . 9 65 1. Introduction 67 Traversal Using Relay NAT (TURN) is a protocol that allows for an 68 element behind a NAT or firewall to receive incoming data over TCP or 69 UDP connections. It is most useful for elements behind symmetric 70 NATs or firewalls that wish to be on the receiving end of a 71 connection to a single peer. 73 This document defines the REQUESTED-ADDRESS-TYPE attribute, which is 74 an extension to TURN that allows a client to explicitly request the 75 address type the TURN server will allocate (e.g., an IPv4-only node 76 may request the TURN server to allocate an IPv6 address). 78 This document also registers the IPv6 address type, which is 79 initially intended to be used in MAPPED-ADDRESS and in REQUESTED- 80 ADDRESS-TYPE attributes. 82 2. Terminology 84 In this document, the key words MUST, MUST NOT, REQUIRED, SHALL, HALL 85 NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are o be 86 interpreted as described in RFC RFC-2119 [1] and indicate requirement 87 levels for compliant TURN implementations. 89 3. Overview of Operation 91 When a user wishes a TURN server to allocate an address of a specific 92 type, it sends an Allocate Request to the TURN server with a 93 REQUESTED-ADDRESS-TYPE attribute. TURN can run over UDP and TCP, as 94 it allows for a client to request address/port pairs for receiving 95 both UDP and TCP. 97 Assuming the request is authenticated and has not been tampered with, 98 the TURN server allocates a transport address of the type indicated 99 in the REQUESTED-ADDRESS-TYPE attribute. This address is called the 100 allocated transport address. 102 The TURN server returns the allocated address in the response to the 103 Allocate Request. This response contains a MAPPED-ADDRESS attribute 104 indicating the mapped IP address and port that the server assigned to 105 the client. 107 4. Client Behavior 109 The client behavior specified here affects the transport processing 110 defined in Section 8 of TURN [2]. 112 4.1. Allocating a Binding 114 A client that wishes to obtain a transport address of a specific 115 address type includes the REQUESTED-ADDRESS-TYPE attribute in the 116 Allocate Request that sends to the TURN server. The mechanisms to 117 formulate an Allocate Request are described in Section 8.3 of [2]. 119 The REQUESTED-ADDRESS-TYPE attribute is used by clients to request 120 the allocation of a specific address type from a server. The 121 following is the format of the REQUESTED-ADDRESS-TYPE attribute. 122 Note that attributes in TURN are TLV (Type-Length-Value) encoded, 123 with a 16 bit type, a 16 bit length, and a variable-length value. 125 0 1 2 3 126 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 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Type | Length | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Family | Reserved | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 Type: the type of the REQUESTED-ADDRESS-TYPE mandatory-to-understand 134 attribute is 0x0016. As it is explained in [3], a server cannot 135 process a message with a mandatory-to-understand attributes unless it 136 understands the mandatory attribute. 138 Length: this 16-bit field contains the length of the attribute in 139 bytes. The length of this attribute is 4 bytes. 141 Family: there are two values defined for this field: 0x01 for IPv4 142 addresses and 0x02 for IPv6 addresses. 144 Reserved: at this point, the 16 bits in the reserved field SHOULD be 145 set to zero by the client and MUST be ignored by the server. 147 Table 1 indicates in which TURN messages can be present the REQUEST- 148 ADDRESS-TYPE attribute. An O indicates that inclusion of the 149 attribute in the message is optional and N/A means that the attribute 150 is not applicable to that message type. 152 Binding Shared Shared Shared 153 Binding Binding Error Secret Secret Secret 154 Att. Req. Resp. Resp. Req. Resp. Error 155 Resp. 156 __________________________________________________________________ 158 REQUESTED-ADDRESS-TYPE O N/A N/A N/A N/A N/A 160 Table 1: Summary of the REQUESTED-ADDRESS-TYPE Attribute 162 4.2. Refreshing a Binding 164 To perform a binding refresh, the client generates an Allocate 165 Request as described in the previous section. The client includes 166 the same REQUESTED-ADDRESS-TYPE attribute as it included in its 167 initial Allocate Request. 169 If the Allocate Response contains the same transport address as 170 previously obtained, the binding has been refreshed. If, however, 171 the response was an Allocate Error Response with an ERROR-CODE 172 indicating a 430 response, it means that the binding has expired at 173 the server. Other response codes do not imply that the binding has 174 been expired, just that the refresh has failed. 176 5. Server Behavior 178 The server behavior specified here affects the transport processing 179 defined in Section 7.2 of TURN [2]. 181 5.1. Allocate Request 183 Assuming the request is authenticated and has not been tampered with, 184 the TURN server processes the request. If the server does not 185 understand the REQUESTED-ADDRESS-TYPE attribute, it MUST generate an 186 Allocate Error Response, and it MUST include an ERROR-CODE attribute 187 with response code 420 (Unknown Attribute). This response MUST 188 contain an UNKNOWN-ATTRIBUTE attribute listing the unknown REQUESTED- 189 ADDRESS-TYPE attribute. 191 If the server can successfully process the request, it allocates a 192 transport address to the TURN client, called the allocated transport 193 address, and returns it in the response to the Allocate Request. 195 As is explained in [2], the Allocate Response contains the same 196 transaction ID contained in the Allocate Request. The server adds a 197 MAPPED-ADDRESS attribute to the Allocate Response and sets it to the 198 allocated transport address. 200 The MAPPED-ADDRESS attribute indicates the mapped IP address and 201 port. It consists of an eight bit address family, and a sixteen bit 202 port, followed by a fixed length value representing the IP address. 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 |x x x x x x x x| Family | Port | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Address | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 STUN [3] defines the 0x01 family type address value for the MAPPED- 213 ADDRESS attribute. The first 8 bits of the MAPPED-ADDRESS are 214 ignored, for the purposes of aligning parameters on natural 215 boundaries. The value of the Address field is 4 bytes (32 bits) long 216 for the IPv4 family type address. 218 This document defines the IPv6 family type address with the value 219 0x02. The value of the Address field is 32 bytes (128 bits) long for 220 the IPv6 address. The fact that the length of this type of address 221 is 32 bytes guarantees the alignment of the attribute on word 222 boundaries. 224 6. IANA Considerations 226 This document defines the REQUESTED-ADDRESS-TYPE attribute, which the 227 IANA has added to the TURN attribute registry defined in TURN [2]. 229 Editor's note: the TURN spec does not create this registry yet. It 230 needs to create it. 232 This document also defines the address family tag "0x002" which IANA 233 has added to the registry defined in STUN [3]. 235 Editor's note: the specs of STUN and TURN do not create any registry 236 for this yet. 238 7. Acknowledgements 240 8. References 242 8.1. Normative References 244 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 245 Levels", BCP 14, RFC 2119, March 1997. 247 8.2. Informative References 249 [2] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 250 draft-rosenberg-midcom-turn-08 (work in progress), 251 September 2005. 253 [3] Rosenberg, J., "Simple Traversal of UDP Through Network Address 254 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-02 (work 255 in progress), July 2005. 257 Authors' Addresses 259 Gonzalo Camarillo 260 Ericsson 261 Hirsalantie 11 262 Jorvas 02420 263 Finland 265 Email: Gonzalo.Camarillo@ericsson.com 267 Oscar Novo 268 Ericsson 269 Hirsalantie 11 270 Jorvas 02420 271 Finland 273 Email: Oscar.Novo@ericsson.com 275 Intellectual Property Statement 277 The IETF takes no position regarding the validity or scope of any 278 Intellectual Property Rights or other rights that might be claimed to 279 pertain to the implementation or use of the technology described in 280 this document or the extent to which any license under such rights 281 might or might not be available; nor does it represent that it has 282 made any independent effort to identify any such rights. Information 283 on the procedures with respect to rights in RFC documents can be 284 found in BCP 78 and BCP 79. 286 Copies of IPR disclosures made to the IETF Secretariat and any 287 assurances of licenses to be made available, or the result of an 288 attempt made to obtain a general license or permission for the use of 289 such proprietary rights by implementers or users of this 290 specification can be obtained from the IETF on-line IPR repository at 291 http://www.ietf.org/ipr. 293 The IETF invites any interested party to bring to its attention any 294 copyrights, patents or patent applications, or other proprietary 295 rights that may cover technology that may be required to implement 296 this standard. Please address the information to the IETF at 297 ietf-ipr@ietf.org. 299 Disclaimer of Validity 301 This document and the information contained herein are provided on an 302 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 303 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 304 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 305 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 306 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 307 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 309 Copyright Statement 311 Copyright (C) The Internet Society (2005). This document is subject 312 to the rights, licenses and restrictions contained in BCP 78, and 313 except as set forth therein, the authors retain all their rights. 315 Acknowledgment 317 Funding for the RFC Editor function is currently provided by the 318 Internet Society.