idnits 2.17.00 (12 Aug 2021) /tmp/idnits53438/draft-ietf-behave-nat-icmp-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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1066. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1037. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1044. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1050. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Setting the ICMP NAT session timeout to a very large duration (say, 240 seconds) could potentially tie up precious NAT resources such as query mappings and NAT Sessions for the whole duration. On the other hand, setting the timeout very low can result in premature freeing of NAT resources and applications failing to complete gracefully. The ICMP Query session timeout needs to be a balance between the two extremes. 60 seconds timeout is a balance between the two extremes. ICMP query session timer MUST not expire in less than 60 seconds. We RECOMMEND however that the administrator(s) be allowed to configure the timer. -- 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 (June 30, 2007) is 5438 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4008 (ref. 'NAT-MIB') (Obsoleted by RFC 7658) == Outdated reference: draft-ietf-behave-tcp has been published as RFC 5382 == Outdated reference: draft-ietf-tcpm-icmp-attacks has been published as RFC 5927 == Outdated reference: draft-ietf-tcpm-tcp-soft-errors has been published as RFC 5461 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Intended Status: Best Current Practice 3 BEHAVE WG P. Srisuresh 4 Internet Draft Kazeon Systems 5 Expires: December 30, 2007 B. Ford 6 M.I.T. 7 S. Sivakumar 8 Cisco Systems 9 S. Guha 10 Cornell U. 11 June 30, 2007 13 NAT Behavioral Requirements for ICMP protocol 14 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document specifies the behavioral properties required of the 42 Network Address Translator (NAT) devices in conjunction with the 43 ICMP protocol. The objective of this memo is to make NAT devices 44 more predictable and compatible with diverse application protocols 45 that traverse the devices. Companion documents provide behavioral 46 recommendations specific to TCP, UDP and other protocols. 48 Table of Contents 50 1. Introduction and Scope ....................................... 51 2. Terminology .................................................. 52 3. ICMP Query Handling .......................................... 53 3.1. ICMP Query Mapping ...................................... 54 3.2. ICMP Query Session Timeouts ............................. 55 4. ICMP Error Forwarding ........................................ 56 4.1. ICMP Error Payload Validation ........................... 57 4.2. ICMP Error Packet Translation ........................... 58 4.2.1. ICMP Error Packet Received from External Realm .... 59 4.2.2. ICMP Error Packet Received from Private Realm ..... 60 4.3. NAT Sessions Pertaining to ICMP Error Payload ........... 61 5. Hairpinning Support for ICMP packets ......................... 62 6. Rejection of Outbound Flows Disallowed by NAT ................ 63 7. Conformance to RFC 1812 ...................................... 64 7.1. IP packet fragmentation ................................. 65 7.1.1. Generating "Packet too Big" ICMP error Message .... 66 7.1.2. Forwarding "Packet too big" ICMP Error Message .... 67 7.2. Generating "Time Exceeded" Error Message ................ 68 7.3. RFC 1812 Conformance Requirements summary ............... 69 8. Summary of Requirements ...................................... 70 9. Security Considerations ...................................... 71 10. IANA Considerations .......................................... 72 11. Acknowledgements ............................................. 74 1. Introduction and Scope 76 As pointed out in RFC 3424 [UNSAF], NAT implementations vary 77 widely in terms of how they handle different traffic. The purpose 78 of this document is to define a specific set of requirements for NAT 79 behavior with regard to ICMP messages. The objective is to reduce 80 the unpredictability and brittleness the NAT devices (NATs) 81 introduce. This document is an adjunct to [BEH-UDP], [BEH-TCP], and 82 other protocol-specific BEHAVE document(s) in the future which 83 define requirements for NATs when handling protocol-specific 84 traffic. 86 The requirements of this specification apply to Traditional NATs as 87 described in [NAT-TRAD]. Traditional NAT has two variations, namely, 88 Basic NAT and Network Address Port Translator (NAPT). Of these, NAPT 89 is by far the most commonly deployed NAT device. NAPT allows 90 multiple private hosts to share a single public IP address 91 simultaneously. 93 This document only covers the ICMP aspects of NAT traversal, 94 specifically the traversal of ICMP Query Messages and ICMP Error 95 messages. Traditional NAT inherently mandates a certain level 96 of firewall-like functionality. However, firewall functionality in 97 general or any other middlebox functionality is out of the 98 scope of this document. 100 In some cases, ICMP Message traversal behavior on a NAT device may 101 be overridden by local administrative policies. Some administrators 102 may choose to entirely prohibit forwarding of ICMP error messages 103 across a NAT device. Some others may choose to prohibit ICMP query 104 based applications across a NAT device. These are local policies 105 and not within the scope of this document. For this reason, some 106 of the ICMP behave requirements listed in the document are preceded 107 with a constraint of local policy permitting. 109 This document focuses strictly on the behavior of the NAT device, 110 and not on the behavior of applications that traverse NATs. A 111 separate document [BEH-APP] provides recommendations for application 112 designers on how to make applications work robustly over NATs that 113 follow the behavioral requirements specified here and the adjunct 114 BEHAVE documents. 116 Per [RFC1812], ICMP is a control protocol that is considered to be 117 an integral part of IP, although it is architecturally layered upon 118 IP - it uses IP to carry its data end-to-end. As such, many of the 119 ICMP behavioral requirements discussed in this document apply to all 120 IP protocols. 122 In case a requirement in this document conflicts with 123 protocol-specific BEHAVE requirement(s), protocol specific BEHAVE 124 documents will take precedence. The authors are not aware of any 125 conflicts between this and any other IETF document at the time of 126 this writing. 128 Section 2 describes the terminology used throughout the document. 129 Sections 3 is focused on requirements concerning ICMP query based 130 applications traversing a NAT device. Sections 4 and 5 describe 131 requirements concerning ICMP error messages traversing a NAT 132 device. Sections 6 and 7 describe requirements concerning ICMP error 133 messages generated by a NAT device. Section 8 summarizes all the 134 requirements in one place. Section 9 has a discussion on security 135 considerations. 137 2. Terminology 139 Definitions for majority of the NAT terms used throughout the 140 document may be found in [NAT-TERM] and [BEH-UDP]. The term 141 "NAT Session" is adapted from [NAT-MIB] and denotes the entity 142 within a NAT device that represents the translation glue for a 143 session traversing the NAT device. 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [RFC2119]. 149 Section 3.2.2 of [RFC1122] broadly groups ICMP messages into two 150 classes, namely "ICMP Query" messages and "ICMP Error" messages. 151 In addition, there are ICMP messages, created after [RFC1122] that 152 do not fall under either category. We refer them as "Post-1122 ICMP 153 Messages". All three ICMP message classes are described as follows. 155 ICMP Query Messages - ICMP query messages are characterized by an 156 Identifier field in the ICMP header. The Identifier field used 157 by the ICMP Query messages is also referred as "Query Identifier" or 158 "Query Id", for short throughout the document. A Query Id is used by 159 query senders and responders as the equivalent of a TCP/UDP port to 160 identify an ICMP Query session. 162 ICMP Error Messages - ICMP error messages provide signaling for IP. 163 All ICMP error messages are characterized by the fact that they 164 embed the original datagram that triggered the ICMP error message. 165 The original datagram embedded within the ICMP Error payload is 166 also referred as "Embedded packet", throughout the document. Unlike 167 ICMP Query messages, ICMP error messages do not have a Query Id in 168 the ICMP header. 170 Post-1122 ICMP Messages - ICMP messages that do not fall under 171 either of the above two classes are referred as "Post-1122 ICMP 172 Messages" throughout the document. For example, discovery ICMP 173 messages ([RFC1256]) are "request/response" type ICMP messages. 174 However, they are not characterized as ICMP Query Messages as they 175 do not have an "Identifier" field within the messages. Likewise, 176 there are other ICMP messages defined in [RFC4065] that do not 177 fall in either of ICMP Query or ICMP Error message categories, but 178 will be referred as Post-1122 ICMP error messages. A NAT MAY drop 179 or appropriately handle a post-1122 ICMP messages. 181 3. ICMP Query Handling 183 This section lists the behavioral requirements for a NAT device 184 when processing ICMP Query packets. The following sub sections 185 discuss requirements specific to ICMP Query handling in detail. 187 3.1. ICMP Query Mapping 188 A NAT device MUST permit ICMP query based applications to be 189 initiated from private hosts to the external hosts. ICMP Query 190 mapping by NAT devices is necessary for current ICMP query based 191 applications to work. Specifically, a NAT device MUST transparently 192 forward any ICMP Query packets initiated from the nodes behind NAT 193 devices and the responses to these Query packets in the opposite 194 direction. As specified in [NAT-TRAD], this requires translating the 195 IP header. A NAPT device further translates the ICMP Query Id and 196 the associated checksum in the ICMP header prior to forwarding. 198 The mapping of ICMP Query identifier within the NAT device SHOULD 199 be external endpoint independent. Say, an internal host A sent an 200 ICMP query out to an external host B using Query Id X. And, say, 201 the NAT assigned this an external mapping of Query id X' on the 202 NAT's public address. If host A reused the Query Id X to send ICMP 203 queries to the same or different external host, the NAT device 204 SHOULD reuse the same Query Id mapping (i.e., map private host's 205 Query id X to Query id X' on NAT's public IP address) instead of 206 assigning a different mapping. This is similar to the "endpoint 207 independent mapping" requirement specified in the TCP and UDP 208 BEHAVE requirements [BEH-TCP, BEH-UDP]. 210 Below is justification for making the endpoint independent mapping 211 for ICMP query IDs a SHOULD [RFC2119] requirement. ICMP Ping 212 ([RFC1470]) and ICMP traceroute ([MS-TRCRT]) are two most commonly 213 known legacy applications built on top of ICMP query messages. 214 Neither of these applications require the ICMP Query Id to be 215 retained across different sessions with external hosts. But, that 216 may not be case with future applications. In the future, when an 217 end host application reuses the same Query identifier in sessions 218 with different target hosts, the end host application might require 219 that the endpoint identity (i.e., the tuple of IP address and Query 220 Identifier) appears the same across all its target hosts. Such a 221 requirement will be valid to make in an IP network without NAT 222 devices. When NAT devices enforce endpoint mapping that is external 223 host independent, the above assumption will be valid to make even in 224 a world with NAT devices. Given the dichotomy between legacy 225 applications not requiring endpoint independent mapping and future 226 applications that might require it, the requirement level is kept 227 at SHOULD [RFC2119]. 229 REQ-1: When local policy permits, a NAT device MUST permit ICMP 230 queries and their associated responses, when the query is initiated 231 from a private host. 232 a) NAT mapping of ICMP Query identifiers SHOULD be external host 233 independent. 235 3.2. ICMP Query Session Timeouts 237 When an application initiates an ICMP query that transits a NAT 238 device, the NAT associates a timer to the ICMP query NAT session. 239 This is so the ICMP query NAT session is freed up if the NAT session 240 remains idle for longer than the timeout set by the timer. Query 241 response times can vary. ICMP query based application are primarily 242 request/response driven. The ICMP Query session timeout requirement 243 is necessary for current ICMP query applications to work. 245 Ideally, the timeout should be set to Maximum Round Trip Time 246 (Maximum RTT). For the purposes of constraining the maximum RTT, the 247 Maximum Segment Lifetime (MSL), defined in [RFC793] could be 248 considered a guideline to set packet lifetime. Per [RFC793], MSL is 249 the maximum amount of time a TCP segment can exist in a network 250 before being delivered to the intended recipient. This is the maximum 251 duration an IP packet can be assumed to take to reach the intended 252 destination node before declaring that the packet will no longer be 253 delivered. For an application initiating ICMP query message and 254 waiting for a response for the query, the Maximum RTT could in 255 practice be constrained to be sum total of MSL for the Query message 256 and MSL for the response message. In other words, Maximum RTT could 257 be constrained to no more than 2x MSL. The recommended value for MSL 258 in [RFC793] is 120 seconds, even though several implementations set 259 this to 60 seconds or 30 seconds. When MSL is 120 seconds, the 260 Maximum RTT (2x MSL) would be 240 seconds. 262 In practice, ICMP Ping ([RFC1470]) and ICMP traceroute ([MS-TRCRT]), 263 the two most commonly known legacy applications built on top of ICMP 264 query messages take less than 10 seconds to complete a round trip, 265 when the target node is operational on the network. 267 Setting the ICMP NAT session timeout to a very large duration (say, 268 240 seconds) could potentially tie up precious NAT resources such as 269 query mappings and NAT Sessions for the whole duration. On the other 270 hand, setting the timeout very low can result in premature freeing 271 of NAT resources and applications failing to complete gracefully. 272 The ICMP Query session timeout needs to be a balance between the two 273 extremes. 60 seconds timeout is a balance between the two extremes. 274 ICMP query session timer MUST not expire in less than 60 seconds. We 275 RECOMMEND however that the administrator(s) be allowed to configure 276 the timer. 278 REQ-2: An ICMP Query session timer MUST NOT expire in less than 60 279 seconds. 280 a) It is RECOMMENDED that the ICMP Query session timer be made 281 configurable. 283 4. ICMP Error Forwarding 285 Many applications make use of ICMP error messages from end hosts and 286 intermediate devices to shorten application timeouts. Some 287 applications will not operate correctly without the receipt of ICMP 288 error messages. The following sub-sections discuss the requirements 289 a NAT device MUST conform to in order to ensure reliable forwarding. 291 4.1. ICMP Error Payload Validation 293 Appendix C of [ICMP-ATK] points out that newer revision end host 294 TCP stacks do not accept ICMP error messages with a mismatched 295 IP or TCP checksum in the embedded packet, if the embedded datagram 296 contains full IP packet and the TCP checksum can be calculated. 297 Whenever validation is possible, NAT devices should ensure that ICMP 298 Error payload is not corrupted. Only after the payload is validated, 299 should the NAT proceed to forward the ICMP error packet. This 300 requirement is meant primarily for future applications. Current 301 applications may not be checking for mismatched checksum. 303 If the IP checksum of the embedded packet does not validate, the 304 NAT device SHOULD simply drop the error packet. [ICMP] stipulates 305 that an ICMP error message should embed IP header and a minimum of 306 64 bits of the IP payload. Section 4.3.2.3 of [RFC1812] further 307 recommends that an ICMP error originator SHOULD include as much of 308 the original packet as possible in the payload without the length of 309 the ICMP datagram exceeding 576 bytes. If the embedded packet is a 310 complete IP packet, including the entire transport segment, and the 311 transport protocol of the embedded packet requires the recipient to 312 validate the checksum, the NAT device SHOULD validate the transport 313 checksum. If the transport protocol is UDP and the checksum is set to 314 zero, the UDP protocol does not require the recipient to validate 315 the UDP checksum. In the case the ICMP Error payload includes ICMP 316 extensions ([ICMP-EXT]), the NAT device SHOULD exclude the optional 317 zero-padding and the ICMP extensions when evaluating transport 318 checksum for the embedded packet. If the transport checksum fails, 319 the NAT device SHOULD drop the error packet. Readers are urged to 320 refer [ICMP-EXT] for identifying the presence of ICMP extensions in 321 an ICMP message. 323 When the IP packet embedded within the ICMP error message includes 324 IP options, the NAT device MUST NOT assume that the transport header 325 of the embedded packet is at a fixed offset (as would be the case 326 when there are no IP options associated with the packet) from the 327 start of the embedded packet. Specifically, the NAT device SHOULD 328 index past all IP options when locating the start of transport 329 header for the embedded packet. 331 REQ-3: When an ICMP error packet is received, the NAT device 332 SHOULD do the following. 333 a) If the IP checksum of the embedded packet fails to validate, drop 334 the error packet; and 335 b) If the embedded packet includes IP options, traverse past the 336 IP options to locate the start of transport header for the embedded 337 packet; and 338 c) If the ICMP Error payload contains ICMP extensions([ICMP-EXT]), 339 exclude the optional zero-padding and the ICMP extensions when 340 evaluating transport checksum for the embedded packet; and 341 d) If the embedded packet contains the entire transport segment, 342 and the transport protocol of the embedded packet requires the 343 recipient to validate the transport checksum, and the checksum 344 fails to validate, drop the error packet. 346 4.2. ICMP Error Packet Translation 348 Section 4.3 of RFC 3022 describes the fields of an ICMP error 349 message that a NAT device translates. In this section, we describe 350 the requirements a NAT device MUST conform to while performing the 351 translations. Requirements identified in this section are necessary 352 for the current applications to work correctly. 354 Consider the following scenario in figure 1. Say, NAT-xy is a NAT 355 device connecting hosts in private and external networks. 356 Router-x and Host-x are in the external network. Router-y and 357 Host-y are in the private network. The subnets in the external 358 network are routable from the private as well as the external 359 domains. By contrast, the subnets in the private network are only 360 routable within the private domain. When Host-y initiated a session 361 to Host-x, let us say that the NAT device mapped the endpoint on 362 Host-y into Host-y' in the external network. The following 363 subsections describe the processing of ICMP error messages on the 364 NAT device(NAT-xy), when the NAT device receives an ICMP error 365 message in response to a packet pertaining to this session. 367 Host-x 368 | 369 ---------------+------------------- 370 | 371 +-------------+ 372 | Router-x | 373 +-------------+ 374 External Network | 375 --------------------+--------+------------------- 376 | ^ 377 | | (Host-y', Host-x) 378 | | 379 +-------------+ 380 | NAT-xy | 381 +-------------+ 382 | 383 Private Network | 384 ----------------+------------+---------------- 385 | 386 +-------------+ 387 | Router-y | 388 +-------------+ 389 | 390 ----------------+-------+-------- 391 | ^ 392 | | (Host-y, Host-x) 393 | | 394 Host-y 396 Figure 1. A Session from a private host traversing a NAT device. 398 4.2.1. ICMP Error Packet Received from External Realm 400 Say, a packet from Host-y to Host-x triggered an ICMP error message 401 from one of Router-x or Host-x (both of which are in the external 402 domain). Such an ICMP error packet will have one of Router-x or 403 Host-x as the source IP address and Host-y' as the destination IP 404 address as described in figure 2 below. 406 Host-x 407 | 408 ---------------+------------------- 409 | 410 +-------------+ 411 | Router-x | 412 +-------------+ 413 External Network | 414 --------------------+--------+------------------- 415 | 416 | | ICMP Error Packet to Host-y' 417 | v 418 +-------------+ 419 | NAT-xy | 420 +-------------+ 421 Private Network | 422 ----------------+------------+---------------- 423 | 424 +-------------+ 425 | Router-y | 426 +-------------+ 427 | 428 ----------------+-------+-------- 429 | 430 Host-y 432 Figure 2. ICMP error Packet Received from External Network 434 When the NAT device receives the ICMP error packet, the NAT device 435 MUST use the packet embedded within the ICMP error message (i.e., 436 the IP packet from Host-y' to Host-x) to look up the NAT Session the 437 embedded packet belongs to. If the NAT device does not have an 438 active mapping for the embedded packet, the NAT SHOULD silently 439 drop the ICMP error packet. Otherwise, the NAT device MUST use 440 the matching NAT Session to translate the embedded packet. That is, 441 translate the source IP address of the embedded packet (e.g., 442 Host-y' -> Host-y) and transport headers. 444 In addition, if the ICMP Error payload contains ICMP extensions 445 ([ICMP-EXT]), the NATs are encouraged to support ICMP extension 446 objects. At the time of this writing, the authors are not aware 447 of any standard ICMP extension objects containing realm 448 specific information. 450 The NAT device MUST also use the matching NAT Session to translate 451 the destination IP address in the outer IP header. In the outer 452 header, the source IP address will remain unchanged because the 453 originator of the ICMP error message (Host-x or Router-x) is in 454 external domain and routable from the private domain. 456 REQ-4: If a NAT device receives an ICMP error packet from external 457 realm, and the NAT does not have an active mapping for the embedded 458 payload, the NAT SHOULD silently drop the ICMP error packet. If the 459 NAT has active mapping for the embedded payload and local policy 460 permits, then the NAT MUST do the following prior to forwarding the 461 packet. 462 a) Revert the IP and transport headers of the embedded IP packet to 463 their original form, using the matching mapping; and 464 b) Leave the ICMP error type and code unchanged; and 465 c) Modify the destination IP address of the outer IP header to be 466 same as the source IP address of the embedded packet after 467 translation. 469 4.2.2. ICMP Error Packet Received from Private Realm 471 Now, say, a packet from Host-x to Host-y triggered an ICMP error 472 message from one of Router-y or Host-y (both of which are in the 473 private domain). Such an ICMP error packet will have one of 474 Router-y or Host-y as the source IP address and Host-x as the 475 destination IP address as specified in figure 3 below. 477 Host-x 478 | 479 ---------------+------------------- 480 | 481 +-------------+ 482 | Router-x | 483 +-------------+ 484 External Network | 485 --------------------+--------+------------------- 486 | 487 | 488 +-------------+ 489 | NAT-xy | 490 +-------------+ 491 | ^ 492 | | ICMP Error Packet to Host-x 493 Private Network | 494 ----------------+------------+---------------- 495 | 496 +-------------+ 497 | Router-y | 498 +-------------+ 499 | 500 ----------------+-------+-------- 501 | 502 Host-y 504 Figure 3. ICMP Error Packet Received from Private Network 506 When the NAT device receives the ICMP error packet, the NAT device 507 MUST use the packet embedded within the ICMP error message (i.e., 508 the IP packet from Host-x to Host-y) to look up the NAT Session the 509 embedded packet belongs to. If the NAT device does not have an 510 active mapping for the embedded packet, the NAT SHOULD silently 511 drop the ICMP error packet. Otherwise, the NAT device MUST use 512 the matching NAT Session to translate the embedded packet. 514 In addition, if the ICMP Error payload contains ICMP extensions 515 ([ICMP-EXT]), the NATs are encouraged to support ICMP extension 516 objects. At the time of this writing, the authors are not aware 517 of any standard ICMP extension objects containing realm 518 specific information. 520 In the outer header, the destination IP address will remain 521 unchanged, as the IP addresses for Host-x is already in the external 522 domain. If the ICMP error message is generated by Host-y, the NAT 523 device must simply use the NAT Session to translate the source IP 524 address Host-y to Host-y'. If the ICMP error message is originated 525 by the intermediate node Router-y, translation of the source IP 526 address varies depending on whether Basic NAT or NAPT function 527 ([NAT-TRAD]) is enforced by the NAT device. A NAT device enforcing 528 Basic NAT function has a pool of public IP addresses and enforces 529 address mapping (which is different from the endpoint mapping 530 enforced by NAPT) when a private node initiates an outgoing session 531 via the NAT device. So, if the NAT device has active mapping for 532 the IP address of the intermediate node Router-y, the NAT device 533 MUST translate the source IP address of the ICMP error packet with 534 the public IP address in the mapping. In all other cases, the NAT 535 device MUST simply use its own IP address in the external domain 536 to translate the source IP address. 538 REQ-5: If a NAT device receives an ICMP error packet from private 539 realm, and the NAT does not have an active mapping for the embedded 540 payload, the NAT SHOULD silently drop the ICMP error packet. If the 541 NAT has active mapping for the embedded payload and local policy 542 permits, then the NAT MUST do the following prior to forwarding the 543 packet. 544 a) Revert the IP and transport headers of the embedded 545 IP packet to their original form, using the matching mapping; and 546 b) Leave the ICMP error type and code unchanged; and 547 c) If the NAT enforces Basic NAT function ([NAT-TRAD]), and the NAT 548 has active mapping for the IP address that sent the ICMP error, 549 translate the source IP address of the ICMP error packet with the 550 public IP address in the mapping. In all other cases, translate the 551 source IP address of the ICMP error packet with its own public IP 552 address. 554 4.3. NAT Sessions Pertaining to ICMP Error Payload 556 While processing an ICMP error packet pertaining to an ICMP Query 557 or Query response message, a NAT device MUST NOT refresh or delete 558 the NAT Session that pertains to the embedded payload within the 559 ICMP error packet. This is in spite of the fact that the NAT device 560 uses the NAT Session to translate the embedded payload. This ensures 561 that the NAT Session will not be modified if someone is able to 562 spoof ICMP error messages for the session. [ICMP-ATK] lists a number 563 of potential ICMP attacks that may be attempted by malicious users 564 on the network. This requirement is necessary for current 565 applications to work correctly. 567 REQ-6: While processing an ICMP error packet pertaining to an ICMP 568 Query or Query response message, a NAT device MUST NOT refresh or 569 delete the NAT Session that pertains to the embedded payload within 570 the ICMP error packet. 572 5. Hairpinning Support for ICMP packets 574 [BEH-UDP] and [BEH-TCP] mandate support for hairpinning for UDP and 575 TCP sessions respectively on NAT devices. A NAT device needs to 576 support hairpinning for ICMP Query sessions as well. Specifically, 577 ICMP query hairpinning MUST be supported on Basic NATs. Say, for 578 example, individual private hosts register their NAT assigned 579 external IP address with a rendezvous server. Other hosts that wish 580 to initiate ICMP Query sessions to the registered hosts might do so 581 using the public address registered with the Rendezvous server. For 582 this reason, Basic NAT devices MUST support the traversal of 583 hairpinned ICMP query sessions. This requirement is necessary for 584 current applications to work correctly. 586 Packets belonging to any of the hairpinned sessions could in turn 587 trigger ICMP error messages directed to the source of hairpinned 588 IP packets. Such hairpinned ICMP error messages will traverse the 589 NAT devices enroute. All NAT devices (i.e., Basic NAT as well as 590 NAPT devices) MUST support the traversal of hairpinned ICMP error 591 messages. Specifically, the NAT device must translate not only the 592 embedded hairpinned packet, but also the outer IP header that is 593 hairpinned. This requirement is necessary for current applications 594 to work correctly. 596 A hairpinned ICMP error message is received from a node in private 597 network. As such, the ICMP error processing requirement specified 598 in Req-5 is applicable in its entirety in processing the ICMP 599 error message. In addition, the NAT device MUST translate the 600 destination IP address of the outer IP header to be same as the 601 source IP address of the embedded IP packet after the translation. 603 REQ-7: NAT devices enforcing Basic NAT ([NAT-TRAD]) MUST support the 604 traversal of hairpinned ICMP query sessions. All NAT devices (i.e., 605 Basic NAT as well as NAPT devices) MUST support the traversal of 606 hairpinned ICMP error messages. 607 a) When forwarding a hairpinned ICMP error message, the NAT device 608 MUST translate the destination IP address of the outer IP header to 609 be same as the source IP address of the embedded IP packet after 610 the translation. 612 6. Rejection of Outbound Flows Disallowed by NAT 614 A NAT device typically permits all outbound sessions. However, 615 a NAT device may disallow some outbound sessions due to resource 616 constraints or administration considerations. For example, a NAT 617 device may not permit the first packet of a new outbound session, 618 if the NAT device is out of resources (out of addresses or TCP/UDP 619 ports or NAT Session resources) to set up a state for the session, 620 or, the specific session is administratively restricted by the NAT 621 device. 623 When the first packet of an outbound flow is prohibited by a NAT 624 device due to resource constraints or administration considerations, 625 the NAT device SHOULD send ICMP destination unreachable message. 626 Section 5.2.7.1 of [RFC1812] recommends routers to use ICMP code 13 627 (Communication administratively prohibited) when they 628 administratively filter packets. ICMP code 13 is a soft error and 629 is on par with other soft error codes generated in response to 630 transient events such as 'network unreachable' (ICMP type=3, 631 code=0). A NAT device SHOULD use ICMP code 13 when generating an 632 ICMP error message. This requirement is meant primarily for future 633 use. Current applications do not require this for them to work 634 correctly. 636 Some NAT designers opt to never reject an outbound flow. When a 637 NAT runs short of resources, they prefer to steal a resource 638 from an existing NAT Session rather than reject the outbound flow. 639 Such a design choice may appear conformant to REQ-8 below. However, 640 the design choice is in violation of the spirit of both REQ-8 and 641 REQ-2. Such a design choice is strongly discouraged. 643 REQ-8: When a NAT device is unable to establish a NAT Session for a 644 new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource 645 constraints or administrative restrictions, the NAT device SHOULD 646 send an ICMP destination unreachable message, with a code of 13 647 (Communication administratively prohibited) to the sender, and drop 648 the original packet. 650 7. Conformance to RFC 1812 652 A NAT device is inherently an intermediate router that forwards 653 IP packets between private and external realms. As such, the NAT 654 device MUST conform to all the requirements of a router, as 655 specified in [RFC1812]. Section 5.2.7.1 of [RFC1812] states that 656 a router MUST also be able to generate ICMP Destination Unreachable 657 messages and SHOULD choose a response code that most closely matches 658 the reason the message is being generated. 660 Note, however, NAT devices also function as hosts on the Internet 661 and are bound by the conformance requirements in [RFC1122]. 662 Protocol-specific BEHAVE documents ([BEH-UDP], [BEH-TCP]) identify 663 instances where a NAT device should deviate from RFC 1122. As such, 664 the host behavior requirements of NAT devices specified in the 665 protocol-specific BEHAVE drafts take precedence over RFC 1122. 667 The focus of this section is on conformance to router requirements. 668 The following sub sections identify specific instances where a NAT 669 device would be expected to conform to RFC 1812. 671 7.1. IP packet fragmentation 673 Many networking applications (which include TCP as well as UDP based 674 applications) depend on ICMP error messages from the network to 675 perform end-to-end path MTU discovery [PMTU]. Once path MTU is 676 discovered, an application that chooses to avoid fragmentation may 677 do so by originating IP packets that fit within the Path MTU enroute 678 and setting the DF (Don't Fragment) bit in the IP header, so the 679 intermediate nodes enroute do not fragment the IP packets. The 680 following sub-sections discuss the need for NAT devices to honor the 681 DF bit in the IP header and be able to generate "Packet too big" 682 ICMP error message when they cannot forward the IP packet without 683 fragmentation. Also discussed is the need to seamlessly forward 684 ICMP error messages generated by other intermediate devices. 686 7.1.1. Generating "Packet too Big" ICMP error Message 688 When a router is unable to forward a datagram because it exceeds 689 the MTU of the next-hop network and its Don't Fragment (DF) bit is 690 set, the router is required by [RFC1812] to return an ICMP 691 Destination Unreachable message to the source of the datagram, with 692 the Code indicating "fragmentation needed and DF set". Further, 693 [PMTU] states that the router MUST include the MTU of that next-hop 694 network in the low-order 16 bits of the ICMP header field that is 695 labeled "unused" in the ICMP specification[ICMP]. 697 A NAT device MUST honor the DF bit in the IP header of the 698 packets that transit the device. If the DF bit is set and the 699 MTU on the forwarding interface of the NAT device is such that 700 the IP datagram cannot be forwarded without fragmentation, the 701 NAT device MUST issue a "packet too big" ICMP message (ICMP 702 type 3, Code 4) with a suggested MTU back to the sender and 703 drop the original IP packet. The sender will usually resend after 704 taking the appropriate corrective action. 706 If the DF bit is not set and the MTU on the forwarding interface 707 of the NAT device mandates fragmentation, the NAT device MUST 708 fragment the packet and forward the fragments [RFC1812]. 710 7.1.2. Forwarding "Packet too big" ICMP Error Message 712 This is flip side of the argument for the above section. By virtue 713 of the address translation NAT performs, NAT may end up being the 714 recipient of "Packet too big" message. 716 When NAT device is the recipient of "Packet too big" ICMP message 717 from the network, the NAT device MUST forward the ICMP message back 718 to the intended recipient, pursuant to the previously stated 719 requirements REQ-3, REQ-4, REQ-5 and REQ-6. 721 7.2. Generating "Time Exceeded" Error Message 723 Section 5.2.7.3 of RFC 1812 says that a router MUST generate 724 "Time Exceeded" ICMP error message when it discards a packet due 725 to an expired TTL field. A router MAY have a per-interface option 726 to disable origination of these messages on that interface, but that 727 option MUST default to allowing the messages to be originated. 729 7.3. RFC 1812 Conformance Requirements summary 731 The requirements outlined in sections 7.1 and 7.2 are necessary for 732 the current applications to work correctly. The following summarizes 733 the requirements specified in sections 7.1 and 7.2, 735 REQ-9: A NAT device MUST conform to RFC 1812 in IP packet handling. 736 Below are specific instances where a NAT device MUST conform to 737 RFC 1812. 738 a) A NAT MUST honor the DF bit in the IP header. If the DF bit is set 739 on a transit IP packet and the NAT device cannot forward the packet 740 without fragmentation, the NAT device MUST send a "Packet too big" 741 ICMP message (ICMP type 3, Code 4) with a suggested MTU back to the 742 sender and drop the original IP packet. If the DF-bit is clear and 743 MTU mandates fragmentation, the NAT device MUST fragment the packet 744 and forward the fragments. 745 b) A NAT device MUST, by default, generate "Time Exceeded" ICMP 746 error message when it discards a packet due to an expired TTL field, 747 unless explicitly configured otherwise. 749 8. Summary of Requirements 751 This section summarizes the requirements discussed in the preceding 752 sections. 754 REQ-1: When local policy permits, a NAT device MUST permit ICMP 755 queries and their associated responses, when the query is initiated 756 from a private host. 757 a) NAT mapping of ICMP Query identifiers SHOULD be external host 758 independent. 760 REQ-2: An ICMP Query session timer MUST NOT expire in less than 60 761 seconds. 762 a) It is RECOMMENDED that the ICMP Query session timer be made 763 configurable. 765 REQ-3: When an ICMP error packet is received, the NAT device 766 SHOULD do the following. 767 a) If the IP checksum of the embedded packet fails to validate, drop 768 the error packet; and 769 b) If the embedded packet includes IP options, traverse past the 770 IP options to locate the start of transport header for the embedded 771 packet; and 772 c) If the ICMP Error payload contains ICMP extensions([ICMP-EXT]), 773 exclude the optional zero-padding and the ICMP extensions when 774 evaluating transport checksum for the embedded packet; and 775 d) If the embedded packet contains the entire transport segment, 776 and the transport protocol of the embedded packet requires the 777 recipient to validate the transport checksum, and the checksum 778 fails to validate, drop the error packet. 780 REQ-4: If a NAT device receives an ICMP error packet from external 781 realm, and the NAT does not have an active mapping for the embedded 782 payload, the NAT SHOULD silently drop the ICMP error packet. If the 783 NAT has active mapping for the embedded payload and local policy 784 permits, then the NAT MUST do the following prior to forwarding the 785 packet. 786 a) Revert the IP and transport headers of the embedded IP packet to 787 their original form, using the matching mapping; and 788 b) Leave the ICMP error type and code unchanged; and 789 c) Modify the destination IP address of the outer IP header to be 790 same as the source IP address of the embedded packet after 791 translation. 793 REQ-5: If a NAT device receives an ICMP error packet from private 794 realm, and the NAT does not have an active mapping for the embedded 795 payload, the NAT SHOULD silently drop the ICMP error packet. If the 796 NAT has active mapping for the embedded payload and local policy 797 permits, then the NAT MUST do the following prior to forwarding the 798 packet. 799 a) Revert the IP and transport headers of the embedded 800 IP packet to their original form, using the matching mapping; and 801 b) Leave the ICMP error type and code unchanged; and 802 c) If the NAT enforces Basic NAT function ([NAT-TRAD]), and the NAT 803 has active mapping for the IP address that sent the ICMP error, 804 translate the source IP address of the ICMP error packet with the 805 public IP address in the mapping. In all other cases, translate the 806 source IP address of the ICMP error packet with its own public IP 807 address. 809 REQ-6: While processing an ICMP error packet pertaining to an ICMP 810 Query or Query response message, a NAT device MUST NOT refresh or 811 delete the NAT Session that pertains to the embedded payload within 812 the ICMP error packet. 814 REQ-7: NAT devices enforcing Basic NAT ([NAT-TRAD]) MUST support the 815 traversal of hairpinned ICMP query sessions. All NAT devices (i.e., 816 Basic NAT as well as NAPT devices) MUST support the traversal of 817 hairpinned ICMP error messages. 818 a) When forwarding a hairpinned ICMP error message, the NAT device 819 MUST translate the destination IP address of the outer IP header to 820 be same as the source IP address of the embedded IP packet after 821 the translation. 823 REQ-8: When a NAT device is unable to establish a NAT Session for a 824 new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource 825 constraints or administrative restrictions, the NAT device SHOULD 826 send an ICMP destination unreachable message, with a code of 13 827 (Communication administratively prohibited) to the sender, and drop 828 the original packet. 830 REQ-9: A NAT device MUST conform to RFC 1812 in IP packet handling. 831 Below are specific instances where a NAT device MUST conform to 832 RFC 1812. 833 a) A NAT MUST honor the DF bit in the IP header. If the DF bit is set 834 on a transit IP packet and the NAT device cannot forward the packet 835 without fragmentation, the NAT device MUST send a "Packet too big" 836 ICMP message (ICMP type 3, Code 4) with a suggested MTU back to the 837 sender and drop the original IP packet. If the DF-bit is clear and 838 MTU mandates fragmentation, the NAT device MUST fragment the packet 839 and forward the fragments. 840 b) A NAT device MUST, by default, generate "Time Exceeded" ICMP 841 error message when it discards a packet due to an expired TTL field, 842 unless explicitly configured otherwise. 844 9. Security Considerations 846 This document does not introduce any new security concerns related 847 to ICMP error message handling in the NAT devices. However, the 848 document does propose counter measures to mitigate security concerns 849 that already exist with ICMP error messages. 851 [ICMP-ATK] lists a number of ICMP attacks that can be directed 852 against end host TCP stacks and suggests remedies to counter the 853 attacks. [TCP-SOFT] describes improvements to the handling of 854 ICMP error messages in many of the existing TCP/IP stacks, including 855 Linux. Section 4 of this document describes a number of measures by 856 which NAT devices should validate and update the embedded payload 857 in ICMP error messages prior to forwarding. These measures ensure 858 that NATs forward the ICMP error messages reliably, as stipulated 859 in [ICMP-ATK]. 861 For example, a rogue entity could bombard the NAT device with a 862 large number of ICMP errors. If the NAT device did not 863 validate the legitimacy of the ICMP error packets, the ICMP errors 864 would be forwarded directly to the end nodes. End hosts not capable 865 of defending themselves against such bogus ICMP error attacks could 866 be adversely impacted by such attacks. Req-3 recommends validating 867 embedded payload prior to forwarding. Checksum validation by itself 868 does not protect end hosts from attacks. However, checksum 869 validation mitigates end hosts from malformed ICMP error attacks. 870 Req-4 and Req-5 further mandate that when a NAT device does not find 871 a mapping selection for the embedded payload, the NAT should drop 872 the ICMP error packets, without forwarding. 874 A rogue source could also try and send bogus ICMP error messages for 875 the active NAT sessions, with an intent to destroy the sessions. 876 Req-6 averts such an attack by ensuring that an ICMP error message 877 does not effect the state of a session on the NAT device. 879 Req-8 recommends a NAT device sending ICMP error message when the 880 NAT device is unable to create a NAT session due to lack of 881 resources. Some administrators may choose not to have the NAT device 882 send ICMP error message, as doing so could confirm to a malicious 883 attacker that the attack has succeeded. For this reason, sending 884 of the specific ICMP error message stated in REQ-8 should be 885 left to the discretion of the NAT device administrator. 887 Unfortunately, ICMP messages are sometimes blocked at network 888 boundaries due to local security policy. Thus, some of the 889 requirements in this document allow local policy to override the 890 recommendations of this document. Blocking such ICMP messages is 891 known to break some protocol features (most notably Path MTU 892 Discovery) and some applications (e.g., ping, traceroute), and 893 such blocking is NOT RECOMMENDED. 895 10. IANA Considerations 897 There are no IANA considerations. 899 11. Acknowledgements 900 The authors wish to thank Fernando Gont, Dan Wing, Carlos Pignataro, 901 Philip Matthews and members of the BEHAVE work group for doing a 902 thorough review of the document and providing valuable input and 903 offering generous amount of their time in shaping the ICMP 904 requirements. Their valuable feedback makes this document a better 905 read. The authors highly appreciate that. Dan Wing and Fernando Gont 906 have been a steady source of inspiration throughout, for each rev of 907 the document. Fernando Gont spent many hours preparing slides and 908 presenting the document in the IETF on behalf of the authors. For 909 this, the authors are grateful to Fernando. The authors also thank 910 and sincerely appreciate Dan Tappan and Carlos Pignataro, the 911 authors of the [ICMP-EXT] document for their feedback on operational 912 experience with ICMP extensions across NAT devices. 914 Normative References 916 [BEH-UDP] F. Audet and C. Jennings, "NAT Behavioral Requirements for 917 Unicast UDP", RFC 4787, January 2007. 919 [ICMP] Postel, J., "Internet Control Message Protocol", STD 5, 920 RFC 792, September 1981. 922 [ICMP-EXT] Bonica, R., Gan, D., Nikander, P., Tappan, D., and 923 Pignataro, C., "Extended ICMP to Support Multi-part 924 Messages", RFC 4884, April 2007. 926 [NAT-MIB] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., 927 and Wang, C., "Definitions of Managed Objects for Network 928 Address Translators (NAT)", RFC 4008, March 2005. 930 [RFC793] "Transmission Control Protocol DARPA Internet Program 931 Protocol Specification", RFC 793, September 1981. 933 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 934 RFC 1812, June 1995. 936 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 937 Requirement Levels", BCP 14, RFC 2119, March 1997. 939 Informative References 941 [BEH-APP] Ford, B., Srisuresh, P., and Kegel, D., "Application Design 942 Guidelines for Traversal through Network Address 943 Translators", draft-ford-behave-app-05.txt (Work In 944 Progress), March 2007. 946 [BEH-TCP] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and 947 Srisuresh, P., "NAT Behavioral Requirements for TCP", 948 draft-ietf-behave-tcp-07.txt (Work In Progress), 949 April 2007. 951 [ICMP-ATK] Gont, F., "ICMP attacks against TCP", 952 draft-ietf-tcpm-icmp-attacks-02.txt (Work In Progress), 953 May 2007. 955 [MS-TRCRT] Microsoft Support, "How to use the Tracert 956 command-line utility to troubleshoot TCP/IP problems 957 in Windows", http://support.microsoft.com/kb/162326, 958 October, 2006. 960 [NAT-TERM] Srisuresh, P. and Holdrege, M., "IP Network Address 961 Translator (NAT) Terminology and Considerations", RFC 2663, 962 August 1999. 964 [NAT-TRAD] Srisuresh, P., and Egevang, K., "Traditional IP Network 965 Address Translator (Traditional NAT)", RFC 3022, 966 January 2001. 968 [PMTU] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 969 November 1990. 971 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 972 Communication Layers", RFC 1122, October 1989. 974 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC1256, 975 September 1991. 977 [RFC1470] Stine, R., "FYI on a Network Management Tool Catalog: Tools 978 for Monitoring and Debugging TCP/IP Internets and 979 Interconnected Devices", RFC 1470, June 1993. 981 [RFC4065] Kempf, J., "Instructions for Seamoby and Experimental 982 Mobility Protocol IANA Allocations", RFC 4065, July 2005. 984 [TCP-SOFT] Gont, F., "TCP's Reaction to Soft Errors", 985 draft-ietf-tcpm-tcp-soft-errors-06.txt (Work In Progress), 986 June 2007. 988 [UNSAF] Daigle, L., and IAB, "IAB Considerations for UNilateral 989 Self-Address Fixing (UNSAF) Across Network Address 990 Translation", RFC 3424, November 2002. 992 Author's Addresses: 994 Pyda Srisuresh 995 Kazeon Systems, Inc. 996 1161 San Antonio Rd. 997 Mountain View, CA 94043 998 U.S.A. 999 Phone: (408)836-4773 1000 E-mail: srisuresh@yahoo.com 1002 Bryan Ford 1003 Computer Science and Artificial Intelligence Laboratory 1004 Massachusetts Institute of Technology 1005 77 Massachusetts Ave. 1006 Cambridge, MA 02139 1007 U.S.A. 1008 Phone: (617) 253-5261 1009 E-mail: baford@mit.edu 1010 Web: http://www.brynosaurus.com/ 1012 Senthil Sivakumar 1013 Cisco Systems, Inc. 1014 7100-8 Kit Creek Road 1015 PO Box 14987 1016 Research Triangle Park, NC 27709-4987 1017 U.S.A. 1018 Phone: +1 919 392 5158 1019 Email: ssenthil@cisco.com 1021 Saikat Guha 1022 Cornell University 1023 331 Upson Hall 1024 Ithaca, NY 14853 1025 U.S.A. 1026 Email: saikat@cs.cornell.edu 1028 Intellectual Property Statement 1030 The IETF takes no position regarding the validity or scope of any 1031 Intellectual Property Rights or other rights that might be claimed to 1032 pertain to the implementation or use of the technology described in 1033 this document or the extent to which any license under such rights 1034 might or might not be available; nor does it represent that it has 1035 made any independent effort to identify any such rights. Information 1036 on the procedures with respect to rights in RFC documents can be 1037 found in BCP 78 and BCP 79. 1039 Copies of IPR disclosures made to the IETF Secretariat and any 1040 assurances of licenses to be made available, or the result of an 1041 attempt made to obtain a general license or permission for the use of 1042 such proprietary rights by implementers or users of this 1043 specification can be obtained from the IETF on-line IPR repository at 1044 http://www.ietf.org/ipr. 1046 The IETF invites any interested party to bring to its attention any 1047 copyrights, patents or patent applications, or other proprietary 1048 rights that may cover technology that may be required to implement 1049 this standard. Please address the information to the IETF at 1050 ietf-ipr@ietf.org. 1052 Copyright Statement 1054 Copyright (C) The IETF Trust (2007). 1056 This document is subject to the rights, licenses and restrictions 1057 contained in BCP 78, and except as set forth therein, the authors 1058 retain all their rights. 1060 This document and the information contained herein are provided on an 1061 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1062 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1063 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1064 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1065 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1066 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1068 Acknowledgment 1070 Funding for the RFC Editor function is currently provided by the 1071 IETF Trust.