idnits 2.17.1 draft-sivakumar-behave-nat-tcp-req-01.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.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 592. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 582. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. == 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 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 abstract seems to contain references ([BEH-UDP], [BEH-GEN]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 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 (March 28, 2005) is 6940 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) == Unused Reference: 'ASND' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'ICMP' is defined on line 501, but no explicit reference was found in the text == Unused Reference: 'NAT-CMPL' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'NAT-CHK' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'V4-REQ' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'UNSAF' is defined on line 514, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 2663 ** Downref: Normative reference to an Informational RFC: RFC 3022 -- Possible downref: Normative reference to a draft: ref. 'BEH-GEN' -- Obsolete informational reference (is this intentional?): RFC 923 (ref. 'ASND') (Obsoleted by RFC 943) Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave Working Group P. Srisuresh 3 Internet-Draft Caymas Systems, Inc. 4 Expires: September 28, 2005 S. Sivakumar 5 K. Biswas 6 Cisco Systems, Inc. 7 B. Ford 8 M.I.T. 9 March 28, 2005 11 NAT Behavioral Requirements for TCP 12 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on August 1, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 NAT devices are available from a number of vendors and are in use by 49 several residential and enterprise users. Yet, there is much 50 variation in how the NAT devices work. Application developers, 51 network administrators and users of NAT devices seek some level of 52 uniformity and predictability in how various of the NAT devices 53 operate. The objective of this document is to specify the 54 operational and behavioral requirements on the NAT devices while 55 processing TCP packets. A NAT device that conforms to the 56 requirements listed in the document will bring predictability in 57 how NATs operate with regard to TCP packet processing. A NAT device 58 is said to be IETF behave compliant when it complies with the 59 requirements outlined in this document and two other companion 60 documents ([BEH-GEN], [BEH-UDP]) which outline the requirements 61 for processing IP, ICMP & UDP. 63 Table of Contents 65 1. Introduction & Scope . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. TCP requirements discussion . . . . . . . . . . . . . . . . . 3 68 3.1 Address Binding and/or TCP Port Binding . . . . . . . . . 3 69 3.2 Timeouts for TCP Sessions . . . . . . . . . . . . . . . . 4 70 3.3 SYN packets during Connecting and Closing phases . . . . . 5 71 3.4 Denial of Service (DoS) attacks . . . . . . . . . . . . . 5 72 3.5 NAT initiated TCP keep-alives . . . . . . . . . . . . . . 6 73 3.6 NAT initiated RST packets . . . . . . . . . . . . . . . 7 74 4. Hints to implementers . . . . . . . . . . . . . . . . . . . . 7 75 4.1 Light weight TCP state machine is a common practice . . . 7 76 4.2 TCP segment processing in NATs supporting ALGs . . . . . . 8 77 4.3 Adjusting Sequence and Acknowledgement Numbers . . . . . . 9 78 5. TCP behavioral requirements summary . . . . . . . . . . . . . 10 79 6. Security considerations . . . . . . . . . . . . . . . . . . . 10 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 83 8.2 Informative References . . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 85 Intellectual Property and Copyright Statements . . . . . . . . . . 13 87 1. Introduction & Scope 89 NAT implementations vary amongst vendors in how they handle TCP 90 packets. This document defines the operational and behavioral 91 requirements that the NAT devices should comply with while 92 processing TCP packets. In addition, a section is devoted to 93 describing hints to implementers in deciphering some of the 94 requirements. 96 The requirements outlined here are applicable across all NAT types 97 identified in [RFC2663], most importantly the Traditional Nat, as 98 described in [RFC3022]. This document does not mandate a specific 99 implementation choice. However, this does require NAT devices to 100 adhere to the basic design principles and general behavioral 101 requirements outlined in [BEH-GEN]. Behavioral requirements for UDP 102 are covered in [BEH-UDP]. 104 Application Layer Gateways (ALGs) are out of scope for this 105 document. However, hints on how a NAT could be extended to support 106 ALGs are discussed under the hints section. 108 2. Terminology 110 Definitions for the NAT terms used throughout the document may be 111 found in [BEH-GEN] and/or [RFC2663]. TCP terms used in the document 112 are as per the definitions given in [TCP]. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. TCP requirements discussion 120 This section lists the behavioral requirements of a NAT device 121 when processing TCP packets. Associated with each requirement, the 122 rationale behind the requirement is discussed in detail. 124 3.1 Address Binding and/or TCP Port Binding 126 NAT provides transparent routing between address realms by 127 assigning realm-specific endpoint locator(s), as packets pertaining 128 to a session cross realm boundaries. Several applications use the 129 same endpoint within a realm to establish multiple simultaneous 130 sessions. Many peer-to-peer applications use the public endpoint 131 registration of peering hosts to initiate sessions into. 133 In order to support peer-to-peer applications and applications 134 that entertain multiple simultaneous session using the same TCP 135 endpoint, NAT MUST retain the association it assigned to an endpoint 136 between realms and reuse the same endpoint association when 137 multiple sessions using the same endpoint are routed through the 138 NAT device. Such a binding between endpoints can occur when a NAT 139 device maintains Address Bindings and/or TCP Port Bindings. 141 REQ-1: A NAT device MUST maintain Address and/or TCP Port 142 Bindings. 144 3.2 Timeouts for TCP NAT Sessions 146 As may be noted from [TCP], an end-to-end TCP session in its 147 lifetime goes through three phases, namely Connecting, Established, 148 and Closing. Each end-to-end TCP session is managed through a 149 separate NAT Session within NAT. The NAT Session must be capable of 150 identifying the current phase of the end-to-end TCP session it 151 represents and use an idle timeout period that is appropriate for 152 the current phase. 154 Connecting Phase: An end-to-end TCP session is said to enter the 155 Connecting Phase when either of the endpoints sends the first SYN 156 for the TCP session and exit the phase upon completion of 3-way SYN 157 handshake. The idle timeout used by the NAT Session during this 158 phase is called the SYN timeout. SYN timeout needs to be relatively 159 short, so NAT can protect itself (and, potentially, the hosts behind 160 it) from SYN flood attacks. A NAT session is freed when the SYN 161 timeout expires. 163 Established Phase: An end-to-end TCP session is said to enter the 164 Established Phase upon completion of 3-way handshake and exit the 165 phase upon seeing the first FIN or RST for the session. The idle 166 timeout used by the NAT during this phase of the end-to-end TCP 167 session is called the Session timeout. Session timeout needs to be 168 relatively long, so the NAT Session can retain state of the 169 end-to-end TCP Session within itself even after long periods of 170 inactivity in the session. Long periods of inactivity is not 171 uncommon with applications such as telnet and ftp. When Session 172 timer expires, the corresponding NAT Session may be freed (or) the 173 NAT Session may assume the TCP connection to have transitioned 174 into the Closing phase. 176 Closing Phase: An end-to-end TCP session is said to enter the 177 Closing Phase when either of the endpoitns sends the first FIN 178 or RST for the session. Alternately, the NAT Session may deem the 179 TCP session to have entered this phase when the TCP Session timer 180 expires. The idle timeout used by the NAT Session during this phase 181 is called the Close timeout. Close timeout is relatively short to 182 ensure that the ACKs for the final FINs on a gracefully-closed TCP 183 session had a chance to propagate in both directions, and to allow 184 time for either endpoint to re-open a recently closed or reset TCP 185 session if desired. A NAT device MAY opt to have different Close 186 timeouts depending upon whether the Closing phase is triggered by 187 FIN or not. Once the Close timer expires, the NAT Session will be 188 freed. 190 The following requirements apply to the NAT's timeouts: 192 REQ-2: A NAT device MUST be capable of identifying the current phase 193 of an end-to-end TCP session and use different idle timeout periods 194 for each phase of the TCP Session. The timeouts used for each phase 195 SHOULD be admin configurable. The recommended value for SYN timeout 196 is 30 seconds. The recommended value for TCP session timeout is 30 197 minutes. Lastly, the recommended value for close timeout is 2 x MSL 198 (Maximum Segment Lifetime) or 4 minutes. 200 3.3 SYN packets during Connecting and Closing phases 202 A NAT device might allow sessions to be initiated in just one 203 direction and not the other. However, once a NAT session is created 204 for a permitted TCP session, and the TCP session is in Connecting 205 phase, the NAT device MUST let the SYN packets through in either 206 direction. Likewise, if the TCP session is in Closing phase and a 207 new SYN packet arrives from either endpoint before the close 208 timer expires, the NAT device should assume that the TCP session 209 has re-entered the Connecting phase and initiate SYN timer as 210 described above. 212 This is because TCP protocol fundamentally permits simultaneous TCP 213 Open from either end. A number of TCP based Peer-to-peer 214 applications utilize the simultaneous TCP open technique to 215 establish peer to peer connections. 217 The following requirement applies to SYN packets arriving during 218 Connecting and Closing phases of a TCP connection. 220 REQ-3: A NAT device MUST let the SYN packets through when the SYN 221 Packets are received on a TCP connection which is in one of 222 Connecting or Closing phase. 224 3.4 Denial of Service (DoS) attacks 226 Since NAT devices are Internet hosts, they can be the target of a 227 number of different DoS attacks, such as SYN floods and RST attacks. 228 NAT devices SHOULD employ the same sort of protection techniques as 229 Internet-based servers do. 231 Let us examine two types of Dos attacks that are well known with 232 regard to TCP connections. A SYN flood attack is a DoS attack in 233 which one or more external entities initiate a number of 234 simultaneous TCP connections using a SYN packet, but donot complete 235 the 3-way handshake. Naturally, a NAT device is prone to this type 236 of attack when the NAT device is in the traversal path of the SYN 237 attacks. One technique to defend against this type of attack is to 238 ensure that the NAT device employs a short SYN timeout and reduce 239 the timeout even further when it determines it is under SYN flood 240 attack. 242 RST attack is another well known DoS attack. An attacker could 243 simply forge a number of RST packets for a variety of Established 244 TCP connections and cause the NAT sessions to be reset and freed. 245 One technique to defend against this type of attack is to validate 246 the RST packet and not let the packet through unless the sequence 247 number used in the RST packet is within the expected TCP window 248 size of the TCP Session. 250 REQ-4: A NAT device SHOULD employ necessary techniques to defend 251 against well known DoS attacks. 253 3.5 NAT initiated TCP keep-alives 255 When session timer expires for a NAT session, that indicates that the 256 associated TCP session has been idle with no activity for the period 257 matching the TCP Session timeout. Sensing no activity, NAT could free 258 up the NAT Session and remove the state associated with the TCP 259 connection within the NAT device. However, doing so would violate the 260 end-to-end reliability of the IP network. Ideally speaking, IP 261 network is not supposed to retain any hard state. Unfortunately, a 262 NAT device retains session state within itself (via the NAT Sessions) 263 and this information should not be dropped without confirming that 264 one or both halfs of the TCP session are alive. 266 A NAT device may validate the liveness of a TCP client by sending 267 keep-alive packets to the TCP client using the technique described 268 in section 4.2.3.6 of [HOST]. If the NAT device receives an ACK or 269 other traffic from the internal endpoint, it resets the session 270 timer and assumes the connection to be in �Established" phase. If 271 the NAT device receives a RST from the TCP client, the NAT device 272 transitions the TCP connection into the "closing" phase and 273 initiates Close timeout for the session. If the NAT device receives 274 no response from the internal endpoint after sending several 275 keep-alive packets, the NAT assumes that the internal endpoint is 276 dead and again assumes that the TCP connection has entered the 277 "closing" phase. 279 Below is the keep-alive requirement on NAT devices 281 REQ-5: When session timer expires for an established TCP connection, 282 the NAT device MAY initiate sending TCP keep-alives to the clients 283 prior to freeing up the Session state within NAT. 285 3.6. NAT initiated RST packets 287 When session timer expires for a NAT session, it is an indication 288 that the associated TCP connection has been idle with no activity 289 for the duration matching the TCP Session timeout. Sensing no 290 activity, NAT could free up the NAT Session and remove the state 291 associated with the TCP connection. When this happens, the two TCP 292 endpoints in the network, which might potentially be alive, may be 293 unable to resume activity on the connection because the NAT device 294 enroute no longer has the state information pertaining to the 295 end-to-end TCP connection. This can be problematic for application 296 servers that impose limits on the number of connections a user 297 might be allowed to setup in a given period of time. After a few 298 zombie sessions, the server might deny access to its clients, when 299 the connection count on the server exceeds the set limit. The Server 300 has no way to know that some of the client sessions it retains are 301 zombies and shouldnt be counted as real. In such a situation, the 302 NAT device sending a RST packet to both parties will alert the two 303 parties of the connection going away. And, the application servers 304 are not fooled with zombie sessions. Note, a NAT device may choose 305 to send RST packets after it probed the TCP client with TCP 306 Keep-alive packets. 308 Below is the requirement on sending TCP RST packet. 310 REQ-6: When Session timer expires on an Established TCP connection, 311 the NAT device SHOULD send a RST packet to both halfs of a TCP 312 connection and enter Closing state on the connection prior to 313 freeing up the NAT Session. 315 4. Hints to implementers 317 4.1 Light weight TCP state machine is a common practice 319 Unlike UDP, TCP sessions are fundamentally unicast in nature and 320 multiple NAT Sessions cannot be aggregated. NAT devices maintain a 321 separate NAT Session to track each end-to-end TCP connection that 322 traverses the NAT device. A NAT device needs to be able to track the 323 current phase of a TCP session at any given time so an idle timer 324 for a duration appropriate for the phase is initiated. Further, a 325 NAT device defending against even the most trivial type of DoS 326 attack will require the knowledge of TCP sequence number and window 327 Size to defend itself against such attacks. As such, many vendors 328 use a light-weight state machine within the NAT Session to 329 track the current state of a TCP connection. Items tracked 330 within the state machine would include the last acknowledged 331 sequence number from either half of the TCP session, TCP window 332 size, and the TCP connection phase. 334 The State machine within a NAT Session enters the Connecting state 335 when NAT sees the first SYN packet for that session. The state 336 machine transitions from the Connecting to Established state once 337 the 3-way handshake is completed. The state machine transitions from 338 the Established state to the Closing state when the NAT observes a 339 FIN/FIN ACK sequence, representing graceful shutdown reached 340 cooperatively by both endpoints, or when the NAT observes a RST 341 from either endpoint, representing a non-graceful connection reset 342 forced by one endpoint. The NAT device deletes the NAT session after 343 the Close timer expires while the TCP connection is in the Closing 344 state. 346 In addition to this basic state information, many NATs also record 347 information about the TCP sequence numbers and the acknowledgment 348 numbers they observe in the TCP packets flowing across the NAT. If 349 the NAT contains built-in ALGs that can change the payload length of 350 TCP packets, effectively inserting or removing bytes from the TCP 351 stream in one or both directions, then the NAT MUST adjust the 352 sequence numbers in all subsequent packets exchanged in either 353 direction to reflect these inserted or removed bytes. 355 4.2 TCP segment processing in NATs supporting ALGs 357 The following discussion on TCP segment processing is relevant only 358 when a NAT device includes support for one or more embedded ALGs. 359 Many NAT devices have the ALG for FTP enabled by default. 360 A NAT device may receive payload relevant to an ALG in multiple TCP 361 segments. Consider the following diagram where the MSS is set to 362 536 bytes in each endpoint of the TCP connection. 364 +-------------------+ +-------------------+ 365 | Application-Layer | | Application-Layer | 366 +-------------------+ +-------------------+ 367 | TCP [MSS = 536] | | TCP [MSS = 536] | 368 +-------------------+ +-------------------+ 369 | IP | | IP | 370 +-------------------+ +-------------------+ 371 | Lower-Layer | | Lower-Layer | 372 | (MTU = 1500 | | (MTU = 1500 | 373 +-------------------+ +-------------------+ 374 End-host-1 End-host-2 375 | +--------+ | 376 +-------------------| NAT |----------------+ 377 +--------+ 379 Say the application layer on end-host-1 is sending a payload of size 380 600 bytes. Even though the MTU is 1500 bytes, the payload is sent to 381 the recipient in 2 TCP segments as follows, because the MSS is set 382 to 536 bytes. 384 TCP Segment 1: 385 +-------+------------------------+----------+ 386 |IP hdr |TCP hdr[Payload-Len=536]|Appl-data1| 387 +-------+------------------------+----------+ 389 TCP Segment 2: 390 +-------+------------------------+----------+ 391 |IP hdr |TCP hdr[Payload-Len=64] |Appl-data2| 392 +-------+------------------------+----------+ 394 A NAT device enroute may receive the TCP segments either in order or 395 out of order. In either case, the NAT device needs to assemble the 396 individual segments into a contiguous payload and make the complete 397 payload available for the ALG to process prior to forwarding the 398 segments transparently to another realm. 400 In order to do this, a NAT device is required to enforce some type 401 of queuing mechanism such that when all relevant segments of a 402 payload are received, it is able to reassemble the TCP segments and 403 make the contiguous payload available for ALG processing. 405 For in-order segments, the NAT device needs to send a TCP ACK for 406 the initial segments it received, but didnt forward to the recipient 407 enpoint. This is done so the NAT device can prompt the sending 408 endpoint to continue to send the remaining TCP segments. 410 4.3 Adjusting Sequence and Acknowledgement Numbers 412 The following discussion on adjusting Sequence and Acknowledgement 413 numbers is relevant only when a NAT device includes support for one 414 or more embedded ALGs. 416 When the embedded ALG on a NAT device modifies the TCP payload, the 417 corresponding payload may increase or decrease in size. As a 418 result, the NAT device is expected to remember the delta change and 419 adjust sequence/acknowledgement numbers in all subsequent TCP 420 packets within the session. Implementors of NAT devices often keep 421 the delta changes in payload due to ALG processing within the NAT 422 Session as an extension of the state information the NAT device 423 keeps. 425 5. TCP behavioral requirements summary 427 Below is a summary of all the TCP behavioral requirements. 429 REQ-1: A NAT device MUST maintain Address and/or TCP Port 430 Bindings. 432 REQ-2: A NAT device MUST be capable of identifying the current phase 433 of an end-to-end TCP session and use different idle timeout periods 434 for each phase of the TCP Session. 436 The timeouts used for each phase SHOULD be admin configurable. The 437 recommended value for SYN timeout is 30 seconds. The recommended 438 value for TCP session timeout is 30 minutes. Lastly, the 439 recommended value for close timeout is 2 x MSL (Maximum Segment 440 Lifetime) or 4 minutes. 442 REQ-3: A NAT device MUST let the SYN packets through when the SYN 443 Packets are received on a TCP connection which is in one of 444 Connecting or Closing phase. 446 REQ-4: A NAT device SHOULD employ necessary techniques to defend 447 against well known DoS attacks. 449 REQ-5: When session timer expires for an Established TCP connection, 450 the NAT device MAY initiate sending TCP keep-alives to the clients 451 prior to freeing up the Session state within NAT. 453 REQ-6: When session timer expires for an Established TCP connection, 454 the NAT device SHOULD send a RST packet to both halfs of a TCP 455 connection and enter Closing state on the connection prior to freeing 456 Up the NAT Session. 458 6. Security considerations 460 The security considerations described in [RFC2663] for all 461 variations of NATs are applicable here. The recommendations and 462 requirements in this document do not effect the security 463 properties of the NAT devices adversely. 465 7. Acknowledgements 467 The authors would like to thank Nagendra Modadugu and Cullen 468 Jennings for their feedback and comments. 470 8. References 472 8.1 Normative References 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", RFC 2119, BCP 14, March 1997. 477 [TCP] Postel, J., "Transmission Control Protocol (TCP) 478 Specification", STD 7, RFC 793, September 1981. 480 [HOST] Braden, R., "Requirements for Internet Hosts -- 481 Communication Layers", RFC 1122, October 1989. 483 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 484 Translator (NAT) Terminology and Considerations", 485 RFC 2663, August 1999. 487 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 488 Address Translator (Traditional NAT)", RFC 3022, January 489 2001. 491 [BEH-GEN] Ford, B., Srisuresh, P., and S. Sivakumar, �Design 492 Principles and General Behavioral Requirements for 493 NATs�, draft-ford-behave-gen-01.txt (work in progress), 494 March 2005. 496 8.2 Informative References 498 [ASND] Reynolds, J. and J. Postel, "Assigned numbers", RFC 923, 499 October 1984. 501 [ICMP] Postel, J., "Internet Control Message Protocol", RFC 792, 502 September 1981. 504 [NAT-CMPL] Holdrege, M. and P. Srisuresh, "Protocol Complications 505 with the IP Network Address Translator", RFC 3027, 506 January 2001. 508 [NAT-CHK] Ford, B. and D. Andersen, "Nat Check Web Site: 509 http://midcom-p2p.sourceforge.net", June 2004. 511 [V4-REQ] Baker, F., "Requirements for IP Version 4 Routers", 512 RFC 1812, June 1995. 514 [UNSAF] Daigle, L. and IAB, "IAB Considerations for Unilateral 515 Self-Address Fixing (UNSAF) Across Network Address 516 Translation", RFC 3424, November 2002. 518 [BEH-UDP] Audet, F. and C. Jennings, "NAT Behavioral Requirements 519 for Unicast UDP�, draft-ietf-behave-nat-00.txt (work 520 in progress), January 2005. 522 Authors' Addresses: 524 Pyda Srisuresh 525 Caymas Systems, Inc. 526 1179-A North McDowell Blvd. 527 Petaluma, CA 94954 528 USA 530 Phone: (707) 283-5063 531 E-mail: srisuresh@yahoo.com 533 Senthil Sivakumar 534 Cisco Systems, Inc. 535 170 West Tasman Dr. 536 San Jose, CA 95134 537 USA 538 Phone: 539 Email: ssenthil@cisco.com 541 Kaushik Biswas 542 Cisco Systems, Inc. 543 170 West Tasman Dr. 544 San Jose, CA 95134 545 USA 547 Phone: +1 408 525 5134 548 Email: kbiswas@cisco.com 550 Bryan Ford 551 M.I.T. 552 Laboratory for Computer Science 553 77 Massachusetts Ave. 554 Cambridge, MA 02139 555 USA 557 Phone: 1-617-253-5261 558 Email: baford@mit.edu 560 Intellectual Property Statement 562 The IETF takes no position regarding the validity or scope of any 563 Intellectual Property Rights or other rights that might be claimed to 564 pertain to the implementation or use of the technology described in 565 this document or the extent to which any license under such rights 566 might or might not be available; nor does it represent that it has 567 made any independent effort to identify any such rights. Information 568 on the procedures with respect to rights in RFC documents can be 569 found in BCP 78 and BCP 79. 571 Copies of IPR disclosures made to the IETF Secretariat and any 572 assurances of licenses to be made available, or the result of an 573 attempt made to obtain a general license or permission for the use of 574 such proprietary rights by implementers or users of this 575 specification can be obtained from the IETF on-line IPR repository at 576 http://www.ietf.org/ipr. 578 The IETF invites any interested party to bring to its attention any 579 copyrights, patents or patent applications, or other proprietary 580 rights that may cover technology that may be required to implement 581 this standard. Please address the information to the IETF at 582 ietf-ipr@ietf.org. 584 Disclaimer of Validity 586 This document and the information contained herein are provided on an 587 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 588 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 589 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 590 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 591 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 592 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 594 Copyright Statement 596 Copyright (C) The Internet Society (2005). This document is subject 597 to the rights, licenses and restrictions contained in BCP 78, and 598 except as set forth therein, the authors retain all their rights. 600 Acknowledgment 602 Funding for the RFC Editor function is currently provided by the 603 Internet Society.