Re: NAT behavior for IP ID field
"t.petch" <daedulus@btconnect.com> Thu, 02 September 2010 09:12 UTC
Return-Path: <daedulus@btconnect.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 CE01C3A67E6 for <ietf@core3.amsl.com>; Thu, 2 Sep 2010 02:12:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[AWL=1.365, BAYES_00=-2.599]
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 kx3bwSDufe-z for <ietf@core3.amsl.com>; Thu, 2 Sep 2010 02:12:36 -0700 (PDT)
Received: from c2beaomr10.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by core3.amsl.com (Postfix) with ESMTP id 376783A67CF for <ietf@ietf.org>; Thu, 2 Sep 2010 02:12:35 -0700 (PDT)
Received: from pc6 (host81-153-11-67.range81-153.btcentralplus.com [81.153.11.67]) by c2beaomr10.btconnect.com with SMTP id FDM50489; Thu, 2 Sep 2010 10:12:27 +0100 (BST)
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C7F6A7B.025F, actions=tag
Message-ID: <00c601cb4a75$e428cfa0$4001a8c0@gateway.2wire.net>
From: "t.petch" <daedulus@btconnect.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>, John Kristoff <jtk@cymru.com>
References: <20100831150444.22bd579e@t61p> <D0D68D38-84CD-4773-BB7E-328E1A31898A@muada.com>
Subject: Re: NAT behavior for IP ID field
Date: Thu, 02 Sep 2010 10:04:52 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com
X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0205.4C7F6A94.0435, ss=1, fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine
X-Junkmail-IWF: false
Cc: 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: Thu, 02 Sep 2010 09:12:38 -0000
----- Original Message ----- From: "Iljitsch van Beijnum" <iljitsch@muada.com> To: "John Kristoff" <jtk@cymru.com> Cc: <ietf@ietf.org> Sent: Wednesday, September 01, 2010 11:53 AM > On 31 aug 2010, at 22:04, John Kristoff wrote: > > > I'm trying to locate an RFC that spells out the behavioral > > requirements, expectations or guidelines for NAT handling of the IP ID > > field, particularly for UDP messages. > > > If this is not written down anywhere, do NATs generally rewrite the ID > > field with or without the MF bit set? > > I don't know. > > We had a discussion about this in the BEHAVE working group while working on stateful IPv6-to-IPv4 translation. Unless I missed something, the ID field needs uniqueness for any combination of source, destination IP addresses and protocol. Assuming the source address doesn't change, this means an ID counter should be maintained per destination address + protocol pair, so the maximum number of packets can be transmitted for each such pair before an ID value is reused. This would be the optimal host behavior, and NATs should act like hosts in this regard. Reusing the ID field from the original packet has a much higher chance of seeing the same ID field for outstanding fragments of a different flow, which can cause undetected data corruption in 1 in 65535 cases when the TCP/UDP checksum doesn't catch this. > > Note that DF=1 doesn't save you from all of this, as RFC 2402 says: > > Mutable (zeroed prior to ICV calculation) > Type of Service (TOS) > Flags > > So it is legal to rewrite the DF bit from 1 to 0. I also know that this happens in the wild because I used to do this at one time. 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. Tom Petch > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf
- 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