Re: [BEHAVE] REQ-5, RFC5508

"Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com> Fri, 05 February 2010 13:09 UTC

Return-Path: <ssenthil@cisco.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07713A6902 for <behave@core3.amsl.com>; Fri, 5 Feb 2010 05:09:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.561
X-Spam-Level:
X-Spam-Status: No, score=-9.561 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5XmbQnsVLwD for <behave@core3.amsl.com>; Fri, 5 Feb 2010 05:09:55 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 39DCC3A6905 for <behave@ietf.org>; Fri, 5 Feb 2010 05:09:52 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApsEAO+na0urR7Ht/2dsb2JhbACcJ6JQmACEUgQ
X-IronPort-AV: E=Sophos;i="4.49,413,1262563200"; d="scan'208";a="296247998"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 05 Feb 2010 13:10:42 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o15DAgko007673; Fri, 5 Feb 2010 13:10:42 GMT
Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 05:10:42 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 05 Feb 2010 05:10:38 -0800
Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB095995E8@xmb-sjc-236.amer.cisco.com>
In-Reply-To: <fc9ed4e7196b.4b6c300e@huaweisymantec.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [BEHAVE] REQ-5, RFC5508
Thread-Index: AcqmL3XNq8/Q6Tw7SDi6uY5j9EzqtAAMRIBA
References: <fc9ed4e7196b.4b6c300e@huaweisymantec.com>
From: "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>
To: WashamFan <Washam.Fan@huaweisymantec.com>, behave@ietf.org
X-OriginalArrivalTime: 05 Feb 2010 13:10:42.0124 (UTC) FILETIME=[9E98E0C0:01CAA664]
Subject: Re: [BEHAVE] REQ-5, RFC5508
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2010 13:09:56 -0000

The NAT box itself has a public IP address assigned to its outgoing
interface/port which can be used instead of allocating one from the
address pool but it is upto the implementation. 

Senthil

-----Original Message-----
From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf
Of WashamFan
Sent: Friday, February 05, 2010 1:50 AM
To: behave@ietf.org
Subject: [BEHAVE] REQ-5, RFC5508

Hi,

THe text says

   REQ-5: If a NAT device receives an ICMP Error packet from the 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, then the NAT MUST do the following prior to
          forwarding the packet, unless explicitly overridden by local
          policy:

          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.
|

I have a comment on the last sentence. 

Please note that NAPT can have a address pool either. If the ICMP Error
message generated by an intermediate node in the interal realm, and NAPT
has no corresponding active mapping for this node. The last sentence
applies in this case, but which one should be picked up for mapping if
the NAPT has multiple external addresses.

Thanks,
washam


_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave