IETF Logo Mail Archive

Re: [dhcwg] RFC3315 DECLINE definition

"Mudric, Dusan (Dusan)" <dmudric@avaya.com> Thu, 09 February 2017 16:25 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 0350E129B61 for <dhcwg@ietfa.amsl.com>; Thu, 9 Feb 2017 08:25:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RhO7AIqqxClo for <dhcwg@ietfa.amsl.com>; Thu, 9 Feb 2017 08:25:12 -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 5ADA1129B8D for <dhcwg@ietf.org>; Thu, 9 Feb 2017 08:25:01 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2ETAQCTlpxY/yYyC4ddGQEBAQEBAQEBAQEBBwEBAQEBgxAXKoFqB4NSigiSCZMngg+CDIYiAhqCUD8YAQIBAQEBAQEBA18ohGkBAQEBAxIREUUMBAIBCA0BAwQBAQECAgYdAwICAjAUAQgIAgQOBQgaiVIBpTKKYoIlJgKLJQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4VChG6BPIMCGBWCby6CMQWbcAGcZ4YvkxMfOX5PFYZ+dYdyAYELAQEB
X-IPAS-Result: A2ETAQCTlpxY/yYyC4ddGQEBAQEBAQEBAQEBBwEBAQEBgxAXKoFqB4NSigiSCZMngg+CDIYiAhqCUD8YAQIBAQEBAQEBA18ohGkBAQEBAxIREUUMBAIBCA0BAwQBAQECAgYdAwICAjAUAQgIAgQOBQgaiVIBpTKKYoIlJgKLJQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4VChG6BPIMCGBWCby6CMQWbcAGcZ4YvkxMfOX5PFYZ+dYdyAYELAQEB
X-IronPort-AV: E=Sophos;i="5.35,137,1484024400"; d="scan'208";a="190093348"
Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Feb 2017 11:24:58 -0500
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 11:24:58 -0500
Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 11:24:56 -0500
From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
To: Andre Kostur <akostur@incognito.com>
Thread-Topic: [dhcwg] RFC3315 DECLINE definition
Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEP//ubmAgABS6jD//68/gIAAUzJQ//+ztAAACh5MoA==
Date: Thu, 09 Feb 2017 16:24:54 +0000
Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA18A99@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> <CAL10_BruJGePQMSBkf0kUCA9fvYXHC1T61ZSxGkfrh=piUg0fg@mail.gmail.com>
In-Reply-To: <CAL10_BruJGePQMSBkf0kUCA9fvYXHC1T61ZSxGkfrh=piUg0fg@mail.gmail.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/JkxPGTbGDqnbykwiCiOhJg2wjZg>
Cc: dhcwg <dhcwg@ietf.org>, Ted Lemon <mellon@fugue.com>, 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:25:14 -0000

” The client will either do a naked SOLICIT and get the reserved IP that the server was configured to give it"

That configured IP might be an address that the client cannot use.

-----Original Message-----
From: Andre Kostur [mailto:akostur@incognito.com] 
Sent: Thursday, February 09, 2017 11:13 AM
To: Mudric, Dusan (Dusan)
Cc: Ted Lemon; dhcwg; Bernie Volz
Subject: Re: [dhcwg] RFC3315 DECLINE definition

On Thu, Feb 9, 2017 at 8:06 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com> wrote:
> Let's say there is a deployment within an enterprise of 20 000 devices, each with DHCPv6 enabled. They are on different locations and use different DHCPv6 servers. One server is configured to statically assign IPv6 addresses (based on the client MAC) or with a pool of IPv6 addresses for the local link. If a client on that location assigns the misconfigured address it becomes unreachable. A user does not even know how to spell DHCPv6 and all he/she experiences is that the device is unusable. The network operator does not get any indication that the device is out of service.

Assigns what misconfigured address?  The client will either do a naked SOLICIT and get the reserved IP that the server was configured to give it, or it will do a CONFIRM with the address it obtained from a different link and the server will REPLY for that address giving it 0 lifetimes to instruct the client that the address is no longer usable.
Then the client goes back to the SOLICIT and gets the reserved IP that the server was configured to give it.

--
Andre Kostur

v2.23.0 | Report a Bug | By Email