DHC working group Anaheim, CA Thursday, March 25, 2010 Full Minutes Administrivia (administrivia) 15 min DHCwg chairs - Added agenda item for James Woodyatt to discuss home gateway reconfiguration problem. - draft-ietf-dhc-agent-vpn-id Needs a new version, then maybe a new working group last call, will discuss after it's reissued. - draft-ietf-dhc-dhcpv6-vendor-message - draft-ietf-dhc-dhcpv4-vendor-message Both drafts have seen IESG review. Update later in meeting. - draft-ietf-dhc-dhcpv6-opt-netboot Submitted to IESG - draft-ietf-dhc-dhcpv6-reconfigure-rebind draft-ietf-dhc-subnet-alloc Ready for IESG submission, but not yet submitted - draft-ietf-dhc-forcerenew-nonce Authors are planning to issue a new version. - draft-ietf-dhc-dhcpv4-bulk-leasequery - draft-ietf-dhc-dhcpinform-clarify - draft-ietf-dhc-option-guidelines - draft-ietf-dhc-leasequery-by-remote-id Will discuss in this meeting. Guidelines for Creating New DHCP Options draft-ietf-dhc-option-guidelines-06 5 min David Hankins Summary: David Hankins has made some updates to the draft since previous presentation, and has some more ideas. Kim Kinnear would like to kick it out the door and revise later if necessary, rather than revising now and never publishing anything. David would like more review. Action Items: Five or six volunteers for review, only one named was Suresh Krishnan. David Hankins will solicit additional feedback on the mailing list. Discussion: David Hankins-- will talk about guidelines and clarify together. bunch of editorial changes before meeting, thought about packet size issues and ways in which v4 and v6 are different. packet size issues author needs to be aware of when writing a new draft. you'll recognize the following four slides from every other presentation I've given on subject. Skipping past security slide. Next steps. It started out in early days as advice I was giving to people who want options to be deployable. That's its current format. Do we think we should change that? Should it be a walkthrough? Any feedback is great. There's discussion about parameter request list, a lot of people write drafts without considering that. Should we have boilerplate? Fantastic one in rfc5223. Should we steal that and put that in here? Question is where do we make dividing line between what new option guideline needs to recommend and what we should leave up to other definition in RFC3315 etc. John Brzozowski-- one question, how many have read doc? Kim Kinnear-- boilerplate wouldn't be bad idea, but we could do this forever. so I liked it, it looks pretty good, let's just do it, we can do it again if we need to. I hate to see ti just linger because we want to make it better. Do last call, do boilerplate as part of that. David Hankins-- kind of hard to last call it when five people raised their hands. John Brzozowski-- more reviewers. Volunteers? Suresh. Five or six others. We'll reach out to reviewers, ... DHCPINFORM Message Clarifications draft-ietf-dhc-dhcpinform-clarify-04 10 min David Hankins Summary: Good discussion of various points in the draft. No conclusions were drawn about next steps. Action Items: David would like more feedback; in particular, about whether clients SHOULD unicast when they can. Kim Kinnear wants David to add back some discussion in the draft about how to find the relevant IP address or subnet for the client; this was removed from the draft, but Kim thinks that the discussion should be there even if we don't make a recommendation. Discussion: David Hankins-- DHCPINFORM clarify. Editorial changes, clarified something that we needed very much, the idea that the server recommitted a read-only copy of client's lease . 2131 says can't look at it, I wanted to clarify that you can look at it, just can't change it. Main things, misconceptions. Not just that people already statically configured are getting options, also dynamically configured clients are getting extra option. These clients don't want to do full DHCP request so they do a DHCPINFORM instead. Also, some clients want to potentially reach a box that's no the main DHCP server. We've had clients show up on network that zeroed ciaddr, absolutely intolerable according to rfc2132. They don't know their address. From mailing list, some vendors putting enterprise id in chaddr, that's not okay. Don't think DHCPINFORM can transit a relay agent, which only becomes relevant in case of zero'd ciaddr. In DHCPINFORM server doesn't set yiaddr, which relay needs to unicast. Finally, permitting read-only image of lease so we can source configuration changes. Fixes interoperability problem between ISC DHCP and Windows. In finishing all those pieces of information, someone came up to ask me if this was a correct conclusion: clients looking for that one extra option, I recommend they unicast to DHCP server, no reason to broadcast. I'd like some feedback if we think that's wrong, and we can talk about that. Again, organized as overlay, assumes you know what DHCPINFORM is. If you haven't been doing it this way, think about changing it. John Brzozowski-- how many readers? Five. Kim Kinnear-- Somewhere in here you talked about how to find the relevant IP address or subnet for the thing. Ciaddr if it's there, link selection suboption of relay agent. Then giaddr. What happened to link selection option that's not in relay agent? David Hankins-- That was a discussion we had before. We decided to omit it. Kim Kinnear-- It's worth saying why you omitted it. David Hankins-- There was a conflict, we decided relay agent won. Not a big deal, otherwise looked great. David Hankins-- we have an issue to clarify, I'll rev the draft to remember/rewind that decision. Will bring it up and discuss it. Then go from there. Ted Lemon-- You talk about the problem of the client not being able to get certain info that it ought to have, then later on you propose that the client use the DHCP server identifier, but the client can't get the info it needs wouldn't have server identifier. David Hankins-- That's why it's a SHOULD. Also there's many different layers of client here, the one that's sending DHCPINFORM to broadcast is setting ciaddr, it's these ones later on that are embedded in a web browser somewhere that are not setting ciaddr. We have different clients, trying to provide input to both. Active DHCPv4 Lease Query draft-kinnear-dhc-dhcpv4-active-leasequery-00 10 min Kim Kinnear Summary: New draft, Kim explained what it does and motivation behind it. Working group participants present at meeting strongly favored adoption. Action Items: Call for adoption on mailing list, WG chairs will do. Discussion: Kim Kinnear-- Active Leasequery for DHCPv4. We'll talk about bulk lease query also. This builds on that. A way to get near realtime updates from a DHCP server, where a bulk leasequery, give me all the stuff you've got, and it dumps a bunch of stuff to you and completes. Active leasequery says give me stuff as you're doing it. So youg et packets periodically whenever DHCP server does "soemthing". You find out what's happening in DHCP server, multiple clients can connect to multiple servers. Why? DHCP knows things people want to know, people really want to know what DHCP knows, would like to know near realtime. This is why /we/ need active leasequery. Our customers keep writing extensions to spit this out. They do that, and they get what they want, about 20% get it wrong, we spend our lives trying to help them get it right. A number of vendors let their customers have direct access to their lease state database. Difficult to standardize. We thought about ways to meet this need for our customers. Along the way we said we could define this capability in a standard way instead of in very specific way. Builds on bulk leasequery. Creates TCP link, sends active leasequery request, looks like bulk leasequery, except it never stops. Client could drop connection, server could drop connection. But generally you would expect this to be something that would just stay up as long as server stayed up. Discussion? David Hankins-- Add to why do we need this. In v4 and v6, problem with reliable communication with relay. This isn't an active solution, provides an inactive backup solution. Kim Kinnear-- absolutely. Next, should we do this? 8-10 hands in favor. no hands against. DHCPv4 Leasequery by remote ID draft-ietf-dhc-leasequery-by-remote-id-04 5 min Kim Kinnear Summary: Leasequery by remote ID draft is mostly ready for publication, but needs to be trimmed to remove verbiage that simply duplicates RFC4388. Action Items: Authors will edit draft to remove duplicate verbiage. We will do a WGLC after they issue the new version. Discussion: Kim Kinnear-- Leasequery by remote-id. Authors couldn't be here, these are the folks that we did bulk leasequery with. Asked me to present. Adding a new query type to basic DHCPv4 UDP leasequery as well as query type we use in the bulk leasequery we're trying to get through last call. Got rid of lease-unassigned, feel it's ready for WGLC. Kim Kinnear-- I have a comment on this. I noticed that there's a lot of mechanism and words reproduced from RFC4388. Not needed. Just change the things you're trying to change. Will make this comment to them directly. Idea is good, didn't do anything wrong. Ted Lemon-- I would suggest the document needs to be edited as you proposed, I agree that extra text is bad, and needs review following that edit bc that's a big edit, could do review in last call, but that's the prerequisite. Kim Kinnear-- if that review says it's okay, otherwise you've got to do two. Ted Lemon-- The only time people actually reread docs is at last call, so we'll do last call and that will light a fire under peoples' feet. Bulk DHCPv4 Lease Query draft-ietf-dhc-dhcpv4-bulk-leasequery-02 5 min Kim Kinnear Summary: Lots of good comments, but not enough review. Action Items: - Spin draft, do another working group last call. - Nominate Alfred Hönes as the DHC working group's Poet Laureate. Kim Kinnear-- Bulk Leasequery Two drafts, info sys tried to do bulk leasequery. It looks a lot like v6 cuz we used the same text, although we're cleaning that out. Two drafts that we put together, ran through last call, reviews from Ted, David Miles, Bud Millwood, Alfred Hönes. Reviewed deeply but not broadly, we've recycled. What is it? RFC4388-style packets over TCP framing, new query types, remote ID, relay ID, query start net times, additional information in this from RFC4388 kinds of lease queries. What's different in -02 from -01, removed grace period. We had weirdness with method option, now it's status code, like v6. Apologize, did that before deadline, didn't get all the references back to it, need to do another pass before last call. Lots of editorial changes, latest thing by Alfred, issues from last call which were much more significant are here, you can get to this slide online, review them all if you want. Comments I didn't take: David Miles asked for less motivation, generalize. I've put in more, people wanted less, less, people wanted more. We can keep changing it if you want. Should we assign new message types? Do we propose new message types? Just leave them TBD? Ted Lemon-- You must leave them TBD. Kim Kinnear-- Don't mix absolute and relative times. Okay, but we must have absolute times. We could take out relative if people care. Bud wanted query times. My offer was we could do vendor-specific query times. Ted was saying you should know if it's leased or not leased. Why are you giving so much information about the binding? Reason we're doing that is bc we imagine that somebody is talking to two different servers doing availability or failover solution, trying to make sense out of both. Which one makes sense? Trying to make sense out of that requires more than just leased or not leased. We can bury that in vendor-specific stuff, but it seems necessary to us. Middle point, somebody said relay agent has to have IP address to do this. Darn right. I think it's time for, I need to spin it once to fix up textual stuff, time for another last call. Didn't make it through last last call cuz nobody read it. Don't have to beat it to death, just read it, understand it, say whether it's moving forward. David Hankins-- I think we should nominate Alfred Hönes as DHCwg's Poet Laureate. You've got those multiple states, could you use numerical assignments from most recent failover draft? That would mean I wouldn't have to do any translation. It makes it very difficult for me to review what's happening when there's some text in the draft that says, in terms of the absolute times, that some agent might set aside the absolute time to be used at a later date. Is that person doing a good thing, is it going to work? That's the end of the discussion, doesn't tell me how it's used later, how it's put together, what the combinations are. Kim Kinnear-- I thought I said clearly what the base time is used for. I may have not said it everywhere, may be some sort of references that lead you and drop you on the floor, I will try and read it again. David Hankins-- also have typos, will send you some mail soon. Kim Kinnear-- I propose doing a rev, another last call. Ted Lemon-- not disputing what you just said, a couple of comments on the things you didn't change or weren't sure which way to change. I tend to think of text in any draft as an attack surface, so the smaller the draft is, the more likely it is to make it through. On that basis, when you have a choice between more and less text and have no particular preference, less text is always better. Other thing is again, just fyi, the reason why I suggested not including so much information about what state a lease was in was that you were requiring the device doing the leasequery to almost simulate the failover protocol in the device. Since you've already got a device that's doing that protocol for you, seemed redundant and adds complexity. Kim Kinnear-- spectacular point. The problem is that if you're talking to both failover servers... If you're just talking to one, then you're right. Problem is if he's doing, you're hosed. Even then if you switch you're kind of in a weird state, he didn't work it out for you. Our model is you are trying to do both of them at the same time. At that point, or you switch over very quickly. You _are_ simulating pieces of the failover protocol. Conflict resolution is indeed in a small but not insignificant way replicated in the client. You can do it the simple way by just using the message type. IPv6 Router Advertisement Option for Stateless DHCP Server draft-xu-ipv6-ra-dhcp-server-option-00 10 min Dacheng Zhang Proposal: Add a router advertisement option specifying addresses of DHCPv6 servers for use by stateless DHCPv6 clients. Summary: There was some question of where to do this work; eventually Ralph (our AD) agreed that it was appropriate to do this in the DHC working group, since it changes the protocol. There was some question as to whether this was even useful--the motivation expressed by Dacheng Zang was to limit extra work required by DHCP relay agents at the control plane, and some participants expressed skepticism that this was in fact a problem that needed to be solved. There was strong interest in this work, and there was also strong opposition--the working group participants present were evenly split on whether this is a good idea. One participant said that he was opposed, but didn't really understand the motivation, and might be less opposed if he did understand. Action: Dacheng Zang will raise this question on the mailing list to stimulate further discussion. Discussion: Dacheng Zhang-- IPv6 router advertisement option. Solution very simple and intuitive, will focus on motivation. During our research we found that out statement in RFC3315 that DHCP for IPv6, a host can only initiatet communication with DHCP server using multicast. Server must discard unicast messages. Why is author of this RFC made this argument? We assume that when host initially connect to network, not know address of DHCP servers. Also, advantage of unicast to relaying of messages of relay agent, avoid overhead. Even the relay function is implemented on routers, overhead of multicast packets on control plane is more. So what we try to do is find a way to enable a host to communicate with these DHCP servers by unicast packets. Our solution very simple, there are typical applicant scenarios in 3gpp, other IETF documents, host can initially obtain IP addresses from stateless, then request other information from stateless DHCP. So add new RA option, list of IP addresses of DHCP servers. User can get information directly to communicate with DHCP server. DHCP server should accept unicast. Ted Lemon-- Idea here is that in certain network environments you don't need the functionality--rationale for clients to send multicast was so we could always get the relay's information--but you're proposing that for an environment that's not needed or wanted, so this seems reasonable to me, but one concern I have is that this is really an extension to ND, necessary for us to do the work, but we would have to recharter to take this on as a wg item. This is DHCP-related. Ralph Droms-- My initial reaction was that the work should be in 6man with review in DHC working group, not quite as clear-cut as some other differentiations have been in the past. I'd need to be convinced otherwise, I really think it should be in 6man with significant review in dhcwg. David Hankins-- This draft changes the DHCPv6 protocol, only adds an option to RA. Or else have to do two drafts, one to permit unicast, other to define RA option. Suresh Krishnan-- requires changes to all DHCP servers to allow information request to come to unicast destination. Second, don't see much value in it. What do we really save? Multicast message, that's it. Not too much value. No failover mechanism, if there's multiple DHCP servers, one picks up, the other goes on. Misconfigured router, there's no way client is going to be able to get out of it, the draft doesn't propose falling back to multicast if unicast fails. Dacheng Zang-- Will unicast bring benefit? Discussion on mailing list? Find out whether people like this or not. Second, dependability issue, a lot of solutions have been used to achieve dependability of failover recovery unicast, that should be no problem. Suresh Krishnan-- actually it is, you have multiple addresses, doesn't specify, do you do them in parallel or in series? Needs to be written in draft. Dacheng Zang-- further discussion in draft, okay. Unicast more efficient than multicast. Anycast more efficient than multicast. Suresh Krishnan-- depends on implementation of relay, ldra, doesn't make a difference. You have scenario where multicast gets kicked to control plane. Some implementations are different. Dacheng Zang-- statement, 3315, benefit of multicast not only by processing speed, and I want to say that only provide an option to enable you to use unicast to DH server. Can still use multicast to communicate with DHCP server. Our argument is we try to break one assumption of DHCP, if user can get unicast address of server, should be able to communicate directly, don't have to use multicast. Suresh Krishnan-- I understand, all existing servers need to be modified to support this. Ted Lemon-- server , 3315 specifies how to do unicast. At least in theory server is receptive. David Hankins-- I think rfc3315 put that text in there to be complete because we have problem with people doing things we didn't think of, see no problem with relaxing that. Multiple address problem, VRRP, anycast. Client expects to receive multiple answers and weigh them. It would really simplify things if you could fit into single option. Ralph Droms-- has been convinced by David's arguments that this does belong here. Collaborative review with 6man to make sure they're okay with option. No need to split into two drafts. Ted Lemon-- before figuring out process to go forward, how many are interested in doing work? Ten hands. Bad idea? it's about even. Slightly more think it's a good idea, definitely isn't a consensus. Next step, Jinmei Tatuya-- I don't think this is a good idea, agree with Suresh, but don't really understand why. ??-- this is a bad idea. Dacheng Zang-- don't need to care about whether current spec allow to use unicast, need to inquire whether this approach makes sense. Leads to one benefit to using unicast. John Brzozowski-- we're done at the mic, finish your statement, we have to move on. Dacheng Zang-- ra is secure, then we can get dhc server address, use unicast to exchange DHC messages. No security consideration. John Brzozowski-- we have pretty split opinion, we're going to take it to the mailing list, raise all these items on the mailing list, after we've had discussion. Ted Lemon-- seems like there's a fair amount of interest for and against this, hope that's reflected on the mailing list. John Brzozowski-- DHCP option we just talked about, how many people have read document? Prefix Delegation in Evolved Packet Core networks draft-krishnan-intarea-pd-epc-00 10 min Suresh Krishnan Problem: Mobile phones or other 3gpp devices may act as routers between the upstream mobile service and some sort of downstream device. Downstream device addresses need to be allocated out of a different prefix than the upstream address. In some cases more than one downstream prefix may be required. But provider would like these prefixes to be contiguous. Summary: Suresh presented a solution to the problem that involved pre-allocating larger prefixes (possibly a /56) at the provider, using a /64 for the link between the provider and the phone or MiFi device, and then allocating further prefixes for downstream use using prefix delegation. There was some confusion as to why Suresh was presenting this to DHC--the reason given was that he wanted us to say it was a reasonable solution to the problem so that he could go back to 3gpp and say the IETF thought it was okay. The general consensus once everybody understood what was being asked was that it was in fact a reasonable way to solve the problem. Action items: That's up to Suresh. Discussion: Suresh Krishnan-- I'm here to present document describes prefix delegation, draft has changed since deadline. Supposed to be standards track document, wanted to change behavior of DHCP, want to present direction forward. Every mobile in network is going to get /64, like RFC3314, same for all mobile networks. Some use cases coming online where mobile doesn't just talk for itself but has a network behind it. Mobile network is only broadband network, like MiFi. To support this, we need prefix delegation to the phone. It's not in the standards yet, but people are making contributions in 3gpp to do this, to allow p-d to the phone. Current state, there's phone, it gets prefix. Now there's set of hosts behind phone, need to delegate prefix. First problem, if you have /64, shorter prefix assigned to the phone, number of entries on IP gateway is going to be double. Also, policy control architecture designed with one prefix in mind. Can't do with two prefixes. So we are trying to have only one routing entry per phone or USB stick. Can have reference in the draft, there's a diameter-framed IPv6 prefix, only one can occur in message. You can only do policy control and charging for one prefix. So what we're tryign to do is make sure we have only one prefix allocated to the mobile. We want the /64 mobile gets for itself to come out of bigger prefix. RFC3633 explicitly disallows this. Seems to me that some implementations can't handle having larger prefixes behind them, smaller prefix to delegating router. Draft says we need to relax this, but we changed our mind, there's enough nodes that don't work. Bottom line, you have USB stick, can be put into any device, can't really control we can have a working implementaiton. So proposed implementation, you have a /x prefix reserved for mobile, don't give it to it right away. Give it a /64, when ask for delegation you only give half the address space to him. If you had /56, you only give him /57, allocate /64 out of other half. Works for old clients that are broken, but wastes some addresses. Once we get consensus in IETF, we will take this to 3gpp, want your opinion on what you think of this. Ralph Droms-- This doesn't require us to do anything. This is just a policy in the server someplace. Suresh Krishnan-- to get this accepted, need IETF to think it's a good idea. Ralph Droms-- I don't understand what you are asking of DHC working group. Nothing in 3315 that says client has to get back a /56, etc. Suresh: right. Ralph: I don't know if we have... I guess I'm confused about what we're being asked to say is a good idea or not. Suresh: is there a better solution? John Brzozowski-- are you saying that the hosts are asking for their mobile devices, they're asking for what? A /64 for themselves. The green box? (it's a phone). Is it going to do hierarchical delegation below it? Yes. It's got a DHCP server? Suresh Krishnan-- It's not designed to have one, but is supposed to be requesting router. John Brzozowski-- I agree with Ralph. Nothing for dhc to say. Suresh: just want consensus that nothing breaks this. Izu Trurey from Pai-- Need requirements from 3gpp. I don't think host want to three only for phone, bandwidth IP save is for anything. Bernie Volz-- In original concept, problem is that phone is host and router at same time, that's why problem with /64 delegated to phone was a problem. Why does it need an address other than link-local on the link to the air? Suresh: it does, has applications running on that. Bernie: it could be a router in itself. It's got two interfaces, downstream side to radio network, other is internal interface for web browsing. John Brzozowski-- I don't think the hosts get anything more than a PD. Bernie Volz-- if the phone had gotten a /64, it could be stateless or DHCP server to give those hosts an address in the same /64. Other mode, phone delegates prefixes. Suresh Krishnan-- yes, but the phone is currently deployed. There's empty phones, they get /64 using either slaaac or using 3gpp-specific conf mechanism, and that's not at the same time as we get the normal address. ??-- I think the picture is not the concern for 3gpp. David Hankins-- What you're asking for is peer-review of an operational practice, this is an int-area working group, I would look in ops area wg. My own feedback, the problems I've had in the past with routes that overlap is when the prefix in question is the same bug has different lengths. Gets into trouble with certain routing protocols. Might skip zero, go for one. Other thing, enumerate all the 64s and then have the covering v6 up there. Ralph Droms: David, thank you for reminding me of that. You can enumerate prefixes, that assumes pd client in phone should know about multiple prefixes, which it should. You could delegate all the prefixes except upstream link. 3gpp uses slightly different terminology, not that the UE is assigned a /64. What that terminology means is the 3gpp operator assigns a /64 to the link. So when you're talking about the phone getting a /64, what it means is that there's a /64 assigned to that link. Being careful about nomenclature, if those are ptp links between phone and hosts, ??? Frank Xia-- Some clarification questions. In your scenario, which entity is the requesting router? Suresh Krishnan-- The phone. Frank Xia-- Second, how long for the prefix for the phone is less than /64? Suresh Krishnan-- Shorter than. Frank Xia-- Is this prefix for all phones or for some special scenario? Suresh Krishnan-- for all scenarios you reserve a shorter prefix, don't necessarily give it. Ted Lemon-- full agenda, this is detail we should have on the mailing list. ??/ If every phone give prefix length is shorter than /64. Discuss later. Ted Lemon-- next step, discuss further on list. Secure DHCPv6 Using CGAs draft-jiang-dhc-secure-dhcpv6-03 10 min Sheng Jiang Problem: How to leverage CGA to authenticate DHCP messages. Summary: Sheng Jiang gave a quick review of the draft, which has been around for a while. There was widespread support for adoption, and no opposition. Action Items: Working group chairs should issue call for adoption on mailing list. Discussion: Sheng Jiang-- how many people already read this draft? Just give a quick reminder here what we are doing. The motivation is simple, current DHCPv6 cannot probe the address ownership, so that means attackers can use fake address to spoof attacks. In order to solve, we introduced cga verification, which can protect the DHCP protocol, we introduce two DHCP options, one is DHCP option with address ... option, other is signature option. Both options must be used together. Define a set of rules and behaviors in server side, only message that ... signature verification secure DHCP message. Because DHCP relay actually takes off source address from the IP header, so the sender's address is in IP header after relay. There was a lot of discussing at last bp of us proved draft issues already addressed in the current draft. So this draft is stable since middle of last year after actually -02 version we have only received positive comments, so I would like to ask wg ? Ted Lemon-- any comments? folks have read the draft? useful work? I don't think I saw a single hand against, seven in favor, I think we can adopt this. I do have one question. I noticed that you defined a new option for the signature instead of using existing option. Is there a reason? Sheng Jiang-- long answer. we already discussed that in mailing list. Ted Lemon-- offline Sheng Jiang-- if you still have doubts you can still ask again in the mailing list. Ted Lemon-- We'll bring this up on mailing list. Unless there's a change in consensus, we'll adopt this as a wg item. Kim Kinnear-- could you adopt just this draft, or are there other drafts required? does this draft stand alone? Sheng Jiang-- yes. Ted Lemon-- motivation was whether you could have a CGA that you could use to authenticate when doing stateful DHCP. Sheng Jiang-- that's totally separate. I could have another wg draft in csi which discuss the possible interactions between the protocol and DHCP. This is following that statement. There's two drafts separate from each other, independent. Configuring Cryptographically Generated Addresses (CGA) using DHCPv6 draft-jiang-csi-cga-config-dhcpv6-01 10 min Sheng Jiang Summary: Sheng Jiang gave a presentation on this new work. There was widespread skepticism about the idea of using the DHCP server to compute CGAs. Action Items: Sheng Jiang should bring this up on the working group mailing list for clarification and further discussion. Discussion: Sheng Jiang--This draft was submit to csi wg, but it didn't include in the csi working group charter, and we think this draft is actually more relevant to dhc working group because is about to config and manage the address. So that's the way we submit this draft to dhc working group, There are two interactions we discussed in this draft, one is dhcpv6 can be extend to propagate the parameters the host did for DHCP address. Prefix it can be configged using router advertisement or a new dhcpv6 option suggest by another draft, draft-host-generate-id. The sick venue which is very specific for cga address only. A keep here which is very perfect or self-generated by the host. So we don't discuss that in this draft. The cga also defined the extension fields which have no use case so far. Another motivation for interaction we discussed, the cga generation can be computational consumption, so we want to extend DHCP protocol to help a host to generate the cga address, which is the computational offloading. The reason we do that is we have to get some test result here by running leathery implementation of cga to see how long this may take. ... Is wg interested in this? Francois Dupont-- The only reason you are using DHCPv6 is because answer is an address. You could use simple RPC to do the generation, only reason you need DHCPv6 is because result is an address. Erik Nordmark-- I don't understand what you're trying to accomplish. Offload computation on DHCP server, or server will store those public/private keys? ??/ for the computation offloading, yes, we just found DHCP server had to be someone can help. DHCP protocol ... Erik Nordmark-- not depending on DHCP server storing any state? Sheng Jiang-- you could. Kim Kinnear-- is this for stateless or stateful address allocation? you're expecting dhcp server to hand out an address? is this just a way to use a DHCP server as a compute server, or doesn't DHCP server need to know the result of the computation? Sheng Jiang-- my previous draft is about how to use cga to protect the dhc message, so that use actually existing cga address, both on server side and on host side. This draft is actually before that. I agree, some scenario of this draft, the communication may not be able to be protected by cga. Kim Kinnear-- that wasn't my point--if you're trying to have a client get a cga-style address, if the client hands it to it, the dhcp server has to do the computation, right? Erik Nordmark-- the thought that I can send IA that says I already have this address, is it okay? So the client can compute its own cga, send it to the server saying I would like to use this address, and the server can record it. John Brzozowski-- hey guys, we're going to stop it after Erik's comment. Sheng Jiang-- as I say, we have another draft which is the csi working group draft which describe all the possible interaction between dhc and cga, that will very nearly explain to you how this handled. I encourage you to read that draft first, if you still have issues after we can discuss on mailing list. John Brzozowski-- no explicit direction for you, we conferred with ad, we're going to have to get back to you with status and next steps. Softwire Concentrator Discovery Using DHCP draft-guo-softwire-sc-discovery-03 10 min Brian Carpenter Summary: Brian described the option. Ralph reminded us not to get into the details of use cases, since we're just reviewing for syntax. James Woodyatt wanted to know if he could use dnssd instead. There was some controversy about whether the draft was needed, and some enthusiasm about using it. Action Items: Needs to be reviewed by softwires working group and adopted as a work item there before DHC does any more with it. If adopted, DHC should review once more before it goes to IESG. Discussion: Brian Carpenter-- this is a draft that carries a softwire designation but needs to be reviewed here. Softwire wg is dealing with general case of IP and IP tunnels to get from customers to tunnel endpoints across server networks. Typically tunnel endpoint will be some kind of concentrator between IPvx and IPvy realms, may be doing translation. CPE has to establish softwire(s) to appropriate concentrator. This throws up some specific requirements. Softwire has not defined the method of discovering these concentrators in the hub and spoke environment that will arise. In order to establish softwire, initiator must know IP address of concentrator, generally an IPv6 address. Must know tunnel type. If there's more than one concentrator, CPE needs to know preferences so it knows how to choose concentrator. So these requirements which need to be met in a generic way are not met in a different way for each one. Proposal is generic softwire discovery mechanism using DHCP, DHCPv6. Needs option or options to support discovery of concentrator or carrier grade nat. Because you may need load sharing or redundancy, reply message may carry more than one message. So obviously there's a management issue, making sure DHCP server is configured with knowledge of where these concentrators are so it can generate appropriate response to customer. here's an example in ds light scenario. ... Frank Xia-- There is some parameter for tunnel type. Ralph Droms-- Would like to avoid discussion of details here cuz we're not the experts. Our job is to examine the syntax, the details of the option. It sounds like we've already provided that service, and there are changes to make, but the details of this discussion belong in softwires. Ted Lemon-- Assuming that this work continues, might be good to bring it back one more time. James Woodyatt-- This option the way it was specified seems to make it so that a residential CPE router gateway would be constrained by the DHCP protocol to the administration domain of the DHCP service for being the source of information about where the software concentrator is. I wonder if that's a deliberate decision in the way you've chosen to use DHCP. John Brzozowski-- it was softwires' choice. James Woodyatt-- maybe you could just use domain name, dnssd. Brian Carpenter-- nobody's forbidding that. Usage of Host Generating Interface Identifier in DHCPv6 draft-xia-dhc-host-gen-id-02 10 min Frank Xia Summary: Frank Xia presented the draft, and there was some lively discussion. No consensus was reached on whether it was work that needed to be done. Action Items: Discuss further on the mailing list. Frank Xia should kick off discussion. Discussion: Frank Xia-- Host generated interface identifier. this draft was presented at ietf72 and ietf74. this is third. according my memory, most comments received are positive. problem is configuration of ipv6 hosts includes two parts, prefix and interface id. mostly interface id is generated by host itself. cga can only be generated based on public key holded by host. Second scenario, host generates interface identifier when doing stateless. So in many cases interface id identifier is generated by host itself. normally the prefix is managed by the DHCP server or access router. In some deployment, it is preferable that server, not access router provide prefix for host, as is also described in Ralph's draft, rational why operator prefer prefix provided by DHCPv6 server, not access router. So in this case prefix is provided by DHCP server, host id by client. There is no scenario where DHCP server can do this. Solution is separation of prefix assignment and interface ID generation. Procedure is very simple. DHCP server ties prefix to host itself generated interface ID, then use this tree information address is formulated. Bernie Volz-- Is assignment really the right word, or is it prefix advertisement? Frank Xia-- I can't tell the very pick people's advertisement assignment is? This is assignment, targeted. Bernie Volz-- no other host will use that prefix. so why not just use p-d and then client can generate its own address. Frank Xia-- yes, prefix delegation limited to requesting router.. Francois Dupont-- specific to the case where the DHCP server provides the prefix it's only in this case you have the issue? Kim Kinnear-- you said this is like -pd, but p-d says you can't use it between these different entities. In my mind, solution is to just allow that. Frank Xia-- if community says you can reuse p-d, I'm fine, but still can use p-d from use of we can't use. My point is p-d document it is stated clearly we can't use this option between host and DHCP server, only for the requesting router and delegating router. But if we want just expand this, say this option can still use between host and DHCP server. But the problem and scenario are totally different. Kim Kinnear-- that's interesting, and in my mind as long as there's no dramatic confusion, if the context you're using the option in is clear, I would say expand the use of it. If it's not clear you have to have a new number. Frank Xia-- because the scenario is completely different, we should define a new option. ??-- get different idea from the speaker. for me, what we present here is actually mainly used for prefix advertisement. That's what I think. So that could be used also for the prefix delegation, but it can also used for prefix advertisement. That's why we did the prefix for the host id generation. Ted Lemon-- how many have read? 3. Of those, how many think it's a good idea? 1. We kind of have an even split, few readers, no consensus. Discuss further on mailing list. I think right now it's too big of an unknown. DHCPv4 and DHCPv6 vendor messages draft-ietf-dhc-dhcpv4-vendor-message draft-ietf-dhc-dhcpv6-vendor-message 5 min DHCwg chairs Ted Lemon-- vendor message drafts for v4 and v6. went through last call, submitted to IESG, got discusses back, one discuss proposed that this might be unnecessary, we should try something less extreme first. Ralph? Ralph Droms-- The IESG feedback, there are several discusses on these documents from the IESG that are pretty strongly negative, some serious concerns from several IESG members, that these documents give up too much control over development of new DHCP messages from DHCP working group. As an alternative proposal to accomplishing some of these goals, the proposal is to go through the IANA registries, where all DHCP message types, option types and subtypes, go through them and make the formal requirements more regular as to what's needed to get a new entry in the registry. RFC, note from your mother, etc. Those are not all consistent at this point. Require various levels of documentation. Proposal from IESG is to go through those registries, regularize rules for assigning new numbers and loosen those requirements in the following way. There's a requirement called "iesg approval" which doesn't require a published RFC. Can point to a document that's not an RFC, can be informational RFC, anything you want, something IESG can point at and say we have reviewed this, it's okay to use this protocol number. How that would address what vendor messages are intended to address is as folllowed. Currently message code points are assigned at the last step before publication of RFC. With this change, preliminary work with sufficient motivation could be assigned a message code prior to publication of a standard's track document. Just as one last historical note on this, the reason we have very tight controls over message type and option codes is that originally we were very loose about handing out option code numbers, and message code numbers--even looser than I'm proposing now--and we found we had a number of codes we handed out and never heard about again, so we tightened it up. Now we're proposing to loosen it a little bit. Bernie Volz-- 2939 says standards track or non-standards track RFC. Does say option isn't assigned until IESG approved, I don't understand what would be different here. Ralph Droms-- what would be different is that now the message code types could be assigned based on an internet draft, not an RFC. David Hankins-- I like it, I think we should do it anyway. The one concern I have is I look to Bernie's draft as one of the ways that the IETF can receive dictation on what vendors are going to do. I think we lose that avenue, that's an avenue we should have. Ted Lemon-- the discussion with the IESG said let's try this, and see if it makes us happy. Not saying we will never do this, just let's hold off until we've tried something less extreme. DHCPv6 Relay Supplied Options draft-lemon-dhc-dhcpv6-relay-supplied-options-00 5 min Ted Lemon Summary: Ted Lemon presented a draft he'd submitted the previous night to address a problem that came up with respect to draft-ietf-mip6-hiopt. There was interest in the work, and no objections to adopting it. Action Items: Ted Lemon will bring the draft up on the mailing list and get call for consensus to adopt it as a working group item. Discussion: Ted Lemon--I'm going to prevent something that just came up, mobile IPv6 has a draft called mipv6-hiopt. That draft passed last call and was in publication queue. This is actually a pretty substantial change in DHCP protocol. I looked for discussion about it, there was some a while ago, never finished, and it proceeded. So I asked the IESG to stop the publication of the draft, and they did. There were some issues in the draft which Alper is going to clear up, Alper is one of the authors. The general proposal of being able to have a relay agent propose stuff to send back to the client is not a bad thing, but having a one-off protocol that's not general is a bad idea. To speed this up, I wrote a draft last night and published it, which describes a general mechanism. We're kind of in a weird situation. I feel like it's a little awkward for us to say you can't publish that at all. The failure mode was that we didn't really architect it properly. Question for wg, given this brief explanation. First of all I'm assuming nobody's read the draft. Does anybody object in principle to what I just suggested? (no) Does anybody think it's a good idea? (several hands raised) I'll bring it up on the mailing list. Stateless DHCPv6 requirements for home gateways 5 min James Woodyatt Problem: What does a residential home gateway or similar device do when its upstream provisioning changes, and it is using stateless DHCPv6 to distribute configuration information to its downstream clients. Summary: The working group had a good discussion of the problem, but no conclusion was reached due to lack of time. Action items: James agreed to post a summary to the mailing list to stimulate discussion there. Discussion: (from agenda bashing) James Woodyatt-- we talked about the problem that has me concerned. I'm kind of worried that stateless DHCP is worthless, doesn't seem to be a way for stateless DHCP servers to deal with reconfiguration updates of DNS server addresses. Stateless client gets lease, prefix delegated, DNS server address. Hosts are happily using internet, wan goes down. 5 min later, wan comes back up, gets different addresses, prefix, DNS server addresses. Hosts are all stateless. They're going to get new prefix. Not going to find out about DNS server addresses changing. That's the problem that I don't know there is a solution to in DHCP. Mark Andrews-- just put a lightweight DNS client in that box. Ted Lemon-- mark, we have experience with those clients. (actual agenda item) Ted Lemon-- James had a question about reconfigure. RFC3315 does say that one of the potential responses to a reconfigure message is an information request. So at least in theory that's covered. But for generating a solicit or request, doc says you should include "I'd like to accept a reconfigure." It doesn't say that for an information request. James Woodyatt-- how do I know where to send the reconfigure? Ted Lemon-- You got an information request from some IP address. James Woodyatt-- So I have to retain state? Bernie-- You need the nonce. A reconfigure-request with information message was really designed more for the case where a client had gotten a lease, and now all the things that's changed are some of the other options that don't require a new address. The reconfigure on information request was never set up to handle reconfiguring a client that only does stateless. The way that was addressed was the IRT parameter. Ted Lemon-- problem is that if information expires and doesn't work anymore, you need it to be renewed immediately. John Brzozowski-- it sounds like we have a problem with the situation you talked about. James Woodyatt-- now I have to maintain a list, and I don't know when I can forget. Dave Hankins-- I would recommend in this particular problem space, make sure rfc4242, IRT isn't sufficient. Ted Lemon-- we talked about that. James Woodyatt-- it's insufficient. Dave Hankins-- set IRT to three seconds. James Woodyatt-- no. John Brzozowski-- we're over on peoples' time here. I think we've got to do something about this here. Bernie Volz-- I think that we need to understand the exact scenario a little better, one of the things that might be broken here is the clients that if they detect any change, when do you do DHCP? When do you restart DHCP? I don't know what configuration changes have happened, what networking changes have happened here. Client mayhbe isn't sensitive enough to see that information isn't valid anymore. Ted Lemon-- given the timing situation here, I would like to propose James that you write up a brief but complete email message to the wg saying what it is that you want and why you want it, and that'll kick off a discussion where we figure out whether you have what you need, which you probably don't. James Woodyatt-- okay, I'll write that up. hopefully the outcome of that discussion is decision about whether to write a draft, and what that should be.