idnits 2.17.1 draft-jennings-behave-test-results-04.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, updated by RFC 4748 on line 581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 592. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 599. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 605. 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-RFC2606-compliant FQDNs in the document. == There are 6 instances 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 (July 7, 2007) is 6131 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-02 ** Obsolete normative reference: RFC 3489 (ref. '2') (Obsoleted by RFC 5389) == Outdated reference: A later version (-12) exists of draft-ietf-behave-multicast-07 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco Systems 4 Intended status: Informational July 7, 2007 5 Expires: January 8, 2008 7 NAT Classification Test Results 8 draft-jennings-behave-test-results-04 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 January 8, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 IETF has several working groups that are considering the impact of 42 NATs on various protocols. Having a classification of the types of 43 NATs that are being developed and deployed is useful in gauging the 44 impact of various solutions. This draft records the results of 45 classifying NATs. 47 This draft is not complete and has only a few test results but it is 48 worth discussing all the testing we wish to do before all the test 49 results are collected. The test results here are very old and work 50 is being done to update them with more current information. 52 1. Introduction 54 A major issue in working with NAT traversal solutions for various 55 protocols is that NATs behave in many different ways. This draft 56 describes the results of testing several residential style NATs. 58 2. Descriptions of Tests 60 2.1. UDP Mapping 62 This test sends STUN[1] packets from the same port on three different 63 internal IP addresses to the same destination. The source port on 64 the outside of the NAT is observed. The test records whether the 65 port is preserved or not and whether all the mapping get different 66 ports. 68 A second set of tests checks out how the NAT maps ports above and 69 below 1024. 71 Tests are run with a group of several consecutive ports to see if the 72 NAT preserves port parity. 74 2.2. UDP Filtering 76 This test sends STUN packets from the same port on three different 77 internal IP addresses to the same destination. It then tests whether 78 places on the outside with 1) a different port but the same IP 79 address and then 2) a different port and a different IP address can 80 successfully send a packet back to the sender. The test is based on 81 technique described in [2]. 83 2.3. UDP Hairpin 85 This test sends a STUN packet from the inside to the outside to 86 create a mapping and discover the external source address called A. 87 It does the same thing from a different internal IP address to get a 88 second external mapping called B. It then sends a packet from A to B 89 and B to A and notes if these packets are successfully delivered from 90 one internal IP address to the other. 92 2.4. ICMP 94 A device on the inside sends a packet to an external address that 95 causes an ICMP Destination Unreachable packet to be returned. The 96 test records whether this packet makes it back through the NAT 97 correctly. 99 2.5. Fragmentation 101 The MTU on the outside of the NAT is set to under 1000; on the inside 102 it is set to 1500 or over. Then a 1200 byte packet is sent to the 103 NAT. The test records whether the NAT correctly fragments this when 104 sending it. Another test is done with DF=1. An additional test is 105 done with DF=1 in which the adjacent MTU on the NAT is large enough 106 the NAT does not need to fragment the packet but further on, a link 107 has an MTU small enough that an ICMP packet gets generated. The test 108 records whether the NAT correctly forwards the ICMP packet. 110 In the next test a fragmented packet with the packets in order is 111 sent to the outside of the NAT, and the test records whether the 112 packets are dropped, reassembled and forwarded, or forwarded 113 individually. A similar test is done with the fragments out of 114 order. 116 2.6. UDP Refresh 118 A test is done that involves sending out a STUN packet and then 119 waiting a variable number of minutes before the server sends the 120 response. The client sends different requests with different times 121 on several different ports at the start of the test and then watches 122 the responses to find out how long the NAT keeps the binding alive. 124 A second test is done with a request that is delayed more than the 125 binding time but every minute an outbound packet is sent to keep the 126 binding alive. This test checks that outbound traffic will update 127 the timer. 129 A third test is done in which several requests are sent with the 130 delay less than the binding time and one request with the delay 131 greater. The early test responses will result in inbound traffic 132 that may or may not update the binding timer. This test detects 133 whether the packet with the time greater than the binding time will 134 traverse the NAT which provide the information about whether the 135 inbound packets have updated the binding timers. 137 An additional test is done to multiple different external IP 138 addresses from the same source, to see if outbound traffic to one 139 destination updates the timers on each session in that mapping. 141 2.7. Multicast and IGMP 143 Multicast traffic is sent to the outside of the NAT, and the test 144 records whether the NAT forwards it to the inside. Next an IGMP 145 Membership Report is sent from inside. The test records whether the 146 NAT correctly forwards it to the outside and whether it allows 147 incoming multicast traffic. More detail on NATs and IGMP is provided 148 in [3]. 150 2.8. Multicast Timers 152 The test records how long the NAT will forward multicast traffic 153 without receiving any IGMP Membership Reports and whether receiving 154 Reports refreshes this timer. 156 2.9. TCP Timers 158 TBD: Measure time before ACK, after ACK, and after FIN and RST. 160 2.10. TCP Port Mapping 162 Multiple SYN packets are sent from the same inside address to 163 different outside IP addresses, and the source port used on the 164 outside of the NAT is recorded. 166 2.11. SYN Filtering 168 Test that a SYN packet received on the outside interfaces that does 169 not match anything gets discarded with no reply being sent. Test 170 whether an outbound SYN packet will create a binding that allows an 171 incoming SYN packet. 173 2.12. DNS 175 Does the DNS proxy in them successfully pass through SRV requests. 177 2.13. DHCP 179 Do any DHCP options received on the WAN side get put into DHCP 180 answers sent on LAN side? 182 2.14. Ping 184 Do ping request sent from LAN side work? 186 2.15. DHCP 188 Do traceroute request sent from LAN side work? 190 3. Observations 192 Several NATs attempt to use the same external port number as the 193 internal host has used. This is referred to as port preservation. 194 Some of the NATs that do this were found to have different 195 characteristics depending on whether the port was already in use or 196 not. This was tested by running the STUN tests from a particular 197 port on one internal IP address and then running them again from the 198 same port on a different internal IP address. The results from the 199 first interface, where the port was preserved, are referred to as the 200 primary type; while the results from the second interface, which did 201 not manage to get the same external port because it was already in 202 use, are referred to as the secondary type. On most NATs the 203 secondary type is the same as the primary but on some it is 204 different; these are referred to as nondeterministic NATs, since a 205 client with a single internal IP address cannot figure out what type 206 of NAT it is. 208 There are several NATs that would be detected as address restricted 209 by the STUN tests but are not. These NATs always use the same 210 external port as the internal port and store the IP address of the 211 most recent internal host to send a packet on that port. The NATs 212 then forward any traffic arriving at the external interface of the 213 NAT on this port to the internal host that has most recently used it. 214 These NATs are labeled "Bad" in the result table since they do not 215 meet the definitions of NAPT in RFC 3022. Interestingly, as long as 216 the clients behind the NAT choose random port numbers, they often do 217 work. STUN detects these NATs as address restricted although they 218 are really not address restricted NATs. This type of NAT is easily 219 detected by sending a STUN packet from the same port on two different 220 internal IP addresses and looking at the mapped port in the return. 221 If both packets have been mapped to the same external port, the NAT 222 is of the Bad type. 224 Another important aspect of a NAT for some applications is whether it 225 can send media from one internal host back to another host behind the 226 same NAT. This is referred to as supporting hairpin media. 228 It was rumored that some NATs existed that looked in arbitrary 229 packets for either the NATs' external IP address or the internal host 230 IP address - either in binary or dotted decimal form - and rewrote it 231 to something else. STUN could be extended to test for exactly this 232 type of behavior by echoing arbitrary client data and the mapped 233 address but sending the bits inverted so these evil NATs did not mess 234 with them. NATs that do this will break integrity detection on 235 payloads. 237 To help organize the NATs by what types of applications they can 238 support, the following groups are defined. The application of using 239 a SIP phone with a TLS connection for signaling and using STUN for 240 media ports is considered. It is assumed the RTP/RTCP media is on 241 random port pairs as recommended for RTP. 243 Group A: NATs that are deterministic, not symmetric, and support 244 hairpin media. These NATs would work with many phones behind 245 them. 246 Group B: NATs that are not symmetric on the primary mapping. This 247 group would work with many IP phones as long as the media ports 248 did not conflict. This is unlikely to happen often but will 249 occasionally. Because they may not support hairpin media, a call 250 from one phone behind a NAT to another phone behind the same NAT 251 may not work. 252 Group D: NATs of the type Bad. These have the same limitations of 253 group B but when the ports conflict, media gets delivered to a 254 random phone behind the NAT. 255 Group F: These NATs are symmetric and phones will not work. 257 4. Results 259 The following table shows the results from several NATs. The NATs 260 tested include some random ones the author had lying around as well 261 as every NAT that could be purchased in February 2004 in the San Jose 262 Fry's, Best Buy, CompUSA, and Circuit City. Clearly this is not a 263 very good approximation to a random sample. It is clear that the 264 NATs widely purchased in the US are different from what are available 265 in Japan and Europe. 267 In the following table the Prim column indicates the primary type of 268 the NAT. A value of Port indicates port restricted, Cone is a full 269 cone, Bad is described in the next section, Symm is Symmetric, and 270 Addr is Address restricted. The Hair column value of Y or N 271 indicates whether the NAT will hairpin media. The Pres column 272 indicates whether the NAT attempts to preserve port numbers. The Sec 273 column indicates the secondary type of the NAT, and a value of Same 274 indicates it is the same as the primary type. The Grp indicates the 275 group that this NAT falls into. 277 Vendor Model Firmware Prim Sec Hair Pres Grp 279 Airlink ASOHO4P V1.01.0095 Port Symm N Y B 280 Apple Air Base V5.2 Cone Same Y N A 281 Belkin F5D5321 V1.13 Port Same N N B 282 Cisco IOS Port Symm - 283 Cisco PIX Port Same - 284 Corega BAR Pro2 R1.00 Feb 21 2003 Cone - 285 DLink DI-604 2.0 Jun 2002 Cone Same N N B 286 DLink DI-704P 2.61 build 2 Cone Same Y N A 287 Dlink DI-804 .30, Tue,Jun 24 20 Cone Same Y N A 288 Hawkings FR24 6.26.02h Build 004 Bad Same Y Y D 289 Linksys BEFSR11 Port B 290 Linksys BEFSR11 V2 1.42.7, Apr 02 200 Port B 291 Linksys BEFSR41 v1.44.2 Port B 292 Linksys BEFSR81 2.42.7.1 June 2002 Addr Same N Y B 293 Linksys BEFSRU31 Port B 294 Linksys BEFSX41 1.44.3, Dec 24 200 Port B 295 Linksys BEFVP41 1.41.1, Sep 04 200 Port B 296 Linksys BEFW11S4 1.45.3, Jul 1 2003 Port B 297 Linksys WRT54G 1.42.2 Port Symm N Y B 298 Linksys WRT55AG 1.04, Jun.30, 2003 Port B 299 Linksys WRV54G 2.03 Port Same N Y B 300 Microsoft MN-700 02.00.07.0331 Cone Same N N B 301 Netgear FVS318 V1.4 Jul. 15 2003 Port Same N N B 302 Netgear RP114 3.26(CD.0) 8/17/20 Cone - 303 Netgear RP614 4.00 April 2002 Cone Same Y N A 304 NetworkEver NR041 Version 1.0 Rel 10 Symm Same N N F 305 NetworkEver NR041 Version 1.2 Rel 03 Bad Same Y Y D 306 SMC 2804WBRP-G v1.00 Oct 14 2003 Port Symm Y Y B 307 SMC 7004ABR V1.42.003 Port Same N N B 308 SMC 7004VBR v1.03 Jun 12, 2002 Cone - 309 Toshiba WRC-1000 1.07.03a-C024a Port Cone N Y B 310 umax ugate-3000 2.06h Port - 311 US Robotics USR8003 1.04 08 Cone Same N N B 312 ZOT BR1014 Unknown Bad Same N Y D 314 Since this testing was done, some additional testing and shopping 315 sprees in France and Taiwan have provided the following results. 317 Vendor Model Firmware Prim Sec Hair Pres Grp 319 Netgear MR814v2 Version 5.01 Bad Same Y Y D 320 Cisco PIX 515 6.3(3) Port Same N N B 321 Dynex DX-E401 1.03 Cone Same Y N A 322 Asante FR1004 R1.13 V2 Cone Same N N B 323 Linksys BEFSR81 2.42.7.1 Addr Note 1 N Y B 324 Lanner BRL-04FPU Cone Same N N 325 AboCom CAS3047 Port Same N Y 326 Lemmel LM-IS6400B Port Same N Y 328 The NAT with a secondary type of "Note 1" is particularly weird. The 329 primary connection is address restricted. If a second host uses this 330 same port, it also gets an Address Restricted, but when a third host 331 uses this same port, it gets Symmetric. 333 Some more recent test results. On this set of NATs, more than half 334 had UPnP disabled by default. 336 TRENDnet TW100-BRF114U Version 1.1 Release 04 337 Primary: Independent Mapping, Address Dependent Filter, 338 preserves ports, no hairpin 339 Secondary: Dependent Mapping, random port, no hairpin 341 Netgear RP614v2 5.13 Jul 08 2003 342 Primary: Independent Mapping, Independent Filter, random port, 343 will hairpin 344 Secondary: Independent Mapping, Independent Filter, random port, 345 will hairpin 347 Netgear WGM124 Version 1.0 Release 07 348 Primary: Independent Mapping, Port Dependent Filter, 349 preserves ports, no hairpin 350 Secondary: Dependent Mapping, random port, no hairpin 352 Netgear MBR814v3 V5.4_06 353 Primary: Independedt Mapping, Address Dependent Filter, 354 preserves ports, will hairpin 355 Secondary: Dependent Mapping, random port, no hairpin 357 Linksys WRTP54G 1.00.20 358 Primary: Independent Mapping, Port Dependent Filter, 359 preserves ports, no hairpin 360 Secondary: Dependent Mapping, random port, no hairpin 362 Linksys WRT54Gv5 v1.00.6, Jan. 20, 2006 363 Primary: Independent Mapping, Port Dependent Filter, 364 preserves ports, will hairpin 366 Secondary: Independent Mapping, Port Dependent Filter, 367 random port, will hairpin 369 Linksys WRT55AG Firmware: 1.04, Jun. 30, 2003 370 Primary: Independent Mapping, Port Dependent Filter, 371 preserves ports, no hairpin 372 Secondary: Dependent Mapping, random port, no hairpin 374 Linksys BEFSR41v4 1.04.02, Feb 18 2005 375 Primary: Independent Mapping, Independent Filter, preserves ports, 376 no hairpin 377 Secondary: Dependent Mapping, random port, no hairpin 379 DLink DI-808HV V1.40, Thu, Aug 12 2004 380 Primary: Independent Mapping, Independent Filter, random port, 381 will hairpin 382 Secondary: Independent Mapping, Independent Filter, random port, 383 will hairpin 385 Netgear WGR614v6 V2.0.13_1.0.13NA 386 Primary: Dependent Mapping, preserves ports, no hairpin 387 Secondary: Dependent Mapping, random port, no hairpin 389 Netgear WNR834M 1.1.15NA 390 Primary: Independent Mapping, Port Dependent Filter, 391 preserves ports, no hairpin 392 Secondary: Dependent Mapping, random port, no hairpin 394 DLink WBR-1310 1.01 , Dec 30 , 2005 395 Primary: Independent Mapping, Independent Filter, random port, 396 will hairpin 397 Secondary: Independent Mapping, Independent Filter, random port, 398 will hairpin 400 Linksys WTR54GS V1.0_15 401 Primary: Independedt Mapping, Address Dependent Filter, 402 preserves ports, no hairpin 403 Secondary: Dependent Mapping, random port, no hairpin 405 Another good source of information for behavior of various NATs is 406 the NATCECK [4] and STUNT [5] web pages. 408 Testing of PING and Traceroute functionality on these NATs provided 409 the following results: 411 Vendor Model Firmware Ping TraceRt 413 Airlink ASOHO4P V1.01.0095 Y Y 414 Apple Air Base V5.2 Y Y 415 Belkin F5D5321 V1.13 Y Y 416 Cisco IOS Y Y 417 Cisco PIX Y Y 418 Corega BAR Pro2 R1.00 Feb 21 2003 Y Y 419 DLink DI-604 2.0 Jun 2002 Y Y 420 DLink DI-704P 2.61 build 2 Y Y 421 Dlink DI-804 .30, Tue,Jun 24 20 Y Y 422 Hawkings FR24 6.26.02h Build 004 Y Y 423 Linksys BEFSR11 V2 1.42.7, Apr 02 200 Y Y 424 Linksys BEFSR41 v1.44.2 Y Y 425 Linksys BEFSR81 2.42.7.1 June 2002 Y Y 426 Linksys BEFSX41 1.44.3, Dec 24 200 Y Y 427 Linksys BEFVP41 1.41.1, Sep 04 200 Y Y 428 Linksys BEFW11S4 1.45.3, Jul 1 2003 Y Y 429 Linksys WRT54G 1.42.2 Y Y 430 Linksys WRT55AG 1.04, Jun.30, 2003 Y Y 431 Linksys WRV54G 2.03 Y Y 432 Microsoft MN-700 02.00.07.0331 Y Y 433 Netgear FVS318 V1.4 Jul. 15 2003 Y Y 434 Netgear RP114 3.26(CD.0) 8/17/20 Y Y 435 Netgear RP614 4.00 April 2002 Y Y 436 NetworkEver NR041 Version 1.0 Rel 10 Y Y 437 NetworkEver NR041 Version 1.2 Rel 03 Y Y 438 SMC 2804WBRP-G v1.00 Oct 14 2003 Y Y 439 SMC 7004ABR V1.42.003 Y Y 440 SMC 7004VBR v1.03 Jun 12, 2002 Y Y 441 Toshiba WRC-1000 1.07.03a-C024a Y Y 442 US Robotics USR8003 1.04 08 Y Y 443 ZOT BR1014 Unknown Y Y 444 Netgear MR814v2 Version 5.01 Y Y 445 Cisco PIX 515 6.3(3) Y Y 446 Dynex DX-E401 1.03 Y Y 447 Asante FR1004 R1.13 V2 Y Y 448 Linksys BEFSR81 2.42.7.1 Y Y 449 Lanner BRL-04FPU Y Y 450 Lemmel LM-IS6400B Y Y 452 Open Issue: How should we arrange all the results? There are going 453 to be too many to put it as one row per device. 455 5. Discussion 457 It is clear from discussions with various vendors and watching how 458 tests have changed over the years that symmetric is becoming less 459 common. This change is being driven primarily by the desire to make 460 online gaming work; many games use methods similar to STUN for NAT 461 traversal. The only symmetric NAT found was an old device. More 462 recent versions of the software on the same device were not 463 symmetric. It is clear that other symmetric NATs are deployed, but 464 it is hard to find them. 466 6. IANA Considerations 468 This document requires no actions by IANA. 470 7. Security Considerations 472 It is often assumed that symmetric NATs are more secure than port 473 restricted NATs. This is not true - they are identical from a 474 security point of view. They both only allow a packet to come inside 475 the NAT if the host inside has previously sent to the exact same 476 external IP and port. One can argue that cone is less secure than 477 port restricted, but this is not true if the attacker can spoof the 478 IP address, which is fairly easy to do in many cases. What level of 479 security can be expected from NATs at all is a strange and curious 480 topic. With all the NATs, if you allow packets out, packets can come 481 in, so don't be surprised if NATs provide less security than 482 anticipated. 484 8. Open Issues 486 The hairpin media tests were done by having a single host use STUN to 487 find a public address on the NAT and then send media to itself and 488 see if it was received. It is possible that NATs might not hairpin 489 media to the same host but would hairpin media to another host behind 490 the same NAT. It is possible that because of this, the hairpin 491 results reported here might be wrong. 493 This sample set of NATs is very US-centric: D-Link, Linksys, and 494 Netgear dominate the US consumer market. It would be good to get 495 more results from other places. 497 These test results should be verified by another group. This has not 498 been done yet. 500 This draft should be moved to be consistent with the classification 501 in [6]. 503 9. Acknowledgments 505 Many people and several mailing lists have contributed to the 506 material on understanding NATs in this document. Many thanks to 507 Larry Metzger, Dan Wing, and Rohan Mahy. The STUN server and client 508 is open source and available at http://sourceforge.net/projects/stun, 509 and thank you to Jason Fischl who runs the public STUN server at 510 larry.gloo.net. Thanks to Yutaka Takeda who tested and found bugs 511 and Christian Stredicke for getting people thinking. Thanks to 512 Francois Audet for catching mistakes, verifying several results, and 513 finding the very strange non-deterministic nature in the BEFSR81. 515 The work of the various people on STUN Client and Server [7], NATCECK 516 [8], and STUNT [9] has greatly helped this work. 518 10. References 520 10.1. Normative References 522 [1] Rosenberg, J., "Simple Traversal of UDP Through Network Address 523 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-02 (work 524 in progress), July 2005. 526 [2] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - 527 Simple Traversal of User Datagram Protocol (UDP) Through Network 528 Address Translators (NATs)", RFC 3489, March 2003. 530 10.2. Informative References 532 [3] Wing, D., "IGMP Proxy Behavior", draft-ietf-behave-multicast-07 533 (work in progress). 535 [4] Ford, B. and D. Andersen, "Nat Check Results 536 http://bgp.lcs.mit.edu/~dga/view.cgi", February 2005. 538 [5] Guha, S. and P. Francis, "STUNT Results 539 http://www.guha.cc/saikat/stunt-results.php", February 2005. 541 [6] Audet, F. and C. Jennings, "Network Address Translation (NAT) 542 Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, 543 January 2007. 545 [7] Jennings, C., "STUN Client and Server: 546 http://www.vovida.org/applications/downloads/stun", 547 February 2005. 549 [8] Ford, B. and D. Andersen, "Nat Check 550 http://midcom-p2p.sourceforge.net", February 2005. 552 [9] Guha, S. and P. Francis, "STUNT 553 http://nutss.gforge.cis.cornell.edu/stunt.php", February 2005. 555 Author's Address 557 Cullen Jennings 558 Cisco Systems 559 170 West Tasman Drive 560 Mailstop SJC-21/2 561 San Jose, CA 95134 562 USA 564 Phone: +1 408 421 9990 565 Email: fluffy-ietf1@iii.ca 567 Full Copyright Statement 569 Copyright (C) The IETF Trust (2007). 571 This document is subject to the rights, licenses and restrictions 572 contained in BCP 78, and except as set forth therein, the authors 573 retain all their rights. 575 This document and the information contained herein are provided on an 576 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 577 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 578 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 579 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 580 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 581 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 583 Intellectual Property 585 The IETF takes no position regarding the validity or scope of any 586 Intellectual Property Rights or other rights that might be claimed to 587 pertain to the implementation or use of the technology described in 588 this document or the extent to which any license under such rights 589 might or might not be available; nor does it represent that it has 590 made any independent effort to identify any such rights. Information 591 on the procedures with respect to rights in RFC documents can be 592 found in BCP 78 and BCP 79. 594 Copies of IPR disclosures made to the IETF Secretariat and any 595 assurances of licenses to be made available, or the result of an 596 attempt made to obtain a general license or permission for the use of 597 such proprietary rights by implementers or users of this 598 specification can be obtained from the IETF on-line IPR repository at 599 http://www.ietf.org/ipr. 601 The IETF invites any interested party to bring to its attention any 602 copyrights, patents or patent applications, or other proprietary 603 rights that may cover technology that may be required to implement 604 this standard. Please address the information to the IETF at 605 ietf-ipr@ietf.org. 607 Acknowledgment 609 Funding for the RFC Editor function is provided by the IETF 610 Administrative Support Activity (IASA).