Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item
"Bernie Volz (volz)" <volz@cisco.com> Mon, 09 April 2012 00:21 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 D2EF921F858E for <dhcwg@ietfa.amsl.com>; Sun, 8 Apr 2012 17:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.524
X-Spam-Level:
X-Spam-Status: No, score=-11.524 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, GB_I_LETTER=-2, 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 mRFxg4SiU67g for <dhcwg@ietfa.amsl.com>; Sun, 8 Apr 2012 17:21:25 -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 6E19F21F8507 for <dhcwg@ietf.org>; Sun, 8 Apr 2012 17:21:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=11171; q=dns/txt; s=iport; t=1333930885; x=1335140485; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ONTyNPjAeSV5HDbOyHLTP0NXzuIeXprRJjY3MlsWKJw=; b=KUUulONc0DFaVuMm6Lxvwg6s1RlIi0xVtrzjgLPW/wq6d/JTbpiZiY1J visQwxVGVHGQtA5+4x2erg7L+ZP2YfJOkwHg+o1Ts6PMlO2BPG+/Duy5e TklqripvrQ8JonKMVe+/0IKtQWaT3blXdwIYFgzgjHwz3oBLJYWZYNyGF 8=;
X-IronPort-AV: E=Sophos;i="4.75,391,1330905600"; d="scan'208";a="73008789"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 09 Apr 2012 00:21:25 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q390LPqd027138; Mon, 9 Apr 2012 00:21:25 GMT
Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 Apr 2012 19:21:24 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 08 Apr 2012 19:21:23 -0500
Message-ID: <D9B5773329187548A0189ED6503667890BCAFBEC@XMB-RCD-101.cisco.com>
In-Reply-To: <4F81BA73.4000400@gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item
Thread-Index: Ac0Vo1FUC+sddg0sScatsbgk57mmYgALM5+Q
References: <D9B5773329187548A0189ED6503667890B9F42CB@XMB-RCD-101.cisco.com> <4F81BA73.4000400@gmail.com>
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>, dhcwg@ietf.org, Ole Troan <ot@cisco.com>
X-OriginalArrivalTime: 09 Apr 2012 00:21:24.0796 (UTC) FILETIME=[B2AD0FC0:01CD15E6]
Subject: Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item
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, 09 Apr 2012 00:21:27 -0000
Tomek: I spend some time reviewing your other points and have comments inline. Ole's position on any of these may be different. Thanks again for your support and feedback!! Much appreciated. - Bernie -----Original Message----- From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com] Sent: Sunday, April 08, 2012 12:19 PM To: dhcwg@ietf.org; Ole Troan Cc: Bernie Volz (volz) Subject: Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item On 12-04-05 19:25, Bernie Volz (volz) wrote: > I kindly request that we adopt this document as a DHC WG work item. I do support this work and its adoption. I also have couple of comments: 0. Would it be reasonable to name this work 3315bis? BV> Already discussed in previous email. 1. I assume this work will also cover all combinations of IA_NA/IA_PD/IA_TA. But what about IA_PA, specified in draft-ietf-dhc-host-gen-id? This work was adopted by DHC, so authors should take a closer look at it. (I'm sorry I can't offer any better comments here. I haven't read host-gen-id yet). BV> Already discussed in previous email. 2. stateful-issues draft is a very useful work. Once adopted it should also look at CGA issues - my understanding is that it basically degrades DHCP into registration service, compared to normal assignment service. I haven't read CGA drafts recently, so again this is only a pointer to something that should be looked at. It is possible that there's nothing to do in that matter. BV> This will have to be studied further. Another interesting question will be how this interacts with failover. We also need to look at the usage cases - will CGA addresses and PD be used by a device (seems to make some sense) and whether the current CGA procedures can accommodate this in the Solicit/Advertise/Request/Reply[/Renew/Reply...] cycle. 3. Abstract could be reworded: "the ne options for Prefix Delegation options for DHCPv6 into DHCPv6" part is repetitive. The same is true for first paragraph of Introduction section. BV> Yes. 4. Text refer to different IA options as IA_. I think it would look better without the underscore. If that is not clear, perhaps it could be clarified that "IA option" means any of IA_NA, IA_TA or IA_PD. BV> Yes. We should use better/consistent terminology. "IA options" is probably better. 5. Section 3.1 states that client MUST ignore IAs with status code NoAddrAvail. That doesn't help much. What about other status codes? IA_PD may be returned with NoPrefixAvail. Much better would be to say that client MUST ignore IAs with status code other than Success. BV> This is just to replace a specific text in Section 17.1.3 that referred to NoAddrsAvail case. I think the new text needs to be fixed as the 'ignore any IAs' here applies to IA_NA (and perhaps IA_TA) but not IA_PD. But to be fair, RFC 3315 only references IA_NA/IA_TA. The point here is simply that NoAddrsAvail applies to IA_NA/IA_TA options and the client should process these for IA_PD (and potentially other IA options). We should also add that client SHOULD rate advertise without assigned IAs lower than other advertises, but exact advertise rating algorithm is up to client imlementors. For example, I would implement a client that accepts advertise with preference=5 and all IAs assigned rather than one with preference=10, but without IA_NA or IA_PD assigned. BV> Yes, this is a good point. Advertises with all requests satisfied should rank higher than ones with one some. This does get complicate fast and we want to make sure to keep it simple since in most cases there will only be one Advertise (there usually aren't a lot of DHCP servers on networks with very different configurations). 6. Section 3.2 says that 3 non-success status codes (NoAddrsAvail, NoPrefixAvail and NotOnLink) should appear within IA options. It would be better to not explicitely limit to those 3 status code, but say all non-success status codes to maintain forward compatibility. Something like "e.g. NoAddrsAvail, NoPrefixAvail, NotOnLink and other non-success status codes" will do. BTW you missed UnspecFail code that is already defined and could be used, so the text as it is does not cover all situations from day 1. BV> 3.2 lists "NoAddrsAvail, NotOnlink, NoBinding" and is describing the differences between the possible location of Status Code options in Reply and Advertise messages.I don't think UnspecFail appears encapsulated in an IA option (where did you find that)? BV> I do think we need to revise the "Proposed Solution" as it isn't just IA_NA but also IA_TA. We believe it best to keep backwards compatibility and not change the existing behavior as we might break client implementations if were to change this. So, we want to stick with the current RFC 3315 behavior. What we feel we can change is that the client SHOULD look at the other IA options that are returned and the 'other configuration' options and use them. Existing clients that follow RFC 3315 to the letter won't as they'll ignore these Advertise messages. 7. It should be clarified that status codes are specified per instance of an option, not per option type. Think about client that sends 3 IA_NA options. It can receive 2 addresses and NoAddrAvail in the third instance. That could be either due to pool depletion (unlikely) or server policy that allow server to assign no more than 2 addresses per client (likely). BV> Actually section 17.2.2 in RFC 3315 says nothing like that. If there are 3 IA_NA options and 2 return addresses, then the Advertise will contain 3 IA_NA options, 2 with IA_ADDR option(s) and one with no IA_ADDR options. The NoAddrAvail is ONLY used when the server returns NO addresses to any IA_NA/IA_TA options. 8. Proposed replacement errata in section 3.2 should clarify that such proposed action should be taken on each IA being answered. BV> Not sure I understand your comment. I think that the text should say this NoAddrsAvail ONLY applies to the IA_NA/IA_TA options). IA_PD is already covered by RFC 3633. And, other IA_* options should state what the behavior is to be (hopefully following IA_PDs lead and encapsulating the status code into the IA option). We can't change IA_NA/IA_TA because of backwards compatibility, but all others should follow the IA_PD lead and place the "NoAddrsAvail" or whatever status code option inside the IA option. 9. Section 3.3 could mention relation between T1/T2 and information refresh option (RFC4242). The reasonable clarification would be that client MAY request other options in ORO when sending RENEW or REBIND. BV> Could you clarify? RFC 4242 (Information Refresh Time) states: "It is only used in Reply messages in response to Information-Request messages." I believe that the T1/T2 times are to cover the 'other information' renewal. 10. Allowing PD to be confirmed with CONFIRM could be tricky. In many deployment scenarios routing is configured separately for each delegated prefix and server can't really say "yeah, I've never assigned you that one, but it should be valid on your link.". I don't object allowing IA_PD in CONFRIM, but it should be accompanied with a clause that server MUST include IA_PD response only if it is certain that delegated prefix is really valid. This will complicate things. What is client sends CONFIRM with IA_NA and IA_PD and server can confirm that address is on-link, but is not sure about prefix? There's no such status as IdontKnow. Different IA combinations should be given more thought. BV> Yes, there is an I Don't Know status. The server MUST NOT Reply in that case. Confirm has this built in. That's why I like Confirm. It doesn't overload other messages. It doesn't require the heavier weight processing of Renew (or Rebind). It allows for 3 responses types - On Link (Success), NotOnLink, and I can't tell / don't know (drop Confirm). BV> I really wonder how often this concept of the delegated prefix being completely outside anything other servers (on the same network) know is. In all of the PD cases I'm aware of, the other would know. Yes, I agree it "could" happen. But in those cases if you used Renew, you'd gain nothing since only the assigning server would be able to say yes or no. 11. Section 3.5. A what??? Are you suggesting that client can send RENEW *after* it sent RELEASE? If that is the case, I strongly object. Once client released a lease, it has no further claims to released address/prefix. It MUST NOT send RENEW. Proper way it to send REQUEST, not RENEW. Also. Section 3.5 title mentions DECLINE, but there is nothing about DECLINE in the text. Authors probably forgot adding a sentence that DECLINE may be sent at any time when client owns a lease. BV> Already answers this in previous email. Yes, we need to clean up this text. DECLINE is the more likely situation. I am not sure why a client would Release just the address but not the prefix if it got both. We probably should add something to the document about discouraging releasing only 'half' the acquired leases. 12. A question about proposed operation in section 3.6. What if there are two servers. Imagines a case with 2 servers: one that provides addresses and second one that provides prefixes. Client requests IA_NA and IA_PD. What should client do? BV> We have specifically indicated that this is NOT a situation we are supporting. We consider this split administrative domains. We will need to add text. BV> If you look at the slide deck uploaded for IETF-83 (Paris), the last slide has a slide about Administrative Domains. So, this is something we will work on. The idea is fairly simple in that we'd add a new "Administrative Domain Name" option which servers could include in replies. The client COULD then decide which administrative domain it wants to use and even support split domains (i.e., accept an Advertise from one domain for addresses and another for prefixes). Clearly there are security issues and client complexity here but if people want this, we'll need to craft something to handle it. BV> Note that the Authentication option already has something like this - the "DHCP Realm". But this would be separating out this concept from any authentication. 13. In 3rd paragraph in section 3.6 it would be better to say non-success status codes rather than NoAddrsAvail (or at least NoAddrsAvail/NoPrefixAvail/NotOnLink/UnspecFail). BV> The RFC 3315 text would only reference NoAddrsAvail. 3633 would need to change to specify NoPrefixAvail instead of NoBinding. But NotOnLink and UnspecFail are not applicable here (they are as already is). 14. Section 3.7 is the most unfortunate. I understand the reasons that led authors to that decision, so I sadly accept it. BV> As mentioned above, we intend to follow on with work to address this (see your 12). Despite my comments, I strongly support this work and it adoption. It is great that we will get this thing clarified. Greetings to all woods dwellers, BV> Thanks! Tomek
- [dhcwg] Call for Adoption, draft-troan-dhc-dhcpv6… Ted Lemon
- [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-iss… Bernie Volz (volz)
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… Kim Kinnear
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… Daryl Tanner
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… Dedecker Hans
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… Timothy Winters
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… Tina TSOU
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… Chris Donley
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… Gaurav Halwasia (ghalwasi)
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… Hans Liu
- Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful… Tomek Mrugalski
- Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful… Bernie Volz (volz)
- Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful… Tomek Mrugalski
- Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful… Bernie Volz (volz)
- Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful… Bernie Volz (volz)
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… STARK, BARBARA H
- Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful… Bud Millwood
- [dhcwg] Fwd: Call for Adoption, draft-troan-dhc-d… Ted Lemon
- Re: [dhcwg] Fwd: Call for Adoption, draft-troan-d… Weil, Jason
- Re: [dhcwg] Fwd: Call for Adoption, draft-troan-d… Tomek Mrugalski
- Re: [dhcwg] Fwd: Call for Adoption, draft-troan-d… Ted Lemon
- Re: [dhcwg] Fwd: Call for Adoption, draft-troan-d… Leaf yeh
- Re: [dhcwg] Call for Adoption, draft-troan-dhc-dh… Ted Lemon