dhc wg IETF 80 minutes 2011-03-31 13:00 Chairs: John Brzozowski Ted Lemon Minutes: Shane Kerr http://www.ietf.org/proceedings/80/agenda/dhc.html [ minutes started a bit late - 13:05 ] Forcerenew Nonce ---- http://tools.ietf.org/html/draft-ietf-dhc-forcerenew-nonce-01 http://www.ietf.org/proceedings/80/slides/dhc-7.pdf Ready for WG Last Call? - No opposition to last call. Ted will put out a message for last call on mailing list. Relay Agent Configuration Option ---- http://tools.ietf.org/html/draft-asati-dhc-relay-agent-config-00 http://www.ietf.org/proceedings/80/slides/dhc-9.pdf Has anybody read the draft? 5+ people Ted: Seems like it has potential to be useful. Do you have customer demand? Rajiv Asati: Yes. We have to do a lot of provisioning. We want the zero touch to be really zero touch. John: I think this could be useful. There would need to be some work in the area of security. Rajiv: I agree. Ted: You want this as an addition to option 82? Handle in the same way? Rajiv: Idea was to keep it entirely out of option 82, but nothing prohibits us from putting this in option 82 or vice versa. Ted: I thought maybe there would be an ORO option that got placed into option 82. I think this would be a lot less complex, and there are plenty of option codes available. Rajiv: Thanks for pointing that out. Ted: You have text to talk about relay agent chains. We already have another draft about relay agent chaining, so if you have anything you need please let me know so we can put it in there rather than repeating this. Ted: Also, there are requirements in your draft that are already specified. It would be good to get rid of those - specifying twice could mean it gets wrong. Rajiv: Totally agree. Rajiv: Perceived to be useful. [ Nobody thought it was bad, some people thought it could be useful. ] Ted: We will send a note to the mailing list to ask to adopt as a working group item. Host Generating Interface Identifer ---- http://tools.ietf.org/html/draft-xia-dhc-host-gen-id-03 http://www.ietf.org/proceedings/80/slides/dhc-1.pdf Ted: Any comments? [ no ] Anyone read draft? [ only 3 people ] Ted: Any opinion on whether this is useful? [ silence ] Ted: Not sure what to do... to me it seems useful... Ted: Is the DHCP's server's job to have a list of prefixes per network and originate those? Or to take a list of prefixes provided by the client and pick one or more of those? Sheng Jiang: Picked by the host. Marc Blanchet: I am still figuring out the real use case and how it is deployed. No SLAAC, not clear to me real use case in real networks. Ted: One proposal is how to secure your DHCP connection using CGA. We don't really have a good way to authenticate a DHCP transaction right now. Marc: This assumes no prefix by RA, right? Jiang: Right. Ted: It seems to me you don't want to bypass RA, but you are giving the DHCP server a chance to help you avoid spening CPU cycles. Jiang: There will be some connection between the neighbor discovery and DHCP, if you have both on hosts. The hosts could be very confused, and there could be some network configuration errors. The host has no way to tell what is a real problem or what is just not correct prefix. Marc: Maybe also discuss in 6man or ip6fix working group. Ted: We've done a lot of thinking about the problem, but this really is a set of building blocks. We've chosen a set of building blocks without really consulting anybody. It might help us a lot if we asked people outside of this working group. [ XXX I would not catch this gentleman's name - he was a first-time attendee ] XXX: I have a security background. From the PoV of security I am hesitant for the last 64-bits provided by the hosts. There is no accountability - I am not looking for a DHCP option like RA. Ted: There are use cases for what you are talking about, and there are use cases for SLAAC. XXX: I have a general question... with router announcements you have have 2 or 3 prefixes. Can you do this with DHCPv6? Ted: Currently no. That is a kind of orthogonal discussion... maybe something for 6man or maybe the routing area. XXX: I speak about addressess... can you do that? Ted: Oh, yeah, absolutely. Dave Thaler: A use case I have in mind - there are many cases where the network is using DNS dynamic update, but doesn't trust hosts to do that. If you are doing something like that, today you cannot put records in DNS if you are using SLAAC. An approach like this could solve that. Ted: Yes, and stay tuned for more presentations. DHCP CGA Configuration and Address Requirements ---- http://tools.ietf.org/html/draft-jiang-dhc-cga-config-dhcpv6-02 http://tools.ietf.org/html/draft-jiang-6man-addr-registration-req-02 http://www.ietf.org/proceedings/80/slides/dhc-2.pdf Shane Kerr: Asks about problem with the network asking for address information maybe being a security problem. Dave Thaler: This seems like a requirement, so maybe the requirement would be not to expose private information to untrusted hosts. Jiang: We can add a requirement that this must be secure. Rajiv: If the intent is to register these hosts and keep track of these addresses, why not just use DHCPv6? Jiang: That's what we're going to do. That is the suggestion. Ted: If you're generating a CGA address then the host has to generate it. Rajiv: Can't we use stateless for this? Jiang: I asked this in 6man... Ole Tr¿an: Maybe talk to SAVI? Ted: What does SAVI do? [ source address validation ] Ted: Seems like a different problem... it's registration not validation. You're telling the server something it has to remember. Jiang: I'll sketch the requirements in another draft, and try a protocol extension. Ralph Droms: Internet Area director. While there may not be anything in SAVI, it wouldnt' hurt to ask. Dave: I agree with Suresh. The problem may be more general, for example triggering DDNS, or maybe ISATAP or other environments that can't use DHCP for address assignment. Jean-Michel Combes: SAVI chair. I didn't read the draft, but I will do so and will send you feedback. Jiang: What is next action from WG? There was consenus in Beijing. Ted: Call for adoption on mailing list got mostly positive comments and one question. [ which was answered ] So we have consensus to adopt. Any disagreement? [ none ] I will send a mail saying we have adopted it. You should resubmit as a draft-ietf-dhc- document. Prefix Pool Option for DHCPv6 Relay Agent ---- http://tools.ietf.org/html/draft-yeh-dhc-dhcpv6-prefix-pool-opt http://www.ietf.org/proceedings/80/slides/dhc-3.pdf Leaf Yeh Shrinivas Joshi: If the client does not respond with a renew or rebind, the prefix option will not be changed because the status is binary. Leaf Yeh: We can do the reconfiguration for the customer if the state has changed. Shrinivas: If the server changes the prefix it should no longer be advertised. Reconfigure is directly recast, it does not go through the relay agent. If the client does not exist or does not respond... Ole: A couple bullets down is a competing proposal. Could we hear that now? Ted: Good idea. Have you brought this up in the 6man area at all? Yeh: No. Ted: I think it would benefit from feedback from people in the routing area and the 6man area. Rajiv: I agree. For me as a routing geek this has been solved by routing summarization. Yeh: So you ask why we need this? [ yes ] To do the aggregation automatically, we need customer routes to be continuous. If a prefix expires then the routes should not be in the PD routes, so we cannot do it automatically. We need information from the router and the server. Rajiv: The router can do all sorts of magical things. You can make the router do all of that automatically. This is day 1 behavior on most routing protocols. Rajiv: This proposal is about telling the DHCP relay agent doing more. maybe it will fit in with another option, if it makes sense at all. Aggregate Route Option ---- http://tools.ietf.org/html/draft-joshi-dhc-dhcpv6-aggr-route-opt-00 http://www.ietf.org/proceedings/80/slides/dhc-5.pdf Ralph: We talked about ways to avoid complexity here in the internet area. So the question is: "Is extending DHCP the right way to solve the problem?" Why not configure the router through some other means? We need to have this presented in other areas. Shrinivas: The other things are SNMP and things like that, but those are proprietary and vendor specific. Ralph: That's part of the gap analysis. John: Why does it have to be so dynamic in nature that DHCP will play a role? Fred Temple: If I have a client that moves to a different relay can it take its prefix with it in this scheme? Shrinivas: That's a good question. You'd have to renumber. Fred: I'd be interested in a scheme that could preserve its information. Yeh: I agreed to solve the problem within the existing mechanisms. I don't think it's necessary to ask other bodies. Ole: The DHCP group can choose between these based on DHCP. Ted: I'd like it if the authors could raise this on the mailing list. Or send me private mail. The next step is mainly procedural. IPv6 Host Configuration in 6rd ---- http://tools.ietf.org/html/draft-guo-softwire-6rd-ipv6-config-02 http://www.ietf.org/proceedings/80/slides/dhc-0.pdf Anybody read the draft? [ some hands ] Ted: When I read the draft it seems like you chose a pretty good solution. I think it would be good if more people read the document. Ole: This does not only apply to 6rd, right? It applies to any link type that does not support multicast. You relay the messages locally. Fred: This is documented in the ??? spec. Ted: I think we should do a call for adoption on the list and see what reaction we get. IPv4 Residual Deployment across IPv6-Service networks (4rd) ---- http://tools.ietf.org/html/draft-despres-intarea-4rd-01 http://www.ietf.org/proceedings/80/slides/dhc-6.pdf Anybody read the draft? [ a couple hands ] Questions? [ none ] Ted: You mashed together options, that will introduce complexity. Better to use separate options. RŽmi DesprŽs: That's not a problem to change it. Ted: Also, you used bitmasks. Generally it's better not to do that. RŽmi: Also no problem to change it. Ted: I think it needs more working group review when you've gone further down the path. Public IPv4 over Access IPv6 Network ---- https://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/ http://www.ietf.org/proceedings/80/slides/dhc-10.pdf Peng Wu: Alain has suggestion to use option 82 for carrying client IPv6 to IPv4 mapping. Is this an abuse? Ted: I think that's a perfectly legitimate solution if that's easier. Anybody read the draft? [ no hands ] Ted: Only appeared on agenda on Tuesday, so that's excusable. Ted: DHC wg doesn't have anything to say about whether this goes through. Probably the right thing to do is to write up a quick summary of the ways that this could be done and present it to the DHC working group and see what people think. Wu: Personally I am going to go with option 82. Ted: We should flesh that out and see how it goes. Administrivia will happen on the mailing list. End 5 minutes early!