IETF Logo Mail Archive

Re: [dhcwg] RFC3315 DECLINE definition

"Mudric, Dusan (Dusan)" <dmudric@avaya.com> Thu, 09 February 2017 15:46 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 D033C129AB5 for <dhcwg@ietfa.amsl.com>; Thu, 9 Feb 2017 07:46:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.919
X-Spam-Level:
X-Spam-Status: No, score=-6.919 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, URIBL_BLOCKED=0.001] 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 mG2vfKTN5B_b for <dhcwg@ietfa.amsl.com>; Thu, 9 Feb 2017 07:46:24 -0800 (PST)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.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 096E21299E1 for <dhcwg@ietf.org>; Thu, 9 Feb 2017 07:46:23 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2ETAQBWjpxY/xUHmMZdGQEBAQEBAQEBAQEBBwEBAQEBgm8hQWGBCQeDUooIkgmTJ4IPggyGIgIaglA/GAECAQEBAQEBAQNfKIRpAQEBAQMSEQpMEAIBCA0BAwQBAQsdAwICAjAUCQgCBA4FCBMHiVIBpSiKYoIlJgKLHwEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GTYRugTyDAhgVH4JQLoIxBYl0i2CGHAGcZ4YvkxMfOX5PFYR7ggN1h3IBgQsBAQE
X-IPAS-Result: A2ETAQBWjpxY/xUHmMZdGQEBAQEBAQEBAQEBBwEBAQEBgm8hQWGBCQeDUooIkgmTJ4IPggyGIgIaglA/GAECAQEBAQEBAQNfKIRpAQEBAQMSEQpMEAIBCA0BAwQBAQsdAwICAjAUCQgCBA4FCBMHiVIBpSiKYoIlJgKLHwEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GTYRugTyDAhgVH4JQLoIxBYl0i2CGHAGcZ4YvkxMfOX5PFYR7ggN1h3IBgQsBAQE
X-IronPort-AV: E=Sophos;i="5.35,349,1484024400"; d="scan'208,217";a="190087705"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Feb 2017 10:46:16 -0500
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 10:46:16 -0500
Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 10:46:15 -0500
From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
To: Ted Lemon <mellon@fugue.com>
Thread-Topic: [dhcwg] RFC3315 DECLINE definition
Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEP//ubmAgABS6jA=
Date: Thu, 09 Feb 2017 15:46:14 +0000
Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA189BD@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>
In-Reply-To: <C16D3614-AD9E-4AB3-915B-5288DB0EB239@fugue.com>
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_9142206A0C5BF24CB22755C8EC422E457AA189BDAZUS1EXMB03glob_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/sJOBSEzjUzg6xymkxQ1MCis9a0A>
Cc: dhcwg <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>
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: Thu, 09 Feb 2017 15:46:26 -0000

The first problem statement is about the server misconfiguration. Instead of client silently ignoring the offered address, or even worse, assigning the misconfigured address, the server (and administrator) should be informed about the misconfiguration.

Regards,
Dusan Mudric.

From: Ted Lemon [mailto:mellon@fugue.com]
Sent: Thursday, February 09, 2017 10:41 AM
To: Mudric, Dusan (Dusan)
Cc: Bernie Volz (volz); dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

On Feb 9, 2017, at 10:38 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com<mailto:dmudric@avaya.com>> wrote:
1.       When DHCPv6 client starts it sends SOLICIT with IA option (without or with IPv6 address). The server sends ADVERTISE message offering IPv6 address(es). If the server offers IPv6 address(es) that client cannot use (e.g. an address with wrong semantics, a multicast address, a reserved address, … , a second address and the client can support only one address), the client should be able to respond to the server indicating which address it cannot use.

Let me stop you here.   This is a server misconfiguration.   The server is not artificially intelligent, so the client can't usefully tell the server it is misconfigured.   If the server is configured to hand out addresses with the wrong semantics, the solution is to fix the server, not complicate the protocol with a way for the client to tell the server something it can't do anything about.   This also needlessly complicates the client.

So why do you think this is a useful thing to do?   What non-hypothetical problem are you trying to solve here?

v2.23.0 | Report a Bug | By Email