IETF Logo Mail Archive

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

Ted Lemon <ted.lemon@nominum.com> Wed, 07 May 2014 19:28 UTC

Return-Path: <Ted.Lemon@nominum.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 8A2C11A08E2 for <dhcwg@ietfa.amsl.com>; Wed, 7 May 2014 12:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.551
X-Spam-Level:
X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_55=1, J_BACKHAIR_56=1, RP_MATCHES_RCVD=-0.651] 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 XuNXh0YQBmv2 for <dhcwg@ietfa.amsl.com>; Wed, 7 May 2014 12:28:52 -0700 (PDT)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id D1B3F1A08E1 for <dhcwg@ietf.org>; Wed, 7 May 2014 12:28:52 -0700 (PDT)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D8AF41B82AA for <dhcwg@ietf.org>; Wed, 7 May 2014 12:28:48 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id C02D019005C; Wed, 7 May 2014 12:28:48 -0700 (PDT)
Received: from [172.17.67.243] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 7 May 2014 12:28:48 -0700
Content-Type: text/plain; charset="iso-2022-jp"
MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B00F31E@xmb-rcd-x04.cisco.com>
Date: Wed, 07 May 2014 14:28:38 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <9C5EC552-A039-4EC5-B475-3A58A3C9BC70@nominum.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> <87A01A92-7517-40A4-8DD0-EE29AADA4AF6@nominum.com> <CAJE_bqeKYoRzVxSgJHg2Ud6H2qEZGaEdFyD=4Ps84NTFyOdELA@mail.gmail.com> <489D13FBFA9B3E41812EA89F188F018E1B00EF3B@xmb-rcd-x04.cisco.com> <074EF8DF-6404-4D90-B56C-6955A3939A6D@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1B00F1F6@xmb-rcd-x04.cisco.com> <9EDC6F15-62FA-42B4-A145-94CEFAAE2918@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1B00F31E@xmb-rcd-x04.cisco.com>
To: Bernie Volz <volz@cisco.com>
X-Mailer: Apple Mail (2.1874)
X-Originating-IP: [192.168.1.10]
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/x6Q4ACp0BTktwJy1ybVexcBniJI
Cc: dhcwg <dhcwg@ietf.org>, 神明達哉 <jinmei@wide.ad.jp>, Ralph Droms <rdroms.ietf@gmail.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 19:28:53 -0000

On May 7, 2014, at 2:14 PM, Bernie Volz (volz) <volz@cisco.com> wrote:
> 1. There is client unicast. Though not sure how much it is used.

You may have missed the point in my message where I addressed that.   Since unicast _only_ happens on renewal, there is no latency issue.

> 2. From my understanding (at least from the IBM documentation), if the destination is local to link (i.e. client multicast), the link's MTU is used (not the min MTU). So this still benefits client multicast and most of the communication in DHCPv6 to use the FULL link's MTU.

Sure, but in that case it just doesn't matter.

> So the only case is when the next hop (again, either relay<->relay or relay<->server or client/server unicast cases where the next-hop isn't local to the link), will the 1280 MTU be used and result in fragmentation.
> 
> I don't know who well PMTU works these days for UDP and how widely it is implemented in the common stacks. If it works great, then maybe this option is unnecessary (as the components must likely to need them are probably on 'good' stacks - relays and servers that implement PMTU).

PMTU discovery is necessary for IPv6.   If the host stack doesn't support it, it's broken and needs fixed.   I have not heard of any cases of this.   Middlebox brokenness is an issue when packets cross networks that are not controlled by the operator.   That's not the case for DHCP.   So I don't think we need to be concerned about this.   This is another difference between DHCP and DNS.

v2.23.0 | Report a Bug | By Email