Subject: [Gen-art] Gen-ART review of IETF LC draft-ietf-behave-nat-icmp-05.txt

From: Miguel Garcia <[email-masked]>
Date: Tue, 09 Oct 2007 11:45:10 +0300

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-behave-nat-icmp-05.txt
Reviewer: Miguel Garcia <[email-masked]>
Review Date: 2007-10-09
IESG LC end date: 2007-10-11

Summary:

Comments:

- Although the document contains a downward normative reference to RFC
   3022, I think it is justified. So, there isn't a proposed action.

- Section 4.1 discusses the checksum of the payload for TCP and UDP
   packets that are embeded in ICMP Error messages. What about UDP-lite
   (RFC 3828) packets with partial checksum coverage? Applying the same
   rules as for UDP would drop legitimate packets. I think the draft
   should say what the NAT should do with respect ICMP Error messages
   that contain UDP-lite packets.

- Section 4.1, I am surprised that the recommendation is for NATs to
   validate the IP checksum of the payload in ICMP errors. I thought
   NATs should forward packets fast, not recalculate two checksums
   (that of the payload, and that of the ICMP packet). Perhaps there is a
   reason for this behavior. Dropping a packet at the NAT would also
   make difficult to trace errors in the NATted host.

Nits:

- The draft should add formal references to RFC 3022 (Section 4.2) and
   RFC 1822 (several sections)

- Abbreviations should be expanded at the first appearance, e.g., NAT
   and ICMP in the title, ICMP in the Abstract as well, etc.

- Capitalization should be consistent. Compare how "Packet too big" and
   "Error Message" is capitalized in the title of Sections 7.1.1 and
   7.1.2. Also, notice the different capitalization styles for ICMP Query
   Messages and ICMP Error Messages throughout the document.

- As a personal taste, I don't like to mention names of working groups
   in RFCs, because those are temporary names, and they stop existing
   once the work is done. So, perhaps the authors could do an effort to
   avoid the usage of the term "BEHAVE" in the document.

- Section 3.1, first paragraph, says: "A NAT device MUST permit ICMP
   query based applications ...." I think the NAT does not know much
   about _applications_, but knows about _messages_. So I would recommend
   to replace "ICMP query based applications" with "ICMP Query messages".

- Section 5 deals with hairpinning support for ICMP packets. It would be
   nice to have a single sentence definition of "hairpinning" at the
   beginning of the section. The reader may or may not be familiar with
   its meaning.

/Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 11 Oct 2007 05:40:29 -0700 (PDT)

Miguel,

Thank you for the comments. Please see my responses inline.

regards,
suresh

>    that contain UDP-lite packets.
[suresh] There are a few things to note here.

a) REQ-3d is transport protocol agnostic and is stated as follows. This is
applicable to UDP-lite as well, assuming the NAT device supports UDP-lite.

   If the embedded packet contains the entire transport segment,
   and the transport protocol of the embedded packet requires the
   recipient to validate the transport checksum, and the checksum
   fails to validate, drop the error packet.

b) UDP-Lite is an independent transport protocol with a protocol identifier of
its own (136). The Behave WG has not dicussed protocols other than TCP and UDP.
RFC4787 (UDP BEHAVE) does not discuss UDP-lite either.

So, I dont believe, it woudl be necessary to include specific comment about
UDP-lite in this document.

>    make difficult to trace errors in the NATted host.
[suresh] Fast is not as important as doing the right thing. RFC1812 says that a
router MUST verify the IP checksum of any packet that is received, and MUST
discard messages containing invalid checksums. Besides, newer revision endhosts
do not accept ICMP error messages with a mismatched IP or TCP checksum in the
embedded packet. Hence the recommendation to validate IP checksum.

>    RFC 1822 (several sections)
[suresh] Will do. Thanks.

>    and ICMP in the title, ICMP in the Abstract as well, etc.

[suresh] OK, I will expand NAT to be "Network Address translator" in the title.
However, I dont believe, it is necessary to expand on well known terms like IP
and ICMP.

>    Messages and ICMP Error Messages throughout the document.
[suresh] OK. I will fix that.

>    avoid the usage of the term "BEHAVE" in the document.
[suresh] I agree with what you say. However, this document needed to refer to
protocol specific  BEHAVE drafts several times. So, I had no choice. This was a
conscious use of the term.

>    to replace "ICMP query based applications" with "ICMP Query messages".
[suresh] OK.

>    beginning of the section. The reader may or may not be familiar with

[suresh] The first sentence in section 5 reads - "[BEH-UDP] and [BEH-TCP]
mandate support for hairpinning for UDP and TCP sessions respectively on NAT
devices."; and the first sentence in the terminology section reads -
"Definitions for majority of the NAT terms used throughout the document may be
found in [NAT-TERM] and [BEH-UDP]." Given this, it does not seem necessary to
repeat the definition again in this document, right.

regards,
suresh

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 12 Oct 2007 09:29:31 +0300

Hi Suresh:

Inline comments (only those that deserve a bit more discussion).

/Miguel

> UDP-lite in this document.

Well, if you think that the checksum validation covers the UDP-lite case 
with partial checksums, then I would agree that the draft covers the 
case, and there is no action for the document. In my opinion, it is a 
hidden from the reader, but that is just my opinion.

I now understand that you don't want to open the can of worms and start 
considering all the protocols that are encapsulated in ICMP Error messages.

> However, I dont believe, it is necessary to expand on well known terms like IP

Before I wrote this comment I went to the RFC Editor policy web page, 
http://www.rfc-editor.org/policy.html#policy.abbrevs and I didn't find 
"ICMP" in the list of accepted abbreviations without expansion. You can 
try to leave the term unexpanded, then it will be up to the RFC editor 
to decide.

/Miguel

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 12 Oct 2007 14:31:11 +0200

> considering all the protocols that are encapsulated in ICMP Error messages.

I think that we can live with the present text.

> try to leave the term unexpanded, then it will be up to the RFC editor

I would leave the title and expand it in the abstract.

I expect an updated draft before progressing this.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 12 Oct 2007 06:03:43 -0700 (PDT)

Thanks, Miguel and Magnus. I will get a revised draft out with the proposed
changes. Thanks.

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 14 Oct 2007 08:35:24 -0700 (PDT)

Miguel, Chris and Magnus,

Attached is the revised draft with your IETF LC comments folded in. Please
review. I will await your comments prior to submitting to the IETF. Thanks.

regards,
suresh

