idnits 2.17.1 draft-rosenberg-mmusic-ice-nonsip-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 674. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (February 15, 2008) is 5914 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-14 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-06 ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-04) exists of draft-bryan-p2psip-reload-02 == Outdated reference: A later version (-02) exists of draft-tschofenig-mip6-ice-01 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Rosenberg 3 Internet-Draft Cisco 4 Intended status: Standards Track February 15, 2008 5 Expires: August 18, 2008 7 NICE: Non Session Initiation Protocol (SIP) usage of Interactive 8 Connectivity Establishment (ICE) 9 draft-rosenberg-mmusic-ice-nonsip-00 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 August 18, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 Interative Connectivity Establishment (ICE) has been specified as a 43 NAT traversal mechanism for protocols based on the offer/answer 44 exchange model. In practice, only the Session Initiation Protocol 45 (SIP) has been based on the offer/answer model. This document 46 defines a SIP independent subset of ICE, called NICE, which can be 47 used with any protocol wishing to establish a direct host-to-host 48 relationship through NAT. Protocol specifications need only 49 reference this document, and include the object defined here in their 50 messages, in order to achieve NAT traversal. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Can My Protocol Use NICE? . . . . . . . . . . . . . . . . . . 3 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 58 5. Differences between ICE and NICE . . . . . . . . . . . . . . . 6 59 6. Gathering Candidates . . . . . . . . . . . . . . . . . . . . . 8 60 7. Sending an Initiate Message . . . . . . . . . . . . . . . . . 8 61 8. Receiving an Initiate Message . . . . . . . . . . . . . . . . 9 62 9. Receiving an Accept Message . . . . . . . . . . . . . . . . . 9 63 10. Connectivity Checks . . . . . . . . . . . . . . . . . . . . . 10 64 11. Concluding ICE . . . . . . . . . . . . . . . . . . . . . . . . 10 65 12. Subsequent Messaging . . . . . . . . . . . . . . . . . . . . . 10 66 13. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 14. Sending and Receiving Data . . . . . . . . . . . . . . . . . . 10 68 15. The NICE Object . . . . . . . . . . . . . . . . . . . . . . . 11 69 16. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 18. Tongue Twister . . . . . . . . . . . . . . . . . . . . . . . . 13 72 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 19.1. Normative References . . . . . . . . . . . . . . . . . . 13 74 19.2. Informative References . . . . . . . . . . . . . . . . . 14 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 Intellectual Property and Copyright Statements . . . . . . . . . . 16 78 1. Introduction 80 Interactive Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice] 81 has been specified by the IETF as a mechanism for NAT traversal for 82 protocols based on the offer/answer model [RFC3264], which exchanges 83 Session Description Protocol (SDP) [RFC4566] objects to negotiate 84 media sessions. 86 ICE has many benefits. It is automated, relying on very little 87 configuration. It works through an extremely broad range of network 88 and NAT topologies. It is robust, establishing connections in many 89 challenging environments. It is efficient, utilizing relays and 90 intermediaries only when other options will not work. At the time of 91 writing, ICE has seen widespread usage on the Internet for traversal 92 of Voice over IP, primarily based on the Session Initiation Protocol 93 (SIP) [RFC3261] 95 However, SIP is not the only protocol that requires the establishment 96 of host-to-host relationships for communications. Consequently, ICE 97 has recently been considered as the NAT traversal technique for other 98 protocols. These include Peer-to-Peer SIP (P2PSIP) 99 [I-D.bryan-p2psip-reload], Host Identity Protocol (HIP) 100 [I-D.manyfolks-hip-sturn] and Mobile IP v6 [I-D.tschofenig-mip6-ice]. 101 In each case, the protocol in question provides a mechanism for two 102 hosts to rendezvous through some intermediary, and then needs a host- 103 to-host connection established. This fits the NAT traversal 104 capability provided by ICE. 106 Unfortunately, the ICE specification itself is intertwined with SDP 107 and the offer/answer model, and is not immediately usable by 108 protocols that do not utilize offer/answer. For this reason, each of 109 these protocols has needed to define its own usage of ICE. This 110 results in duplicate work and inconsistent solutions for NAT 111 traversal. 113 To remedy this, this document defines a generic NAT traversal 114 solution based on ICE, called NICE. It does so by referencing the 115 specific parts of the ICE specification that are needed. It also 116 defines a simply object that can be exchanged in other protocols. 117 Consequently, protocols that fit the design pattern for NICE need 118 only reference this document, and provide a way to include the 119 defined object in their messages. With that, they have a solution 120 for NAT traversal. 122 2. Can My Protocol Use NICE? 124 Not all protocols can make use of NICE. NICE works only with 125 protocols that fit the pattern of a session protocol. A session 126 protocol is one in which there exists some kind of rendezvous 127 service, typically through a server on the Internet, by which hosts 128 can contact each other. Through the rendezvous service, hosts can 129 exchange information for the purposes of negotiating a direct host to 130 host connection. Each host is assumed to have an identifier by which 131 it is known to the rendezvous service, and by which other hosts can 132 identify it. There is typically some kind of registration operation, 133 by which a host connects to the rendezvous service and identifies 134 itself. This protocol design pattern is shown in Figure 1. 136 +--------------+ 137 | | 138 | | 139 > | Rendezvous | \ 140 / | Service | \ 141 / | | \ 142 / | | \ 143 / | | \ 144 / +--------------+ \ 145 / \ 146 / Connect \ 147 / To Y \ 148 / \ 150 +--------+ +--------+ 151 | | | | 152 | | | | 153 | Host | ......................... | Host | 154 | ID:X | | ID:Y | 155 | | | | 156 +--------+ +--------+ 158 Figure 1: Session Protocols 160 If hosts can reach each other through the rendezvous service, why 161 create direct connections? Typically, the rendezvous service 162 provides an indirect connection, and may be very suboptimal in terms 163 of latency and other path metrics. The rendezvous service may also 164 have limited bandwidth, and not be capable of supporting the volume 165 of data required to flow between the hosts. 167 As an example, in SIP, the rendezvous service is the SIP server. The 168 identifier is the SIP URI. The registration process is supported 169 using the REGISTER method. Connections are established using the 170 INVITE method. 172 For a protocol to use NICE, it must exhibit the properties of a 173 session protocol as described above. Furthermore, it must provide a 174 mechanism for exchanging MIME objects between the hosts for purposes 175 of establishing the connection. It must provide for, at least, one 176 message from the initiator to the other host, and one message back. 177 If all of these criteria are met, NICE can be used. 179 3. Terminology 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in RFC 2119 [RFC2119]. 185 In addition, this document introduces the following terms: 187 Session Initiator: A software or hardware entity on a host that 188 wishes to establish establish communications with another host, 189 called the session responder. A session initiator is also called 190 an initiator. 192 Initiator: Another term for a session initiator. 194 Session Responder: A software or hardware entity on a host that 195 receives a request for establishment of communications from the 196 session initiator, and either accepts or declines the request. A 197 session responder is also called a responder. 199 Responder: Another term for a session responder. 201 Client: Either the initiator or responder. 203 Peer: From the perspective of one of the clients in a session, its 204 peer is the other client. Specifically, from the perspective of 205 the initiator, the peer is the responder. From the perspective of 206 the responder, the peer is the initiator. 208 Rendezvous Service: A protocol service provided to the clients that 209 allows them to identify each other using a well known identifier, 210 and then send messages back and forth. 212 Initiate Message: The message in the rendezvous protocol used by an 213 initiator to establish communications. It contains the ICE 214 parameters needed to establish communications. 216 Accept Message: The message in the rendezvous protocol used by a 217 responder to establish communications. It contains the ICE 218 parameters needed to establish communications. 220 4. Overview of Operation 222 To utilize NICE, one host, the INITIATOR, sends a message using the 223 rendezvous protocol. This message is addressed towards another host, 224 the RESPONDER. This message is called the Initiate message. That 225 message contains a MIME object, specified in Section 15, which 226 includes the information needed by NICE. In particular, it contains 227 a set of candidates for the purposes of establishing a single 228 "stream". This stream is a host-to-host UDP association or TCP 229 connection. The rendezvous service delivers the Initiate message to 230 the RESPONDER. It sends a message back to the initiator, called the 231 Accept message. This message also carries the same object, 232 containing information from the Responder for the purposes of 233 establishing the stream. 235 NICE uses server reflexive and relayed candidates learned from 236 Session Traversal Utilities for NAT (STUN) STUN 237 [I-D.ietf-behave-rfc3489bis] and Traversal Using Relay through NAT 238 (TURN) [I-D.ietf-behave-turn] servers. These functions can be 239 provided by the rendezvous service, or by traditional STUN and TURN 240 servers in the network. The candidates learned from these servers 241 are what is included in the objects exchanged through the rendezvous 242 protocol. 244 Once exchanged, the clients perform connectivity checks. These 245 checks probe for connectivity between the pairs of candidates 246 signaled through the rendezvous protocol. Once a match is found, the 247 Initiator sends an updated connectivity check, indicating that a pair 248 has been selected. At that point, packets can flow between initiator 249 and responder. 251 5. Differences between ICE and NICE 253 NICE differs from ICE in two fundamental ways. Firstly, it is 254 abstracted from SDP and RTP specifics. Secondly, it is subsetted. 255 This subsetting operation removes many of the features in ICE that 256 are there for reasons having to do with the nuances of SIP, or the 257 need for real-time operation. In particular, the following ICE 258 features are not used in NICE: 260 o ICE has the notion of a default candidate. This default candidate 261 is used for backwards compatibility with pre-ICE SIP 262 implementations. That mechanism is very specific to SDP backwards 263 compatibility techniques, and is not used here. Instead, if the 264 protocol using NICE requires backwards compatibility, it needs to 265 define its own mechanisms for such. 267 o ICE supports the notion of updated offers and answers that can 268 modify information. Indeed, it requires such an update when the 269 pair selected by ICE does not match the default. The notion of 270 default has been removed in NICE, as has the ability to update the 271 ICE information. This update allowed for mid-call changes in 272 connectivity, a frequent occurrence in events like call transfer. 273 If a protocol using NICE requires a connection to a different 274 host, it has to start a totally new and unrelated ICE session. 275 This can result in discontinuous connectivity while the checks re- 276 run. Continuous operation is needed for real-time usage, but not 277 more generally. 279 o Simllarly, ICE restarts are not supported in NICE. Restarts are 280 an artifact of sending updated offers and answers. 282 o ICE provides some guidance for handling SIP forking. This is a 283 case where a single offer elicits multiple answers. Forking is 284 specific to SIP, and so this capability is removed from NICE. 285 NICE allows connectivity to be set up only between a pair of 286 hosts. 288 o ICE defines a lite mode of operation for supporting ease of 289 implementation. Since NICE is already simpler by the removal of 290 several large ICE features (most notably updated offers and 291 answers), this simplified mode seems unneeded. It seems better to 292 simplify NICE overall rather than define complexity in the normal 293 mode in order to introduce a simplified lite mode. 295 o ICE supports the notion of multiple streams and multiple 296 components per stream. This was done specifically to address the 297 needs of multimedia. NICE provides the ability to establish a 298 single connection between a pair of hosts. Consequently, that 299 capability is not present in NICE. 301 o ICE defines an algorithm called the Frozen algorithm. This 302 algorithm exists to speed up completion of ICE in cases where 303 multiple candidates share similar properties. For example, when 304 an audio and video candidate are on the same host IP address. 305 Since NICE only supports a single candidate and a single 306 component, the use cases for the Frozen algorithm diminish 307 significantly. Furthermore, the Frozen algorithm is entirely 308 about speed and is not as much an issue for more general non-real 309 tiem protocols . Thus, this algorithm is not used by NICE. It 310 falls out by using the algorithm defined in ICE, but by setting 311 each foundation to a unique value. 313 o ICE defines SDP attributes for "remote-candidates". These are 314 used to resolve a race condition between a subsequent offer/answer 315 and the ICE checks. Since NICE does not use any subsequent 316 rendezvous signaling, this attribute and its procedures are not 317 used in NICE. 319 o ICE defines an SDP attribute called "ice-mismatch". This detects 320 an ICE failure case due to the presence of signaling 321 intermediaries that don't support ICE. This problem is specific 322 to SIP and thus this attribute and associated procedures are not 323 used in NICE. 325 6. Gathering Candidates 327 When a client wishes to establish a connection, it follows the 328 process of gathering candidates as described in Section 4.1 of ICE 329 [I-D.ietf-mmusic-ice]. However, the client MUST follow those rules 330 under the assumption of a single media stream and a single component 331 for that stream. This simplification means that component ID for an 332 ICE candidate is always one. In addition, the rules in Section 333 4.1.1.3 MUST be ignored; instead, each candidate MUST have a unique 334 foundation, assigned arbitrarily by the client. 336 If the client wishes to establish a TCP connection and not a UDP 337 stream, or wishes to try both, the client MUST implement ICE-tcp 338 [I-D.ietf-mmusic-ice], and MUST follow the procedures defined there 339 for gathering of TCP candidates, again assuming a single component. 341 The default candidate selection described in Section 4.1.3 of ICE 342 MUST be ignored; defaults are not signaled or utilized here. 344 The ICE specification assumes that an ICE agent is configured with, 345 or somehow knows of, TURN and STUN servers. Protocols using ICE need 346 to describe how such information is learned by clients. 348 7. Sending an Initiate Message 350 Section 4.3 of ICE describes procedures for encoding the SDP. 351 Instead of actually encoding an SDP, the candidate information (IP 352 address and port and transport protocol, priority, foundation, 353 component ID, type and related address) is carried within the object 354 defined in Section 15. Similarly, the username fragment and password 355 are carried in this object. This object does not contain any default 356 candidates or the ice-lite attribute, as these features of ICE are 357 not used in NICE. The object does contain a Next-Protocol field. 358 This field is a string that contains the protocol name that is to be 359 run over the TCP or UDP association created by ICE. These names are 360 drawn from the list of protocols defined by IANA at 361 http://www.iana.org/assignments/port-numbers. Note that, since NICE 362 will cause STUN and this protocol to be multiplexed on the same port, 363 NICE can only be used to negotiate protocols that can be 364 differentiated from STUN by inspection. If the desired protocol 365 cannot be differentiated, it MUST be shimmed with a field that allows 366 such differentiation, and the resulting protocol MUST be given a new 367 name. 369 8. Receiving an Initiate Message 371 A responder MUST take the role of controlled. The role determination 372 mechanism in Section 5.2 of ICE is not used with NICE. The ICE 373 verification step in Section 5.1 is not used either. Instead, 374 protocols using this specification will need to describe how to 375 handle interoperability between clients which are using it, and ones 376 which are not. 378 The responder follows the procedures in Section 6 to gather 379 candidates. It then forms an Accept message and includes the object 380 defined in Section 15. 382 The responder MUST follow the procedures in Section 5.7 and 5.8 of 383 ICE, following the full implementation requirements and behaving as 384 if there was a single media stream with a single component. Because 385 there is only a single media stream and single component in NICE, the 386 states described in Section 5.7.4 will become simplified. There will 387 only be a single check list, and none of the candidate pairs will 388 ever have the state of Frozen; all pairs will start in the Waiting 389 state. 391 9. Receiving an Accept Message 393 When the initiator receives a response message, it extracts and NICE 394 object from the message. The initiator MUST take the role of 395 controlled, and then MUST follow the procedures of Section 5.7 and 396 5.8 of ICE, following the full implementation requirements and 397 behaving as if there was a single media stream with a single 398 component. 400 10. Connectivity Checks 402 The process of performing connectivity checks, as described in 403 Section 7 of ICE, is used here without change. This means that STUN 404 connectivity checks will contain the ICE-CONTROLLED and ICE- 405 CONTROLLING attributes. Strictly speaking, these are not needed. 406 However, they are retained here to allow for the possibility of 407 gatewaying between NICE and ICE (for example, in the event that H.323 408 decided to utilize NICE). 410 11. Concluding ICE 412 The controlling client MUST utilize regular nomination. This is to 413 ensure consistent state on the final selected pairs without the need 414 for additional signaling. 416 The procedures in Section 8 of ICE are followed to conclude ICE, with 417 the following exceptions: 419 o The controlling agent MUST NOT attempt to send an updated offer 420 once the state of its single media stream reaches Completed. 422 o Once the state of ICE reaches Completed, the agent can immediately 423 free all unused candidates. This is because the concept of 424 forking is not used here, and thus the three second delay in 425 Section 8.3 of ICE does not apply. 427 12. Subsequent Messaging 429 A client MUST NOT send additional Initiate or Accept messages. Thus, 430 the procedures in Section 9 of ICE MUST be ignored. A client that 431 needs to modify its connection parameters in some way MUST establish 432 a completely new connection by starting a totally new Initiate/Accept 433 exchange and ICE connectivity checks. 435 13. Keepalives 437 A NICE client MUST utilize STUN for the keepalives described in 438 Section 10 of ICE. 440 14. Sending and Receiving Data 442 A client follows the procedures of Section 11.1.1 of ICE to determine 443 when it can proceed to send data. However, in this case, the "media" 444 takes the form of application layer protocols. The concept of a 445 previous selected pair for a component does not apply to NICE, since 446 ICE restarts are not used. A client MUST be prepared to receive data 447 at any time. 449 15. The NICE Object 451 NICE operates by exchaning a MIME object, called the NICE object, in 452 an initiate and response message. The syntax of that object is 453 described here using the BNF defined in [RFC5234]. 455 NICE-obj = nice-ufrag CRLF 456 nice-pwd CRLF 457 nice-proto CRLF 458 1*(nice-cand CRLF) 459 *(nice-opts CRLF) 460 *(nice-ext CRLF) 461 nice-ufrag = ice-pwd-att 462 nice-pwd = ice-ufrag-att 463 nice-cand = candidate-attribute 464 nice-opts = ice-options 465 nice-proto = "nextproto:" token 466 nice-ext = ext-name ":" ext-value 467 ext-name = token 468 ext-value = byte-string 470 The BNF productions for ice-pwd-att, ice-ufrag-att, candidate- 471 attribute and ice-options are defined in [I-D.ietf-mmusic-ice]. The 472 NICE object also contains an extensibility mechanism, allowing new 473 parameters to be defined which follow the form of name:value. The 474 grammar for the name and its value follow those for SDP attributes. 475 This allows for a direct copying of any future ICE-related SDP 476 extensions into NICE without translations or specifications; the 477 attribute is simply placed into the bottom of the NICE object using 478 the grammar defined for it in the ICE extension. 480 The nextproto field contains an indication of the protocol that is to 481 be multiplexed with STUN over the established connection. In some 482 cases there is only one choice, based on the rendezvous protocol. 484 STUN connectivity checks between agents are authenticated using the 485 short term credential mechanism defined for STUN 486 [I-D.ietf-behave-rfc3489bis]. This mechanism relies on a username 487 and password that are exchanged through protocol machinery between 488 the client and server. With NICE, the Initiate and Accept exchange 489 is used to exchange them. The username part of this credential is 490 formed by concatenating a username fragment from each agent, 491 separated by a colon. Each agent also provides a password, used to 492 compute the message integrity for requests it receives. The username 493 fragment and password are exchanged in the nice-ufrag and nice-pwd 494 attributes, respectively. In addition to providing security, the 495 username provides disambiguation and correlation of checks to media 496 streams. 498 16. Security Considerations 500 ICE provides an extensive discussion on security considerations. 501 That discussion applies here as well. 503 In particular, ICE security depends in part on message integrity and 504 confidentiality of the offer/answer exchange. In the case of NICE, 505 the rendezvous protocol carrying the ICE object needs to provide 506 confidentiality and message integrity. Rendezvous protocols 507 utilizing ICE MUST implement and SHOULD use some kind of mechanism to 508 achieve that. 510 17. IANA Considerations 512 This specification registers a new MIME type, "message/nice", 513 according to the procedures of RFC 2048 [RFC2048]. This allows NICE 514 to readily be used with protocols that provide MIME transport, though 515 MIME transport is not required to use NICE. 517 MIME media type name: message 519 MIME subtype name: nice 521 Mandatory parameters: None 523 Optional parameters: None. 525 Encoding considerations: None 527 Security considerations: See Section 16 of RFC XXXX [[RFC EDITOR: 528 Replace with RFC number of this specification]]. 530 Interoperability considerations: none. 532 Published specification: RFC XXXX [[NOTE TO RFC EDITOR: Please 533 replace XXXX with the published RFC number of this 534 specification.]]. 536 Applications which use this media type: This media type is used in 537 the NICE protocol defined in in RFC XXXX [[NOTE TO RFC EDITOR: 538 Please replace XXXX with the published RFC number of this 539 specification.]]. 541 Additional Information: 543 Magic Number: None 545 File Extension: .nic 547 Macintosh file type code: "TEXT" 549 Personal and email address for further information: Jonathan 550 Rosenberg, jdrosen@jdrosen.net 552 Intended usage: COMMON 554 Author/Change controller: The IETF. 556 18. Tongue Twister 558 Say this five times fast: "ICE is nice, but NICE is nicer ICE". 560 19. References 562 19.1. Normative References 564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, March 1997. 567 [I-D.ietf-mmusic-ice] 568 Rosenberg, J., "Interactive Connectivity Establishment 569 (ICE): A Protocol for Network Address Translator (NAT) 570 Traversal for Offer/Answer Protocols", 571 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 573 [I-D.ietf-behave-rfc3489bis] 574 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 575 "Session Traversal Utilities for (NAT) (STUN)", 576 draft-ietf-behave-rfc3489bis-14 (work in progress), 577 February 2008. 579 [I-D.ietf-behave-turn] 580 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 581 Relays around NAT (TURN): Relay Extensions to Session 582 Traversal Utilities for NAT (STUN)", 583 draft-ietf-behave-turn-06 (work in progress), 584 January 2008. 586 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 587 Specifications: ABNF", STD 68, RFC 5234, January 2008. 589 [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose 590 Internet Mail Extensions (MIME) Part Four: Registration 591 Procedures", BCP 13, RFC 2048, November 1996. 593 19.2. Informative References 595 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 596 with Session Description Protocol (SDP)", RFC 3264, 597 June 2002. 599 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 600 Description Protocol", RFC 4566, July 2006. 602 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 603 A., Peterson, J., Sparks, R., Handley, M., and E. 604 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 605 June 2002. 607 [I-D.bryan-p2psip-reload] 608 Jennings, C., Lowekamp, B., Rescorla, E., and J. 609 Rosenberg, "REsource LOcation And Discovery (RELOAD)", 610 draft-bryan-p2psip-reload-02 (work in progress), 611 November 2007. 613 [I-D.manyfolks-hip-sturn] 614 Nikander, P., Melen, J., Komu, M., and M. Bagnulo, 615 "Mapping STUN and TURN messages on HIP", 616 draft-manyfolks-hip-sturn-01 (work in progress), 617 November 2007. 619 [I-D.tschofenig-mip6-ice] 620 Tschofenig, H. and G. Bajko, "Mobile IP Interactive 621 Connectivity Establishment (M-ICE)", 622 draft-tschofenig-mip6-ice-01 (work in progress), 623 July 2007. 625 Author's Address 627 Jonathan Rosenberg 628 Cisco 629 Edison, NJ 630 US 632 Phone: +1 973 952-5000 633 Email: jdrosen@cisco.com 634 URI: http://www.jdrosen.net 636 Full Copyright Statement 638 Copyright (C) The IETF Trust (2008). 640 This document is subject to the rights, licenses and restrictions 641 contained in BCP 78, and except as set forth therein, the authors 642 retain all their rights. 644 This document and the information contained herein are provided on an 645 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 646 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 647 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 648 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 649 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 650 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 652 Intellectual Property 654 The IETF takes no position regarding the validity or scope of any 655 Intellectual Property Rights or other rights that might be claimed to 656 pertain to the implementation or use of the technology described in 657 this document or the extent to which any license under such rights 658 might or might not be available; nor does it represent that it has 659 made any independent effort to identify any such rights. Information 660 on the procedures with respect to rights in RFC documents can be 661 found in BCP 78 and BCP 79. 663 Copies of IPR disclosures made to the IETF Secretariat and any 664 assurances of licenses to be made available, or the result of an 665 attempt made to obtain a general license or permission for the use of 666 such proprietary rights by implementers or users of this 667 specification can be obtained from the IETF on-line IPR repository at 668 http://www.ietf.org/ipr. 670 The IETF invites any interested party to bring to its attention any 671 copyrights, patents or patent applications, or other proprietary 672 rights that may cover technology that may be required to implement 673 this standard. Please address the information to the IETF at 674 ietf-ipr@ietf.org. 676 Acknowledgment 678 Funding for the RFC Editor function is provided by the IETF 679 Administrative Support Activity (IASA).