IETF Logo Mail Archive

Re: [dhcwg] RFC3315 DECLINE definition

"Mudric, Dusan (Dusan)" <dmudric@avaya.com> Wed, 08 February 2017 22:19 UTC

Return-Path: <dmudric@avaya.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 AEECE129EBB for <dhcwg@ietfa.amsl.com>; Wed, 8 Feb 2017 14:19:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 pD7mcyO6UMma for <dhcwg@ietfa.amsl.com>; Wed, 8 Feb 2017 14:19:26 -0800 (PST)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6630129EB3 for <dhcwg@ietf.org>; Wed, 8 Feb 2017 14:19:25 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2GfAACKmJtY/yYyC4ddGQEBAQEBAQEBAQEBBwEBAQEBgxBBYYEJB4NSigiSCYgMixuCD4FJQyaFfAKCbz8YAQIBAQEBAQEBA18ogls9BgcvAQEBAQEBAQEBAQEBARwCD0EBARgBAQEBAxIPAUwLDAQCAQgNBAQBAQIDBgUYAgMCIREUCQgBAQQOBQgaiToDFQGScJJsil0BgikmAocRDYQKAQEBAQEBAQECAQEBAQEBAQEBAQEdgQiFRYRugTyBFYFtGIMBMYIxBZs4OAGGbIcLAYZniAiGL4VthEeIXx85OkRPFTyGQnWGQgeBKQGBCwEBAQ
X-IPAS-Result: A2GfAACKmJtY/yYyC4ddGQEBAQEBAQEBAQEBBwEBAQEBgxBBYYEJB4NSigiSCYgMixuCD4FJQyaFfAKCbz8YAQIBAQEBAQEBA18ogls9BgcvAQEBAQEBAQEBAQEBARwCD0EBARgBAQEBAxIPAUwLDAQCAQgNBAQBAQIDBgUYAgMCIREUCQgBAQQOBQgaiToDFQGScJJsil0BgikmAocRDYQKAQEBAQEBAQECAQEBAQEBAQEBAQEdgQiFRYRugTyBFYFtGIMBMYIxBZs4OAGGbIcLAYZniAiGL4VthEeIXx85OkRPFTyGQnWGQgeBKQGBCwEBAQ
X-IronPort-AV: E=Sophos;i="5.35,348,1484024400"; d="scan'208";a="189999738"
Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Feb 2017 17:19:22 -0500
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2017 17:19:22 -0500
Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.03.0319.002; Wed, 8 Feb 2017 17:19:22 -0500
From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Thread-Topic: RFC3315 DECLINE definition
Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iA=
Date: Wed, 08 Feb 2017 22:19:20 +0000
Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com>
References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com>
In-Reply-To: <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.11.85.50]
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/Wu3KKw9xLVrnS3tAZRlaNDkFQMo>
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:19:27 -0000

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>; 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=

v2.23.0 | Report a Bug | By Email