Intended Status: Best Current Practice
BEHAVE WG                                                   P. Srisuresh
Internet Draft                                            Kazeon Systems
Expires: April 15, 2008                                          B. Ford
                                                                  M.I.T.
                                                            S. Sivakumar
                                                           Cisco Systems
                                                                 S. Guha
                                                              Cornell U.
                                                           October, 2007

                NAT Behavioral Requirements for ICMP protocol
                <draft-ietf-behave-nat-icmp-06.txt>

Status of this Memo

   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.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document specifies the behavioral properties required of the 
   Network Address Translator (NAT) devices in conjunction with the
   Internet Control Message Protocol (ICMP). The objective of this
   memo is to make NAT devices more predictable and compatible with
   diverse application protocols that traverse the devices. Companion
   documents provide behavioral recommendations specific to TCP, UDP
   and other protocols.

Srisuresh, et. al.                                              [Page 1]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

Table of Contents

   1.  Introduction and Scope .......................................
   2.  Terminology ..................................................
   3.  ICMP Query Handling ..........................................
       3.1. ICMP Query Mapping ......................................
       3.2. ICMP Query Session Timeouts .............................
   4.  ICMP Error Forwarding ........................................
       4.1. ICMP Error Payload Validation ...........................
       4.2. ICMP Error Packet Translation ...........................
           4.2.1. ICMP Error Packet Received from External Realm ....
           4.2.2. ICMP Error Packet Received from Private Realm .....
       4.3. NAT Sessions Pertaining to ICMP Error Payload ...........
   5.  Hairpinning Support for ICMP packets .........................
   6.  Rejection of Outbound Flows Disallowed by NAT ................
   7.  Conformance to RFC 1812 ......................................
       7.1. IP packet fragmentation .................................
           7.1.1. Generating "Packet Too Big" ICMP Error Message ....
           7.1.2. Forwarding "Packet Too big" ICMP Error Message ....
       7.2. Generating "Time Exceeded" Error Message ................
       7.3. RFC 1812 Conformance Requirements summary ...............
   8.  Summary of Requirements ......................................
   9.  Security Considerations ......................................
   10. IANA Considerations ..........................................
   11. Acknowledgements .............................................

1. Introduction and Scope

   As pointed out in RFC 3424 [UNSAF], NAT implementations vary
   widely in terms of how they handle different traffic. The purpose
   of this document is to define a specific set of requirements for NAT
   behavior with regard to ICMP messages. The objective is to reduce
   the unpredictability and brittleness the NAT devices (NATs)
   introduce. This document is an adjunct to [BEH-UDP], [BEH-TCP], and
   other protocol-specific BEHAVE document(s) in the future which
   define requirements for NATs when handling protocol-specific
   traffic.

   The requirements of this specification apply to Traditional NATs as
   described in [NAT-TRAD]. Traditional NAT has two variations, namely,
   Basic NAT and Network Address Port Translator (NAPT). Of these, NAPT
   is by far the most commonly deployed NAT device. NAPT allows
   multiple private hosts to share a single public IP address
   simultaneously.

Srisuresh, et. al.                                              [Page 2]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

   This document only covers the ICMP aspects of NAT traversal, 
   specifically the traversal of ICMP Query messages and ICMP Error
   messages. Traditional NAT inherently mandates firewall-like
   filtering behavior [BEH-UDP]. However, firewall functionality in
   general or any other middlebox functionality is out of the scope
   of this document.

   In some cases, ICMP Message traversal behavior on a NAT device may 
   be overridden by local administrative policies. Some administrators
   may choose to entirely prohibit forwarding of ICMP Error messages
   across a NAT device. Some others may choose to prohibit ICMP Query
   based applications across a NAT device. These are local policies
   and not within the scope of this document. For this reason, some
   of the ICMP requirements listed in the document are preceded with a
   constraint of local policy permitting. 

   This document focuses strictly on the behavior of the NAT device,
   and not on the behavior of applications that traverse NATs. A
   separate document [BEH-APP] provides recommendations for application
   designers on how to make applications work robustly over NATs that
   follow the requirements specified here and the adjunct 
   protocol-specific BEHAVE documents.

   Per [RFC1812], ICMP is a control protocol that is considered to be
   an integral part of IP, although it is architecturally layered upon
   IP - it uses IP to carry its data end-to-end. As such, many of the
   ICMP behavioral requirements discussed in this document apply to all
   IP protocols. 

   In case a requirement in this document conflicts with 
   protocol-specific BEHAVE requirement(s), protocol-specific BEHAVE
   documents will take precedence. The authors are not aware of any
   conflicts between this and any other IETF document at the time of
   this writing. 

   Section 2 describes the terminology used throughout the document.
   Sections 3 is focused on requirements concerning ICMP Query based
   applications traversing a NAT device. Sections 4 and 5 describe
   requirements concerning ICMP Error messages traversing a NAT
   device. Sections 6 and 7 describe requirements concerning ICMP Error
   messages generated by a NAT device. Section 8 summarizes all the
   requirements in one place. Section 9 has a discussion on security
   considerations. 

2. Terminology

   Definitions for majority of the NAT terms used throughout the

Srisuresh, et. al.                                              [Page 3]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

   document may be found in [NAT-TERM] and [BEH-UDP]. The term
   "NAT Session" is adapted from [NAT-MIB] and denotes the entity
   within a NAT device that represents the translation glue for a
   session traversing the NAT device. 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   Section 3.2.2 of [RFC1122] broadly groups ICMP messages into two
   classes, namely "ICMP Query" messages and "ICMP Error" messages.
   In addition, there are ICMP messages, created after [RFC1122] that
   do not fall under either category. We refer them as "Post-1122 ICMP 
   Messages". All three ICMP message classes are described as follows.

   ICMP Query Messages - ICMP Query messages are characterized by an
   Identifier field in the ICMP header. The Identifier field used
   by the ICMP Query messages is also referred as "Query Identifier" or
   "Query Id", for short throughout the document. A Query Id is used by
   Query senders and responders as the equivalent of a TCP/UDP port to
   identify an ICMP Query session. 
   
   ICMP Error Messages - ICMP Error messages provide signaling for IP.
   All ICMP Error messages are characterized by the fact that they
   embed the original datagram that triggered the ICMP Error message.
   The original datagram embedded within the ICMP Error payload is 
   also referred as "Embedded packet", throughout the document. Unlike
   ICMP Query messages, ICMP Error messages do not have a Query Id in
   the ICMP header.

   Post-1122 ICMP Messages - ICMP messages that do not fall under
   either of the above two classes are referred as "Post-1122 ICMP 
   Messages" throughout the document. For example, discovery ICMP
   messages ([RFC1256]) are "request/response" type ICMP messages. 
   However, they are not characterized as ICMP Query messages as they
   do not have an "Identifier" field within the messages. Likewise, 
   there are other ICMP messages defined in [RFC4065] that do not
   fall in either of ICMP Query or ICMP Error message categories, but
   will be referred as Post-1122 ICMP Error messages.

