Re: [dhcwg] RFC3315 DECLINE definition

"Mudric, Dusan (Dusan)" <dmudric@avaya.com> Thu, 09 February 2017 15:38 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 C3B4B129AD9 for <dhcwg@ietfa.amsl.com>; Thu, 9 Feb 2017 07:38:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.919
X-Spam-Level:
X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 0WB0RlvrL7Ib for <dhcwg@ietfa.amsl.com>; Thu, 9 Feb 2017 07:38:05 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.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 18CC0129AE7 for <dhcwg@ietf.org>; Thu, 9 Feb 2017 07:38:05 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ESAQABjJxY/xUHmMZdGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8hQWGBCQeNWpIJkyeCD4IMhiICgmo/GAECAQEBAQEBAQNfKIR?= =?us-ascii?q?pAQEBAQMSG0ELEAIBCA0BAwQBAQsWBwcyFAkIAgQOBQgRCYlSAaUljQcmAosfA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHYZNhG6BPIMCGDSCfoIxBYl0i2CGHAGcZ4Y?= =?us-ascii?q?vkxMfOX5PFTyERB2BYXWHcgGBCwEBAQ?=
X-IPAS-Result: =?us-ascii?q?A2ESAQABjJxY/xUHmMZdGQEBAQEBAQEBAQEBBwEBAQEBgm8?= =?us-ascii?q?hQWGBCQeNWpIJkyeCD4IMhiICgmo/GAECAQEBAQEBAQNfKIRpAQEBAQMSG0ELE?= =?us-ascii?q?AIBCA0BAwQBAQsWBwcyFAkIAgQOBQgRCYlSAaUljQcmAosfAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBHYZNhG6BPIMCGDSCfoIxBYl0i2CGHAGcZ4YvkxMfOX5PFTyER?= =?us-ascii?q?B2BYXWHcgGBCwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.35,349,1484024400"; d="scan'208,217";a="214668449"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Feb 2017 10:38:03 -0500
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 10:38:03 -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; Thu, 9 Feb 2017 10:38:02 -0500
From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
To: Ted Lemon <mellon@fugue.com>
Thread-Topic: [dhcwg] RFC3315 DECLINE definition
Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEA==
Date: Thu, 9 Feb 2017 15:38:01 +0000
Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA1898F@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>
In-Reply-To: <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.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: multipart/alternative; boundary="_000_9142206A0C5BF24CB22755C8EC422E457AA1898FAZUS1EXMB03glob_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/p7RiyAdnMeMNY6-g4AQ7bDDwKyw>
Cc: dhcwg <dhcwg@ietf.org>, "Bernie Volz \(volz\)" <volz@cisco.com>
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: Thu, 09 Feb 2017 15:38:06 -0000

Hi Ted,

Let's start with the problem statements:

1.       When DHCPv6 client starts it sends SOLICIT with IA option (without or with IPv6 address). The server sends ADVERTISE message offering IPv6 address(es). If the server offers IPv6 address(es) that client cannot use (e.g. an address with wrong semantics, a multicast address, a reserved address, ... , a second address and the client can support only one address), the client should be able to respond to the server indicating which address it cannot use.

2.       After T1 the client needs to RENEW the address. If REPLY from the server has new IPv6 address(es) that client cannot use (e.g. a multicast address, a reserved address, ... , a second address and the client can support only one address), the client should be able to respond to the server indicating which address it cannot use.

3.       After T2 the client needs to REBIND the address. If REBIND from the server has new IPv6 address(es) that client cannot use (e.g. a multicast address, a reserved address, ... , a second address and the client can support only one address), the client should be able to respond to the server indicating which address it cannot use.

4.       If the client cannot use the offered address, it might be left in one of the two states:

a.       Without any IPv6 address, or

b.      Still has IPv6 address in preferred state

a)      The client does not have IPv6 address and needs immediately another offer from the DHCPv6 server with a different address (e.g. a global, unreserved address)

b)      With a valid IPv6 address

a.       The client has IPv6 address it can use during the valid life time and needs another address from DHCPv6 server (e.g. with a different address type) before the valid life time expires

b.      The client cannot handle the address change and does not need the new address from DHCPv6 server

c.       The client has IPv6 address it can use and does not need multiple addresses from DHCPv6 server

5.       DHCPv6 server should

a.       Offer a different address type, or

b.      Make the address available to other clients, or

c.       Block the address for further use (e.g. the address was invalid).

I propose that DECLINE should be defined as a response for the addresses that cannot be assigned. There can be a reason code in DECLINE helping the server interpret the response.

Regards,
Dusan Mudric.


From: Ted Lemon [mailto:mellon@fugue.com]
Sent: Thursday, February 09, 2017 9:56 AM
To: Mudric, Dusan (Dusan)
Cc: Bernie Volz (volz); dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

On Feb 9, 2017, at 9:41 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com<mailto:dmudric@avaya.com>> wrote:
How can I contribute to RFC3315bis? What is the process?

The first step would be to figure out what you want, why you want it, and why anybody should care about it.   Then you explain that on the mailing list and see if you get some interest.

>From reading what you've said so far, what you want is the ability for a client to say it doesn't like a particular address, with the intended effect that if it asks for another address, it will get a _different_ address.   But your intended semantics are unclear, and I don't see how the server can usefully address this use case.   You'd need to explain that.