IETF Logo Mail Archive

Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

神明達哉 <jinmei@wide.ad.jp> Wed, 07 May 2014 15:57 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EF41A0367 for <dhcwg@ietfa.amsl.com>; Wed, 7 May 2014 08:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfCUHQvqELa3 for <dhcwg@ietfa.amsl.com>; Wed, 7 May 2014 08:57:32 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id B29C61A035C for <dhcwg@ietf.org>; Wed, 7 May 2014 08:57:31 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id z12so1231131wgg.24 for <dhcwg@ietf.org>; Wed, 07 May 2014 08:57:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=QxYk2MKGGL+EWy/8is5vDYGHiw0r5fRCbyXWCB5lTOc=; b=NKyTPsXzrIu/5/2ZqVeSPBJC3MqplIP7v3n+1i2Ga1G0SCeUovDQPQ68plAQ3m3rhU N7c5T1/4EhQxmkpD8QDr4bNj/0C2sIC1QSiP1GyuXVgh6tnSKhkgfLCkB0rvwBLao9dw hDWgwnjbHqB2i9NM5QzWrdb7P8U+VxaTI9l5wt5WTDo7SFf/7KCWzc6EFohGbccWF0BY Is+jQp5OArF5UTJLyWcz0rsnplCy9YOwFMzeqP/T3OSeTo4Heg22tELKuXoiNDNH70Xz McwWSNT/3idR5lN/CpTU9dSY4/16BZP8El9IXLz2+DYpr6CJvJb6ayapjKZcmaps/EZG VDww==
MIME-Version: 1.0
X-Received: by 10.180.75.45 with SMTP id z13mr27300674wiv.41.1399478246911; Wed, 07 May 2014 08:57:26 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.3.14 with HTTP; Wed, 7 May 2014 08:57:26 -0700 (PDT)
In-Reply-To: <4891B713-5C8E-414A-99D7-64869C2E6F3A@gmail.com>
References: <535FEDAD.5010103@gmail.com> <CAJE_bqen37j5UCsKZj6syVyvk2Xed4V_xGp-t4xY8shjmS+H5g@mail.gmail.com> <489D13FBFA9B3E41812EA89F188F018E1B008430@xmb-rcd-x04.cisco.com> <4F2473AB-E8F7-4620-874C-3DCA59E70DE5@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923AE431FB@nkgeml512-mbx.china.huawei.com> <489D13FBFA9B3E41812EA89F188F018E1B00BAC1@xmb-rcd-x04.cisco.com> <9A6A9452-AF57-4EE1-9401-E0CE26922E6B@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923AE438BE@nkgeml512-mbx.china.huawei.com> <4891B713-5C8E-414A-99D7-64869C2E6F3A@gmail.com>
Date: Wed, 07 May 2014 08:57:26 -0700
X-Google-Sender-Auth: HLABasbyniXwy13UMx-r2RUte6w
Message-ID: <CAJE_bqc+qofsHEHZyuG7UotHmZ170OuFoUzz13hz7Rj_8V5FsA@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: Ralph Droms <rdroms.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Fk9NhtVn4eDtwg3W8vhCS4XEY4Y
Cc: dhcwg <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 15:57:33 -0000

At Wed, 7 May 2014 07:23:20 -0400,
Ralph Droms <rdroms.ietf@gmail.com> wrote:

> However, this extension to DHCPv6 may result in DHCPv6 messages that are much larger than current messages (and are much larger than the original designers of DHCP generally anticipated).  It may require the use of IPv6 fragmentation, which is not widely used and which introduces some potential problems with UDP transport.  Therefore, I think it would be prudent to add some explicit analysis and notice to implementors and deployers of this extension about the issues around large DHCPv6 messages.

I agree.

One specific point: newer DHCPv6 implementations that support this
protocol would have to use the IPV6_USE_MIN_MTU socket option (or
something equivalent to it), for exact the same kind of reason why all
modern DNS server implementations use it on UDP sockets.  I've quickly
checked a few open source implementations, and found none of them use
this option right now.  I'm not sure whether this draft should be as
specific as to mention that particular socket option, but at least
some higher level notes to implementors would be very helpful to avoid
surprise beforehand.

--
JINMEI, Tatuya

v2.23.0 | Report a Bug | By Email