3. ICMP Query Handling

   This section lists the behavioral requirements for a NAT device
   when processing ICMP Query packets. The following sub sections
   discuss requirements specific to ICMP Query handling in detail.

3.1. ICMP Query Mapping

Srisuresh, et. al.                                              [Page 4]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

   A NAT device MUST permit ICMP Query based applications to be
   initiated from private hosts to the external hosts. ICMP Query 
   mapping by NAT devices is necessary for current ICMP Query based
   applications to work. Specifically, a NAT device MUST transparently
   forward any ICMP Query packets initiated from the nodes behind NAT
   devices and the responses to these Query packets in the opposite
   direction. As specified in [NAT-TRAD], this requires translating the
   IP header. A NAPT device further translates the ICMP Query Id and
   the associated checksum in the ICMP header prior to forwarding.   

   The mapping of ICMP Query identifier within the NAT device SHOULD
   be external endpoint independent. Say, an internal host A sent an
   ICMP Query out to an external host B using Query Id X. And, say,
   the NAT assigned this an external mapping of Query id X' on the
   NAT's public address. If host A reused the Query Id X to send ICMP
   Queries to the same or different external host, the NAT device
   SHOULD reuse the same Query Id mapping (i.e.,  map private host's 
   Query id X to Query id X' on NAT's public IP address) instead of
   assigning a different mapping. This is similar to the "endpoint 
   independent mapping" requirement specified in the TCP and UDP
   requirement documents ([BEH-UDP], [BEH-TCP]). 

   Below is justification for making the endpoint independent mapping
   for ICMP Query IDs a SHOULD [RFC2119] requirement. ICMP Ping 
   ([RFC1470]) and ICMP traceroute ([MS-TRCRT]) are two most commonly
   known legacy applications built on top of ICMP Query messages. 
   Neither of these applications require the ICMP Query Id to be
   retained across different sessions with external hosts. But, that
   may not be case with future applications. In the future, when an
   end host application reuses the same Query identifier in sessions
   with different target hosts, the end host application might require
   that the endpoint identity (i.e., the tuple of IP address and Query
   Identifier) appears the same across all its target hosts. Such a
   requirement will be valid to make in an IP network without NAT 
   devices. When NAT devices enforce endpoint mapping that is external 
   host independent, the above assumption will be valid to make even in
   a world with NAT devices. Given the dichotomy between legacy
   applications not requiring endpoint independent mapping and future
   applications that might require it, the requirement level is kept
   at SHOULD [RFC2119].

   REQ-1: When local policy permits, a NAT device MUST permit ICMP 
   Queries and their associated responses, when the Query is initiated
   from a private host. 
   a) NAT mapping of ICMP Query identifiers SHOULD be external host 
   independent.

Srisuresh, et. al.                                              [Page 5]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

3.2. ICMP Query Session Timeouts

   When an application initiates an ICMP Query that transits a NAT
   device, the NAT associates a timer to the ICMP Query NAT session.
   This is so the ICMP Query NAT session is freed up if the NAT session
   remains idle for longer than the timeout set by the timer. Query
   response times can vary. ICMP Query based applications are primarily 
   request/response driven. The ICMP Query session timeout requirement
   is necessary for current ICMP Query applications to work.

   Ideally, the timeout should be set to Maximum Round Trip Time 
   (Maximum RTT). For the purposes of constraining the maximum RTT, the
   Maximum Segment Lifetime (MSL), defined in [RFC793] could be 
   considered a guideline to set packet lifetime. Per [RFC793], MSL is
   the maximum amount of time a TCP segment can exist in a network
   before being delivered to the intended recipient. This is the maximum
   duration an IP packet can be assumed to take to reach the intended
   destination node before declaring that the packet will no longer be
   delivered. For an application initiating ICMP Query message and
   waiting for a response for the Query, the Maximum RTT could in
   practice be constrained to be sum total of MSL for the Query message
   and MSL for the response message. In other words, Maximum RTT could
   be constrained to no more than 2x MSL. The recommended value for MSL
   in [RFC793] is 120 seconds, even though several implementations set
   this to 60 seconds or 30 seconds. When MSL is 120 seconds, the
   Maximum RTT (2x MSL) would be 240 seconds.

   In practice, ICMP Ping ([RFC1470]) and ICMP traceroute ([MS-TRCRT]),
   the two most commonly known legacy applications built on top of ICMP
   Query messages take less than 10 seconds to complete a round trip,
   when the target node is operational on the network.

   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. 

   REQ-2: An ICMP Query session timer MUST NOT expire in less than 60
   seconds.
   a) It is RECOMMENDED that the ICMP Query session timer be made
   configurable.

Srisuresh, et. al.                                              [Page 6]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

4. ICMP Error Forwarding
 
   Many applications make use of ICMP Error messages from end hosts and
   intermediate devices to shorten application timeouts. Some
   applications will not operate correctly without the receipt of ICMP
   Error messages. The following sub-sections discuss the requirements
   a NAT device MUST conform to in order to ensure reliable forwarding. 

