IETF Logo Mail Archive

Re: [dhcwg] RFC3315 DECLINE definition

"Mudric, Dusan (Dusan)" <dmudric@avaya.com> Thu, 09 February 2017 16:47 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 B58D9129BC0 for <dhcwg@ietfa.amsl.com>; Thu, 9 Feb 2017 08:47:47 -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 aqm-JKMsuZy7 for <dhcwg@ietfa.amsl.com>; Thu, 9 Feb 2017 08:47:46 -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 3A08A129B85 for <dhcwg@ietf.org>; Thu, 9 Feb 2017 08:47:46 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2ESAQCJnJxY/xUHmMZdGQEBAQEBAQEBAQEBBwEBAQEBgm8hQWGBCQeNWpIJkyeCD4IMhiICgms/GAECAQEBAQEBAQNfKIRpAQEBAQMSG0wQAgEIDQEDBAEBCx0HMhQJCAIEDgUIGolSAaU0jQcmAospAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZNhG6BPIMCGDSCfoIxBYl0kXwBnGeGL5MTHzl+TxWGfnWGRCuBAwGBCwEBAQ
X-IPAS-Result: A2ESAQCJnJxY/xUHmMZdGQEBAQEBAQEBAQEBBwEBAQEBgm8hQWGBCQeNWpIJkyeCD4IMhiICgms/GAECAQEBAQEBAQNfKIRpAQEBAQMSG0wQAgEIDQEDBAEBCx0HMhQJCAIEDgUIGolSAaU0jQcmAospAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZNhG6BPIMCGDSCfoIxBYl0kXwBnGeGL5MTHzl+TxWGfnWGRCuBAwGBCwEBAQ
X-IronPort-AV: E=Sophos;i="5.35,137,1484024400"; d="scan'208,217";a="190096309"
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 11:47:43 -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 11:47:43 -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 11:47:42 -0500
From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
To: Ted Lemon <mellon@fugue.com>
Thread-Topic: [dhcwg] RFC3315 DECLINE definition
Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEP//ubmAgABS6jD//68/gIAAUzJQ//+28gAACnV4EAAKQI6AAB7vbSAAMyFpAABwmj1w
Date: Thu, 09 Feb 2017 16:47:42 +0000
Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA18B5E@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-81599408C8F7@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>
In-Reply-To: <B2511278-5D7A-40E0-AC4A-60784C101A80@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_9142206A0C5BF24CB22755C8EC422E457AA18B5EAZUS1EXMB03glob_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/PZKWQFlQJmVK4V3dMsS7-v64IQ8>
Cc: dhcwg <dhcwg@ietf.org>, Bernie 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 16:47:48 -0000

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.

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

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

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

Dusan

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

On Feb 9, 2017, at 11:37 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com<mailto:dmudric@avaya.com>> wrote:
The application does the semantic check for the address and, if the address is semantically correct, checks if the device using the offered address can be reached within the domain the in which device has to communicate. If, for example, the device has to be globally reachable, the address has to be an unreserved, or not deprecated, global address.

OK.   Why can't the DHCP server do this validation?

v2.23.0 | Report a Bug | By Email