IETF Logo Mail Archive

Re: [dhcwg] RFC3315 DECLINE definition

Andre Kostur <akostur@incognito.com> Thu, 09 February 2017 16:13 UTC

Return-Path: <akostur@incognito.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 8496B129B63 for <dhcwg@ietfa.amsl.com>; Thu, 9 Feb 2017 08:13:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=incognito-com.20150623.gappssmtp.com
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 ocBJuAn95MaX for <dhcwg@ietfa.amsl.com>; Thu, 9 Feb 2017 08:13:05 -0800 (PST)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F04BF129B62 for <dhcwg@ietf.org>; Thu, 9 Feb 2017 08:13:04 -0800 (PST)
Received: by mail-yw0-x22e.google.com with SMTP id u68so5044345ywg.0 for <dhcwg@ietf.org>; Thu, 09 Feb 2017 08:13:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=incognito-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2DVsXwuajqTQB6uBHPj1ss8lnim2E+z78pAHlt8hj5Y=; b=b+Ir2NWcjJrubuDE58W/bKfNxwtmKRMAjBt0hMio6xJy0siFUqLlqnSFc2OUzeZsAv y6k4D37fMCi3RlecU74mrgVbHJNM6wV+TotQiBqPV6J3awN+S3mlGJstgoak/IuhHAca XpZUpXSLV8czXBuLCzjhvk7qs+3h69KCida+mMVJdlHRPVSmxDpRwE07gtEJwVK76gJx yfrQX2jSIHDGQN6b2tIotuY0TYj6Ox8XfYVAZU0FsYlu3rvvJsz8V8BVCiMDkZJszPEr bKxxIct3XD7/UzL8dHe3sGvyTQ0gI1OwcucSr0uRtq/ArDL1BkbSXeOFBhTf1TlqF8As g86A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2DVsXwuajqTQB6uBHPj1ss8lnim2E+z78pAHlt8hj5Y=; b=lqH2DMTlnPEzxFRWA/R4VkeNewoyFRgjoRjXEh2VeUaQM2Q6Bt3z9mVEAaLxNlhddm RFRZRe8Mc5dUTqJkzoX0oiVNYh6ypmNZTtwDsahrOjSKJMA7xp70OO6s3Pgaq72oIe78 bU9Ea90paK4K+yOgAq9bTrNfoUvLNiN1A6+tZHqRkFROkQ/wWzUYI8hm65JtWCCXA9Ig d/LuN83+fh1DnxScqtk7ikB4oIgKhnwbQWGcUtUuKMsqW1nXz53Hc7UrTqAt1+CUfioC bx+Zcr4w8pWjVOcVmEMcqXWAcnu+c5gQSAa3P58UzV/9KCfRdV8xEzpX7A57BPkdQfWM 5z7A==
X-Gm-Message-State: AMke39k3/CO5HXvALKrGxxjG3dcJTqk4Hlu0ewbjbSwLZo4ExkLy87AdB868qa1qSpEjpRVjzQSMBrwAAkx1/+3g
X-Received: by 10.129.101.10 with SMTP id z10mr3178736ywb.45.1486656778768; Thu, 09 Feb 2017 08:12:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.113.5 with HTTP; Thu, 9 Feb 2017 08:12:58 -0800 (PST)
In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA189F9@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>
From: Andre Kostur <akostur@incognito.com>
Date: Thu, 09 Feb 2017 08:12:58 -0800
Message-ID: <CAL10_BruJGePQMSBkf0kUCA9fvYXHC1T61ZSxGkfrh=piUg0fg@mail.gmail.com>
To: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/f_bX5KKpAKk1GqdPREw4KJ94GRc>
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:13:10 -0000

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