4.1. ICMP Error Payload Validation
 
   Appendix C of [ICMP-ATK] points out that newer revision end host 
   TCP stacks do not accept ICMP Error messages with a mismatched 
   IP or TCP checksum in the embedded packet, if the embedded datagram
   contains full IP packet and the TCP checksum can be calculated.
   Whenever validation is possible, NAT devices should ensure that ICMP
   Error payload is not corrupted. Only after the payload is validated,
   should the NAT proceed to forward the ICMP Error packet.

   If the IP checksum of the embedded packet does not validate, the
   NAT device SHOULD simply drop the ICMP Error packet. [ICMP]
   stipulates that an ICMP Error message should embed IP header and a
   minimum of 64 bits of the IP payload. Section 4.3.2.3 of [RFC1812]
   further recommends that an ICMP Error originator SHOULD include as
   much of the original packet as possible in the payload without the
   length of the ICMP datagram exceeding 576 bytes. If the embedded
   packet is a complete IP packet, including the entire transport
   segment, and the transport protocol of the embedded packet requires
   the recipient to validate the checksum, the NAT device SHOULD
   validate the transport checksum. If the transport protocol is UDP
   and the checksum is set to zero, the UDP protocol does not require
   the recipient to validate the UDP checksum. In the case the ICMP
   Error payload includes ICMP extensions ([ICMP-EXT]), the NAT device
   SHOULD exclude the optional zero-padding and the ICMP extensions
   when evaluating transport checksum for the embedded packet. If the
   transport checksum fails, the NAT device SHOULD drop the Error
   packet. Readers are urged to refer [ICMP-EXT] for identifying the
   presence of ICMP extensions in an ICMP message.
   
   When the IP packet embedded within the ICMP Error message includes
   IP options, the NAT device MUST NOT assume that the transport header 
   of the embedded packet is at a fixed offset (as would be the case
   when there are no IP options associated with the packet) from the
   start of the embedded packet. Specifically, the NAT device SHOULD
   index past all IP options when locating the start of transport
   header for the embedded packet.
   
   REQ-3:  When an ICMP Error packet is received, the NAT device 

Srisuresh, et. al.                                              [Page 7]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

   SHOULD do the following.
   a) If the IP checksum of the embedded packet fails to validate, drop 
   the Error packet; and
   b) If the embedded packet includes IP options, traverse past the 
   IP options to locate the start of transport header for the embedded
   packet; and
   c) If the ICMP Error payload contains ICMP extensions([ICMP-EXT]), 
   exclude the optional zero-padding and the ICMP extensions when
   evaluating transport checksum for the embedded packet; and
   d) If the embedded packet contains the entire transport segment, 
   and the transport protocol of the embedded packet requires the
   recipient to validate the transport checksum, and the checksum
   fails to validate, drop the Error packet.

4.2. ICMP Error Packet Translation

   Section 4.3 of [NAT-TRAD] describes the fields of an ICMP Error
   message that a NAT device translates. In this section, we describe
   the requirements a NAT device MUST conform to while performing the
   translations. Requirements identified in this section are necessary
   for the current applications to work correctly.

   Consider the following scenario in figure 1. Say, NAT-xy is a NAT
   device connecting hosts in private and external networks.
   Router-x and Host-x are in the external network. Router-y and
   Host-y are in the private network. The subnets in the external
   network are routable from the private as well as the external
   domains. By contrast, the subnets in the private network are only
   routable within the private domain. When Host-y initiated a session
   to Host-x, let us say that the NAT device mapped the endpoint on
   Host-y into Host-y' in the external network. The following
   subsections describe the processing of ICMP Error messages on the
   NAT device(NAT-xy), when the NAT device receives an ICMP Error
   message in response to a packet pertaining to this session.

Srisuresh, et. al.                                              [Page 8]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

                                  Host-x
                                     |
                             ---------------+-------------------
                                            |
                                     +-------------+
                                     |  Router-x   |
                                     +-------------+
               External Network             |
               --------------------+--------+-------------------
                                   |   ^ 
                                   |   | (Host-y', Host-x)
                                   |   |                  
                             +-------------+
                             |    NAT-xy   |
                             +-------------+
                                   |
       Private Network             | 
      ----------------+------------+----------------
                      |
               +-------------+
               | Router-y    |
               +-------------+
                      |
      ----------------+-------+--------
                              | ^
                              | | (Host-y, Host-x)
                              | |
                            Host-y

   Figure 1. A Session from a private host traversing a NAT device.

4.2.1. ICMP Error Packet Received from External Realm 

   Say, a packet from Host-y to Host-x triggered an ICMP Error message
   from one of Router-x or Host-x (both of which are in the external
   domain). Such an ICMP Error packet will have one of Router-x or 
   Host-x as the source IP address and Host-y' as the destination IP
   address as described in figure 2 below.

Srisuresh, et. al.                                              [Page 9]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

                                  Host-x
                                     |
                             ---------------+-------------------
                                            |
                                     +-------------+
                                     |  Router-x   |
                                     +-------------+
               External Network             |
               --------------------+--------+-------------------
                                   |
                                   |  | ICMP Error Packet to Host-y'
                                   |  v
                             +-------------+
                             |    NAT-xy   |
                             +-------------+
       Private Network             |
      ----------------+------------+----------------
                      |
               +-------------+
               | Router-y    |
               +-------------+
                      |
      ----------------+-------+--------
                              | 
                            Host-y

   Figure 2. ICMP Error Packet Received from External Network

   When the NAT device receives the ICMP Error packet, the NAT device
   MUST use the packet embedded within the ICMP Error message (i.e., 
   the IP packet from Host-y' to Host-x) to look up the NAT Session the
   embedded packet belongs to. If the NAT device does not have an
   active mapping for the embedded packet, the NAT SHOULD silently
   drop the ICMP Error packet. Otherwise, the NAT device MUST use
   the matching NAT Session to translate the embedded packet. That is,
   translate the source IP address of the embedded packet (e.g.,
   Host-y' -> Host-y) and transport headers.
   
   ICMP Error payload may contain ICMP extension objects ([ICMP-EXT]).
   NATs are encouraged to support ICMP extension objects. At the time
   of this writing, the authors are not aware of any standard ICMP
   extension objects containing realm specific information. 

   The NAT device MUST also use the matching NAT Session to translate
   the destination IP address in the outer IP header. In the outer
   header, the source IP address will remain unchanged because the
   originator of the ICMP Error message (Host-x or Router-x) is in

Srisuresh, et. al.                                             [Page 10]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

   external domain and routable from the private domain.

   REQ-4: If a NAT device receives an ICMP Error packet from external
   realm, and the NAT does not have an active mapping for the embedded
   payload, the NAT SHOULD silently drop the ICMP Error packet. If the
   NAT has active mapping for the embedded payload and local policy
   permits, then the NAT MUST do the following prior to forwarding the
   packet. 
   a) Revert the IP and transport headers of the embedded IP packet to
   their original form, using the matching mapping; and
   b) Leave the ICMP Error type and code unchanged; and
   c) Modify the destination IP address of the outer IP header to be
   same as the source IP address of the embedded packet after
   translation.

4.2.2. ICMP Error Packet Received from Private Realm
 
   Now, say, a packet from Host-x to Host-y triggered an ICMP Error
   message from one of Router-y or Host-y (both of which are in the
   private domain). Such an ICMP Error packet will have one of
   Router-y or Host-y as the source IP address and Host-x as the
   destination IP address as specified in figure 3 below.

