Re: [dhcwg] RFC3315 DECLINE definition

Andre Kostur <akostur@incognito.com> Thu, 09 February 2017 17:14 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 10AF0129C27 for <dhcwg@ietfa.amsl.com>; Thu, 9 Feb 2017 09:14:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 qcmlvulv8_3L for <dhcwg@ietfa.amsl.com>; Thu, 9 Feb 2017 09:14:32 -0800 (PST)
Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (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 69F6E129C24 for <dhcwg@ietf.org>; Thu, 9 Feb 2017 09:14:32 -0800 (PST)
Received: by mail-yb0-x236.google.com with SMTP id o65so3275701ybo.2 for <dhcwg@ietf.org>; Thu, 09 Feb 2017 09:14:32 -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=IbFB7gxD+sv1+iDKwzcZiPjlgRmSA9E+rPTA8Uap6Fw=; b=DRSNoXUZQql1r5FOZglZe6eQq+DpUmJ7stxjpMC0nqCqjuuTmuot4hDn5UjxsKN13j j0+LnFQuRCqIHnmipHDC6f4ih5sM+nOjDMMHol0Vx3WmXibgLjniHhnsfr/seYqGxczx 1CyvZjVc/ro+GLV5mj3EifK6yifi0adUKIjNSHd27GwdzYAh5x+eUtdbswCMPOY5UpaM DqdoOshFLM6jftZ/AiAFlDJSwn3t0QBXZA8HS1RpS1sYTqg3pIW9ZdrTk+mmHPYnNqhf ZbGDB28soTgkGSgOneDQ5RvPu0ZALgt1zglolVYKFon59tExiT0KBr14GmAeTD2wfi4B AxUA==
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=IbFB7gxD+sv1+iDKwzcZiPjlgRmSA9E+rPTA8Uap6Fw=; b=Sj3l171ipVQJ0Q88YTf50ufaBfA/tuWDY3LGzgobT7t1rVI866UeK0nUbatY/9Uxf7 ezxbl/dQ1zOTxIZ6b1G2wQgr817Q6ps/alG0b304cKQBb2LkhQhpzU1Qf30mgYC+VBiK QerhrhdzaEsduYvK6IB3eW11d6MSHQpl2XCdwwzsEwonVxEtwRIu9N6UCkXdZV+zVsDw G6+xUMGa1Ury+8W0G8tObEzk3OlaJs8KjLZTi3PJVt8acewJ98N6krJ9tgPzrenDHsDx xvqscWNTXiAEUNXTAWTFPnfquAqVldB23vAKYIQ6jL9TlHwFpM0VKNhUkC6q5dBWXvV2 3PiQ==
X-Gm-Message-State: AMke39nlqRAlWXyX0mbMfARLTQbYlQ7WZyOyzGSza2iE20IBxJFeX6KpJ1gNLieRFBbZOFbvOAIbG1vdG12KCnc4
X-Received: by 10.37.38.12 with SMTP id m12mr3116923ybm.30.1486660471387; Thu, 09 Feb 2017 09:14:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.113.5 with HTTP; Thu, 9 Feb 2017 09:14:30 -0800 (PST)
In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA18B73@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> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <E4F9FD26-ECE0-4FE8-AACD-ED0EA79BCC2D@thehobsons.co.uk> <9142206A0C5BF24CB22755C8EC422E457AA18B73@AZ-US1EXMB03.global.avaya.com>
From: Andre Kostur <akostur@incognito.com>
Date: Thu, 9 Feb 2017 09:14:30 -0800
Message-ID: <CAL10_BpbNy5HrDE=5Nr6Q+hXfEPCXtg=bErcXxpNccpY0zjPew@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/cpkmt9KNsj9DDcLt-hM780CUSAU>
Cc: dhcwg <dhcwg@ietf.org>
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 17:14:34 -0000

On Thu, Feb 9, 2017 at 8:53 AM, Mudric, Dusan (Dusan) <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