Re: NAT behavior for IP ID field
Stephen Kent <kent@bbn.com> Tue, 14 September 2010 16:20 UTC
Return-Path: <kent@bbn.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4893A6898 for <ietf@core3.amsl.com>; Tue, 14 Sep 2010 09:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.892
X-Spam-Level:
X-Spam-Status: No, score=-101.892 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, USER_IN_WHITELIST=-100]
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 a661gYCltSAM for <ietf@core3.amsl.com>; Tue, 14 Sep 2010 09:20:03 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id B803B3A68D9 for <ietf@ietf.org>; Tue, 14 Sep 2010 09:20:03 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:33382 helo=[192.168.4.205]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1OvYEt-0005HV-V6; Tue, 14 Sep 2010 12:20:12 -0400
Mime-Version: 1.0
Message-Id: <p06240800c8b4f7967812@[195.12.186.7]>
In-Reply-To: <4C8A962A.6080202@gont.com.ar>
References: <20100831150444.22bd579e@t61p> <D0D68D38-84CD-4773-BB7E-328E1A31898A@muada.com> <00c601cb4a75$e428cfa0$4001a8c0@gateway.2wire.net> <4C8A962A.6080202@gont.com.ar>
Date: Tue, 14 Sep 2010 06:00:58 -0400
To: Fernando Gont <fernando@gont.com.ar>
From: Stephen Kent <kent@bbn.com>
Subject: Re: NAT behavior for IP ID field
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: Iljitsch van Beijnum <iljitsch@muada.com>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2010 16:20:05 -0000
>... > > > >> Curious; RFC2402 says >> " Flags -- This field is excluded since an intermediate router might >> set the DF bit, even if the source did not select it." >> which is a licence to set the bit but I had not thought to reset the bit. >> RFC791, RFC1122 and RFC1812 would appear to be silent on this. > >I'm curious abut RFC 2402, then. Firstly, the host might not implement >PMTUD, and hence setting the DF bit on its behalf could possibly cause >interoperability problems. Secondly, some hosts clear the DF bit if the >advertised MTU in an ICMP "frag needed" is below some specified >threshols. This RFC2402-behavior could cause problems in this scenario, too. We made the decision ton exclude the DF bit from the ICV computation in 2402, based on what we believed was happening in the net, irrespective of what should have been happening ;-). We retained this behavior in RFC 4202, for the same reason. Steve
- NAT behavior for IP ID field John Kristoff
- Re: NAT behavior for IP ID field Iljitsch van Beijnum
- Re: NAT behavior for IP ID field t.petch
- Re: NAT behavior for IP ID field Iljitsch van Beijnum
- Re: NAT behavior for IP ID field Fernando Gont
- Re: NAT behavior for IP ID field Stephen Kent
- Re: NAT behavior for IP ID field Joe Touch