Srisuresh, et. al.                                             [Page 11]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

                                  Host-x
                                     |
                             ---------------+-------------------
                                            |
                                     +-------------+
                                     |  Router-x   |
                                     +-------------+
               External Network             |
               --------------------+--------+-------------------
                                   |
                                   |
                             +-------------+
                             |    NAT-xy   |
                             +-------------+
                                   |  ^
                                   |  | ICMP Error Packet to Host-x
       Private Network             |
      ----------------+------------+----------------
                      |
               +-------------+
               | Router-y    |
               +-------------+
                      |
      ----------------+-------+--------
                              |
                            Host-y

   Figure 3. ICMP Error Packet Received from Private Network

   When the NAT device receives the ICMP Error packet, the NAT device
   MUST use the packet embedded within the ICMP Error message (i.e., 
   the IP packet from Host-x to Host-y) to look up the NAT Session the
   embedded packet belongs to. If the NAT device does not have an
   active mapping for the embedded packet, the NAT SHOULD silently
   drop the ICMP Error packet. Otherwise, the NAT device MUST use
   the matching NAT Session to translate the embedded packet. 

   ICMP Error payload may contain ICMP extension objects ([ICMP-EXT]).
   NATs are encouraged to support ICMP extension objects. At the time
   of this writing, the authors are not aware of any standard ICMP
   extension objects containing realm specific information. 

   In the outer header, the destination IP address will remain
   unchanged, as the IP addresses for Host-x is already in the external
   domain. If the ICMP Error message is generated by Host-y, the NAT
   device must simply use the NAT Session to translate the source IP
   address Host-y to Host-y'. If the ICMP Error message is originated

Srisuresh, et. al.                                             [Page 12]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

   by the intermediate node Router-y, translation of the source IP
   address varies depending on whether Basic NAT or NAPT function
   ([NAT-TRAD]) is enforced by the NAT device. A NAT device enforcing
   Basic NAT function has a pool of public IP addresses and enforces
   address mapping (which is different from the endpoint mapping
   enforced by NAPT) when a private node initiates an outgoing session
   via the NAT device. So, if the NAT device has active mapping for
   the IP address of the intermediate node Router-y, the NAT device
   MUST translate the source IP address of the ICMP Error packet with
   the public IP address in the mapping. In all other cases, the NAT
   device MUST simply use its own IP address in the external domain
   to translate the source IP address.

   REQ-5: If a NAT device receives an ICMP Error packet from private
   realm, and the NAT does not have an active mapping for the embedded
   payload, the NAT SHOULD silently drop the ICMP Error packet. If the
   NAT has active mapping for the embedded payload and local policy
   permits, then the NAT MUST do the following prior to forwarding the
   packet.
   a) Revert the IP and transport headers of the embedded
   IP packet to their original form, using the matching mapping; and
   b) Leave the ICMP Error type and code unchanged; and
   c) If the NAT enforces Basic NAT function ([NAT-TRAD]), and the NAT
   has active mapping for the IP address that sent the ICMP Error, 
   translate the source IP address of the ICMP Error packet with the
   public IP address in the mapping. In all other cases, translate the
   source IP address of the ICMP Error packet with its own public IP
   address.

4.3. NAT Sessions Pertaining to ICMP Error Payload

   While processing an ICMP Error packet pertaining to an ICMP Query
   or Query response message, a NAT device MUST NOT refresh or delete
   the NAT Session that pertains to the embedded payload within the 
   ICMP Error packet. This is in spite of the fact that the NAT device
   uses the NAT Session to translate the embedded payload. This ensures
   that the NAT Session will not be modified if someone is able to
   spoof ICMP Error messages for the session. [ICMP-ATK] lists a number
   of potential ICMP attacks that may be attempted by malicious users
   on the network. This requirement is necessary for current
   applications to work correctly.

   REQ-6: While processing an ICMP Error packet pertaining to an ICMP
   Query or Query response message, a NAT device MUST NOT refresh or
   delete the NAT Session that pertains to the embedded payload within
   the ICMP Error packet.

Srisuresh, et. al.                                             [Page 13]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

5. Hairpinning Support for ICMP packets

   [BEH-UDP] and [BEH-TCP] mandate support for hairpinning for UDP and
   TCP sessions respectively on NAT devices. A NAT device needs to 
   support hairpinning for ICMP Query sessions as well. Specifically,
   ICMP Query hairpinning MUST be supported on Basic NATs. Say, for 
   example, individual private hosts register their NAT assigned
   external IP address with a rendezvous server. Other hosts that wish
   to initiate ICMP Query sessions to the registered hosts might do so
   using the public address registered with the Rendezvous server. For
   this reason, Basic NAT devices MUST support the traversal of 
   hairpinned ICMP Query sessions. This requirement is necessary for 
   current applications to work correctly.

   Packets belonging to any of the hairpinned sessions could in turn
   trigger ICMP Error messages directed to the source of hairpinned
   IP packets. Such hairpinned ICMP Error messages will traverse the
   NAT devices enroute. All NAT devices  (i.e., Basic NAT as well as
   NAPT devices) MUST support the traversal of hairpinned ICMP Error
   messages. Specifically, the NAT device must translate not only the
   embedded hairpinned packet, but also the outer IP header that is
   hairpinned. This requirement is necessary for current applications
   to work correctly.

   A hairpinned ICMP Error message is received from a node in private
   network. As such, the ICMP Error processing requirement specified
   in Req-5 is applicable in its entirety in processing the ICMP
   Error message. In addition, the NAT device MUST translate the
   destination IP address of the outer IP header to be same as the
   source IP address of the embedded IP packet after the translation.

   REQ-7: NAT devices enforcing Basic NAT ([NAT-TRAD]) MUST support the
   traversal of hairpinned ICMP Query sessions. All NAT devices (i.e., 
   Basic NAT as well as NAPT devices) MUST support the traversal of
   hairpinned ICMP Error messages. 
   a) When forwarding a hairpinned ICMP Error message, the NAT device
   MUST translate the destination IP address of the outer IP header to
   be same as the source IP address of the embedded IP packet after
   the translation.

