Re: [dhcwg] RFC3315 DECLINE definition

Tim Chown <> Fri, 10 February 2017 10:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C62D11294B9 for <>; Fri, 10 Feb 2017 02:13:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.111
X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xM0paivCc-4M for <>; Fri, 10 Feb 2017 02:13:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 17FDF129487 for <>; Fri, 10 Feb 2017 02:13:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=K/omN3aZeLLrlv3d4hC3ydEtE2XMTqwPR+mrmO01Px8=; b=YViMpCifgwjRiCngtzc+cRb+IOsk6rhtHr6weXszl+l2Kpng0fFmD5Upv7NZCby1ftbMpdsu1HfZzAIw/T4HI7mDv8AKgXWeuorwBuJu7yr4bkTEYS5tar5JF6o2qiiHQM4Zr+9ytbpuc1rODm6OXF9CLiIXK9jesD6GXFNSu9I=
Received: from ( []) (Using TLS) by with ESMTP id uk-mta-103-7ZLvdDvaNzqUefDdL33uew-1; Fri, 10 Feb 2017 10:13:31 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Fri, 10 Feb 2017 10:13:30 +0000
Received: from ([fe80::69c4:89e7:78ae:238f]) by ([fe80::69c4:89e7:78ae:238f%14]) with mapi id 15.01.0888.026; Fri, 10 Feb 2017 10:13:30 +0000
From: Tim Chown <>
To: Simon Hobson <>
Thread-Topic: [dhcwg] RFC3315 DECLINE definition
Date: Fri, 10 Feb 2017 10:13:29 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <0540D77C-E307-4B96-A53B-81599408C8> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3259)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:a88:d510:1101:d517:d0:57c1:3897]
x-ms-office365-filtering-correlation-id: 8d1871ee-7777-4221-9f92-08d4519d7632
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1139;
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:Ujusza8xyA98Zv8lS92UuRoJjmF1z3rIbs5CUcjSXUj0l2Ws0TINEi2lRme4z4JLu7IYZQK5ciICeiXBQokYb5YVQzxjEBoSRcsFRn9u/OEZ4gI3nVqIIgIHUB8vnEc8EtLMRP+c6+/Qpj6lZAtHKjYYo2hn7qEt0mB0WofxgRrZRO3yYdZ3wNVS3lIG7PQP1vc0uH05vkt8TG4T4StMHsMcI17kMcNaNTrmvIliKYOrCoSpQ2ZV1ExFcKYmlU9wYDBUTMQ4/WcPQVEV1jdYKnGNm38IHgrUi124d59EfaRxRQlHRgo7NPvyW+52JzW2iVt99pW2/IYxl3IlyVkEYFPScBqBSfZ8Rdk9S/nJHrBGMsKmI3jNo41Mf8Mb/kPPceBsUq+9FvXU9OKc/KXhyHPX9baDCECKx60U3X37WO4nCTVBhtoY6eBq7sJsM5NDdXxJGMIg3HgAGvFQLKXj0I210V0SQLvLyKDJ3pywzcLFrBEU2Oa+lRZz7TsbbmjHshs9y2GMmQ6q3iARh8HJsQ==; 20:/aizYOAK12RWYdNxe2SYDchZt2jTXs9Sj6j3x1QLF5d3dWILe1Ak8tlCtyMD/9EaKmq6UToWoOD6i3ImdQcKq0oQuAytPaMk3SI192vtW2GQcswNqb6vGfWRJchW0Cllh1kgFgb6w6UpJP0FikbS3eFj3R54kZbo7B7DChOaU8Q=
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123558025)(20161123564025)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139;
x-forefront-prvs: 0214EB3F68
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(24454002)(199003)(189002)(8936002)(2900100001)(99286003)(76176999)(50986999)(92566002)(86362001)(36756003)(106356001)(8676002)(101416001)(3280700002)(6506006)(81166006)(81156014)(5660300001)(68736007)(7736002)(189998001)(6436002)(105586002)(53936002)(6486002)(5250100002)(3660700001)(102836003)(6116002)(6512007)(42882006)(2950100002)(57306001)(6916009)(38730400002)(53546003)(229853002)(83716003)(110136004)(4326007)(50226002)(82746002)(74482002)(6246003)(2906002)(93886004)(305945005)(33656002)(97736004)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 10:13:30.0045 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139
X-MC-Unique: 7ZLvdDvaNzqUefDdL33uew-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: <>
Cc: dhcwg <>
Subject: Re: [dhcwg] RFC3315 DECLINE definition
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Feb 2017 10:13:40 -0000

> On 9 Feb 2017, at 17:23, Simon Hobson <> wrote:
> "Mudric, Dusan (Dusan)" <> wrote:
>> -          Assignment of multiple IPV6 addresses, that the client cannot support
> I thought it was part of the spec that a client must be capable of being configured with multiple addresses. As a minimum it must support 2 - one link-local, and one globally unique if external connectivity is needed.

RFC 7934 is a good read on that topic, though as I think Bernie pointed out the DHCP set in Section 6 could have been slightly better written.

> "Mudric, Dusan (Dusan)" <> wrote:
>> I was just saying the validation is done in the application because DHCPv6 client cannot do it. It is about the network reachability and not about the application. Site-Local (FEC0::/10), for example, cannot be used by any device (RFC 3879: Deprecating Site Local Addresses. The prefix MUST NOT be reassigned for other use except by a future IETF standards action.)
> 1) How does the application know that allocation of such addresses isn't a deliberate policy decision ?
> 2) It's an "admin error" anyway and it will either a) be spotted fairly quickly due to the lack of connectivity, b) obviously isn't that important.
> And as I said before, there is nothing to stop the admin putting (say) an incorrect router address in DHCPv4 - and I can't say I've seen a lot of clamour for "we must handle this automatically" features.

Well, it’s a reason why those who favour hosts fate-sharing router discovery with their router(s) via RAs have objected to adding a DHCPv6 default gateway option. In a changing network topology/scenario, the DHCP server may not be configured with up-to-date information, or even after it is hosts may not have requested it.

I’m with Ted here - I am not sure what problem this suggestion really solves.  Or maybe it’s a reason to use SLAAC.