IETF DHC WG 2007-12-04 @ 13:00 Chairs: Ralph Droms Stig Venaas Scribe: Shane Kerr Jabber scribe: John Brzozowski Slides: http://tools.ietf.org/wg/dhc/agenda?item=agenda70.html - ---------------------------------------------------------------------- Announcement from Alain Durand: There is a DHCPv6 Bake-Off this weekend. - ---------------------------------------------------------------------- Agenda: http://www3.ietf.org/proceedings/07dec/slides/dhc-6.pdf - ---------------------------------------------------------------------- Stig: DHC is slightly outside what I usually work on. Looking for another co-chair for this working group. It's been good to be here and learn a lot about DHCP. Ralph: Thank you for your efforts! (Applause) - ---------------------------------------------------------------------- RFC 3942 status update Bernie Volz http://www3.ietf.org/proceedings/07dec/slides/dhc-9.pdf Need to get IANA to represent current status of things. Option 177 is special - should not be used or reassigned. New file moves a number of options into the unassigned category. Issues with Etherboot: 128 & 129 are already assigned to PXE, 150 is supposed to be TFTP for VoIP. Possible actions: 1. Per RFC 3942, say "sorry", give them up and require assignments via IETF process. 2. Allow their "claim". (Can't do fully due to existing conflicts.) 3. Some of both: 128, 129, 150 need to move, others are okay. Ralph: Have any of you run into a conflict? (Nobody.) Bernie: Has anybody configured Etherboot or knows someone running it? Stig: I know people using it, but no personal experience. Ted Lemon: Given that neither implementation went through proper channels, lets publish both drafts and register with IANA as "reserved and used by following RFCs". Bernie: That's sort of option #2. Richard Johnson: Started using 150 when not part of public space, and now it is, it has been out there for a while and we were following what we supposed to use. Bernie: They did liaison early on, but did not complete the process. Richard: Anyone from Etherboot here? (No.) Bernie: We are no worse off if it is documented. Ralph: Will go through details on the mailing list. David Hankins: Some listed as deprecated. (175 and 177.) Would be good to not drop those. They should go back to "deprecated". Mark the land-mine with a flag and move on. - ---------------------------------------------------------------------- Virtual Subnet Selection Option Richard Johnson http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-07.txt http://www3.ietf.org/proceedings/07dec/slides/dhc-0.pdf http://www3.ietf.org/proceedings/07dec/slides/dhc-10.pdf Virtual Subnet Selection RAIO Sub-Option Kim Kinnear http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-vpn-id-05.txt Want volunteers to commit to write a review of the revised version of these documents so we can go through WGLC. Who will volunteer? Bernie Volz David Hankins Evan Hunt David Hankins: In one section you specify that if a server does not support the sub-option it will omit it. This is incorrect, servers will echo back entire contents of the relay agent sub-option whether they support it or not. Kim: Good point. Implies you used it in the allocation. We'll deal with that. - ---------------------------------------------------------------------- Container Option for Server Configuration Ralph Droms http://www.ietf.org/internet-drafts/draft-droms-dhc-container-opt-01.txt http://www3.ietf.org/proceedings/07dec/slides/dhc-3.pdf Willing to take this on as a WG work item? (Hum: strong support for this) Will confirm on mailing list. - ---------------------------------------------------------------------- DHCPv6 Bulk Leasequery Mark Stapp http://www.ietf.org/internet-drafts/draft-stapp-dhc-dhcpv6-bulk-leasequery-00.txt http://www3.ietf.org/proceedings/07dec/slides/dhc-8.pdf Mark: Adopt as WG document? John Brzozowski: Query requirement ID, what about link address in context? (Going across multiple relay-agents.) Mark: If useful in DOCSIS cable-land, then we definitely should add this. John: Another query mechanism would increase the usability. Bernie: Think about relay agent that just rebooted; if not configured with explicit unicast addresses it has no way of discovering what the TCP usable addresses are. Might want a new query to find out what the servers are. Bernie: This won't work where you have multiple hops and there is no connectivity via TCP (only via relay). Should probably just be documented as not working in those kinds of environments. Ted Lemon: Depending on structure of database and DHCP server, may be quite difficult to enumerate across all the entries in the table that has that. Should only ask for those keys you really need. Mark: Unsaid explicitly in the draft, but did say it on mailing list discussion. Would like to have specific queries with data that is identifiable and locatable. Would rather target things we know and understand and expect to use. David: Authentication. No indication of anything other than "I trust your IP address". Mark: IPv6 answer to all security questions is IPSEC. If you don't trust the traffic, there is a way to do it... John: I don't know that by default you can assume secure communications. Mark: All for wordsmithing a draft now, but I won't remember anything I agre to change. Ralph: Please hum if you think the WG should take on as a work item. (Large volume in favor, no against.) - ---------------------------------------------------------------------- Layer 2 Relay Agent Information http://www.ietf.org/internet-drafts/draft-joshi-dhc-l2ra-00.txt Stefaan De Cnodder on behalf of Bharat Joshi, Pavan Kurapati http://www3.ietf.org/proceedings/07dec/slides/dhc-2.pdf David Miles: Is this working group considering similar L2 information for DHCPv6? Stefaan: Work coming from DSL forum, so not considered for IPv6. Ted Lemon: Whole point is just to document existing practice, in which case the end result will be informational RFC? Ralph: Yes. For this document. May be other documents. Ted: Doing at L2 is because IP addresses are scarce? Stefaan: Maybe devices belonging to different service providers. Want to avoid IP addresses. Ted: Suggest solving this problem by giving each device an IPv6 address. But since this is informational probably not that important. Erik Nordmark: Make it hard for someone to steal another domains' resources. This type of technology is useful in a broader context. Should we have some different ways of doing flexible relays. The suggestion to not have to configure these devices can help it scale up. Mark Stapp: Does get used a lot. It is undocumented. I do have issues with some of the details. It is valuable work to be taking on. I would rather see the WG guide the recommendations and descriptions than a vendor document vendor-specific practice. Think WG should take on the work. Ralph: You mean beyond just one specific implementation? Mark: Capturing what is being done and generating guidelines will increase interoperability. David Miles: Complexity of adding IPv6 addresses is expensive. Benefits to using a DHCPv6 layer relay agent. Make the DSLAM as simple as possible. Ralph: Take document to publish as informational RFC? (Some hum in favor, no opposition.) - ---------------------------------------------------------------------- NTP Options for DHCPv6 Benoit Lourdelet http://www.ietf.org/internet-drafts/draft-gayraud-dhcpv6-ntp-opt-00.txt http://www3.ietf.org/proceedings/07dec/slides/dhc-1.pdf (Not slides actually used.) John: Can you describe why you didn't specify one option and a flag that says, "this is an address" or "this is an FQDN"? Benoit: This will probably be in the next version. Ted: Could be a very long discussion, but... historically we have not done that. It creates complexity without really adding value. From my own perspective, the draft looks great, but would allow for more than one IP address. Putting FQDN and IP address is more complexity than we usually have. Encourage you to think twice about that. Benoit: Was quite in favor of just IPv6 address. Look through all of the IP services defined, and they all had just address. Prefer that now. Ralph: There are a couple of ways to fix this. Just because the IP address is sent in the protocol, does not mean the server has to be *configured* that way. Brain Haberman: A lot of the confusion was lack of understanding in the NTP community about how DHCP works. Ralph: The option is going to be developed as an NTP working group item. If necessary will get volunteers and take names for this option in the NTP working group. David Hankins: NTP clueless! Don't understand SNTP and NTP protocols. Benoit: When you receive an SNTP server you cannot redistribute that to a downward client. But the bits are the same on the wire. Benoit: In some cases you can specify a delay for a multicast address. John (questions from Jabber): Just put an address not a name, can get a new address on renew. If you have not yet set your time how can you use DNSSEC. Richard Gayraud: You have a need to fine tune the parameters. You will want a list of servers and parameters for each server. Added an option which can appear several times in a DHCP message. Some people suggested we use sub-options. Any suggestions on how to handle this and have it be implementable? Ted: Should probably read RFC 3396. Adding more than one of the same type of option doesn't do what you think it does. (Bernie: This is DHDPv6.) Never mind! Ted: As far as structures... always good to stick with formats that have been used before. But if you want a structure as long as it is reasonable you can do that. Richard: Was told not to have records because that is not what servers currently do. Stig: Take to NTP work group and tell them how to understand DHCP. Other volunteers? (Some hands.) - ---------------------------------------------------------------------- Service Identfiers List Option for DHCPv6 Hui Deng http://www.ietf.org/internet-drafts/draft-deng-dhc-service-identifiers-00.txt http://www3.ietf.org/proceedings/07dec/slides/dhc-5.pdf Ted: If you provide a list of ports that you allow through, this could be very large. The opposite could also be very large. Unless the list is quite restricted in length it is impractical. Ted: As far as identifiers go, you need to say what they mean or it does not mean a whole lot. Hui: We have talked about this. Ted: It seems like you will need to have a registry of strings. Also you need to specify how the variable length identifier length is given. If I was going to do this I would just want to know what network I am connected to and the client would then know what is going on. David Miles: Why would you tell the client what protocols are not supported, rather than just assuming those are not supported. Hui: Quite a special consideration. When the mobile node has a second wireless connection the node has to think about handover. David Miles: Imply that any options not listed are not supported. Otherwise the list grows quite large. Mark: Felt like this draft was not very complete. I could not understand at all how the information would make it to any application running on the device. I can't understand how this would possibly work, considering all of the issues. Until all the pieces are present in writing it is hard to imagine how this would function. Jari Arkko: Recognize the need to sometimes do things like this, but I would suggest that this be done very carefully and in a limited manner. Previous networks have led to problems with user interface problems. Doesn't make sense from the point of view of the operator either, since they are missing out on income. If you want to do something like this, you may want to do this at a coarser level, "the Internet", "corporate network", and so on. Bernie: Echo Mark's comments. Don't understand how this is supposed to be used, already are some protocols that might help or have some of this information in it. Not clear where this fits in and why it can't be done using some of those other techniques. Why are existing techniques to do some of this stuff undesirable. Ralph: This is interested and WG is interested in reviewing it, but it is not yet ready to be a WG work item. Encourage you to bring back to WG mailing list. Jari: Think it is unlikely that this will be part of this working group's charter. Rethink why you are doing this. - ---------------------------------------------------------------------- DHCPv6 Delegation of Certificates Option Ralph Droms http://www.ietf.org/internet-drafts/draft-popoviciu-dhc-certificate-opt-00.txt If routers using SEND, need a way to pass the certificate to downstream links. Stig: What is the pointer? Also a bit worried about the UDP packet being too big. Francis Dupont: Not useful only for SEND. Used by all kinds of secure routing, SBGP and things like that. Francis: Agree not a good idea to send certificates. Should include a pointers. Francis: Usually for SEND you need 1 certificate. Usually a 1-to-1 match. Jari: In SEND you need both a certificate and a key pair. How does the DHCP server know what the key pair of the router is. Ralph: The security issue is getting the key from the router to the DHCP server. Ted: Is this the solution for how to get routing information into the router in PD? Stig: First thing I said when I saw the draft. Interesting to look at. Jari: BoF Thursday on SEND-CGA maintenance. There is a work item on how SEND and DHCP live together. And now it is not very well. That BoF is to look at that problem. If this is to support router certificates it should go to SIDR or something like that. Ralph: Didn't know about that BoF. If it becomes a WG will be in touch with that group. http://www3.ietf.org/proceedings/07dec/agenda/csi.txt Co-chair for the BoF. How it is worded in the BoF is that the requirements will come from the BoF and the work would happen here. Jari: Will talk off-line about who does what. - ---------------------------------------------------------------------- Rebind Capability in DHCPv6 Reconfigure Msgs Ralph Droms http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-rebind-03.txt http://www3.ietf.org/proceedings/07dec/slides/dhc-4.pdf No comments. - ---------------------------------------------------------------------- Neighbor Discovery Information over DHCP Suresh Krishnan http://www.ietf.org/internet-drafts/draft-krishnan-dhc-ndc-option-00.txt http://www3.ietf.org/proceedings/07dec/slides/dhc-7.pdf Alain Durand: Some of the things that we need from the RA (like prefix length), but most of the things are not necessary. Do we really need to have this complexity and import *all* the RAs? Would it not be better to add the critical pieces that are missing? I think it is a much, much simpler route. Jari: Agree with previous comments. Real issue is what do you do with the data that you get? So the container aspect is not the issue, the semantics are the issue. Better to decide that we have 2 options that we need in DHCP as well, and not keep adding stuff. Suresh: If you bring them as separate options, the problem does not go away. You still have to resolve the precedence of these two! Alain: If you define it in DHCP, don't use RA any more. Ralph: If we are defining the DHCP options one by one rather than a container option, then we can add words about how to resolve them when we define them. Suresh: But is that up to the protocol to specify? Isn't that local policy? Ralph: Good question, but at least we have some way to write down the rules. Bernie: More information that may want to come through the DHCP method. Because you are not able to update the lifetimes, for instance. You may want the information to be updated much more frequently. I think there is much more verbiage that you would want to put in the DHCPv6 option. Allows you to add information about the precedence, and so on. Having more well-defined options for each individual need lets us write more about how you use this. [ Ralph cuts comment line off due to time. ] Shin Maruyama: Still remember difference between DHCP and RA. IP vs. UDP protocols. Almost nothing different other than UDP vs. IP. So I agree to use same scheme to send to client - should have only one. DHCP doesn't have DAE, need something like an RA, but we should stop extending the RA. Lets use DHCP. If we need some extension we can develop DHCP for this. Suresh: If we decide not to develop any more stuff for RA, then read my draft for v6man. Want to have one place to define an option, not 2 places. Shin: Other difference is RA usually implemented in kernel code. In DHCP it is usually easy to add, without patching kernels. If you need new parameters modify the daemon on top. Stop extending RA! Hemant Singh: Getting v6 completely backwards. All the prefix and subnet design should be on the router. If you do this kind of a thing then you are taking DHCPv6 backwards. David Hankins: Regarding precedence... I always found them confusing whenever anyone brings it up. When DHCP was written, we didn't look at RARP. No point arguing about which goes first or last. - ---------------------------------------------------------------------- Ralph: Thank you all, see you in Philadelphia.