6. Rejection of Outbound Flows Disallowed by NAT

   A NAT device typically permits all outbound sessions. However,
   a NAT device may disallow some outbound sessions due to resource
   constraints or administration considerations. For example, a NAT
   device may not permit the first packet of a new outbound session,
   if the NAT device is out of resources (out of addresses or TCP/UDP

Srisuresh, et. al.                                             [Page 14]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

   ports or NAT Session resources) to set up a state for the session,
   or, the specific session is administratively restricted by the NAT
   device.

   When the first packet of an outbound flow is prohibited by a NAT
   device due to resource constraints or administration considerations, 
   the NAT device SHOULD send ICMP destination unreachable message.
   Section 5.2.7.1 of [RFC1812] recommends routers to use ICMP code 13 
   (Communication administratively prohibited) when they 
   administratively filter packets. ICMP code 13 is a soft error and 
   is on par with other soft error codes generated in response to
   transient events such as 'network unreachable' (ICMP type=3, 
   code=0). A NAT device SHOULD use ICMP code 13 when generating an
   ICMP Error message. This requirement is meant primarily for future
   use. Current applications do not require this for them to work
   correctly.

   Some NAT designers opt to never reject an outbound flow. When a 
   NAT runs short of resources, they prefer to steal a resource 
   from an existing NAT Session rather than reject the outbound flow.
   Such a design choice may appear conformant to REQ-8 below. However,
   the design choice is in violation of the spirit of both REQ-8 and 
   REQ-2. Such a design choice is strongly discouraged. 
    
   REQ-8: When a NAT device is unable to establish a NAT Session for a
   new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource
   constraints or administrative restrictions, the NAT device SHOULD
   send an ICMP destination unreachable message, with a code of 13
   (Communication administratively prohibited) to the sender, and drop
   the original packet.

7. Conformance to RFC 1812

   A NAT device is inherently an intermediate router that forwards 
   IP packets between private and external realms. As such, the NAT 
   device MUST conform to all the requirements of a router, as 
   specified in [RFC1812]. Section 5.2.7.1 of [RFC1812] states that
   a router MUST also be able to generate ICMP Destination Unreachable
   messages and SHOULD choose a response code that most closely matches
   the reason the message is being generated. 

   Note, however, NAT devices also function as hosts on the Internet
   and are bound by the conformance requirements in [RFC1122]. 
   Protocol-specific BEHAVE documents ([BEH-UDP], [BEH-TCP]) identify
   instances where a NAT device should deviate from RFC 1122. As such,
   the host behavior requirements of NAT devices specified in the
   protocol-specific BEHAVE drafts take precedence over RFC 1122.

Srisuresh, et. al.                                             [Page 15]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

   The focus of this section is on conformance to router requirements.
   The following sub sections identify specific instances where a NAT 
   device would be expected to conform to [RFC1812].

7.1. IP packet fragmentation

   Many networking applications (which include TCP as well as UDP based
   applications) depend on ICMP Error messages from the network to
   perform end-to-end path MTU discovery [PMTU]. Once path MTU is
   discovered, an application that chooses to avoid fragmentation may
   do so by originating IP packets that fit within the Path MTU enroute
   and setting the DF (Don't Fragment) bit in the IP header, so the
   intermediate nodes enroute do not fragment the IP packets. The
   following sub-sections discuss the need for NAT devices to honor the
   DF bit in the IP header and be able to generate "Packet Too Big" 
   ICMP Error message when they cannot forward the IP packet without
   fragmentation. Also discussed is the need to seamlessly forward
   ICMP Error messages generated by other intermediate devices.

7.1.1. Generating "Packet Too Big" ICMP Error Message

   When a router is unable to forward a datagram because it exceeds
   the MTU of the next-hop network and its Don't Fragment (DF) bit is
   set, the router is required by [RFC1812] to return an ICMP
   Destination Unreachable message to the source of the datagram, with
   the Code indicating "fragmentation needed and DF set". Further, 
   [PMTU] states that the router MUST include the MTU of that next-hop
   network in the low-order 16 bits of the ICMP header field that is
   labeled "unused" in the ICMP specification[ICMP].

   A NAT device MUST honor the DF bit in the IP header of the
   packets that transit the device. If the DF bit is set and the 
   MTU on the forwarding interface of the NAT device is such that
   the IP datagram cannot be forwarded without fragmentation, the
   NAT device MUST issue a "Packet Too Big" ICMP message (ICMP 
   type 3, Code 4) with a suggested MTU back to the sender and
   drop the original IP packet. The sender will usually resend after
   taking the appropriate corrective action. 

   If the DF bit is not set and the MTU on the forwarding interface
   of the NAT device mandates fragmentation, the NAT device MUST
   fragment the packet and forward the fragments [RFC1812].

7.1.2. Forwarding "Packet Too Big" ICMP Error Message

   This is flip side of the argument for the above section. By virtue
   of the address translation NAT performs, NAT may end up being the

Srisuresh, et. al.                                             [Page 16]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

   recipient of "Packet Too Big" message. 
 
   When NAT device is the recipient of "Packet Too Big" ICMP message
   from the network, the NAT device MUST forward the ICMP message back
   to the intended recipient, pursuant to the previously stated
   requirements REQ-3, REQ-4, REQ-5 and REQ-6.

7.2. Generating "Time Exceeded" Error Message

   Section 5.2.7.3 of [RFC1812] says that a router MUST generate
   "Time Exceeded" ICMP Error message when it discards a packet due
   to an expired TTL field. A router MAY have a per-interface option
   to disable origination of these messages on that interface, but that
   option MUST default to allowing the messages to be originated. 

7.3. RFC 1812 Conformance Requirements summary

   The requirements outlined in sections 7.1 and 7.2 are necessary for
   the current applications to work correctly. The following summarizes
   the requirements specified in sections 7.1 and 7.2,

   REQ-9: A NAT device MUST conform to RFC 1812 in IP packet handling.
   Below are specific instances where a NAT device MUST conform to 
   RFC 1812.
   a) A NAT MUST honor the DF bit in the IP header. If the DF bit is set
   on a transit IP packet and the NAT device cannot forward the packet
   without fragmentation, the NAT device MUST send a "Packet Too Big" 
   ICMP message (ICMP type 3, Code 4) with a suggested MTU back to the
   sender and drop the original IP packet. If the DF-bit is clear and 
   MTU mandates fragmentation, the NAT device MUST fragment the packet
   and forward the fragments.
   b) A NAT device  MUST, by default, generate "Time Exceeded" ICMP
   Error message when it discards a packet due to an expired TTL field,
   unless explicitly configured otherwise. 

