dhc-wg 2010-07-29 09:00 Chairs: Ted Lemon, John Jason Brzozowski Chair e-mail: Minutes: Shane Kerr dhc WG I-D status ----------------- reconfigure/rebind: will require refresh, probably resubmitted today leasequery-by-remote-id: in WG last call dhcpv4-bulk-leasequery: need status update Ted: About leasequery-by-remote-id... got 0 people saying they care about it - not even the authors! Don't feel comfortable pushing draft forward if nobody says they want it. Will announce it failed last call. We did get 1 review that produced minor editorial changes, but somebody has to say they want it. dhc charter ----------- Ted: DHC domain option went away, so taken off list. Ted: Proposing adding DHCPv6 peering/redundancy. Useful because of PD. Ted: No working group to do CGA authentication except this one. That's something that solves a problem we've had for a long time, so we should be thinking about it, or figure out which working group should. -- Ted: If you ask for IA_NA and IA_PD and only get IA_PD but not the other, both base DHCPv6 and PD spec say to ignore the whole thing. Ralph Droms: This may be solvable via an errata rather than a separate document. Ted: Do implementors ever read errata? Mark Andrews: Occasionally... we *generate* errata. David Hankins: I do actually read errata sometimes, when I care about them. The discussion is surprising to me, but if there is a valid address or prefix underneath an IA somewhere we take it and go on. Ted: That seems reasonable, but the specs specifically say not to do that. Hankins: I missed that then. This is the part of our client which does "scoring". Maybe the solution to this is to explore the selection criteria a little more closely in a draft specifically for that purpose. Ted: That is sensible except that is probably a multi-year process which will never converge. And the base problem that Ralph described is very clear cut. David: I think it is very easy to say, "here is *one* way". I don't agree this would be really long. ???: Either we need to re-spin the RFCs, because they assume they live in isolation and that is clearly not true. Ted: That is one of the items I was going to mention. We took that off of the charter because nobody is working on updating those drafts. -- Ted: Took out the idea of advancing DHCPv4 and DHCPv6 specs to standard. This is apparently a changed process anyway. Ralph: It should be put on hold. Thomas Narten: What you say is correct. The larger background is that there are known ambiguities in the docs. I wish we would clean up the things we know should be cleaned up. Ted: RFC 2131/2132 were written a long time ago. The process of reviewing documents was not as good then. There are a lot of ambiguities. The problem is the functional DHCP specificiation is really not what the IETF wants in a protocol spec. We have a lot of heuristics to deal with broken things. The difficulty is that if we try to specify the correct behavior, it would probably break a number of devices if someone follows it. What is the utility of doing that? Is DHCPv4 really something we care about going into the 22nd century? Thomas: You just made the comment I was trying to make... the fundamental reason that documents do not advance is that deployed stuff is at odds with the spec. The question to ask is, "do we care? are people still implementing DHCPv4 these days? do they need the spec to go back to?" If the answer is "yes" then leaving the spec ambiguous is bad. Ted: If we were to produce an unambiguous spec it probably would not interoperate. Hankins: There must exist one implementation that does interoperate. But will we drop my draft? Ted: No. Ted: My feeling is that if you are willing to work on this and think you can get other members of the working group with you, then we can put it in the charter. Hankins: Yes, I am here to work on this. If people are not working on this, they need to get out of the way! Ted: Can you suggest text? Hankins: Yes. Ted: I want a charter that is what we are working on instead of a wishlist. Thomas: We should not make it out of scope for advancing & clearing up the spec, even if there is not a lot of energy for this. Thomas: The other reason why specs don't advance is that people have a limited number of cycles and concentrate on new features. -- Ted: Dual-stack seems to be a myth now. We're not doing it because we don't think it's doable. Ted: We had a item about on-link information and router information, but we pushed that off to another working group. Ted: Line items about Hankins work. Ghant: When those other groups come up with a DHC solution, presumably they will be back here... Ted: Charter already says that we will review work in other groups. -- Ralph: Let me suggest you chat with Olafur from DNS, who has a tool which scans all newly published draft for the occurance of "DNS". If you had this for "DHCP" it might help. Ted: It's difficult to keep up with all the new drafts that are published. I really don't want to read some draft that is not going to advance... Ralph: Maybe only look at ones accepted as working group items. Thomas: Might not be a bad idea to send a note every 6 months or so to let other WG chairs know that DHC is here. New Chair --------- Ted: Starting in December of this year I'm going to do a long retreat and won't be able to be chair in Beijing. We're going to try to find someone to help John out. If anyone is interested and wants to send e-mail that would be great. options-guidelines, dhcpinform-clarify David Hankins -------------------------------- http://www.ietf.org/proceedings/78/slides/dhc-0.pdf Hankins: Ready for last call? Thomas: What is the boilerplate issue? Ted: Whether we propose text for people for options. Nothing to do with IPR. -- Ted: How many in favor of going to last call? [ Some for, none against, some support in jabber room ] Ted: I think that last call will encourage closer reading -- [ dhcpinform clarify ] Ted: Some people have used DHCP without IP addresses? Hankins: They have an address, but are not setting CIADDR. Ted: The client has an IP address... it will either be CIADDR or be in the address of the packet. Hankins: It could be the source address of the relay agent. Ted: So we're contorting the spec horribly out of shape to accomidate clients in a broken environment... Hankins: It isn't broken, it's working for them... Ted: But it's preventing clients from following the spec. Ted: We're using things for a different purpose. The right thing to do is define a different message, rather than changing semantics. Hankins: The problem is we still need to define what people do today... Thomas: Let me agree in principle with Ted is saying. Ambiguity makes people do it. Ted: We do not have a solid reason to justify order. How do you get interoperability out of that? What you're doing in the ISC server by accomidating broken clients is good, but that is different from putting in a spec. Hankins: Well if we don't put it in a spec, they won't know what to do. Ted: Sometimes you have to be out of spec to work with broken clients, but that does not mean we should put it in the spec. Thomas: You can have it both ways sometimes, and this group has done that. Make it clear that this is NOT part of the spec. Ralph: Make it an appendix or something. Thomas: If you don't revise the spec and clean them up in the first 3 or 4 years of deployment, you end up where we are here. -- Hankins: If we add a separate message that will increase complexity rather than simplify it. Ted: That would be true except there is no way to get this to work. I do think if you have CIADDR you *must* use that, and if you have a source address you *must* use that. Clean up the ambiguities. Ted: If the client is broken it should not work. It is better to fail than succeed, because otherwise the broken behavior becomes standard. Hankins: I agree with you, except the amount of time that these clients have been around. Shane Kerr: Can we use informational RFCs for this? Thomas: Is the behavior so widespread we have no way to fix it? Or should we just break the guys that are broken? Hankins: If the IETF directs me to fail to respond to these clients I won't do it! Ted: How often does this happen? Hankins: We see this all the time. Thomas: Which clients? Hankins: Microsoft.NET clients do this. Thomas: Is this something that can be fixed? Hankins: I would love to talk about this. The first message I sent to the dhc working group was to get someone at Microsoft to talk to about this. Thomas: If nothing else this would be useful information. Ted: I have a lot of sympathy for this situation. At the same time I am a protocol zealot. Can we come up with a concensus? Maybe we can try to get co-operation from Microsoft first. Ted: Thomas do you know someone at Microsoft? Can you do this? Thomas: yes. -- Hankins: I want review for the hacks we are doing. I'm seeing some nodding, I don't see anyone at the microphone, so I'll leave it there. Ted: Good to have time to actually have the discussion for real! Relay Agent Encapsulation Ted Lemon http://www.ietf.org/proceedings/78/slides/dhc-1.pdf ---- Hui Deng: BTW, I don't work for Huawei. (China Mobile) ... Hankins: This is a difficult problem. The DHCPv4 relay chaining problem. I am very enthusiastic for solutions for. I think one of your slides requiring that it be enabled may allow us a more radical approach. Maybe we can *really* do something more like DHCPv6 relay chaining. Ted: I should say this is the result of some discussions by some folks who were working on related drafts. I think it would be worth exploring your suggestion... I rejected it when I started the draft to support legacy relay agents. But you're right it would be easier to implement it with a new type. Ted: Can we talk that over? Hui Deng: We also plan to implement this draft... Ted: Would it be easier if we did that before you implemented? Hui Deng: We plan to start when I get back. Ted: Is there general agreement that the legacy requirement is not necessary? Hankins: If the type is a new BOOTP message, I think that captures the legacy relay agent... Ted: The legacy relay agent is not necessarily the first in the chain. We do need to decide if we want to support the legacy relay agent... I am very attracted to the idea of doing it this way. Ted: Will try a new version with this change. DUID-UUID Thomas Narten http://www.ietf.org/proceedings/78/slides/dhc-2.pdf --------------------------------------------------- Eric Osborne: We need to work on for sure. But on virtual machine, if you copy to another one you get the same UUID? Thomas: If someone makes a mistake you end up with 2 virtual machines with the same UUID. Ted: Maybe make a note to the virtual machine implementors. Eric: I know for active directory it was a problem. Hankins: The bits you say about DHCPv4 and hardware address and stuff are completely wrong. I appreciate you were trying to be brief... I'll send you text. I realize it is not crucial. Hankins: We should absolutely work on this. Hankins: In DHCPv4 we have PXE. It is a bootloader that loads something else. There is WINCE (Windows CE). WINCE can boot off of PXE, but it needs new options, so it does DHCPDISCOVER to get new options. PXE is identified by MAC address, the WINCE client sends client identifier. The 2nd stage boot loader is using PXE's network stack but could not change IP address, and so it would fail on reboot. Morale: vendors like to identify by hardware instead of system. Erik Nordmark: I think we should work on this. We could use this in IPv4 as well as IPv6. Thomas: Is there a DUID for v4? [many]: Yes. [jabber]: Support adoption. Ted: I agree this is a good idea. When we wrote the DUID spec, we thought that whoever implemented would put into non-volatile RAM. But I don't know if anyone ever implemented that. -- Ted: How many folks support adopting this? [ about half of room yes, none opposed ] Eric Vyncke: If you use this kind of DUID, Ted: Normally in a DHCP packet you get the link local IP address. Hankins: There's no field for the MAC address. This is an issue that comes up separately, but is not related to the draft... Ted: I think we'll adopt it. -- Sean Shen: Have IP address alliance. Some of the ISPs hope that DHCP message can carry user ID with messages, with another type of DUID. Not sure if they mean customer ID or people ID. What's the proper way to do that? Ted: That is a separate ID, and is probably not the DUID since DUID must be unique. That might be interesting work but not really related to this work. Write a draft. Thomas: But maybe write something informally to the mailing list, to make sure it makes sense. Hankins: Also some existing use cases in DHCPv4. People either modify DHCP servers or modify packets on the side, will use a switch port to insure IP address. Can't force clients disconnect gracefully. I don't think the DUID is necessarily the right area to solve that, but it might get combined or might become the identifier. -- Suresh Krishnan: Don't need to create a new DUID type since we have the enterprise option. Thomas: I think it's the wrong answer. First figure out whether DHCP makes sense, then figure out whether a standards-based approach makes sense. Ted: Enterprise was meant to be the serial number of the device or something. Meant to be unique. Suresh: I think it's a bad idea, but... -- Thomas: Early on there was discussion about the problems of doing in IPv6 what you can do in IPv4. When a new machine comes in, read the MAC address on the side of the box, type it in, and it takes off. The DUID is not on the side of the box... John: In DOCSIS we had a similar situation. We have a separate option field for device MAC address. There is existing work that we can point to, that people can refer to. Erik: Building servers it's hard to have 1 MAC address on the box, since they ship with 4 NIC by default. The vendor really should put the BIOS UUID on the box. Ted: It wasn't always the case that vendors had these on the box. I think they did because DHCP started using them. Hankins: We're delving into completely different space here... I think MAC address itself should never be used unless otherwise defined. -- Ted: Are you going to get hammered by people concerned about privacy? Thomas: I hope not! Ted: Have you thought about it? Thomas: No... pd-exclude Jouni Korhonen http://www.ietf.org/proceedings/78/slides/dhc-3.pdf --------------------------------------------------- Frank Brockners: This is a preference range with a hole... You can either make this as a hole, or as a collection of other networks. We're changing the client and server... Jouni: I address that. Ted: This option does not anticipate that the server will necessarily give a delegation that encloses the excluded prefix. It seems like an optimization to me, since the server has a hint that will allow it to give you a more compact prefix. Jouni: Yes. Wojciech Dec: What are the objections to the unnumbered model? Jouni: In this particular case, the link model for the server is "set up the pair and give no addresses". Wojciech: Why is link local not good? Jouni: It's not enough... it's just not possible. If that were possible we would not be here. Wojciech: Something to look at from 6man perspective? Ted: Design decision or software bug? Jouni: Design decision from 10 years ago. Wojciech: This is so the router has less routes. But if you split out a delegated PD, to me it would sound like the router needs to chop up the space. Jouni: Everything you delegate is behind one pipe. -- Suresh: I am sympathetic to your problem, but I don't see wasting of address space as a problem. If I had to pick something I would pick #2... or #1 (from slide of "existing solutions"). Jouni: Operators are already seeing a red flag for #2. -- Behcet Sarikaya: The problem is arising because you want to push the RR to the end node. This is not designed to be at the end node. If you architecturally put things in the right place. Moving RR is not a good idea. -- Hankins: This all started because PD prevents client from configuring in the upstream. I think we were thinking of physical hard routers we are used to. If you look at this form the point of view of point to point links, I think it makes sense to just relax that requirement for this special case. Go ahead have the phone do the RA on the upstream interface. Ralph: There is a problem with mechanism. You have to tell the upstream, and that requires another DHCP option and changed behavior on the client, which does not give you anything over this option. Hankins: 2 suggestions are similiar. -- Ted: Is this related to work done in another WG? Jouni: No. Ted: We're having a routing discussion in the DHC working group, which seems wrong to me. Jouni: No. We have certain behavior and that is a DHC document. -- Suresh: About 3 years ago we had this discussion on the mailing list. The bottom line was there were broken implementations that did not work at that time, so it became a MUST NOT in the spec. There is space to make this work, by changing to a SHOULD not without any DHCP changes. -- John: We should take to mailing list and have some discussion. Is that reasonable? Jouni: The time window we have is not infinite. If we don't come with a good solution others will go another way... John: We'll take to the list as the next step. Teemu Savolainen: I'm co-author. Why doesn't requesting router know that it has been delegated that it has been delegated block that is part of uplink? Backwards compatibility. Chris Donley IPv6 CPE Router http://www.ietf.org/proceedings/78/slides/dhc-4.pdf --------------------------------------------------- David Mils: Question on the LAN side. Do you make recommendations? Chris: The assumption we are making is we don't know what the client is going to support. DHCP client or SLAC only? We'll support both. David: Different from discussion we had in the broadband forum, because we know all clients support SLAC. Whether it's on by default for home users... may be worthwhile to document the result (client getting 2 addresses). -- Suresh: The DHCP server and DHCP router... any communication required between DHCP server and SLAC module? Chris: Only talking on subnets, not about delegation. Suresh: RA needed.... needs to know prefix from RA side. Chris: Router will pick address for the LAN, and advertise that in RAs, or SLAC if supportec by local policy. Will also support stateful DHCP in the same range. -- Hankins: Some parts of this that make perfect sense, and sound like operational requirements. There are a few that sound like changing DHCPv6. To what extent are you accepting new text from people? Ted: That's the point of the review. Hankins: I have more things to say than I can say at the microphone. John: We're going to need reviewers who can provide comments. Hankins: We should do that. -- Hankins: You have device client+server. Ralph Droms wrote something on that already. The thing we would like those devices to do is collect the sum of option request options from clients and present that on the server side. Ted: I think this is probably out of scope. -- ???: It's great to get review here... can I get some deadline or something? John: I'd like to get 2 more reviewers? Hankins, Suresh, Ted. Deadline? John: Take offline, work with reviewers to have reasonable deadline.