DHC WG Minutes - IETF 76 0900-1130 2009-11-12 (Last revised 2009-11-19 06:35 PM EST) ------------------------------------ [Thanks to Shane Kerr for the extremely detailed note-taking you see below. Thanks to Behcet Sarikaya for being the Jabber scribe.] Chairs: John Jason Brzozowski Ted Lemon Minutes: Shane Kerr DHC WG I-D status: - waiting for suballoc author http://tools.ietf.org/wg/dhc/draft-ietf-dhc-subnet-alloc/ - vendor messages past last call, waiting on shepard document from chairs http://tools.ietf.org/wg/dhc/draft-ietf-dhc-dhcpv4-vendor-message/ http://tools.ietf.org/wg/dhc/draft-ietf-dhc-dhcpv6-vendor-message/ - l2ra drafts went to last call October 2008, lots of comments, respun, respun, forgotten - ready for WG last call, will need comments on current version - forcerenew-nonce, puts DHCPv6 nonce to DHCPv4, ready for WG last call - leasequery-by-remote-id had lots of discussion; agreement on how it should work... nobody in room knows what status is, but think waiting for new version based on discussion - netboot draft had pushback based on complexity, less complex draft respun, ready for WG last call - will be call for review on mailing list Will be 5 drafts for WG last call. Will have one per week. Please read and comment! netboot had no comments during WG last call... *after* WG last call had lots of comment! - guidelines was being worked off a year ago; useful, but not seen anything since - ldra status David Miles: ready for last call, all comments collected, changes made to draft, final review then last call John Brzozowski: Any objections? [ none ] Take to mailing list. Working Group Charter Chairs 10 minutes - Ted Lemon: If EAP draft wanted in WG, then charter change needed. Draft about securing DHCPv6 using CGAs coming, also not in charter. Related to DHCP, this is probably the right place to be doing it. I think we should recharter. John will talk about redundancy setup with multiple DHCPv6 servers, similar to DHCPv4. If we were to work on this, it would also require a charter change. Think about whether WG should be working on them as we go through them. I will bring it up on the mailing list. DHCPv6 option for network boot Authors or Chairs 5 minutes - Ted Lemon: netboot option originally set up to be able to support setting up redundancy, and different places you could go and download different files. Consensus was that this was too complicated. Authors are not here, but they believe it is ready for last call. Has anybody read this draft? [ No hands ] Anybody interested here? [ No hands ] There is a lot of interest on the mailing list, but we don't have to talk any more about it here. DHCPv6 Redundancy Considerations J. Brzozowski 15 minutes John presented this draft from slides - read the slides and the draft for details. http://tools.ietf.org/agenda/76/slides/dhc-8.pdf - Ted Lemon: Does anybody think this is work they would be interested in? [ Lots of hands ] Current state of the art discussed, but also would it be useful to have a more formal redundancy protocol like DHCPv4 failover. The key point is that DHCPv6 is also about assigning prefixes, which you can run out of. When you're doing prefix delegation, you don't want to force them to renumber. Even if you have lots of prefixes, you still want to make sure you always give out the same prefix. Some sort of redundancy protocol for DHCPv6 sounds like a good idea. [ Some hands ] This work would require a recharter. Will bring this up on the mailing list. We cannot adopt this draft without a recharter. Any comments? [ None ] EAP Authentication for DHCP for Broadband Ric Pruss 10 minutes http://tools.ietf.org/agenda/76/slides/dhc-6.pdf - Ric Pruss: Document is unchanged from last IETF. Have had feedback from a number of customers that they don't like vendor messaging. Reconsider the messaging and get a message type for this - the point of having a standard is that it is a standard. That is the main issue. I don't have any thing against that personally, but really getting strong feedback. DHCP Authentication Analysis Chairs 10 minutes http://tools.ietf.org/agenda/76/slides/dhc-4.pdf - John Brzozowski: Some problem with document names. But based off of pruss-06. Intention is to cite ongoing concerns with proposal. This analysis draft will continue to represent items that would be a concern. - Ted Lemon: Got e-mail about holding state in relay agent. I started thinking about issues about how much state to store, and related issues. Number of new observations in this analysis that talks about this issue. Recommendations about how we think this ought to be done. I appreciate the feedback. - John Brzozowski: At this point no plan for a subsequent revision. I think a new revision will end up on the mailing list. We need direction from area director. - Ralph Droms: (Internet AD) Document ready to be accepted as WG item, analysis document giving information for WG. Has analysis document been accepted as WG item? Not trying to add additional overhead, if ready than AD can sponsor it. - Ted Lemon: How many people think the analysis document is ready to be taken on as a WG item? I think this is part of what we do. We don't have to recharter to take this on! [ No hands ] If it should be published as an actual document, either we need to take it on or Ralph needs to sponsor it. - Ric Pruss: I've tried to knock it down so little is left for analysis document. - Ted Lemon: Agree, still some issues for the document. Some guidance whether it makes sense to implement. - Ralph Droms: Would like to capture some history of changes made. Avoid revisiting arguments! - Glen Zorn: Actual value of document is as a historical record. End document will have like 3 lines. Not sure how to do that in a clean way, but seems valuable. - Mark Townsley: It would seem logically that if there is stuff in the analysis document that if there is a protocol designer who wants it in their document, publish it in the analysis document *after* the protocol document seems backwards. - Ralph Droms: Important in the end that the analysis gets put in the public record (as an informational document), so someone can look at the protocol and analysis documents and figure out what to do. - Ted Lemon: Would also like the protocol document to reference the analysis document. So someone in the future would find it. - Behcet Sarikaya: Has the idea of using vendor specific messages for authentication been done in practice before? - Ted Lemon: Has not made it through IESG yet, so "no". This would be the first one. I don't know where Ric's work is going to wind up, because it is a little controversial. A lot of people want it, a lot of people don't want it. Personally I don't see any problem using a DHCP message type, but I don't see any problem using a vendor message type. If this does NOT become a working group document, assigning a DHCP message type becomes problematic. - Glen Zorn: I had a recent problem with an AD-sponsored draft which was to become standards track. Somebody decided it would be informational without asking authors. If I had known this I would have simply sent it to the RFC editor! If these things are vendor specific, then why could we not just send it to the RFC editor and ignore the IESG? - Ralph Droms: I'm confused. I thought the reason we were going through this was to *not* have this be vendor specific options. Vendor specific was a temporary measure I thought? (Ric Pruss: yes) - Ric Pruss: We would like the document to be accepted as a WG item and use normal DHCP messages. What we are doing with the messaging is one issue, to be worked through on the WG. - Ralph Droms: Your (Ric's) goal is to have IANA registry message types? (Ric Pruss: correct). You (Ted's) goal is the same thing? (Ted Lemon: I don't care) Have we asked the working group? - Ted Lemon: As I said, this is controversial. At some point we need to ask the question whether the WG will do this or not? Should we answer that now, or after issues in analysis draft have been addressed? I need a response back from Ric about the analysis we *just* submitted - it seems premature to ask this question. - Ric Pruss: There is nothing life-threatening there. But some issues I really need to think through. - Ted Lemon: That's exactly my point. Why I don't want to ask about adoption now. If the WG is going to be reviewing this, then it should be taken on as a WG item. - Glen Zorn: Doesn't have to be in a perfect, Venus stepping from a half-shell state. Would prefer it to be a standards track document, although not after 7 years of work. - Alper Yegin: I think the analysis is incomplete. - Ted Lemon: Would appreciate if you could check the latest stuff when you get a chance. But understand you didn't get a chance. - David Miles: Point of WG is a collaborative area. Would like to call the question now. - Ted Lemon: If we were to call this question now, would have to call it on the mailing list anyway. Would be nice to have a deadline, a small number of weeks. - Ric Pruss: Sounds good. - Ted Lemon: So the question now is not binding. But I would like to get a sense of the room. - Ralph Droms: To be clear, question will be called on WG mailing list. - Alper Yegin: What's the point of doing the analysis draft again? - Ted Lemon: The current WG charter says the WG must analyze DHCP related documents and give feedback to the document. We would have to recharter to adopt the draft itself. So the point of the analysis draft is to do the part of the process that we are chartered to do. - Alper Yegin: Questioning the point of an incomplete analysis draft. - Ted Lemon: We feel the draft is complete. If omissions when would like to hear. - Alper Yegin: How about we go step-by-step? Set a deadline for the analysis, *then* make a call? - Ted Lemon: Do you have time in the next 2 weeks? - Alper Yegin: Absolutely. - Ted Lemon: If draft is complete, then will call question ASAP. If draft is incomplete, then we will NOT call the question, and will discuss on mailing list. - Ted Lemon: *** 12th is today *** *** 23rd is deadline for feedback on list *** *** 30th question will be called *** - Ted Lemon: Need hard deadline. Need to be able to be say we are done. - Glen Zorn: Sounds like a WG last call. - Ted Lemon: What we're doing is weird. - Ric Pruss: We're working on the document! In my sense there is nothing life-threatening in the analysis. There are issues to fix and we are working through and fixing the issue. - Glen Zorn: This is a de-facto WG document! - Ted Lemon: If we agree to work on it, does not mean we will get an RFC at the end. - Alper Yegin: Why are we jumping ahead? - Ted Lemon: We are not! We have done the analysis! Everyone involved in this discussion is quite interested. One way or the other we are *not* having this discussion at the next IETF. - Glen Zorn: I've learned a lot about delaying tactics in this WG. It has been a very valuable education. Please ask this room for its sense of whether or not to adopt this document! - Ted Lemon: Can we get a show of hands for people interested in adopting this as a WG item? [ 10 or 11 ] People *not* interested? [ 2 ] Probably people not in this room, so what is why this is not binding. Have seen evidence for support. Please review analysis document and register interest on mailing lst. Secure DHCPv6 Using CGAs Sean Shen 15 minutes http://tools.ietf.org/agenda/76/slides/dhc-3.pdf - Ted Lemon: Has anybody read this document? [ about 7 or 8 readers ] Any questions or discussions? Are people interested in taking this on? [ probably 8 people ] Any interest in *not* taking this on? [ nobody ] We'll raise this question on mailing list. This would require recharter, but not a big deal since we're already talking about that. - Ralph Droms (Internet AD): Requires rechartering. May end up in a different WG. I need to confirm what CSI is doing. We'll also want to get some security expert review. - Ted Lemon: My personal opinion is that it is a DHC document not a CSI document. In addition, there is another document which talks about how to communicate your CGA information to the DHC server, which is in the CSI group. I think that document belongs here. - Sheng Jiang: We have another document in the CSI working group. We prefer to have this document in this WG, and leave the analysis in the CSI working group. - Behcet Sarikaya: Co-author of other draft. Agree that it should be here. - Ted Lemon: Is there interest for taking on that work? [ 10 or 15 hands ] DHCP Relay Agent Stacking Robin Zheng 10 minutes http://tools.ietf.org/agenda/76/slides/dhc-2.pdf - John Jason Brzozowski: How many people have read the draft? [ Something like 5 ] - Ric Pruss: I would be very concerned with multiple option 82 in broadband elements. - Ted Lemon: Are you talking about the DHCP server? - Ric Pruss: All the elements! I buy into the problem statement. But the particular solution in the draft is scary. - Ted Lemon: Point of order - we have another presentation with an alterative solution to the same problem following. I think we need to come up with a combined solution. Multiple Relay Agent Information Option Hui Deng 10 minutes proposes using a different option for stacking relay agent information http://tools.ietf.org/agenda/76/slides/dhc-1.pdf - Ted Lemon: Comments? - John Jason Brzozowski: How many people have read the draft? [ 3 ] - Sheng Jiang: I don't understand why this work has come back. Something that should have been solved from the very beginning. There are multiple relays everywhere. I think we should do it as early as possible. - David Miles: Why is this so important today? We have OMTs which are tagging sufficient information. There is a well defined relationship between the OMT and the LT. - Robin Zheng: If the ONU adds all this information, in transit, we need to configure the OLTs information in all the ONUs. Also, with multihoming there are at least 2 OLT that communicate with the same ONU due to redundancy. If the ONU changes the OLT then you need to reconfigure the OLT information. Seems that the best way is that the ONU adds its own information, and the OLT also. - David Miles: I understand, I don't think it is a problem. - Ted Lemon: 2 different paths is not a problem? - David Miles: One DHCP packet, so 1 ONU. I have not seen this as a problem. I am not opposed to it, but I don't see it as a big issue. Perhaps more discussion in the broadband forum would be useful. - Ted Lemon: A fair number of people have said they care about this. - Hongyu Li: In the broadband forum, in the TR-156, the only definition about what the line ID could look like, but not how you can add it. Since this is IETF protocol, it is a sort of "forbidden area". It is valuable to have a better solution to make this happen in this group. For IPv6 we already have layer 2 and layer 3 ways to handle this better. But we need to solve this for DHCPv4. Regarding the configuration part, this is more related to the physical layer. Basically you need 2 informations... you have to do this! - Sean Shen: I like this because it will help operators who prefer centralized administration, so I hope this work can be done here. - Ric Pruss: Broadband forum does not specify how you do this. These are layer 2 elements so they don't appear as relay agents at layer 3. - Ted Lemon: The layer 2 can and does add option 82 depending on the configuration. - Ric Pruss: It's an append function. If it breaks things it should not have done that. - Ted Lemon: But people have identified the need for a 2nd relay agent option. Are you saying they are wrong, or ...? - Ric Pruss: I don't see what needs to be done. - Ted Lemon: If they want to do that, the protocol does not support that. You can't have 2 option 82s in a row. - Ric Pruss: But you can have two relays in a row change option 82. - Ralph Droms: The 2nd element jams more stuff into existing option 82. There are multiple ways to do this. - David Miles: Specified in the broadband forum documents. I think this is not the right forum to be discussing this. It should be done in the broadband forum first. - Ted Lemon: Was originally brought up in the context of configuring an office building. The example is just an example. Whether or not this is a good idea is independent of whether this is applicable to PON. - Hongyu Li: Agree that we can insert information into the existing option? - Ted Lemon: Current RFC does not say that. Violates the spirit of existing documents for authentication. If you want multiple relay agents, need a new document. Multiple relay agents are explicitly excluded. - Ric Pruss: Surprised that you want this. The information can be learned in multiple ways. - Ted Lemon: One of the specification describes this. - Ric Pruss: Broadband forum describes this. - Ted Lemon: Lets table that. This is not a broadband forum only issue. The office case is a legitimate use case. If you think it will break the protocol, then please explain it. If you do not have objection of that kind, then there are people who want to do this and feel they have a real application for it. I don't see the point of the WG saying "you can't". - David Miles: This may be worth debating on the list whether we want to include this in another draft. The lightweight DHC relay agent draft already does this. - Ted Lemon: Can I see a show of hands for people supporting some solution to this problem? [ about 15 or 20 people ] People oppose doing a solution to this problem? [ no hands ] Concensus this is work that needs to be done. You can't stack multiple option 82s. Authors come together for a new draft? - Robin Zheng: Sounds good to me. Choices: modify option 82, define a new suboption to option 82.... - Ted Lemon: Please have discussion on mailing list. DHCPv6 Route Option W. Dec 10 minutes http://tools.ietf.org/agenda/76/slides/dhc-7.pdf - Wojciech Dec: draft is actually -02 not -01 - Wojciech Dec: presented 2 meetings ago, some discussion - David Miles: Is there anything that prevents the use of next hop? - Wojciech Dec: Next hop must be link local, so removed recursive lookup. - David Miles: Having option of global unicast... - Wojciech Dec: Left that open in the document. If you point it to the next hop address that is not on the subnet, is it smart enough to do a recursive next hop? Global next hop *is* allowed in the draft. But if a link local address is received it must be associated with an interface. - David Miles: sounds great - Ted Lemon: Where are you planning on doing this work? - Wojciech Dec: Here? - Ted Lemon: Sounds like routing work. - Wojciech Dec: Breaks no new area in terms of routing. - Ted Lemon: Takes place of existing routing mechanism, right? - Wojciech Dec: No. It's a configuration parameter which is passed down, so I guess like configuring a static route could be considered a routing protocol, but I'm not quite sure this is breaking new ground. - Ralph Droms (Internet AD): Not sure why breaking new ground is important. Issues in IPv6 world... IPv6 world has mechanisms in place for placing information about routes using router advertisements. Parallel mechanisms need to be motivated and driven by either the v6 extensions WG or perhaps the routing area. It's not something that the DHC working group can take on unilaterally. Information is being carried through DHCP, but it is information for the host that is not directly related to the operation of the DHCP protocol. We need to at least have the discussion with some of the other ADs to determine where this should go. - Yasuhiro Ohara: I think this is a fairly simple request. I can imagine because when we implement the DHCP client we assign addresses and default route. I also wondered why we can install some prefix. I feel the same way. DHCP must have this kind of option. In comparison to the RA, there is some kind of difference - stateless vs. stateful. - Ted Lemon: I am not saying this is not useful work. - Wojciech Dec: I am not sure how to proceed then. - Ralph Droms: I understand. It will take me a short conference to proceed. We will have an answer for you in a short integer number of weeks. DHCP Option Guidelines D. Hankins - David Hankins: Draft is waiting on reviewers. At IETF 74 we didn't have enough folks who had read the draft. It wasn't presented at IETF 75 in my absence. I will mini-review myself and rev the draft to reintroduce it to the I-D database and ask for reviewers on the mailing list, maybe we can move it to WGLC at or after IETF 77. DHCPINFORM Clarification D. Hankins - David Hankins: I judged needed time to absorb more reviewers as well, so I will take the same action (mini-review, rev to re-up it to database). John Brzozowski: We're done, thank you. Ted Lemon: Thank you everybody for coming.