Re: [dhcwg] RFC3315 DECLINE definition

Andre Kostur <akostur@incognito.com> Fri, 10 February 2017 16:25 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 328061299E1 for <dhcwg@ietfa.amsl.com>; Fri, 10 Feb 2017 08:25:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 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] 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 mz_sJWHZSomx for <dhcwg@ietfa.amsl.com>; Fri, 10 Feb 2017 08:25:22 -0800 (PST)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 77020129577 for <dhcwg@ietf.org>; Fri, 10 Feb 2017 08:25:22 -0800 (PST)
Received: by mail-yw0-x22a.google.com with SMTP id v200so23873438ywc.3 for <dhcwg@ietf.org>; Fri, 10 Feb 2017 08:25:22 -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=H+lYkFkUfuAzOshjEvN+3FM6G/qULH/nmxDeUrfoWxI=; b=eJ3lVidEJHM5E+7LcqOws/sWUqFv01OUBswTIa9AypDMClVuDDn3Gwxi/rahX6ODNv tXYkDtT1g+Iy3d4V+VWTJNpovOfV7uMzlhqf4ySsCno++lkpdGMhTEMghSh99Akn82UQ LQOEgwi0p7yx3MBD2CixiZv0t0dIjDXZQO33yAoGvVtbfO+1sgwzTVf6fjlFtbTZMnRW ZWGX9qE4x2IIKSuDBK86aQPWjYzSStqAI97JHceOxsRuXWJlIr4feugOIcIzGOcf1PSj Rs6o3CvD0rvvguZqPidhQftHV3amFZar/9SJBy7+m8xaj/6e5VZQ7iEOAvsN2x+j/eEg 4NRg==
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=H+lYkFkUfuAzOshjEvN+3FM6G/qULH/nmxDeUrfoWxI=; b=DF6vXWI4uPJBOkCxybJoclkvIsMa0HsX9NlQsOZhYEqUb42hJzYEq2IkXuwHqdmSga Jkh21OGMAcfIJF7ScQlaSk6vlpzlb8Qhq2jz/NfCR48sRVu8AOjN6p0VI3V86xj7Y597 ywNsVv0xJDBdzozPEHtiFFEl9kZhLtDSRh6BCfBff3pU3eS8+UigG3wSxjuNBh/0eypB ZhO9LAS3GPNb+FxTtjqxfgIxCggv8BdNohjvhThPaq2GZpL2+4XFPZFqoLZGqAuNxWB/ TrZkji+T9ak8Tf2e0+qYLJ3HoXQnRARt2mvGBHK87JMA2oyin2rDv7KR5FLbG5ZhCJxq V2Bw==
X-Gm-Message-State: AMke39l2mb0cY+ogoyNxVSuOTTeFJdmvwmtFXKBJULqXMZl7LiTrsf4h/HaUe2vlzkJS9bL71UY5n6MQ3s43RLhs
X-Received: by 10.13.196.129 with SMTP id g123mr7199124ywd.17.1486743921304; Fri, 10 Feb 2017 08:25:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.113.5 with HTTP; Fri, 10 Feb 2017 08:25:20 -0800 (PST)
In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA18ED6@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> <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> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> <9142206A0C5BF24CB22755C8EC422E457AA18ED6@AZ-US1EXMB03.global.avaya.com>
From: Andre Kostur <akostur@incognito.com>
Date: Fri, 10 Feb 2017 08:25:20 -0800
Message-ID: <CAL10_BqFTSbhe6krvTUz1VnLw0pQGodPRrt8c39sNcMhRUqvQw@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/zUTxDlUKoTt48TUxy_GN4VRRfww>
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: Fri, 10 Feb 2017 16:25:24 -0000

On Fri, Feb 10, 2017 at 6:35 AM, Mudric, Dusan (Dusan)
<dmudric@avaya.com> wrote:
> - If the key feature of the stateful DHCPv6 is the address assignment, why
> there is no any address validation?

You need to be clear on what you mean by "address validation".  (Oh,
and DHCPv6 is responsible for both address and prefix assignment)

> - Why is the human intervention a part of the protocol? Why the protocol
> requires an administrator not to make mistakes?

Everything is susceptible to human error.  You need to have more
specific use-cases to get anywhere near this question.  Also, the
protocol does not mandate configuration management.  Perhaps your DHCP
server has the capability of comparing its configuration with that on
a router to look for certain potential configuration mismatches.  But
that's a quality of implementation issue, not a protocol issue.

> - Why the client must assign every address offered by the server? Why should
> the client save the advertised leases for every IAADDR in IA’s, if the
> status code is STATUS_Success?

It doesn't have to.  The client can pick and choose, preferably at the
ADVERTISE/REQUEST stage.  The server ADVERTISEs a dozen addresses, the
client decides that it wants only 1 of them and REQUESTs it.   Or a
less well-behaved client could REQUEST them all, but only actually
configure one of them on an interface.

> - Why the client must use the address that does not match any of the router
> prefixes?

The router may not be advertising any prefixes, so the client doesn't
know any different.  (Nor should it)

> - Why the client is not interworking with ND protocol?

Be more specific.  ND covers a lot of ground.

> - Why the client does not return the address it does not use?

Talk to your client vendor.  The client can return addresses by
protocol.  Either by not REQUESTing it in the first place (though this
isn't returning an address, it's just not claiming it), or by
RELEASEing it.

> - Why is DECLINE message associated with only one error code (DAD failed)?

No use-case has been presented that the DHC working group has agreed
upon that a DECLINE for other reasons is the appropriate response.

-- 
Andre Kostur