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