8. Summary of Requirements

   In the preceding sections, ICMP requirements were identified for
   NAT devices, with primary focus on ICMP Query and ICMP Error
   messages. Post-1122 ICMP messages were not part of that discussion.
   A NAT MAY drop or appropriately handle post-1122 ICMP messages.
   Below is a summary of all the requirements.

   REQ-1: When local policy permits, a NAT device MUST permit ICMP 
   Queries and their associated responses, when the Query is initiated
   from a private host. 
   a) NAT mapping of ICMP Query identifiers SHOULD be external host 

Srisuresh, et. al.                                             [Page 17]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

   independent.

   REQ-2: An ICMP Query session timer MUST NOT expire in less than 60
   seconds.
   a) It is RECOMMENDED that the ICMP Query session timer be made
   configurable.

   REQ-3:  When an ICMP Error packet is received, the NAT device 
   SHOULD do the following.
   a) If the IP checksum of the embedded packet fails to validate, drop 
   the Error packet; and
   b) If the embedded packet includes IP options, traverse past the 
   IP options to locate the start of transport header for the embedded
   packet; and
   c) If the ICMP Error payload contains ICMP extensions([ICMP-EXT]), 
   exclude the optional zero-padding and the ICMP extensions when
   evaluating transport checksum for the embedded packet; and
   d) If the embedded packet contains the entire transport segment, 
   and the transport protocol of the embedded packet requires the
   recipient to validate the transport checksum, and the checksum
   fails to validate, drop the Error packet.

   REQ-4: If a NAT device receives an ICMP Error packet from external
   realm, and the NAT does not have an active mapping for the embedded
   payload, the NAT SHOULD silently drop the ICMP Error packet. If the
   NAT has active mapping for the embedded payload and local policy
   permits, then the NAT MUST do the following prior to forwarding the
   packet. 
   a) Revert the IP and transport headers of the embedded IP packet to
   their original form, using the matching mapping; and
   b) Leave the ICMP Error type and code unchanged; and
   c) Modify the destination IP address of the outer IP header to be
   same as the source IP address of the embedded packet after
   translation.

   REQ-5: If a NAT device receives an ICMP Error packet from private
   realm, and the NAT does not have an active mapping for the embedded
   payload, the NAT SHOULD silently drop the ICMP Error packet. If the
   NAT has active mapping for the embedded payload and local policy
   permits, then the NAT MUST do the following prior to forwarding the
   packet.
   a) Revert the IP and transport headers of the embedded
   IP packet to their original form, using the matching mapping; and
   b) Leave the ICMP Error type and code unchanged; and
   c) If the NAT enforces Basic NAT function ([NAT-TRAD]), and the NAT
   has active mapping for the IP address that sent the ICMP Error, 
   translate the source IP address of the ICMP Error packet with the
   public IP address in the mapping. In all other cases, translate the

Srisuresh, et. al.                                             [Page 18]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

   source IP address of the ICMP Error packet with its own public IP
   address.

   REQ-6: While processing an ICMP Error packet pertaining to an ICMP
   Query or Query response message, a NAT device MUST NOT refresh or
   delete the NAT Session that pertains to the embedded payload within
   the ICMP Error packet.

   REQ-7: NAT devices enforcing Basic NAT ([NAT-TRAD]) MUST support the
   traversal of hairpinned ICMP Query sessions. All NAT devices (i.e., 
   Basic NAT as well as NAPT devices) MUST support the traversal of
   hairpinned ICMP Error messages. 
   a) When forwarding a hairpinned ICMP Error message, the NAT device
   MUST translate the destination IP address of the outer IP header to
   be same as the source IP address of the embedded IP packet after
   the translation.

   REQ-8: When a NAT device is unable to establish a NAT Session for a
   new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource
   constraints or administrative restrictions, the NAT device SHOULD
   send an ICMP destination unreachable message, with a code of 13
   (Communication administratively prohibited) to the sender, and drop
   the original packet.

   REQ-9: A NAT device MUST conform to RFC 1812 in IP packet handling.
   Below are specific instances where a NAT device MUST conform to 
   RFC 1812.
   a) A NAT MUST honor the DF bit in the IP header. If the DF bit is set
   on a transit IP packet and the NAT device cannot forward the packet
   without fragmentation, the NAT device MUST send a "Packet too big" 
   ICMP message (ICMP type 3, Code 4) with a suggested MTU back to the
   sender and drop the original IP packet. If the DF-bit is clear and 
   MTU mandates fragmentation, the NAT device MUST fragment the packet
   and forward the fragments.
   b) A NAT device  MUST, by default, generate "Time Exceeded" ICMP
   Error message when it discards a packet due to an expired TTL field,
   unless explicitly configured otherwise. 

9. Security Considerations

   This document does not introduce any new security concerns related
   to ICMP Error message handling in the NAT devices. However, the
   document does propose counter measures to mitigate security concerns
   that already exist with ICMP Error messages.

   [ICMP-ATK] lists a number of ICMP attacks that can be directed 
   against end host TCP stacks and suggests remedies to counter the

Srisuresh, et. al.                                             [Page 19]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

   attacks. [TCP-SOFT] describes improvements to the handling of
   ICMP Error messages in many of the existing TCP/IP stacks, including
   Linux. Section 4 of this document describes a number of measures by
   which NAT devices should validate and update the embedded payload
   in ICMP Error messages prior to forwarding. These measures ensure
   that NATs forward the ICMP Error messages reliably, as stipulated
   in [ICMP-ATK].

   For example, a rogue entity could bombard the NAT device with a
   large number of ICMP Errors. If the NAT device did not
   validate the legitimacy of the ICMP Error packets, the ICMP Errors
   would be forwarded directly to the end nodes. End hosts not capable
   of defending themselves against such bogus ICMP Error attacks could
   be adversely impacted by such attacks. Req-3 recommends validating
   embedded payload prior to forwarding. Checksum validation by itself
   does not protect end hosts from attacks. However, checksum
   validation mitigates end hosts from malformed ICMP Error attacks. 
   Req-4 and Req-5 further mandate that when a NAT device does not find
   a mapping selection for the embedded payload, the NAT should drop
   the ICMP Error packets, without forwarding.

   A rogue source could also try and send bogus ICMP Error messages for
   the active NAT sessions, with an intent to destroy the sessions.
   Req-6 averts such an attack by ensuring that an ICMP Error message
   does not effect the state of a session on the NAT device.

   Req-8 recommends a NAT device sending ICMP Error message when the
   NAT device is unable to create a NAT session due to lack of
   resources. Some administrators may choose not to have the NAT device
   send ICMP Error message, as doing so could confirm to a malicious
   attacker that the attack has succeeded. For this reason, sending 
   of the specific ICMP Error message stated in REQ-8 should be
   left to the discretion of the NAT device administrator.

   Unfortunately, ICMP messages are sometimes blocked at network 
   boundaries due to local security policy. Thus, some of the
   requirements in this document allow local policy to override the
   recommendations of this document. Blocking such ICMP messages is
   known to break some protocol features (most notably Path MTU
   Discovery) and some applications (e.g., ping, traceroute), and
   such blocking is NOT RECOMMENDED.

