Re: [dhcwg] RFC3315 DECLINE definition

"Bernie Volz (volz)" <volz@cisco.com> Wed, 08 February 2017 22:28 UTC

Return-Path: <volz@cisco.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 170DB12A03E for <dhcwg@ietfa.amsl.com>; Wed, 8 Feb 2017 14:28:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 AsGVhyvk6NXv for <dhcwg@ietfa.amsl.com>; Wed, 8 Feb 2017 14:28:31 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF0812A03D for <dhcwg@ietf.org>; Wed, 8 Feb 2017 14:28:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3467; q=dns/txt; s=iport; t=1486592911; x=1487802511; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WfMzONzcY4pBbjaOrs7ZL7aY6+EOCSqmzxtsPouUmKU=; b=BP24RetVmWE++gu3eIiDseLqlWKsG3bMuj6fr52OOp7L7N18Rfcvimtg 8YE+hixrdgEij4PG0sZl0xDlhfxYEM6GnpBsmMou0IT85usgS5G5ezxVt oX3G4UTh3BuvaCY2GTVld81T7qd12LY2GIn+6bvJZuRMMAZ/AwOWZfU3D U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AQAcmptY/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHg1KKCJIJiAyLG4IPggwmhXwCgm8/GAECAQEBAQEBAWI?= =?us-ascii?q?ohGkBAQEEIQFMCwwEAgEIEQQBAQIDCxgCAwIhERQJCAEBBA4FCIlUAxWSZZ1JA?= =?us-ascii?q?YIphzkNhAoBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQiKM4E8gRWBbYMZgmIFmzg?= =?us-ascii?q?4AYZshwyEEIJXjjeFbYRHiF4BHzg6RE8VPIZCdYZCB4EpgQwBAQE?=
X-IronPort-AV: E=Sophos;i="5.35,348,1484006400"; d="scan'208";a="383256358"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2017 22:28:30 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v18MST8Q016557 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Feb 2017 22:28:30 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 8 Feb 2017 16:28:29 -0600
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Wed, 8 Feb 2017 16:28:29 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
Thread-Topic: RFC3315 DECLINE definition
Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgA==
Date: Wed, 8 Feb 2017 22:28:29 +0000
Message-ID: <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com>
References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com>
In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.131.32.56]
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/0e4xWuzdlITp5TWEwGNSkkmNLJM>
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: Wed, 08 Feb 2017 22:28:33 -0000

I'm confused ... advertised vs assigned addresses. Once a Reply is received, the address is assigned -- no longer advertised.

DECLINE means that the address is in use. If the client DECLINEs it and just makes it available immediately, the next client to get that address assigned and does DAD will also find a conflict ... so what’s the value of that.

Generally, declined addresses should not be used for a while (that is policy dependent) since it means some other device is using the address.


I thought you were trying to say a Decline sent in response to an Advertise would tell the server "I don't want those addresses". But that is not meaningful and why would a client even try to do that. Also, an Advertise is just that -- and advertisement; it is not a commitment to assigned those addresses -- the client can only use the addresses in the Reply. (DHCPv4 is a bit different in this respect -- the address in the Offer must be same as in the Ack. DHCPv6 has no such hard requirement -- it usually is, but that's not required.)

- Bernie

-----Original Message-----
From: Mudric, Dusan (Dusan) [mailto:dmudric@avaya.com] 
Sent: Wednesday, February 08, 2017 5:19 PM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: dhcwg <dhcwg@ietf.org>
Subject: RE: RFC3315 DECLINE definition


Hi Bernie,

I am talking about DECLINE after REPLY. What I am  proposing is to use DECLINE for "I don't want your Advertised address(es)". I think this will be much cleaner then to let the server timeout the advertised addresses, which can take long.

Thanks,

Dusan

-----Original Message-----
From: Bernie Volz (volz) [mailto:volz@cisco.com] 
Sent: Wednesday, February 08, 2017 4:57 PM
To: Mudric, Dusan (Dusan); 神明達哉; Lishan Li
Cc: dhcwg
Subject: RE: RFC3315 DECLINE definition

Dusan:

DECLINE is used after a REPLY, not after an ADVERTISE.

A client has not been assigned an address until it receives the REPLY (at which point it does DAD and may send a DECLINE).

There is no mechanism for a client to indicate to a server "I don't want your Advertised address(es)", except by not proceeding to send a REQUEST.

The server may have held the address "reserved" for a short period of time, but does that really matter? IPv6 addresses are not in short supply.

- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Mudric, Dusan (Dusan)
Sent: Wednesday, February 08, 2017 4:47 PM
To: 神明達哉 <jinmei@wide.ad.jp>jp>; Lishan Li <lilishan48@gmail.com>
Cc: dhcwg <dhcwg@ietf.org>
Subject: [dhcwg] RFC3315 DECLINE definition

Hi,

Can DECLINE definition be extended beyond the DAD usage? I think DECLINE should be used every time DHCPV6 client decides not to assign the offered address, for any reason, not just the address is duplicate. When receiving DECLINE, DHCPV6 server should be able to immediately make the same address available in the address pool for the other clients.

Regards,
Dusan.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dhcwg&d=DQIFJg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dSOZR4dOvOIFlrJUO0ra9EaHoccrAjAiWycX_Y4vnRQ&s=e5wK-WS09BIx0RKDTBE_iEdUlrK_bP6gv4TfQaMTPiU&e=