IETF Logo Mail Archive

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

"Bernie Volz (volz)" <volz@cisco.com> Wed, 07 May 2014 16:06 UTC

Return-Path: <volz@cisco.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 001271A0791 for <dhcwg@ietfa.amsl.com>; Wed, 7 May 2014 09:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.852
X-Spam-Level:
X-Spam-Status: No, score=-14.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 gCrFolU5WDvJ for <dhcwg@ietfa.amsl.com>; Wed, 7 May 2014 09:06:00 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB141A0392 for <dhcwg@ietf.org>; Wed, 7 May 2014 09:06:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2932; q=dns/txt; s=iport; t=1399478756; x=1400688356; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aYFAbIiuKsedDIDEO/hZcUsm5F/+lEJ1Wy5JzGrh9z0=; b=OchBRcp1nHt3wyGphvVd/59uOdDprfKr8NLXmsovjef/rDpNnIRsaL+N vas+RmOA5m0wAmZMorxAlTomy/TdqMt/bpXRUNvv6lzL03066tciP8pfm 8EhIHy82z/FSFFcZcxjHk6GiA5XmI1/xSuMI/q4G5y6X3eUV8xIUzAVX7 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiAFAMtYalOtJA2F/2dsb2JhbABagwaBJ4JnwjMBGYEAFnSCJQEBAQMBIxFFBQcEAgEIEQQBAQMCBh0DAgICHxEUAQgIAgQBDQUIiCUDCQiqO55vDYZIF4Eqihl4gWYWGwcGgm42gRUBA5dFjwyFYYM0gi8
X-IronPort-AV: E=Sophos;i="4.97,1004,1389744000"; d="scan'208";a="323092466"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP; 07 May 2014 16:05:55 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s47G5tKr014366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 16:05:55 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 7 May 2014 11:05:55 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: 神明達哉 <jinmei@wide.ad.jp>, Ralph Droms <rdroms.ietf@gmail.com>
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18
Thread-Index: AQHPag0KHMzNFfxEIk6wcBa/GM4ndJs1Rs+w
Date: Wed, 07 May 2014 16:05:55 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B00ECF9@xmb-rcd-x04.cisco.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> <CAJE_bqc+qofsHEHZyuG7UotHmZ170OuFoUzz13hz7Rj_8V5FsA@mail.gmail.com>
In-Reply-To: <CAJE_bqc+qofsHEHZyuG7UotHmZ170OuFoUzz13hz7Rj_8V5FsA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [161.44.70.121]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Vtw0_Rz1sQWoDpxPrQBXQX7uGw0
Cc: dhcwg <dhcwg@ietf.org>
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 16:06:02 -0000

I agree with Jinmei and Ralph that this packet size should be mentioned in the document.

I think explicitly mentioning IPV6_USE_MIN_MTU socket option as an EXAMPLE (i.e., e.g.) would be a good idea. Makes it easier for all to find this particular feature (and possibly map it to whatever stack they are using).

At least from the one description of this that I found it looks to be exactly what you want:

"A value of 1 enables this option for unicast and multicast destinations. All packets are sent without using path MTU discovery information, using the minimum MTU size, unless a direct route is available to the destination."

- Bernie

-----Original Message-----
From: jinmei.tatuya@gmail.com [mailto:jinmei.tatuya@gmail.com] On Behalf Of ????
Sent: Wednesday, May 07, 2014 11:57 AM
To: Ralph Droms
Cc: Sheng Jiang; dhcwg; Bernie Volz (volz)
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

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