Re: [dhcwg] RFC3315 DECLINE definition

"Mudric, Dusan (Dusan)" <dmudric@avaya.com> Fri, 10 February 2017 14:35 UTC

Return-Path: <dmudric@avaya.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 19CB312952C for <dhcwg@ietfa.amsl.com>; Fri, 10 Feb 2017 06:35:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 KAm4X-5QcCG7 for <dhcwg@ietfa.amsl.com>; Fri, 10 Feb 2017 06:35:07 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2A31295EA for <dhcwg@ietf.org>; Fri, 10 Feb 2017 06:35:07 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GjAAC6zp1Y/xUHmMZeGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8hGCphgQkHjVqSDJMngg+BSkMnhXsCgnY/GAECAQEBAQEBAQN?= =?us-ascii?q?fKIJbPQYHAwEBAQEoAQEBAQEBAQEBAQEBARwCD0EBARgBAQEBAgESG0EQBwQCA?= =?us-ascii?q?QgNAQMEAQELHQcyFAkIAgQBEggaiU4IAQ2kcY0HJgKLKQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAR2GTYRugTyBW4EnGIMygjEFiQVvhxWES4YeAYZugyCKU4gIhi+TF?= =?us-ascii?q?R85fk8VPIQ/BR2BYXUBAYdiK4EDAYELAQEB?=
X-IPAS-Result: =?us-ascii?q?A2GjAAC6zp1Y/xUHmMZeGQEBAQEBAQEBAQEBBwEBAQEBgm8?= =?us-ascii?q?hGCphgQkHjVqSDJMngg+BSkMnhXsCgnY/GAECAQEBAQEBAQNfKIJbPQYHAwEBA?= =?us-ascii?q?QEoAQEBAQEBAQEBAQEBARwCD0EBARgBAQEBAgESG0EQBwQCAQgNAQMEAQELHQc?= =?us-ascii?q?yFAkIAgQBEggaiU4IAQ2kcY0HJgKLKQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GT?= =?us-ascii?q?YRugTyBW4EnGIMygjEFiQVvhxWES4YeAYZugyCKU4gIhi+TFR85fk8VPIQ/BR2?= =?us-ascii?q?BYXUBAYdiK4EDAYELAQEB?=
X-IronPort-AV: E=Sophos;i="5.35,141,1484024400"; d="scan'208,217";a="214805173"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Feb 2017 09:35:05 -0500
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Feb 2017 09:35:05 -0500
Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.03.0319.002; Fri, 10 Feb 2017 09:35:04 -0500
From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
To: Simon Hobson <linux@thehobsons.co.uk>, dhcwg <dhcwg@ietf.org>
Thread-Topic: [dhcwg] RFC3315 DECLINE definition
Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEP//ubmAgABS6jD//68/gIAAUzJQ//+28gAACnV4EAAKQI6AAB7vbSAAMyFpAABwmj1wANVT+AABigYKQA==
Date: Fri, 10 Feb 2017 14:35:03 +0000
Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA18ED6@AZ-US1EXMB03.global.avaya.com>
References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <fd3365190bd445b1ad00a7d8043530dd@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <C16D3614-AD9E-4AB3-915B-5288DB0EB239@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <0540D77C-E307-4B96-A53B-81599408C8 F7@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <A3AFA8FF-FDEF-4058-814A-E687D5CC2969@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <A023117A-2B06-4660-88B9-9AB183F05B66@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <B2511278-5D7A-40E0-AC4A-60784C101A80@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk>
In-Reply-To: <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.11.85.50]
Content-Type: multipart/alternative; boundary="_000_9142206A0C5BF24CB22755C8EC422E457AA18ED6AZUS1EXMB03glob_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/lpIbpeIPUACMnE-sZIojLmGuF-U>
Subject: Re: [dhcwg] RFC3315 DECLINE definition
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: Fri, 10 Feb 2017 14:35:10 -0000

Thanks for all the comments. Personally, I don't think DHCPv6 should be used for the address assignment. That topic is already discussed in a different thread. Will not discuss it here. But, if it is used for the address assignment, I would like all of the questions below to be addressed by the protocol.



On  this topic, there are several open questions about DHCPv6 protocol:

- If the key feature of the stateful DHCPv6 is the address assignment, why there is no any address validation?

- Why is the human intervention a part of the protocol? Why the protocol requires an administrator not to make mistakes?

- Why the client must assign every address offered by the server? Why should the client save the advertised leases for every IAADDR in IA's, if the status code is STATUS_Success?

- Why the client must use the address that does not match any of the router prefixes?

- Why the client is not interworking with ND protocol?

- Why the client does not return the address it does not use?

- Why is DECLINE message associated with only one error code (DAD failed)?



In terms of the implementation, when the problems are understood, both the server and the client can be improved. The improvements can be done in flexible ways. For example, DHCPv6 client policies can be configured in the client configuration file. There is no need to change the client code.



Regards,

Dusan.



-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Simon Hobson
Sent: Thursday, February 09, 2017 12:23 PM
To: dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition



"Mudric, Dusan (Dusan)" <dmudric@avaya.com<mailto:dmudric@avaya.com>> 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.



On Thu, Feb 9, 2017 at 8:53 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com<mailto:dmudric@avaya.com>> wrote:

> " By your own admission, the device **DOES** have a valid working address, but for some reason the **APPLICATION** cannot use it."

>

> 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.)



So you don't configure your DHCP server to give out those IP addresses.  Problem solved.  This doesn't need a protocol change.  And should it (the FEC0::/10 prefix) be reassigned for other uses in a future IETF standards action, then one would need to change your

application again, and/or change the DHCP server again.   And, the

application may be in use in some network that already has that prefix in use because that network has not had the time to renumber that prefix into something like a Unique Local IPv6 prefix (RFC 4193).



--

Andre Kostur


On Feb 9, 2017, at 11:47 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com<mailto:dmudric@avaya.com>> wrote:
The server can do the same validation. If the server does the validation, it will be a new feature and there will be a mix of servers that do and do-not provide this validation. The client either has to talk to the server that does provide the validation or do the validation itself.

So why is it easier to have the client do the validation than the server?   You're adding protocol to make this work, and in order for this to be useful, changes are required on the server anyway.   These changes are quite a bit more complex than the changes required to simply do whatever validation you are arguing should be done.   So why not do it the easy way instead of the hard way?


This is the first problem statement. There are two more:
-          Assignment of multiple IPV6 addresses, that the client cannot support

Then the client is broken.   Why not fix it instead of adding more protocol?


-          A change of IPv6 address, that the client cannot handle

Again, the client is broken.   Why not fix it instead of adding more protocol?



On Thu, Feb 9, 2017 at 8:47 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com<mailto:dmudric@avaya.com>> wrote:

> This is the first problem statement. There are two more:

>

> -          Assignment of multiple IPV6 addresses, that the client cannot

> support



Already dealt with by the protocol.  The server OFFERs 2 addresses, the client just REQUESTs one of them.



--

Andre Kostur





"Mudric, Dusan (Dusan)" <dmudric@avaya.com<mailto:dmudric@avaya.com>> 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.



_______________________________________________

dhcwg mailing list

dhcwg@ietf.org<mailto:dhcwg@ietf.org>

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dhcwg&d=DQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=2pBdk64V6N1NIvcAysqRqvG-d1lULT9TqIVtrbk-o8w&s=1tSJd7nDKcvuC97XDWtrkjskLaJPuQovExyz6N3kI_A&e=