Re: [dhcwg] RFC3315 DECLINE definition

Andre Kostur <akostur@incognito.com> Fri, 10 February 2017 20:10 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 EECFE129591 for <dhcwg@ietfa.amsl.com>; Fri, 10 Feb 2017 12:10:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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] 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 EbZat1cC6XZJ for <dhcwg@ietfa.amsl.com>; Fri, 10 Feb 2017 12:10:00 -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 65BAE1295A4 for <dhcwg@ietf.org>; Fri, 10 Feb 2017 12:09:59 -0800 (PST)
Received: by mail-yb0-x236.google.com with SMTP id o65so14766951ybo.2 for <dhcwg@ietf.org>; Fri, 10 Feb 2017 12:09:59 -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=DByg3alcfTIkcaX4/oynw3dSJABg4BDGap84uF7vu5U=; b=cZywq0g6Hqk0iIy1Qe6OK0Wk0q5Q2DGWWFB5JC4DUGkNhsclFOzxteVPllG4DgiCGf Xa9KzVoykHlyObvCZkBs8LirydDAF4kjruUc9lmx9WHO0UgTg15q0xxvka0V2xNYX5TN 9mbu5KSzgpeyAGteeEP6aNW5jKmBOTRj8A5p9j6bttWrEW92s9/qv5MlCJWqXSpirRzN RgxY1IHj/I/KlYADqzgbXz5VyMhn2KVDVnAE7ff1Cj4B2WmW7UN+AIFpPex0Tgzv3f2T YBETOjkFdHaq9t5xZ57RmJEx7qlvhLTgm1fE9SMztLa4kNc4ZHWLTbew3MBnWMoZOUaW XQag==
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=DByg3alcfTIkcaX4/oynw3dSJABg4BDGap84uF7vu5U=; b=bmNl0NFWOvkPfHrTFzTxGPTYvMTnQG7T408q2x520yTnAl2zX6wYXpC1Q6CtcA/cZE WWuefKtgm5G9KIgEBMnRTGdDo8IjetGmLXtnf0BMOMkpwl0k4CIJvE4TbWFS93IQaRNi ScGzgoD71NQX8RmQ4FdR8xB/sk2HSr7HmX0rBaTKwAKscM8CWE8sZac36WvJxC3g6H6f z605CG8c5sBRV9Y94GBiHpQIHuSn0nS/OEJB9EVNoIKgo0xPaY7zwSFZaGXym0u8WJ2T 5Wu3F13sn89y+eo+hpqhQx26O819sRjZnlNKExt0Le5IWWXvuLL0+Zv68CrLt3m9nT8H u6fA==
X-Gm-Message-State: AMke39nY/AidX19gn8b5Zo5r9aedXCq9aRfYaxxZ1YPwYUhRFJhHL+Vt/Iw5ExWrT3nAFDASAvyrmDCC6l/dW86L
X-Received: by 10.37.197.74 with SMTP id v71mr7891670ybe.33.1486757398442; Fri, 10 Feb 2017 12:09:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.113.5 with HTTP; Fri, 10 Feb 2017 12:09:57 -0800 (PST)
In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA1906F@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> <CAL10_BqFTSbhe6krvTUz1VnLw0pQGodPRrt8c39sNcMhRUqvQw@mail.gmail.com> <9142206A0C5BF24CB22755C8EC422E457AA1906F@AZ-US1EXMB03.global.avaya.com>
From: Andre Kostur <akostur@incognito.com>
Date: Fri, 10 Feb 2017 12:09:57 -0800
Message-ID: <CAL10_BorkqQXZUOFWarj_+275u1z9L9Xtkse=RQjGnOeFveNJg@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/negza1NhuHpIV0G-EAchs_pbPKM>
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 20:10:02 -0000

On Fri, Feb 10, 2017 at 9:10 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)
>
> [Dusan] - Syntax checks

All of the addresses are necessarily syntactically correct.  An
address is a 16-byte value.

>               - Semantic checks

Again, covers a lot of ground.  Be more specific.

>               - Prefix checks

A decent DHCP server will only allocate addresses that are appropriate
to where the client is requesting from.  How the DHCP server knows
what prefixes are appropriate is a configuration issue and beyond the
scope of the DHCPv6 protocol.

>> - 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.
>
> [Dusan] If the server communicates with a router to compare the
> configuration, it is a protocol

Just not the DHCPv6 protocol.  Which puts it beyond the scope of the
working group.

>> - 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.
>
> [Dusan] Which section in RFC3315 defines how DHCPv6 client selects the
> leases? Which section defines what the client does with non-selected leases?

Beyond the scope of the protocol.  The client may use whatever logic
it wants to choose which leases it wishes to establish.  It REQUESTs
the ones it wants, does nothing with the rest.  Most servers will
quickly reclaim addresses which have been ADVERTISEd but not
REQUESTed.  That is why it is (by default) a 4-message exchange to
establish a lease.  The server already has to deal with the idea that
its ADVERTISE is never answered.  The client may have chosen a
different server to get its leases from.

>> - 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)
>
> [Dusan] What if the router advertised a prefix and the client received an
> address that does not start with the prefix?

The network administrator may still want to give out an address for an
unadvertised prefix.

>> - Why the client is not interworking with ND protocol?
>
> Be more specific.  ND covers a lot of ground.
>
> [Dusan] DHCPv6 client does not know about router prefixes and does not know
> which router is reachable. Which section in RFC3315 defines what the client
> should do with the address:
> - if ND receives prefix P1?
> - if the router that advertised P1 is not reachable?

Beyond the scope of the protocol.  Again, the admin may be wishing to
assign addresses for an unadvertised prefix.  Or the admin may be
wishing to give out an address that is intentionally unroutable.  Not
the protocol's role to decide that.

>> - 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.
>
> [Dusan] Which section in RFC3315 defines what the client should RELEASE
> after ADVERTISE and REPLY? Why should RELEASE be used for the address that
> is not even assigned?

Nothing to RELEASE after the ADVERTISE.  The client does not yet have
the lease.  As you've already pointed out, the address had not yet
been assigned.  Section 18.1.6.

>> - 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.
>
> [Dusan] That is why I am presenting these use cases.

And so far none of them have been accepted (as problems) by the
working group.  You need to convince the working group that a problem
exists, why the existing protocol can't deal with it, and what is the
proposed solution to the problem (with at least some specificity), and
why it's worth changing the protocol to deal with the problem.

-- 
Andre Kostur