Re: [dhcwg] RFC3315 DECLINE definition

"Bernie Volz (volz)" <volz@cisco.com> Wed, 08 February 2017 22:52 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 7E32912A095 for <dhcwg@ietfa.amsl.com>; Wed, 8 Feb 2017 14:52:01 -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 D6EDYCFa9QCd for <dhcwg@ietfa.amsl.com>; Wed, 8 Feb 2017 14:51:56 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B259D12A094 for <dhcwg@ietf.org>; Wed, 8 Feb 2017 14:51:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4674; q=dns/txt; s=iport; t=1486594316; x=1487803916; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=d77DuQC/B3QpajV+rcRcMVuoR2Xu2akasdMwKMHmJpY=; b=CP+iPD7CSHzOkF8RwfiM5syRuYlZh5XOPy206KJ0OZU6+uFCKIX9+B90 cUGyHLR2pl+dVSHywAtU26+V6v5K3omh7AUrG2R+vZ8hz6N9KT897J8My xTmWXAdlJt38YgSP+MjCL+i36s3duSkCf/boVt4wTrlWnthfSfpDoz4BH M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AQCTn5tY/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHg1KKCJIJiAyLG4IPggwmhXwCgm8/GAECAQEBAQEBAWI?= =?us-ascii?q?ohGkBAQEEIQFMCwwEAgEIEQQBAQIDCxgCAwIhERQJCAEBBA4FCIlUAxWSZp1JA?= =?us-ascii?q?YIphzgNhAoBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQiKM4E8gRWBbYMZgmIFmzg?= =?us-ascii?q?4AYZshwyEEIJXjjeFbYRHiF4BHzg6RE8VPIZCdYZCB4EpgQwBAQE?=
X-IronPort-AV: E=Sophos;i="5.35,348,1484006400"; d="scan'208";a="206435510"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2017 22:51:55 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v18Mpt5l023007 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Feb 2017 22:51:55 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 8 Feb 2017 16:51:54 -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:51:54 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
Thread-Topic: RFC3315 DECLINE definition
Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeA=
Date: Wed, 8 Feb 2017 22:51:54 +0000
Message-ID: <fd3365190bd445b1ad00a7d8043530dd@XCH-ALN-003.cisco.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>
In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA18746@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/-TPAzifc6agLrdY12MFlSC8Gmvo>
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:52:01 -0000

No.

DECLINE means address is bad (duplicated). DECLINE is only valid after Reply, not after Advertise. 

RELEASE means client does not want to use the address provided.

I don't see any benefit to change this.

- Bernie

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

Understand the concern. The client should be able to DECLINE addresses in both ADVERTISE and REPLY. Receiving the REPLY does not mean that a unique address must be assigned to the interface. If a client DECLINEs the ADVERTISEd or REPLIEd address, DHCPV6 server should be able to advertise another address.

The client should also be able to tell that is does not want another address. For example, if RENEW/REBIND returns a new address, the client should be able to DECLINE it.

Regards,
Dusan.

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

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=