Re: [dhcwg] 3rd & *FINAL* try before ABANDONING draft-ietf-dhc-dhcpv6-stateful-issues-04.txt

"STARK, BARBARA H" <bs7652@att.com> Mon, 25 November 2013 14:31 UTC

Return-Path: <bs7652@att.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216591ADE86 for <dhcwg@ietfa.amsl.com>; Mon, 25 Nov 2013 06:31:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 brkkh7thxtLg for <dhcwg@ietfa.amsl.com>; Mon, 25 Nov 2013 06:31:07 -0800 (PST)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id E501C1ADDBD for <dhcwg@ietf.org>; Mon, 25 Nov 2013 06:31:06 -0800 (PST)
Received: from unknown [144.160.229.23] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id b2f53925.7e539940.255876.00-538.706794.nbfkord-smmo06.seg.att.com (envelope-from <bs7652@att.com>); Mon, 25 Nov 2013 14:31:07 +0000 (UTC)
X-MXL-Hash: 52935f2b4da7137d-5d228213f579f8800c0b4f3613f962347e3f19da
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id a2f53925.0.255866.00-255.706759.nbfkord-smmo06.seg.att.com (envelope-from <bs7652@att.com>); Mon, 25 Nov 2013 14:31:07 +0000 (UTC)
X-MXL-Hash: 52935f2b549fc8a4-f3efbe1a6be852764caebf23ad73fd165f129195
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rAPEV5oU010340; Mon, 25 Nov 2013 09:31:06 -0500
Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rAPEUuGB010146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Nov 2013 09:30:57 -0500
Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (GAALPA1MSGHUB9A.itservices.sbc.com [130.8.36.87]) by alpi132.aldc.att.com (RSA Interceptor); Mon, 25 Nov 2013 14:30:46 GMT
Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.03.0158.001; Mon, 25 Nov 2013 09:30:45 -0500
From: "STARK, BARBARA H" <bs7652@att.com>
To: Ole Troan <otroan@employees.org>, "Bernie Volz (volz)" <volz@cisco.com>
Thread-Topic: [dhcwg] 3rd & *FINAL* try before ABANDONING draft-ietf-dhc-dhcpv6-stateful-issues-04.txt
Thread-Index: AQHO6dzKbWNUzRQwB0ebbqFgjNKkPpo1/plw
Date: Mon, 25 Nov 2013 14:30:45 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E611303AB7DB@GAALPA1MSGUSR9L.ITServices.sbc.com>
References: <489D13FBFA9B3E41812EA89F188F018E1ADA9977@xmb-rcd-x04.cisco.com> <7692F1B0-A42C-49E0-9768-C26F0667218F@employees.org>
In-Reply-To: <7692F1B0-A42C-49E0-9768-C26F0667218F@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.61.166.223]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <bs7652@att.com>
X-SOURCE-IP: [144.160.229.23]
X-AnalysisOut: [v=2.0 cv=cZ5lWA/M c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=PCRoD-sj21sA:10 a=bk5NS_50c8gA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=fro2ymJJfqYA:10 a=48vgC7mUAAAA:8 a=NO3tdRle-1hkHz]
X-AnalysisOut: [E1NhIA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=8SgUW__qRyx]
X-AnalysisOut: [Xa8pK:21 a=xszeZ1oz8V0n1XP-:21]
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "Ralph Droms \(rdroms\)" <rdroms@cisco.com>
Subject: Re: [dhcwg] 3rd & *FINAL* try before ABANDONING draft-ietf-dhc-dhcpv6-stateful-issues-04.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Nov 2013 14:31:10 -0000

> > The 04 draft has expired and I'd like to publish a revised draft.
> >
> > However, as this is a WG document, I can't just make changes on my own -
> I need support for the WG for changes.
> >
> > And I sent this out a while back (twice) but, to my knowledge, received NO
> input.
> >
> > So, I will once again solicit feedback as to whether people support this or
> not.
> >
> > If I do NOT receive any feedback (either positive or negative), the only
> course of action is to ABANDON the stateful-issues work as it seems that
> there is NO interest in this work and therefore no reason to continue it.
> >
> > I'm really surprised at the lack of feedback given that the community at one
> time was very interested in this work and wanted to resolve the issues with
> "combining" RFC 3315 and 3633. This also was supposed to be input into the
> RFC 3315bis work ...
> 
> I for one is very supportive of this work.
> I don't think you can build an IPv6 CPE without it.
> 
> I also thought Tim Winters from UNH strongly supported this, based on IPv6
> CE ready logo testing?

I definitely think the draft is important.
For the specific rebinding issue being asked about -- the suggested approach makes sense to me, but I don't have enough detailed DHCPv6 expertise to take a strong stance.
Barbara

> > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On
> Behalf Of Bernie Volz (volz)
> > Sent: Monday, June 10, 2013 3:55 PM
> > To: dhcwg@ietf.org
> > Cc: Kim Kinnear (kkinnear); Ole Troan (otroan); Ralph Droms (rdroms)
> > Subject: [dhcwg] 2nd Try - draft-ietf-dhc-dhcpv6-stateful-issues-04.txt
> >
> > 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