idnits 2.17.1 draft-lowekamp-mmusic-ice-tcp-framework-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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 538. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 545. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 551. 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. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 23, 2008) is 5663 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) ** Downref: Normative reference to an Informational RFC: RFC 3089 (ref. '3') ** Downref: Normative reference to an Experimental RFC: RFC 3103 (ref. '4') ** Downref: Normative reference to an Experimental RFC: RFC 4540 (ref. '11') == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-16 == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-ice-tcp-07 == Outdated reference: A later version (-07) exists of draft-ietf-behave-turn-tcp-00 ** Downref: Normative reference to an Experimental draft: draft-denis-udp-transport (ref. '17') == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-03 ** Downref: Normative reference to an Informational draft: draft-cheshire-nat-pmp (ref. '18') -- Possible downref: Non-RFC (?) normative reference: ref. '19' Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC WG A. B. Roach 3 Internet-Draft Tekelec 4 Expires: April 26, 2009 B. B. Lowekamp 5 SIPeerior Technologies 6 October 23, 2008 8 A Proposal to Define Interactive Connectivity Establishment for the 9 Transport Control Protocol (ICE-TCP) as an Extensible Framework 10 draft-lowekamp-mmusic-ice-tcp-framework-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 26, 2009. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 The ICE-TCP mechanism is currently regarded as of limited usefulness 44 due to the low success rate of TCP simultaneous open for NAT 45 traversal. This document presents a vision of the ICE-TCP document 46 as an extensible framework for negotiating a variety of approaches 47 for establishing a TCP connection between NATed hosts. This document 48 further proposes significantly extending the current set of 49 collection mechanisms to encompass a wide variety of technologies 50 that are currently available, including UPnP, SOCKS, and Teredo. 51 Because several of these technologies are already widely deployed, 52 the direct connection rate should be significantly higher than using 53 straight TCP alone. We envision that as future TCP connection 54 establishment techniques are developed, they too will specify an ICE 55 encoding that will allow their negotiation. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Gathering Candidates . . . . . . . . . . . . . . . . . . . 4 63 3.2. Prioritization . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Initial Set of Candidate Collection Technologies . . . . . . . 6 65 4.1. Host Candidates . . . . . . . . . . . . . . . . . . . . . 6 66 4.2. Non-Relayed NAT Candidates . . . . . . . . . . . . . . . . 7 67 4.2.1. NAT-Assisted . . . . . . . . . . . . . . . . . . . . . 7 68 4.2.2. UDP Tunneled . . . . . . . . . . . . . . . . . . . . . 9 69 4.2.3. Non-NAT-Assisted . . . . . . . . . . . . . . . . . . . 9 70 4.3. Relayed Candidates . . . . . . . . . . . . . . . . . . . . 10 71 4.3.1. SOCKS . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.3.2. SOCKS IPv4-IPv6 Gateway . . . . . . . . . . . . . . . 10 73 4.3.3. SSH Tunnels . . . . . . . . . . . . . . . . . . . . . 10 74 4.3.4. TURN TCP . . . . . . . . . . . . . . . . . . . . . . . 10 75 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 77 Intellectual Property and Copyright Statements . . . . . . . . . . 14 79 1. Introduction 81 The ICE-TCP document [15] currently relies on a closed set of 82 technologies for gathering candidates. While there is no prohibition 83 on the use of alternate technologies, ICE-TCP limits its discussion 84 to those technologies discussed in the base ICE specification [14]. 85 Specifically, this approach discusses the use of host candidates, 86 server reflexive candidates, and relayed candidates (with a focus on 87 TURN). 89 Unfortunately, this focus has led to the impression that ICE-TCP must 90 either use relayed candidates or rely on the "simultaneous open" 91 approach that is known to have a low chance of success. In fact, 92 both ICE and ICE-TCP can be extended to leverage any of a myriad of 93 NAT traversal technologies. 95 The most appealing feature of these technologies is that many of them 96 are already widely deployed. For example: 98 Teredo: Teredo establishes a UDP tunnel for other transport protocols 99 that is visible to applications on a host as an IPv6 address. It 100 is included in all current distributions of Windows and available 101 for Mac OS X, Linux, and most BSD platforms as a freely 102 installable package. 104 UPnP: deployed on the majority of residential-grade NAT/Firewall 105 devices and allows hosts behind the NAT to request a publicly 106 accessible TCP port. 108 SOCKS: Widely available as a relaying protocol, it has also been 109 extended to act as a NAT traversal solution in many NATs. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [2]. 117 3. Proposal 119 The authors propose that the ICE-TCP document be modified and 120 expanded to clarify the way that candidates are gathered and 121 prioritized. 123 3.1. Gathering Candidates 125 The current version of ICE-TCP discusses the use of STUN and TURN for 126 gathering Server Reflexive and Relayed candidates, respectively. We 127 propose this be written in a way that clarifies that such candidates 128 can be gathered via myriad mechanisms, and gives advice on which 129 types of candidates to gather. 131 To that end, we propose to replace the following text in section 3.1: 133 Next, the agent SHOULD take all host TCP candidates for a 134 component that have the same foundation (there will typically be 135 two - a passive and a simultaneous-open), and amongst them, pick 136 two arbitrarily. These two host candidates will be used to obtain 137 relayed and server reflexive candidates. To do that, the agent 138 initiates a TCP connection from each candidate to the TURN server 139 (resulting in two TCP connections). On each connection, it issues 140 an Allocate request. One of the resulting relayed candidate is 141 used as a passive relayed candidate, and the other, as a 142 simultaneous-open relayed candidate. In addition, the Allocate 143 responses will provide the agent with a server reflexive candidate 144 for their corresponding host candidate. 146 For all of the remaining host candidates, if any, the agent only 147 needs to obtain server reflexive candidates. To do that, it 148 initiates a TCP connection from each host candidate to a STUN 149 server, and uses a Binding request over that connection to learn 150 the server reflexive candidate corresponding to that host 151 candidate. 153 Once the Allocate or Binding request has completed, the agent MUST 154 keep the TCP connection open until ICE processing has completed. 155 See Section 1 for important implementation guidelines. 157 With: 159 Next, the agent SHOULD take all host TCP candidates for a 160 component that have the same foundation (there will typically be 161 two - a passive and a simultaneous-open), and amongst them, pick 162 two arbitrarily. These two host candidates will be used to obtain 163 two Relayed Candidates (see Section 4.3). 165 The agent should then obtain one or more non-relayed NAT 166 candidates (see Section 4.2). The mechanisms for establishing 167 such candidates and the number of candidates to collect vary from 168 technique to technique. These considerations are discussed in the 169 relevant sections, below. 171 Once the relayed candidates and non-relayed NAT candidates have 172 been prepared, the agent MUST keep the TCP connection open until 173 ICE processing has completed. See Section 1 for important 174 implementation guidelines. 176 (Note that, in the preceding text, references to Section 4.3 and 177 Section 4.2 refer to sections in this document, not to sections in 178 draft-ietf-mmusic-ice-tcp.) 180 3.2. Prioritization 182 The current prioritization scheme defined in ICE-TCP favors 183 simultaneous-open candidates over active and passive candidates. 184 This prioritization is presumably based on the prospect that non- 185 relayed connections are the exclusive domain of STUN-discovered 186 Server Reflexive Candidates. Such candidates necessarily rely on 187 "fooling" the NAT into allowing TCP connections through; and one 188 might assume that simultaneous open has a higher chance of succeeding 189 in doing so. 191 Empirical evidence on the simultaneous open technique described in 192 ICE-TCP has shown that, while it has a relatively high chance of 193 establishing the proper state in a NAT, it suffers from a high 194 failure rate on the actual endpoints. 196 Several NAT traversal techniques, both deployed and proposed, provide 197 means for discovering NAT-allocated address/port combinations in such 198 a way that the NAT is actively participating in the TCP establishment 199 effort instead of impeding it. Others leverage the behavior of UDP 200 binding in NATs to carry TCP traffic over UDP. In such cases, normal 201 active and passive candidates actually have a higher chance of 202 success than simultaneous-open candidates. 204 To reflect this reality, we propose that the prioritization scheme 205 for ICE-TCP be revised. Specifically, we propose to replace the 206 following text in section 3.2: 208 It is RECOMMENDED that, for all connection-oriented media, 209 simultaneous-open candidates have a direction-pref of 7, active of 210 5 and passive of 2. 212 With: 214 It is RECOMMENDED that, for all connection-oriented media, 215 candidates have a direction-pref assigned as follows: 217 7 NAT-Assisted Active Candidate 218 6 NAT-Assisted Passive Candidate 219 5 UDP-Tunneled Active Candidate 220 4 UDP-Tunneled Passive Candidate 221 3 Simultaneous Open Candidate 222 2 Non-NAT-Assisted Active Candidate 223 1 Non-NAT-Assisted Passive Candidate 224 It is RECOMMENDED that the type preference for NAT-Assisted 225 candidates be set higher than that for server-reflexive candidates 226 and that the type preference for UDP-Tunneled candidates be set 227 lower than that for server-reflexive candidates. The RECOMMENDED 228 values are 105 for NAT-Assisted candidates and 75 for UDP-Tunneled 229 candidates. 230 TODO: The same information probably doesn't need to be encoded in 231 both the type-pref and direction-pref. More work is needed to 232 iron out how to represent appropriate priorities. 234 4. Initial Set of Candidate Collection Technologies 236 (The authors propose that the entirety of this Section 4 and its 237 subsections, with the exception of this parenthetical paragraph, be 238 included in ICE-TCP.) 240 The following sections discuss a number of techniques that can be 241 used to obtain candidates for use with ICE-TCP. It is critical to 242 note that this list is not intended to be exhaustive, nor is 243 implementation of any specific technique considered mandatory. 244 Implementors are encouraged to implement as many of the following 245 techniques from the following list as is practical, as well as to 246 explore additional NAT-traversal techniques beyond those discussed in 247 this document. 249 4.1. Host Candidates 251 For each TCP capable media stream the agent wishes to use (including 252 ones, like RTP, which can either be UDP or TCP), the agent SHOULD 253 obtain two host candidates (each on a different port) for each 254 component of the media stream on each interface that the host has - 255 one for the simultaneous open, and one for the passive candidate. If 256 an agent is not capable of acting in one of these modes it would omit 257 those candidates. 259 For maximum interoperability with the techniques described below, 260 implementors should take particular care to include both IPv4 and 261 IPv6 candidates as part of the process of gathering candidates. If 262 the local network or host does not support IPv6 addressing, then 263 clients SHOULD make use of Teredo (Section 4.2.2.1) or SOCKS IPv4- 264 IPv6 Gatewaying (Section 4.3.2). 266 4.2. Non-Relayed NAT Candidates 268 The following techniques can be used to gather candidates that 269 represent NAT traversal, while not going through any additional 270 relays. This includes Server Reflexive Candidates (non-NAT- 271 assisted), candidates established in cooperation with the NAT (NAT- 272 assisted), and candidates tunnel TCP over UDP to leverage widespread 273 NAT UDP binding behavior (UDP-tunneling). 275 Generally, when several options are available, clients should favor 276 NAT-assisted techniques over UDP-tunneling techniques, and UDP- 277 tunneling techniques over non-NAT-assisted techniques. 279 4.2.1. NAT-Assisted 281 To traverse NATs, the best approach is to work with the NATs 282 themselves, rather than trying to "game" their behavior with tricks 283 and relays. To that end, clients behind NATs should favor approaches 284 that work with NATs whenever possible. 286 Because these techniques interact with the NAT directly to acquire a 287 publicly accessible transport address, once obtained these candidates 288 are encoded as normally TCP candidates (typically tcp-pass) as 289 specified in Section 3.4 of ICE-TCP. 291 4.2.1.1. UPnP IGD 293 The UPnP forum's Internet Gateway Device (IGD) protocol [19] is 294 designed to facilitate client configuration of NAT port forwarding 295 behavior. IGD is deployed on a majority of residential-grade NAT/ 296 Firewall devices, and is available for Linux- and FreeBSD-based 297 firewalls. 299 Clients wishing to use IGD-obtained addresses as candidates do so by 300 retrieving the ExternalIPAddress state variable; then, they use the 301 AddPortMapping command to establish a new TCP binding at the NAT. 302 The client is responsible for establishing the binding so that it 303 corresponds to a Host Candidate, and for periodically refreshing the 304 port mapping to keep the lease from expiring. When the IGD-acquired 305 candidate is no longer necessary, the client SHOULD remove the 306 binding with a DeletePortMapping command. 308 4.2.1.2. MIDCOM SNMP 310 The MIDCOM MIB [12] defines an SNMP-based mechanism for controlling 311 NATs, Firewalls, and other middleboxes. 313 TODO: add application notes about how to obtain candidates 315 4.2.1.3. SOCKS 317 Although originally designed as a relaying protocol, SOCKS [1] has 318 been incorporated in a number of NATs as a NAT-assisted traversal 319 technique. The approach for using SOCKS for NAT-assisted traversal 320 is identical to that for using it as a relay protocol (see 321 Section 4.3.1). 323 If the ICE agent is aware that SOCKS is being used as a NAT-assisted 324 protocol instead of a relay protocol, it SHOULD set the local- 325 preference accordingly. 327 4.2.1.4. RSIP 329 The Realm Specific IP (RSIP) protocol [4] is an experimental protocol 330 designed to allow clients within a realm to communicate with gateways 331 on the edge of that realm so as to lease globally-visible resources 332 on those gateways. 334 TODO: add application notes about how to obtain candidates 336 TODO: examine RSIP as a v4/v6 bridging technology 338 4.2.1.5. SIMCO 340 The SIMCO protocol [11] an experimental mechanism for controlling 341 NATs, Firewalls, and other middleboxes. 343 TODO: add application notes about how to obtain candidates 345 4.2.1.6. NAT-PMP 347 The NAT Port Mapping Protocol (PMP) [18] is designed to allow clients 348 to determine the external IP address of a NAT, learn about any 349 changes in that IP address, and create and refresh UDP and TCP 350 bindings on the NAT. NAT-PMP is currently supported in a number of 351 field-deployed products, such as the Apple Airport Express, Apple 352 Airport Extreme, and Apple Time Capsule, as well as a large number of 353 primarily peer-to-peer software applications. 355 Clients wishing to use PMP-obtained addresses as candidates do so by 356 retrieving the external IP address, using the PMP opcode 0; then, 357 they use the PMP opcode 2 to establish a new TCP binding at the NAT. 358 The client is responsible for establishing the binding so that it 359 corresponds to a Host Candidate, and for periodically refreshing the 360 port mapping to keep the lease from expiring. When the PMP-obtained 361 candidate is no longer necessary, the client SHOULD remove the 362 binding with a PMP opcode 2 with the port mapping lifetime set to 0. 364 4.2.2. UDP Tunneled 366 4.2.2.1. Teredo 368 The Teredo protocol [10] defines a system allow nodes behind one or 369 more NATs to obtain IPv6 addresses by tunneling IPv6 over UDP. 370 Teredo it included in all modern Windows operating systems by 371 default, and is available for most other major operating systems, 372 such as Linux, OS X, and *BSD. 374 Teredo essentially provides a UDP tunnel for other transport 375 protocols that is visible to the host application as an IPv6 address. 376 Therefore, Teredo candidates are encoded as IPv6 addresses in the 377 SDP. 379 The Teredo framework includes provisions for routing between Teredo 380 IPv6 addresses and native IPv6 addresses; therefore, the efficacy of 381 Teredo tunneling will be significantly improved for each ICE-TCP 382 implementation that advertises at least one globally-routable IPv6 383 address candidate (whether Teredo, SOCKS tunneled, 6-to-4 relayed, 384 IPv6 tunneled, or native). 386 TODO: add application notes about how to obtain candidates 388 4.2.2.2. TCP over UDP 390 TODO: Describe TCP/UDP/IP, as defined in [17]. 392 TODO: add application notes about how to obtain candidates; need to 393 include discussion of SDP extensions necessary to specify encoding 394 for TCP over UDP. 396 4.2.3. Non-NAT-Assisted 398 4.2.3.1. STUN 400 TODO: Describe STUN, as defined in [13]. 402 To obtain STUN server reflexive candidates, the agent initiates a TCP 403 connection from two host candidates to a STUN server, and uses a 404 Binding request over that connection to learn the server reflexive 405 candidate corresponding to that host candidate. 407 4.3. Relayed Candidates 409 4.3.1. SOCKS 411 TODO: Describe SOCKS, as defined in [1] 413 TODO: add application notes about how to obtain candidates 415 4.3.2. SOCKS IPv4-IPv6 Gateway 417 TODO: Describe IPv4/IPv6 bridging technique described in [3] 419 TODO: add application notes about how to obtain candidates 421 4.3.3. SSH Tunnels 423 TODO: Describe SSH Tunneling technique described in [5] [6] [7] [8] 424 [9] 426 TODO: add application notes about how to obtain candidates 428 4.3.4. TURN TCP 430 TODO: Describe TURN TCP protocol described in [16] 432 To acquire TURN TCP candidates, the agent initiates a TCP connection 433 from two host candidates to the TURN server (resulting in two TCP 434 connections). On each connection, it issues an Allocate request. 435 One of the resulting relayed candidate is used as a passive relayed 436 candidate, and the other, as a simultaneous-open relayed candidate. 437 In addition, the Allocate responses will provide the agent with a 438 server reflexive candidate for their corresponding host candidate. 440 5. References 442 [1] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. 443 Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. 445 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 446 Levels", BCP 14, RFC 2119, March 1997. 448 [3] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", 449 RFC 3089, April 2001. 451 [4] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm 452 Specific IP: Protocol Specification", RFC 3103, October 2001. 454 [5] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol 455 Assigned Numbers", RFC 4250, January 2006. 457 [6] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol 458 Architecture", RFC 4251, January 2006. 460 [7] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 461 Authentication Protocol", RFC 4252, January 2006. 463 [8] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport 464 Layer Protocol", RFC 4253, January 2006. 466 [9] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection 467 Protocol", RFC 4254, January 2006. 469 [10] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network 470 Address Translations (NATs)", RFC 4380, February 2006. 472 [11] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple 473 Middlebox Configuration (SIMCO) Protocol Version 3.0", 474 RFC 4540, May 2006. 476 [12] Quittek, J., Stiemerling, M., and P. Srisuresh, "Definitions of 477 Managed Objects for Middlebox Communication", RFC 5190, 478 March 2008. 480 [13] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 481 Traversal Utilities for (NAT) (STUN)", 482 draft-ietf-behave-rfc3489bis-16 (work in progress), July 2008. 484 [14] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 485 Protocol for Network Address Translator (NAT) Traversal for 486 Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in 487 progress), October 2007. 489 [15] Rosenberg, J., "TCP Candidates with Interactive Connectivity 490 Establishment (ICE)", draft-ietf-mmusic-ice-tcp-07 (work in 491 progress), July 2008. 493 [16] Rosenberg, J. and R. Mahy, "Traversal Using Relays around NAT 494 (TURN) Extensions for TCP Allocations", 495 draft-ietf-behave-turn-tcp-00 (work in progress), 496 November 2007. 498 [17] Denis-Courmont, R., "UDP-Encapsulated Transport Protocols", 499 draft-denis-udp-transport-00 (work in progress), July 2008. 501 [18] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 502 draft-cheshire-nat-pmp-03 (work in progress), April 2008. 504 [19] Warrier, U., Iyer, P., Pennerath, F., Marynissen, G., Schmitz, 505 M., Siddiqi, W., and M. Blaszczak, "Internet Gateway Device 506 (IGD) Standardized Device Control Protocol V 1.0", 507 November 2001. 509 Authors' Addresses 511 Adam Roach 512 Tekelec 513 17210 Campbell Rd. 514 Suite 250 515 Dallas, TX 75252 516 US 518 Email: adam@nostrum.com 520 Bruce B. Lowekamp 521 SIPeerior Technologies 522 5251-18 John Tyler Highway #330 523 Williamsburg, VA 23185 524 USA 526 Phone: +1 757 565 0101 527 Email: bbl@lowekamp.net 529 Intellectual Property Statement 531 The IETF takes no position regarding the validity or scope of any 532 Intellectual Property Rights or other rights that might be claimed to 533 pertain to the implementation or use of the technology described in 534 this document or the extent to which any license under such rights 535 might or might not be available; nor does it represent that it has 536 made any independent effort to identify any such rights. Information 537 on the procedures with respect to rights in RFC documents can be 538 found in BCP 78 and BCP 79. 540 Copies of IPR disclosures made to the IETF Secretariat and any 541 assurances of licenses to be made available, or the result of an 542 attempt made to obtain a general license or permission for the use of 543 such proprietary rights by implementers or users of this 544 specification can be obtained from the IETF on-line IPR repository at 545 http://www.ietf.org/ipr. 547 The IETF invites any interested party to bring to its attention any 548 copyrights, patents or patent applications, or other proprietary 549 rights that may cover technology that may be required to implement 550 this standard. Please address the information to the IETF at 551 ietf-ipr@ietf.org. 553 Disclaimer of Validity 555 This document and the information contained herein are provided on an 556 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 557 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 558 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 559 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 560 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 561 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 563 Copyright Statement 565 Copyright (C) The IETF Trust (2008). This document is subject to the 566 rights, licenses and restrictions contained in BCP 78, and except as 567 set forth therein, the authors retain all their rights. 569 Acknowledgment 571 Funding for the RFC Editor function is currently provided by the 572 Internet Society.