IETF Logo Mail Archive

Re: [dhcwg] RFC3315 DECLINE definition

"Bernie Volz (volz)" <volz@cisco.com> Wed, 08 February 2017 21:57 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 2EFD41295FD for <dhcwg@ietfa.amsl.com>; Wed, 8 Feb 2017 13:57:27 -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 lv6r_wCxndef for <dhcwg@ietfa.amsl.com>; Wed, 8 Feb 2017 13:57:26 -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 F36FF128874 for <dhcwg@ietf.org>; Wed, 8 Feb 2017 13:57:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1346; q=dns/txt; s=iport; t=1486591045; x=1487800645; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fmvlvxrGt+Vi3Cu6qLGeSYubygEr+BuW4qjjGeqed0M=; b=PxC9/2+IuhYqFfy7CfyzL8TWlZKdZcI+8UVXY28dMUMWNvg5SjEoWVhn XQmXKat5aW3IHNV6JGc5BWKSZg6V200UX8lxp564GILojYmhg513b9uWC c+S4jf1XYlAlHcK6HJ2fU/4FTm0GE5pautCxDS6OD6whu1FWnWboiiPYO E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A5AQD9k5tY/5NdJa1dGQEBAQEBAQEBAQEBBwEBAQEBg1FhgQkHg1KKCJIJiAyNKoIMHwuFeAKCbz8YAQIBAQEBAQEBYiiEaQEBAQQBAR8BTAsMBAIBCBEEAQECAwsYAgMCIQYLFAkIAQEEAQ0FCIlUAxUOkl+dSQGCKYc5DYQKAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBCIozgTyBFYFtgxmCYgWbODgBjXiEEJEOhW2ER4heAR84OkRPFTyGQnWGQgeBKYEMAQEB
X-IronPort-AV: E=Sophos;i="5.35,348,1484006400"; d="scan'208";a="206416469"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2017 21:57:04 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v18Lv4J6022137 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Feb 2017 21:57:04 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 8 Feb 2017 15:57:03 -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 15:57:03 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>, 神明達哉 <jinmei@wide.ad.jp>, Lishan Li <lilishan48@gmail.com>
Thread-Topic: RFC3315 DECLINE definition
Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQA
Date: Wed, 08 Feb 2017 21:57:03 +0000
Message-ID: <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com>
References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com>
In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA186B9@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/PtfSjg3wOYAoAv7Ckj6gSkk_KXQ>
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 21:57:27 -0000

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://www.ietf.org/mailman/listinfo/dhcwg

v2.23.0 | Report a Bug | By Email