Re: [dhcwg] MTU option for DHCPv6?

"Bernie Volz (volz)" <volz@cisco.com> Thu, 28 July 2016 15:05 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E524F12D647 for <dhcwg@ietfa.amsl.com>; Thu, 28 Jul 2016 08:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.807
X-Spam-Level:
X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 msY_xydNsWsI for <dhcwg@ietfa.amsl.com>; Thu, 28 Jul 2016 08:05:07 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31C612D7DB for <dhcwg@ietf.org>; Thu, 28 Jul 2016 08:05:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13128; q=dns/txt; s=iport; t=1469718306; x=1470927906; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EHIAcSKMjJu1Tv8Zcc7IkNIl1TRGx4F//8ue2UtsK+Y=; b=N5SdNVwhe5g9mlcmccN6Z88NkM6qTPqlh0xlDuOjeHNVjvXKQ8n7XaAI 1RH0GgOj7w3ufmiFziSTGGN8ZDAsDrm6YZ/fB9CngruzVK9QguYTmQBJI hJ8BHxN+Js4/1lkK94rt3LUsUsN6dsBmWHUZdrla4eHppPGJFIIH5+74M 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAgCSHppX/5RdJa1dgndOVnwGs2eFB?= =?us-ascii?q?YF9JIV5AhyBFzgUAQEBAQEBAV0nhFwBAQQBIwpMBQsCAQgRBAEBKAMCAgIwFAk?= =?us-ascii?q?IAgQOBQiIDwMPCA6teI1PAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWKd4JDgWckC?= =?us-ascii?q?R8CgkmCWgWZMgGGF4hegXKNVIZihUyDdwEeNoN6bgGHd38BAQE?=
X-IronPort-AV: E=Sophos;i="5.28,434,1464652800"; d="scan'208,217";a="303667704"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jul 2016 15:05:05 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u6SF55lf011094 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Jul 2016 15:05:05 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 28 Jul 2016 10:05:05 -0500
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 28 Jul 2016 10:05:05 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Lorenzo Colitti <lorenzo@google.com>
Thread-Topic: [dhcwg] MTU option for DHCPv6?
Thread-Index: AdHoQoGGAMbjaqWBR9aaxP1yToT6sgAB2X5AAABnFgAAAhk9oAAgutWAAACVwgAAAP0twAALRg2AAApvqUA=
Date: Thu, 28 Jul 2016 15:05:05 +0000
Message-ID: <5e520d66cf87409293b904d8670a2ded@XCH-ALN-003.cisco.com>
References: <8c706ad593cc403d9e738c7aafec8360@XCH15-05-05.nw.nos.boeing.com> <5671d2f3bf364bec9b70ab8cbb9cd2a9@XCH-ALN-003.cisco.com> <9db5a86d50314519b4fcc4589717f802@XCH15-05-05.nw.nos.boeing.com> <f98d75f73d224798a406084fdb4cdedc@XCH-ALN-003.cisco.com> <F22A046E-27FA-4EED-9699-70A6B3D49A66@gmx.com> <20AC7B4D-430C-4D56-8D5C-1E134AEEDA76@employees.org> <516a0ed770414d0095ca69905c3a83a3@XCH-ALN-003.cisco.com> <CAKD1Yr2nx_GeyZJ7YA3b1zktRUG-yvkRQKOVywzg0i7s=WTyaw@mail.gmail.com>
In-Reply-To: <CAKD1Yr2nx_GeyZJ7YA3b1zktRUG-yvkRQKOVywzg0i7s=WTyaw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.98.1.206]
Content-Type: multipart/alternative; boundary="_000_5e520d66cf87409293b904d8670a2dedXCHALN003ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/1md5_1d6XthBzT-TegzVDel72hI>
Cc: "<dhcwg@ietf.org>" <dhcwg@ietf.org>
Subject: Re: [dhcwg] MTU option for DHCPv6?
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 28 Jul 2016 15:05:12 -0000

> it looks like reconfigure messages MUST be discarded if they do not include authentication.

It has always been that way (see https://tools.ietf.org/html/rfc3315#section-15.11). Reconfigure uses the Reconfigure Key Authentication Protocol (the server provided the client the key at some point earlier in the client/server interaction). Of course, this does require the client to indicate it is willing to do Reconfigure.

BTW: If I understood draft-van-beijnum-multi-mtu, it is about using ND, not RAs. And this allows [link local] destination specific MTUs to be used.


-          Bernie

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Thursday, July 28, 2016 10:57 AM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: otroan@employees.org; Ian Farrer <ianfarrer@gmx.com>om>; Templin, Fred L <Fred.L.Templin@boeing.com>om>; <dhcwg@ietf.org> <dhcwg@ietf.org>
Subject: Re: [dhcwg] MTU option for DHCPv6?

On Thu, Jul 28, 2016 at 10:52 PM, Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>> wrote:
And, note that Fred had indicated "I'm operating on a link where I don't need to get any configuration information from RS/RA - everything comes from DHCPv6." So, looks like at least he wants DHCPv6 option(s).

Yes, but it doesn't have to be that way. Sending an RA would work just as well. Like all RA parameters, it also has the advantage that it is easier to update dynamically if needed. Doing that in DHCPv6 is more difficult, because at least as of RFC3315bis, it looks like reconfigure messages MUST be discarded if they do not include authentication.