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:59 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 ECE211A02F8 for <dhcwg@ietfa.amsl.com>; Wed, 7 May 2014 12:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 r0RwHBkDT5sG for <dhcwg@ietfa.amsl.com>; Wed, 7 May 2014 12:59:38 -0700 (PDT)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id CD34C1A0366 for <dhcwg@ietf.org>; Wed, 7 May 2014 12:59:38 -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 C47E91B82A4 for <dhcwg@ietf.org>; Wed, 7 May 2014 12:59:34 -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 A744619005C; Wed, 7 May 2014 12:59:34 -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:59:34 -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: <489D13FBFA9B3E41812EA89F188F018E1B00F3EF@xmb-rcd-x04.cisco.com>
Date: Wed, 07 May 2014 14:59:24 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <94504235-1ADB-4C0A-9AEB-E46A1746453E@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> <9C5EC552-A039-4EC5-B475-3A58A3C9BC70@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1B00F37C@xmb-rcd-x04.cisco.com> <18E909A0-1955-4E5B-A003-304FE2B946FD@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1B00F3EF@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/caakW2TvC0A9F-tnfHQnsZuOQb4
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:59:41 -0000

On May 7, 2014, at 2:52 PM, Bernie Volz (volz) <volz@cisco.com> wrote:
> So, I guess best to just rely on the Kernel PMTU support.

Yup.

> Getting back to this draft, I think pointing out that this can result in large packets and that for some communication (relay <-> relay/server, client/server unicast), PMTU support is critical. And, that where packets are larger than the v6 min mtu (1280), firewalls in the DHCPv6 communication path that drop fragments must not be used.

Yup.

> We can consider your request in 3315bis - I created http://trac.tools.ietf.org/group/dhcpv6bis/ticket/92.

Thanks.

BTW, reading Jinmei's excellent presentation, he does say one thing that contradicts what I said, and I would assume that he is correct and I am wrong: if you send a UDP Packet and get an ICMP too big back, the kernel doesn't retransmit.   So this would result in a retransmission on the DHCP side.   DHCP does retransmit, so this is okay, but it's worth being clear about it.

We _could_ consider defining a PMTU discovery mechanism at the application layer for DHCPv6, but I think we should wait until someone comes to us and says "we are having a problem" before doing so.

v2.23.0 | Report a Bug | By Email