[dhcwg] 2nd Try - draft-ietf-dhc-dhcpv6-stateful-issues-04.txt
"Bernie Volz (volz)" <volz@cisco.com> Mon, 10 June 2013 19:55 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 BDC8B21F9A22 for <dhcwg@ietfa.amsl.com>; Mon, 10 Jun 2013 12:55:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+3WhX0ynbGX for <dhcwg@ietfa.amsl.com>; Mon, 10 Jun 2013 12:55:14 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A592621F9A23 for <dhcwg@ietf.org>; Mon, 10 Jun 2013 12:55:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33916; q=dns/txt; s=iport; t=1370894113; x=1372103713; h=from:to:cc:subject:date:message-id:mime-version; bh=eWPLYO1YQ/fYfDEGVY3kFOzTqKcZowmbDw+N2HiAmCU=; b=NMRAPw++mriiw3GsYJ/SnDO0A/qsw8xTkBt16oIzUcpvmNWdq0WwUw/c ZttB0kTfx9k4NJjOCIIoPsShx4KzcGkc5jseVjZkaL3Un8ArmjeIjg61j AwpHp0Gx3LPj1Gb03+OlAHnuOuZ82fwRyd0uPAJAt6FLwbaWiVRhjIWFU 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArEGAHwutlGtJV2b/2dsb2JhbABZgkVEMEm+RIEFFm0HgiMBAQEELUwSARkEAQELFgEGORQJCQEEDgUIiAW5aY8HMQYHgnlhA6kCgw+CJw
X-IronPort-AV: E=Sophos; i="4.87,840,1363132800"; d="scan'208,217"; a="221049087"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 10 Jun 2013 19:55:12 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5AJtCYJ032232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Jun 2013 19:55:12 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 14:55:12 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: 2nd Try - draft-ietf-dhc-dhcpv6-stateful-issues-04.txt
Thread-Index: Ac5mDwOCm/6nW/ykRcKtRPT2sF6nQQ==
Date: Mon, 10 Jun 2013 19:55:11 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E1859B0CF@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.241.52]
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1859B0CFxmbrcdx04ciscoc_"
MIME-Version: 1.0
Cc: "Kim Kinnear (kkinnear)" <kkinnear@cisco.com>, "Ole Troan (otroan)" <otroan@cisco.com>, "Ralph Droms (rdroms)" <rdroms@cisco.com>
Subject: [dhcwg] 2nd Try - draft-ietf-dhc-dhcpv6-stateful-issues-04.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 10 Jun 2013 19:55:19 -0000
As this is a WG document, I would like some feedback from people about whether the proposed change is "valid". I received no feedback or discussion about this Rebind issue. While this technically doesn't change 3315 as 3315 permits a Rebind to return the NoBinding status in the Reply and 18.2.4 never mentions adding 'new' addresses, I think this may well be a valid interpretation of what is not said in 18.2.4. To perhaps make the intended change more clear, here's some potential wording for replacement text of 18.2.4 of RFC 3315. Some text was moved and new text has + in column 1. This may not be the final text (suggestions to improve greatly welcome). 18.2.4. Receipt of Rebind Messages When the server receives a Rebind message that contains an IA option from a client, it locates the client's binding and verifies that the information in the IA from the client matches the information stored for that client. + If the server finds the addresses in the IA for the client and the server determines that the addresses in the IA are appropriate for the link to which the client's interface is attached according to the server's explicit configuration information, the server SHOULD send back the IA to the client with new lifetimes and T1/T2 times. If the server cannot find a client entry for the IA and the server determines that the addresses in the IA are not appropriate for the link to which the client's interface is attached according to the server's explicit configuration information, the server MAY send a Reply message to the client containing the client's IA, with the lifetimes for the addresses in the IA set to zero. This Reply constitutes an explicit notification to the client that the addresses in the IA are no longer valid. In this situation, if the server does not send a Reply message it silently discards the Rebind message. + If the server cannot find a client entry for the IA and the server determines that the addresses in the IA are appropriate for the link to which the client's interface is attached according to the server's explicit configuration information, and the addresses are not in use, the server MAY assign the addresses to the client and send a Reply message to the client with new lifetimes and 1T1/T2 time for the bindings. If the server cannot assign the addresses to the client, the server returns the IA containing no addresses with a Status Code option set to NoBinding in the Reply message. + Note: A server SHOULD NOT provide additional bindings to the client as the client could accept a Reply from a different server (this is the same issue as in the Discussion under the Rapid Commit option, see section 22.14). The server constructs a Reply message by setting the "msg-type" field to REPLY, and copying the transaction ID from the Rebind message into the transaction-id field. The server MUST include a Server Identifier option containing the server's DUID and the Client Identifier option from the Rebind message in the Reply message. The server includes other options containing configuration information to be returned to the client as described in section 18.2. There are four possible response to a Rebind (note that I'm restricting my wording here to addresses as that is all RFC 3315 speaks to, but you can replace "address" with "delegated prefix" for 3633): 1. No response. This is used when the server does not have a record of the bindings and cannot determine whether the bindings are on-link. As the addresses may be valid, but this server has insufficient information to determine this, it is best it remain silent. If other servers respond, the client will have its information. Otherwise, the client will deal with the issues when the lifetimes expire. 2. Reply with Bindings with 0 lifetimes. This is used when the server determines that the bindings are not on-link. 3. Reply with NoBinding status code(s) response. This is used when the server is unable to assign the addresses requested or the client needs "new" information. As this will cause the client to return to sending Request, it provides the server another and better chance to provide the client complete information. 4. Reply with updated lifetimes and T1/T2 times. This is when the server has a record of bindings and they are still valid or is able to assign what the client already has. Based on other changes to stateful-issues, I'd also indicate that the server MUST pick one of these for ALL of the IA_* options. And, I think the server should pick the lowest numbered respond based on processing each binding. Note again the server should NOT allocate any "new" addresses to the client even if its current configuration would dictate as it would not know if the client uses this information, UNLESS the server is configured honor Rapid Commit. If there is new information that should go to the client, the server should either respond as in case 3 above or initiate a Reconfigure of the client. - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Monday, May 13, 2013 2:04 PM To: dhcwg@ietf.org Subject: [dhcwg] draft-ietf-dhc-dhcpv6-stateful-issues-04.txt Hi: This is an updated version of this document. It includes a few minor changes from the WG last call and is there mostly to restore this document as it has expired a few days ago. I still have a bunch of the comments from the WG Last Call in January/February to address. There is also one key issue that will need some discussion from the WG. In particular, handling of Rebind requests. One major flaw with respect to the Rebind message handling in RFC 3315 and this draft is that as the client has sent the Rebind to multiple servers, all of which could respond, there is no way for a particular server to know whether its Reply will be accepted by the client. This is essentially the same issue with using Rapid Commit in a Solicit when there are multiple servers available. I think the Rebind processing should essentially be changed so that a server will either return everything the client requested to be rebound (and nothing more) or nothing (in which case it returns NoBinding status for all bindings). If the server is willing to extend (or grant) the existing leases, the Rebind is fine. If the server is unwilling or unable, then it should force the client back into a Request phase as described in RFC 3315 section 18.1.8. That 18.1.8 section is also the only place a NoBinding status appears to be mentioned in terms of the Rebind. - Bernie
- [dhcwg] 2nd Try - draft-ietf-dhc-dhcpv6-stateful-… Bernie Volz (volz)