Re: [DNSOP] RFC 2671
Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Wed, 23 December 2009 22:43 UTC
Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04ED3A672E for <dnsop@core3.amsl.com>; Wed, 23 Dec 2009 14:43:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.734
X-Spam-Level: *
X-Spam-Status: No, score=1.734 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_NJABL_PROXY=1.643]
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 h+t8hvq-QD5i for <dnsop@core3.amsl.com>; Wed, 23 Dec 2009 14:43:45 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id A30543A67F2 for <dnsop@ietf.org>; Wed, 23 Dec 2009 14:43:44 -0800 (PST)
Received: (qmail 56111 invoked from network); 23 Dec 2009 23:27:14 -0000
Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 23 Dec 2009 23:27:14 -0000
Message-ID: <4B329CEB.7010906@necom830.hpcl.titech.ac.jp>
Date: Thu, 24 Dec 2009 07:42:51 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja, en
MIME-Version: 1.0
To: bmanning@vacation.karoshi.com
References: <20091223183707.GA29415@vacation.karoshi.com.>
In-Reply-To: <20091223183707.GA29415@vacation.karoshi.com.>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] RFC 2671
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Dec 2009 23:49:38 -0000
bmanning@vacation.karoshi.com wrote: > to wit: > > -P, --edns-packet-max=<size> > Specify the largest EDNS.0 UDP packet which is supported by the DNS for- > warder. Defaults to 1280, which is the RFC2671-recommended maximum for eth- > ernet. > > Is there any interest in revisting this RFC or should we be happy with a functional limit > on EDNS0 message size being 1280 bytes? The RFC needs revision. First of all, because the largest IPv4 header is 60B and UDP header is 8B, the following statement: > 4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP > reassembly buffer. is wrong and DNS requires the IPv4 reassembly buffer 580B or larger, which is beyond the requirement of 576B in RFC791. But, we can reasonably expect reassembly buffer > 1400B, of course. Then, it is reasonable to allow messages as large as 1280B over IPv4, as long as don't fragment bit is *NOT* asserted. Further, *IF* we can safely assume path MTU larger than 1348B, don't fragment bit may be asserted. But, if we can assume path MTU larger than 1348B, there is no point to perform path MTU discovery to send a 1348B packet. That is, we don't have to assert the don't fragment bit. On the other hand, for IPv6, as the minimum MTU is only 1280B long, even when there are no extension headers, DNS message size can be only as large as 1280-40-8=1232B. Worse, as extension headers are silently inserted for mobility and other purposes and can be infinitely lengthy, the DNS message size safely carried over IPv6 is 0B. You can request IETF to limit the maximum length of extension headers below certain limit (e.g. 208B to allow for 1024B messages), though a request was formally rejected by IPv6 WG when I did so last time with the exact example of the DNS message size requirement. It should be a lot of fun, because the request imply to change the IPv6 specification and all the implementations (at least those following RFC3542). Or, just stick to (port restricted) IPv4 and to ignore IPv6 saying "you have been warned". Masataka Ohta
- [DNSOP] RFC 2671 bmanning
- Re: [DNSOP] RFC 2671 bmanning
- Re: [DNSOP] RFC 2671 Paul Wouters
- Re: [DNSOP] RFC 2671 Masataka Ohta
- Re: [DNSOP] RFC 2671 Francis Dupont