10.  IANA Considerations

   There are no IANA considerations.

Srisuresh, et. al.                                             [Page 20]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

11. Acknowledgements

   The authors wish to thank Fernando Gont, Dan Wing, Carlos Pignataro,
   Philip Matthews and members of the BEHAVE work group for doing a
   thorough review of early versions of the document and providing
   valuable input and offering generous amount of their time in shaping
   the ICMP requirements. Their valuable feedback makes this document
   a better read. The authors appreciate that. Dan Wing and Fernando
   Gont have been a steady source of encouragement. Fernando Gont spent
   many hours preparing slides and presenting the document in an IETF
   meeting on behalf of the authors. For this, the authors are grateful
   to Fernando. The authors wish to thank Carlos Pignataro and
   Dan Tappan, authors of the [ICMP-EXT] document, for their feedback
   concerning ICMP extensions. The authors also wish to thank Philip 
   Matthews for agreeing to be a technical reviewer for the document. 

Normative References

[BEH-UDP]   F. Audet and C. Jennings, "NAT Behavioral Requirements for
            Unicast UDP", RFC 4787, January 2007.

[ICMP]      Postel, J., "Internet Control Message Protocol", STD 5,
            RFC 792, September 1981.

[ICMP-EXT]  Bonica, R., Gan, D., Nikander, P., Tappan, D., and
            Pignataro, C., "Extended ICMP to Support Multi-part
            Messages", RFC 4884, April 2007.

[NAT-MIB]   Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., 
            and Wang, C., "Definitions of Managed Objects for Network
            Address Translators (NAT)", RFC 4008, March 2005.

[NAT-TRAD]  Srisuresh, P., and Egevang, K., "Traditional IP Network
            Address Translator (Traditional NAT)", RFC 3022,
            January 2001.

[RFC793]    "Transmission Control Protocol DARPA Internet Program
            Protocol Specification", RFC 793, September 1981.

[RFC1812]   Baker, F., "Requirements for IP Version 4 Routers", 
            RFC 1812, June 1995.

[RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

Informative References

Srisuresh, et. al.                                             [Page 21]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

[BEH-APP]   Ford, B., Srisuresh, P., and Kegel, D., "Application Design
            Guidelines for Traversal through Network Address
            Translators", draft-ford-behave-app-05.txt (Work In
            Progress), March 2007.

[BEH-TCP]   Guha, S., Biswas, K., Ford, B., Sivakumar, S., and
            Srisuresh, P., "NAT Behavioral Requirements for TCP",
            draft-ietf-behave-tcp-07.txt (Work In Progress), 
            April 2007.

[ICMP-ATK]  Gont, F., "ICMP attacks against TCP",
            draft-ietf-tcpm-icmp-attacks-02.txt (Work In Progress),
            May 2007.

[MS-TRCRT]  Microsoft Support, "How to use the Tracert 
            command-line utility to troubleshoot TCP/IP problems
            in Windows", http://support.microsoft.com/kb/162326,
            October, 2006.

[NAT-TERM]  Srisuresh, P. and Holdrege, M., "IP Network Address
            Translator (NAT) Terminology and Considerations", RFC 2663,
            August 1999.

[PMTU]      Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
            November 1990.

[RFC1122]   Braden, R., "Requirements for Internet Hosts -- 
            Communication Layers", RFC 1122, October 1989.

[RFC1256]   Deering, S., "ICMP Router Discovery Messages", RFC1256,
            September 1991.

[RFC1470]   Stine, R., "FYI on a Network Management Tool Catalog: Tools
            for Monitoring and Debugging TCP/IP Internets and
            Interconnected Devices", RFC 1470, June 1993.

[RFC4065]   Kempf, J., "Instructions for Seamoby and Experimental
            Mobility Protocol IANA Allocations", RFC 4065, July 2005.

[TCP-SOFT]  Gont, F., "TCP's Reaction to Soft Errors", 
            draft-ietf-tcpm-tcp-soft-errors-06.txt (Work In Progress),
            June 2007.

[UNSAF]     Daigle, L., and IAB, "IAB Considerations for UNilateral
            Self-Address Fixing (UNSAF) Across Network Address
            Translation", RFC 3424, November 2002.

Srisuresh, et. al.                                             [Page 22]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

Author's Addresses:

   Pyda Srisuresh
   Kazeon Systems, Inc.
   1161 San Antonio Rd.
   Mountain View, CA 94043
   U.S.A.
   Phone: (408)836-4773
   E-mail: [email-masked]

   Bryan Ford
   Computer Science and Artificial Intelligence Laboratory
   Massachusetts Institute of Technology
   77 Massachusetts Ave.
   Cambridge, MA 02139
   U.S.A.
   Phone: (617) 253-5261
   E-mail: [email-masked]
   Web: http://www.brynosaurus.com/
 
   Senthil Sivakumar
   Cisco Systems, Inc.
   7100-8 Kit Creek Road
   PO Box 14987
   Research Triangle Park, NC  27709-4987
   U.S.A.
   Phone: +1 919 392 5158
   Email: [email-masked]

   Saikat Guha
   Cornell University
   331 Upson Hall
   Ithaca, NY  14853
   U.S.A.
   Email: [email-masked]

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

Srisuresh, et. al.                                             [Page 23]

Internet-Draft    NAT Behavioral Requirements for ICMP      October 2007

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Copyright Statement

   Copyright (C) The IETF Trust (2007).  
   
   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   IETF Trust.

Srisuresh, et. al.                                             [Page 24]

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 15 Oct 2007 18:22:27 +0300

Fine one me. A minor comment: In the table of contents, compare the 
different capitalization of "Big/big" in the titles of Section 7.1.1 and 
7.1.2. This is weird, because the titles themselves are correct.

/Miguel

Pyda Srisuresh wrote:
> ------------------------------------------------------------------------
> 
> 
> 
>

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 15 Oct 2007 08:51:39 -0700 (PDT)

Oops. Fixed in my private rev. Thanks.

regards,
suresh