Dynamic Host Configuration Working Group IETF 85 Working Group Minutes Agenda Bashing Working Group Status draft-ietf-dhc-redundancy-consider ** Ted will review ** Tomek will submit to IESG whether or not Ted reviews bulk leasequery v4 Kim: we think we have addressed the issues. Ralph: I will try to take Wes aside and talk to him at IESG wrapup ** Ralph will talk to Wes about whether he's happy with the updates. client-id draft Ted: comments lingering Ralph: Needs to have me sign off on it. Will take a look to see if anything to call out. ** Ralph will review comments and either call out any concerns he thinks remain or sign off on draft. tunnel option doc Ted: Problem: ugly kludge to get around restriction in RFC3315. Lots of back and forth, do kludge, fix rfc3315? No activity on mailing list. Ole: Prefer to fix in 3315 if we can. Ted: Question is whether fixing in 3315 creates more problems than it solves. Ole: I could try to do a proposal and see if the working group would accept it, but would like to get help from a DHCP person. ** Ole will ask Bernie Volz for help on this; if Bernie isn't available, Ted will help him. class-based-prefix ** Authors will publish a new version of the document with additional use cases that Ian has provided. dhcpv4-over-ipv6 Francis: suggest asking for more feedback on 6man ** Ted sent WGLC reminder to 6man mailing list dns-pd ** John will evaluate consensus. sol-max-retry ** John will issue WGLC. stateful issues doc ** Will do WGLC after IETF. triggered-reconfigure Med: would like further review, otherwise ready for last call ** We will issue a WGLC on the mailing list, hopefully get some final review Draft: DHCP Options for 3GPP Service URL: http://www.ietf.org/id/draft-liu-dhc-3gpp-option-02.txt Presenter: Liu Guoyan Slot: 5 min ** 3GPP should take this to 6man ** There are some issues both with option format and security model Draft: Failover requirements URL: http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-failover-requirements-02.txt Presenter: Tomek Mrugalski Slot: 5 min Draft: Failover design Presenter: Tomek Mrugalski URL: http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-failover-design-02.txt Slot: 20 min ** Kim says it's a 50-page document, and he would really appreciate it if people could review the document. ** Particularly would like review from people who aren't experienced with DHCPv4 failover, and therefore don't already know the underlying assumptions. Draft: Option guidelines Presenter: Tomek Mrugalski URL: http://www.ietf.org/id/draft-ietf-dhc-option-guidelines-08.txt Slot: 5 min ** Room consensus was to use variable length prefix ** Will post WGLC on mailing list. Draft: A Generic IPv6 Addresses Registration Solution Using DHCPv6 Presenter: Sheng Jiang URL: http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 Slot: 5 min ** Question came up: why are we using an FQDN for this. ** Consensus seems to be to use an IPv6 address, but we should check with Bernie, who is thought to have been the one who suggested an FQDN. ** Question came up as to whether this would be specifying a non-DHCP address resolution server. Clarification: no. ** Further discussion might be wanted on the mailing list about whether host or router should do address registration. ** Would be nice to have a motivational doc that talks about the uses for the registration service coming from hosts versus coming from routers. Draft: Configuring Cryptographically Generated Addresses (CGA) using DHCPv6 Presenter: Sheng Jiang URL: http://tools.ietf.org/html/draft-ietf-dhc-cga-config-dhcpv6-03 Slot: 5 min Question: why does the client have to do all this work? ** We will discuss further on mailing list. Draft: Prefix Assignment in DHCPv6 Presenter: Sheng Jiang URL: http://tools.ietf.org/html/draft-ietf-dhc-host-gen-id-04 Slot: 5 min ** Ole will review the document and maybe bring it up on 6man Draft: CER ID option Presenter: Chris Donley URL: http://www.ietf.org/id/draft-donley-dhc-cer-id-option-01.txt ** Not going to adopt, waiting for work to happen in homenet or elsewhere ** Feedback requested by authors, particularly about whether it would be useful to include ISP-supplied prefix length ** We should have a discussion on the mailing list. Draft: DHCP Option for Port Set Assignment Presenter: Qi Sun URL: http://www.ietf.org/id/draft-sun-dhc-port-set-option-00.txt Slot: 5 min Also: Discussion about the lw4over6 and MAP-E/MAP-T DHCP solutions Extensive discussion on this. Main points discussed: - Need for port set obfuscation. Francis was strongly in favor, but cited no reasons; Ted, Alain, authors all agree that obfuscation doesn't add value. General consensus was that this is ultimately up to softwires, not dhc, but the dhc interest in this question is that the option should be simple, and not offer four different obfuscation mechanisms with related and varying inputs that would have to be represented in the option. - Is the option idempotent? Alain was concerned that this was not clear in the draft. - Do we need a DHCPv4 or a DHCPv6 option, or both, and should they be the same if both? The debate here comes down to a couple of issues: * Duplication of effort--if we have both, gateways will have to support both. * Gratuitous incompatibility--currently the proposed DHCPv4 and DHCPv6 options are different. * Desire not to deploy DHCPv4 infrastructure on transition networks where DHCPv6 is already a necessity. * Do we need additional IPv4 configuration? If so, position of DHC working group has long been that these must be addressed using DHCPv4, not DHCPv6. * One solution would be to use DHCPv4-over-IPv6 for all port set configuration and related IPv4 options (this requires using DHCPv6 to configure the Client Relay Agent). Ralph expressed some concern that this might result in shared IP addresses accidentally being used by non-port-set-aware clients, but subsequent discussion allayed this concern (I think). * Another solution would be to use DHCPv6 for port set configuration, and then use DHCPINFORM (DHCPv4) over a tunnel for all other IPv4 configuration. Two problems with this: reserved ports (client requires them, shared IP address prohibits them), and general lameness of DHCPINFORM specification that would likely cause interop problems. ** No clear consensus. A group of participants will write a document summarizing the issues and present it to the working group. It looks like Suresh, Ole, Ted and Alain were interested in doing this work. --- unedited transcript --- Radius option Leaf Yeh not here, that got a lot of review and commentary, Leaf wants us to do a last call, anybody object? I'm just going to do a last call on the ML. DHCPv4-over-IPv6 We got a lot of commentary, nice update to the doc, nobody responded to second WGLC. Francis Dupont: I suggest to cross-post it to the sixman mailing list too because interest is in 6man. Ok, that's a good suggestion, thank you. dns-pd John: I owe ted an eval. I think I have the next one too. Also accepted as a working group item SOL-MAX-RETRY, need to get out a WGLC. The intention for SMR is to do WGLC by email, would like to get some feedback from the crowd, any objections? Got mail on list indicated that folks would like to see that move forward. Objections? Thanks. Ted: So the stateful-issues document, there was some good discussion, authors submitted new version at beginning of IETF, probably ready for last call. So I'm going to send out another last call if there's no objection. Med did a new option, triggered-reconfigure, adopted by wg, everybody thought it was a good idea, what's your status? You ready to go on that? Med: There was two issues that has been raised here, in first verion we have sent the two option to mailin glist to propose mitigation to these issues, no response, so we did the change, issued updated version. If wg can review, good idea, we think it is stable from our POV. Ted: So you think you're ready for WGLC. We'll do last call, if someone objects they will review it in the last call. That's it for WG status, if I missed anything, please say so. Prefix Pool Leaf wasn't able to come to this IETF. There were a lot of comments, Leaf would like to bring it to last call. The prefix pool option is less baked than radius option, a lot of work has been done, it's fairly mature, but I think it needs more review. It would be nice if somebody could volunteer to review it. I'll bring it up on the mailing list and ask for review on the mailing list. DHCP Options for 3GPP service draft Lorenzo: Clarification Question: what's a trusted non-3GPP access? Prez: In 3GPP consider the WLAN interface trusted non-3GPP access. Lorenzo: provided by same carrier? Prez: yes. Ted: you should say that in the draft. Sheng: clarification question. Here you say it's a message DHCP message exchange between the mobile node and the trusted non-3GPP access. So I get confused here, you have the DHCP client on your mobile node, but where is DHCP server? Chrissi So, Chang Hui: the TR he referenced in the beginning, the DHCP server is in trusted wireless lan gateway, so will be DHCP server function in that. Intentions of that functional entity is communicate with 3GPP core network, IP address is associated with specific APN, has to go to that gateway, hosting that APN, communicate with the packet gateway in 3GPP network to obtain IP address from that APN. Sheng: I'm fine with that, but you should have that in the figures. John Gaipolimano with Huawei. This solution is addressing an underlying connectivity problem that represents 3GPP, but when we come to non-3GPP we need some options. Currently 3GPP is looking at multiple solutions, DHCP, but could just as well be EAP, or could be dedicated protocol that conveys session options, or 802.11u or GAS. Ted: So as an IETFy note, the DHC working group is not in a position to make a decision about which tech to use, so what we need from 3GPP would be some kind of liason statement. John: So 3GPP is studying, may pick this solution. Lorenzo: This will not give you equal capabilities to what yo uhave on a 3GPP network. O n 3gpp when you attach to an APN, you get an RA that gives you a /64, so your terminal can choose whatever interface ID it wants to use. An APN is a link, not an IP address. It's a multiplexor of networks, not IP address. So if you use this option you lose the functionality you have today on a 3GPP network. E.g. privacy addresses. So given that the IETF provided feedback to 3GPP that assigning single IP addresses to terminals was not appropriate, /64 has to be encoded in standards, IETF position was that a terminal should get a network and not a single IP address. I think we should say that. Chrissi: in intial attachment, fully agree prefix is good way that is required, but important scenario is that right now today many 3gpp operator is going to deploy wireless lan, offloading traffic. When you have mobility handover prefix is no longer appropriate. In voice, want to be able to preserve IP session continuity, so when mobile is hand over from 3gpp to non-3gpp want to maintain IP addresses, so using prefixes is no longer able to satisfy this consideration. Ted: At this point in the process having a big long discussion about this in this working group is a bad dea. What you guys should do is get more clarity on what your final goal--get closer to picking a solution. And this discussion should happen in 6man, not here. From DHCwg perspective, there are two points to the doc we might want to discuss here, but this discussion about whether to adopt this work doesn't happen here. Chrissi: There is a circular dependency btw 3gpp and ietf, in one sense company want t propose solutions, is there draft in IETF, otoh when we come to iETF want to open idea, look for possible ... Ted: So to resolve that dependency, right thing owuld be to go to 6man and get some clarity on what this option would look like if it were implement, then go back to 3gppp, say here's what the IETF proposes, is this what you want. There are serious issues that might be better solved with EAP. Ralph: Doesn't have to happen at IETF meeting. Ted: Right, you can bring this up on 6man mailing list tomorrow, don't have to wait until Orlando. Or go find the 6man chairs and talk to them. Erik Klein: So if you need to test something, evaluate if this works for you, there are vendor codes, you can define own option and experiment. Trusted wireless LAN, it's operated by same carrier? Chrissie: Yes, in the most common one you will be operate from the same operator, but however the model does not preclude trusted relationship between two operators. But thsoe policy, we do not specify, up to operator. Suresh: As someone who has read the 3gpp specs in quesiton, the trusted relationship is not between operators, but whether operator is trusted to separate traffic from different UEs. Point is there is an IETF recommendation, RFC3314, says every mobile gets a /64. No need for liason statement. Erik: So the root of my question is does this need to be standardized, does there need to be interoperability, answer seems to be yes. Kim Kinnear: Your last suboption didn't look like a suboption to me, might want to look at section 5.4 of the option draft. When you're starting from scratch defining suboptions, no need to do weird stuff. Tomek Failover work redundancy-consideration last call on failover-requirements concluded Nov. 12. failover-design John: there is actually a need for failover on individual addresses. Requesting review by people who have not read this before. Alistair Woodman: about the general premise, using tcp etc, do you not feel that you are trying to overspecify the solution? Why not say what it has to do and not describe how it does it? Kim: The requirements doc is the requirements it needs to meet. Alistair: I'm suggesting others might solve the problem using distributed hash tables, etc. Ted: This is not a requirements document. It's certainly true that you could define another protocol that meets the same requirements. Alistair: Why are we spending time trying to get that ratified? Kim: Do you think there is value in having any design? Alistair: If somebody wanted to say I have a DHCPv6 system that has failover, what it has to do to meet that requirement. John B: The value add for us is potential interoperability. Alistair: That was expressly excluded at the beginning because there's nothing about what's going on on the wire. Kim: You can't do the what's going on over the wire without this. Ted: The DHCPv4 failover doc was 150 pages. Never made it through the IESG because it was too big. THe purpose of this draft is not to specify requirements. It is a _part_ of what the failover draft did. If you don't think the DHC working group should do this work, that's a legitimate point. If you don't agree you should say so during WGLC. But it is not on topic to have a discussion about whether this document ought to exist. Kim: Please respond to the requirements WGLC and please read this document. Tomek Option Document Tomek: what do you think should be the recommendation? Tomek: when you want to send prefix over wire can do with fixed option or variable length option; which do you prefer? Suresh: variable. Erik Kline: In the variable case, how do you transmit the prefix if it is not byte aligned? Tomek: padded to nearest byte boundary. Erik: but you want to transmit a prefix as well, but you may have a final byte.. Ted: this is for prefixes not addresses Erik: ok Ole: This is just for prefixes, right? Tomek: yes. Ole: So currently we have options that do both of these, right? Is there a third? Pick one, certainly, I'm fine with variable. Ted: The code is already in the servers and clients; why not use it? Tomek: will also ask question on list, publish new version, then ready for WGLC. Ted: We'll post a WGLC on the list, hopefully people will respond. Generic IPv6 address registration (Sheng) Kim: why use FQDN? Erik Kline: I don't think hosts should do this. Things that do multicast listener discovery should do this. Sheng: I think Bernie wanted the FQDN. Lorenzo: If you use the FQDN, for the first address you have a bootstrapping problem--can't resolve FQDN until you have an address. Sheng: This is about self-generated address. Ted: So you already have an address. Lorenzo: how do you get? Sheng: host generates it. Suresh: Two cases, one where registering of addresses is prereq for network address. We assume the case where you just register it informationally. Lorenzo: you get your first address. Ted: It would be really great if you could have this conversation on the mailing list. Did you get the impression that we could use IP address rather than FQDN? ** Author will check with Bernie, and maybe work on some text to send to Lorenzo and Erik. Sheng: do we want support for registration server which is not a DHCP server? Ted: Speaking a different protocol? Sheng: No, speaking the same protocol. ??: Then it's a DHCP server. Sheng: take DHCP PD, it's talking between routers, but using DHCP protocol. Configuration CGA using DHCPv6 (Sheng) Ted: Has anybody read this document? It would be nice if a few more people read the document. Lorenzo: can I use this type of address? No. Can I use this? No. What about this? Yes. What's the host supposed to do? I connect to the net, then have to negotiate what style of address I can use? Yes, it's good to create work for router vendors, but are the host vendors really asking to do this work? Ted: I think one of the key elements here is what sec value to use. Lorenzo: Creating the burden of a two-way handshake, it would be better it would be simpler for the host to just tell it, not negotiate. Put it in an RA option, here's the values we support. Sheng: that's what we suggest at the very beginning, but has serious security issues. Consider your RA some high sec value, then the host has to use that to generate CGA. Sec value 1 will consume more than 1000x power. Lorenzo: then host can say "no." Sheng: then you don't have network access. If you use advertisement model, then what happen if I fake router to just send out malicious sec value, then every time, in this way you need Lorenzo: if you have malicious router on the link you have way bigger issues. Suresh: sheng said RA can be spoofed, but with CGA and SEND RA can not be spoofed. Sheng: we take that offline. Prefix Assignment: Sheng Had last call Aug 12-Aug 27. Technical comments from various people, and objection from Bernie saying that's not ready yet. Then according to comments 03 version needed, major different is describing of motivation and the client needs to include IA_PA with IAID. There's no prefix announcement or advertisement module anymore. Procedures are prefix associate time expired. Clarify return status code when no preferred prefix which is existing code. Ole: I haven't read the document. You're suggesting to replace ND/PD with DHCP? Sheng: no. not replace ND bc ND is still needed for the first hop router information. Ole: is it prefix discovery as in for on-link determination? Purpose of ND/DHCP, of on-link determination is to know what neighbors are on the same link. DHCP is you can give different information to each client. Kind of against purpose of on-link determination. Lorenzo: this is addressed in the document. Ole: I don't understand the purpose of a prefix if you don't use it for on-link determination. You don't set the "l" bit, or for address assignment. What is the host supposed to do with this prefix? Sheng: for situation where host want to generate its own address, CGA address or random address. If that's the PPP situation, you can reach PPP link. Ole: I promise to go read the document. Erik Kline: Was there a 6man information? Advertising PIO information not in PIOs warrants a 6man review. Sheng: I believe at least one email request has been sent to 6man. Ted: ISTR there was advice to talk to 6man a while back. Sheng: the problem we always have is we don't have enough readers to give feedback. Ole: So why don't I read the document? If appropriate, send to 6man. Lorenzo: In the interest of making ourselves even more popular. If you don't have a lot of interest, then perhaps people don't want to use it? Ted: the problem is that as I said, I think this doc has been in the wg for quite some time, there was interest when it was introduced, assumption is that there is still interest, may be wrong. Sheng: people seem only attention to new documents. Ralph Droms: There are two subtly different questions to ask. Are there any comments on the draft? Would you use this? Asking any comments doesn't get you that second answer. Lorenzo: you mean wouldyou personally use it? Ralph: Two different questions. I was thinking would you implement this? But even those two sub-questions of the same question would be useful. Do you think it's generally useful? Do you have a specific use for it? Would you use it yourself? Lorenzo: Our colleague had a t-shirt printed, has the IETF logo, on the front: IETF: Asking "how" before "why" for 25 years. I think his point is before we go into all the details of how we do this, there's a valid question: should we do this work? Ted: That's dhc adopting it, and there is the larger question for the IETF. Ralph: I think we asked why at one point, need to refresh. Ted: It is not out of scope to re-ask that question four years later. Sheng: at least 2.5. Ted: Let's ask that question on the mailing list. Sheng: Ole, your promise to do some work in two days, and I am count on you, we come back to say what's next. Okay? Chris Donley, cer-id option, was on agenda in Paris, didn't get to it. Several Home network addressing mechanisms require identification of customer edge router. Idea is that the internal routers within the home relay up their prefix request to the edge router that gets the prefix from the MSO and spreads it throughout the home net. Internal routers need to know which is edge router. CER using ... Lorenzo: clarification question, where everything has "I need a /64" is it possible to say "I need two /64s?" Chris: You could ask for /62. To do this using DHCP we're proposing a DHCP option to identify the CER. ISP would indicate that it's not CER by setting CER to all zeroes or not returning CER option. If something in home does not receive CER ID option it thinks that it is the CER. When the CER gets this option set to zero, identifies itself as CER, populates the option with its IPv6 address, passes it on down through the network, all the internal routers learn ... Lorenzo: what is its address? Chris: we recommand a GUA address from the LAN interface. ?? wouldn't the router's PD request be different depending on whether it's a CER? ?? Suresh: Eric Nordmark and I worked on this draft in homenet, how does an IR on level two know the routing for the PD that somebody lower than it got? Chris: DHCP snooping. Ted: when you unplug your router and plug it in in a different place it detects that and re-does DHCP, so it will detect this very quickly. Chris: the RA changes, the downstream know they need to change their address, need to re-do DHCP, it iwll come back to a new topology. Chris: I don't think this is the right wg to spend a lot of time on this mechanism--it really belongs in homenet. I want to get on to discussing the specific DHCP option. Ole: I think prefix assignment is in the scope of homenet, given that homenet hasn't decided what mechanism to use. Suresh: it has, and it rejected the DHCP request we proposed, they are using OSPF. Ole: I'm certainly in OSPF camp, but that doesn't mean it's decided. John: Just review in this wg. Tim CHown: this approach isn't precluded by homenet arch doc. Lorenzo: so the intention of this draft is to agree on a format so that if homenet agrees this is the way to go, this is ready. Chris: there are two drafts, draft-gman-?? and this one. Lorenzo: so there's a chance homenet will decide to do something else, in which case work is wasted. John: unless there's another use for this. Ted: God forbid that the IETF waste time. Suresh: I think there's nothing wrong with the option. We had something like this, the issue was homenets are pretty dynamic, those things need to be reconciled with homenet. Ole: PD fails in four or five or ten different ways. Ted: we don't need to have that discussion here. Ole: why are we having this now? Ted: So you would not vote to adopt this option as a working group work item. Ole: right. Lorenzo: definining the syntax of the option... Ted: I think we get that point. ??: what happens if ISP doesn't send CER option? Chris: doesn't have to (see above) Chris: draft-gman-homenet-relay-autoconf, but could be used for other mechanisms. We had some feedback since we posted this that it could be extended to include other information such as size of prefix handed down by MSO or ISP. Question to wg: we're looking for feedback on the option. Second, is this something we should extend and add additional information such as the size of the big prefix? John: one of the things I was thinking about was feedback we got so far, we could for now perhaps it seems reasonable to get feedback fromw g about what's been specified so far, extensions could rely on homenet or other places. Lorenzo: having just read the draft, I would like to see in the spirit of wg feedback, I would like to see a bit more clarification on the use case. What can I do with that information? Ted: Can I get a show of hands, does anybody think this is something we should adopt right now? Shouldn't? So not a big surprise, once the work proceeds in homenet or there's another customer for this we can revisit that. Nevertheless I think it's interesting since you're presenting a solution in homenet, it's worth having the documentation as to how you do it. Next, Qi Sun. dhcpv4 option for port set assignment Francis: why you use port mask and not min/max? Seems far more flexible. Qi: we discuss with vendors, port mask is winner in router implementation. Francis: second question, port randomization. I believe you mean you randomize inside the port set. For me it's not acceptable. Far too easy to recognize the clients/customers looking at ports. Ted: we had kind of a big discussion about that whole question which led to the merging of the two drafts. No matter what you do, if you start sharing addresses, the number of ports that the host gets is small, and the way that you share has to be standardized. So even if you have a clever algorithm, it's easily reversable because attacker knows the algorithm. Francis: there is a draft that looks at all kind of looking at port set to avoid too easy reverse engineering, concludes contiguous port set is not enough. Ted: So do you have some kind of metrics for that? It would be interesting to get metrics as opposed to random speculation. I definitely heard many people advance arguments, like the one you just did, but no metrics we can use to evaluate those arguments. Alain: First, glad to see this moving forward. Issues, first as Francis explained, might as well have min/max. If you put a 1 as last bit of mask, you will get every other port. So does that not guarantee you that you will not have any sort of continuity. Agree with Ted Lemon, there's no point in fancy algorithm. Have to live with reduced anonymity, it's just what it is. Next point, is this option idempotent? If I ask twice, do I get the same port set? Qi: from implementation view, it is the same... Alain: I don't care about the draft, I care about the standard. Ted: the document has to say that. Can you send a proposed change? Alain: I don't care either way. Next comment, you said in draft, lifetime is same as lifetime of address, that is lower than lifetime of address. Don't see why the two have to be the same. Francis: I propose to make clear, this is an assigned resource, the same thing as the address, should be idempotent, should get the same. Alain: if you ask twice, you get the same thing. Ole: The actual port mapping algorithm should be discussed in softwire here. Regardless, now that we have one v6 option doing this and one v4 option specifying the exact same thing, could we agree on bit representation? Yofor Mathew: offset view in your format. That will make the noncontiguuous port set for one client. Ole: we represent a v6 prefix with 2001::/18, right? In MAP port option, we present a port range like xxx::/6, giving you a thousand ports. We're doing different in v6 and v4, please let's agree. Qi: wg decision whether to do in v4 or v6. Suresh: the first step is whether th eoptions can be similar. Second, do it in dhcpv4 and dhcpv6, two different questions need to be answered. I think it's premature to proceed with this at this point until discussions in softwire end somewhere. Ted: so this is a presentation about a particular option. there is a meta-question that we also need to answer which is in fact, the whole question of whether we solve this problem with dhcpv6, dhcpv4, or both. Speaking with my wg chair hat on, I can't say which of those things we do. Speaking with my dhcp geek hat on, I'd like it if we could come up with a single solution, don't know if we can. If we are forced to do two solutions, I certainly agree with Ole that they should be the same as much as possible, not arbitrarily different. Again with tech hat on, I interrupted the authors of these drafts to get them to coalesce on a single option, bc what they had done before was a very complex option. I would like it if this were as simple as possible. If softwires wants security through obscurity, that should be the only option. That's a question that softwires should answer, we'd like it it softwires could address that option. Alain: this is purely a DHCP issue, do we use DHCPv4, do we use DHCPv6. Ted: you raise a very good point, IMHO it's up to softwires to decide, buut the list of choices they should decide from is fairly constrained. If the only thin that needs to be configured on the CPE device is an IP address and a port range, then I think it's relatively harmless to use DHCPv6 for that. My concern, I guess with my tech hat on, is that if we go down that route, it's going to be come clear very quickly that there are different Ipv4 parameters that need to be configured, e.g. SIP server, don't have Ipv6-capable SIP, have to run over IPv4, they are going to have to configure that. If that is an actual requirement, clearly not using DHCPv6. Alain: in softwire this is about having a CPE that has to somehow bootstrap and get network connectivity. Softwire is not concerned with what happens next. Next is service discovery issue. Then you need to establish services like SIP, VoIP, etc, all those services have to use DHCP to come up. If services offered only on IPv4, they will have to discover IPv4 parameters, so I believe it should be DHCPv4, not DHCPv6. Suresh: that is not the question about this draft. Decision has to be made independent of this draft. How does DHCP wg believe v4 parameters should be configured over a v6 link. Ted: dhc has already said we don't want to configure DHCPv4 parameters over DHCPv6. Suresh: we don't want four different softwire-related options for doing the same thing. Francis: in fact the v6/v4 is not so simple. the resource with lifetime is the port set, not the address. You can't have the same thing with DHCPv6 as v4, DHCPv6 is not supposed to assign IPv4 addresses. Just reusing DHCPv4, just using address renew on lifetime in fact port set. Ted: so you are you saying address and port set should have different lifetimes? Francis: the attributes attached to the address when in fact it was used for the port set. Yong Cui: I think softwire should focus on IPv6 transition use, and we also need the DHCP option and softwire and other wg may also define DHCP options. But I think this draft focus on min way trans of DHCP options, resource allocation, what is the resource, should be originally IP address, but this draft comes up with new resource, port set, important changes, should belong to DHC working group. Second part, if we need to allocate IPv4 related resource, should belong to DHCPv4. Ralph Droms: tech hat. I have a security concern or op concern about this particular option. I think it's security considerations section, should not be used on a shared medium, bc if you get two devices trying to use shared port set it will break things. I think that needs to be a whole lot stronger, needs to be as many mechanisms in place to ensure that this does not escape ... So I would like to see this as an address and port set that isolates the option. Ted: How would that prevent that from happening? Ralph: avoid yet another error case where regular IP... well, maybe not. Nevermind. Woj: I just want to say I think that main context for this is running IPv4 over IPv6 infrastructure. Most operators interested shoudn't be necessarily steered to deploy new types of DHCPv4 servers. If soltuion is possible on DHCPv6, then for this particular configuration, configuration parameters, we should do this. Ted: so your argument is people whouldn't have to upgrade their DHCPv4 servers? Woj: there are existing options for NTP, etc. If what they really want is tateless 4over6, port sharing, just using DHCPv6 or DHCPv4 option could be okay. Ted: it seems like a pretty weak argument. Woj: the argument is if you are running that service, and have no additional needs, you do not need to deploy a DHCPv4 server. Ted: the problem we have is that what you are saying is that. I have two worries. O ne, the simple worryo fgreat, now we have two solutions to one problem. Second is, ... Ole: to reply to ralph's concern, given that there are only specific link layer types that can support this, you could tie provisioning of that l2 link with the prot and adddress, if you tie that together as a package you lessen the options of that getting out. Alain: this is running always over tunnels, and both tunnels are p2p tunnels, so there is no reason for having this on a shared media. Ted: here's the problem we have, we have three minutes left. Don't think we're going to come to a resolution on this. Alain: you gys have been saying for eyars all IPv4 done with DHCPv4, all IPv6 done with DHCPv6. Why are we changing this? Ted: hopefully we're not, dhc working group is not in a position to say... if the *only* use case is configuring the prefix, then DHCPv6 is okay, but I don't think that's true, and because that's not true, then we're going to wind up in a situation where we're going to say you can use this dhcpv6 option, but only in this one restricted case, and otherwise you have to use dhcpv4 option, so now we're going to have to implement two things instead of one. And the other thing, which I couldn't remember earlier, if the DHCPv6 option gets standardized, if softwires comes to us and says we're never going to configure anything but the prefix, then two or three months later somebody's going to come from somewhere, maybe not softwires, we have this need, we're configuring IPv4 with DHCPv6, now we have this need to configure SIP service for IPv4 with DHCPv6, and that would be bad. Suresh: I think personally that DHCPv4 is the right hting to do, but in softwire it may not be sufficient. We need IPv4 prefix to get passed down. Do you want us to define a DHCPv4 option for that? We haven't had that discussion. Alain: the transport is independent from what is transported. Ralph: one more thing for discussion on mailing list, AD hat off. I won't give you the person who thought of this idea, I'll take the heat. To keep these things separate and allay my concerns about where these things might wind up, a DHCPv6 option that carries a string of bits that's 32 bits long and is used as a label for the tunnel would satisfy my concern about these addresses floating off to where they're not supposed to be, would give SPs way of configuring tunnel with DHCPv6. We do have DHCPINFORM for IPv4. Ted: they don't have a reserved port. Ralph: Well, that's what we talk about on the mailing list. Hong dea speaking, from China Telecom. I suppose this draft, sometimes we prefer dynamic port range assignment from BNG to user. We are talking about port tange be announced DHCPv4. If we don't want assign any IPv4 option through DHCPv6, we have to define new option for DHCPv6. It's not a problem in IPv6, it's only a transport layer. Suresh: my point is if the dhc has a strong preference, let's go ahead and put it somewhere. If we can come to some agreement from dhc saying this is the way to do configuration parameters, we can go with that. Ted: maybe we should just write a document that says what we think the solution is, consensus is the way to go. Suresh: I talked to Ole, he says he's willing to write it with me, I can send you a straw man. Ted: we're over our time slot. Alain: quick comment. people don't have dhcpv4 server, I think this argument is bogus. If they need to have dhcpv4 to get other parameters like SIP...